34
It depends
There are many factors that decide whether a test is "good" or "bad" (useful or not) - some examples are:
A test is more likely to be good if it surfaces new information about the performance of the software
The happy path tests you do when you're exploring new functionality become much less good once that functionality is stable, but can be ...
28
Great question.
Every test has a value and a cost. Its value is its ability to reduce risk. Here are some ways that a test can be valuable:
Impact. Detecting high-impact bugs is more valuable than detecting low-impact bugs, which is more valuable than not detecting any bugs.
Diagnostic value. A test that narrows down the cause of a bug is more ...
25
Yes, while rather crude and possibly not the most graceful of test cases, such 'abusive' test cases are an important tool in stepping off 'happy path' thinking and testing.
Effectively a test like this is a crude load/response test.
While in theory it shouldn't happen in the real world environment, the fact that a bug was discovered with such abusive ...
17
A requirement is typically a general statement, whereas a use case is typically a specific statement implied or derived from the requirement. A requirement may map to multiple use cases. A scenario might be a set of background assumptions that put a use case in context, or it might be grouping of use cases.
Here is a contrived example. The requirement is ...
12
For the REST service testing Postman and HttpMaster are good tools. It supports dynamic parameters, validation of response data, various data viewers, etc. If you are looking for performing load testing of the REST services than Grinder and JMeter open source tools can be considered.
This data is taken from the post
Tools for REST webservice testing
10
Telling the interviewer what is less important than telling them why. They asked for the two best cases - not just a list of cases. This means that you need to explain to them why these cases are "better" than the many other cases you could have offered up. It doesn't matter if you give good answers if you cannot also explain why they are good answers.
A ...
10
User acceptance test (UAT) criteria (in agile software development)
are usually created by business customers and expressed in a business
domain language
https://en.wikipedia.org/wiki/Acceptance_testing
I don't think Field Length Validation has anything to do with User acceptance testing. Maybe the business should write their own tests.
Never the ...
answered Apr 29 '19 at 12:11
Niels van Reijmersdal
31.2k3 gold badges49 silver badges115 bronze badges
9
There are at least two (conflicting) ways to think about this:
Whether you provide a default depends on the context. If you provide a default, you should be prepared for people to select it even when it's the wrong selection. This is particularly true for user interfaces that require lots of inputs.
For example, my company's application has an online ...
8
It's really no different than any other test case.
Set up conditions:
Check actual result against the expected result
So you'll need a list of all the error messages in the system and the conditions that make these errors appear
If you want to really test them out then use the FAILURE mnemonic as detailed here.
8
The short version - It depends
The longer version
There are merits to both approaches. Some general heuristics:
Everything in one document is a priority - if your company believes it is important that testers have all the information they need in the test case document, then they will want business logic in the test cases.
DRY is a priority - if your ...
8
Most of the question (and answer) isn't specific to API testing; combinatorial explosion is a problem whenever you have a function that takes multiple inputs.
So, first, you'd need to understand how the API interacts with the backend service. Is it actually doing anything, or is it just passing a call on to some other program? If so, was any testing of ...
8
In my experience, it's down to the tester(s) for the same reason that developers can't test their own work. You can't find your own faults. That said, I don't think it'd hurt for you to test as well... but you need to draw the line somewhere.
QA are independent and, whilst you're working towards the same goal, should have a different approach. ie, you do ...
8
In our company we believe in "checks and balances", so whole process is a balancing act between following major forces:
business management, who requires major features and sets priorities
business analyst, who understands the customer needs and mental models, writes story requirements
developer, who understands the code, and also writes tests (unit, e2e ...
7
Considering your description, the clarifications can be given as :
Requirement : It is the changing need of the stakeholders which is tried to fulfil by the development team at the time of developing the product
Use case : After the requirements are clear, then the use cases can be designed/decided which will clear the overall flow of the system to ...
7
Think it this way:
Test case = is a set of conditions under which a tester will determine
whether an feature can function as expected.
Test specifications = well defined conditions that will define test
results.
Test procedure = how a test is carried out, what to do for step 1,
step 2 and etc
Test design = how a test is conceived from ...
7
While studying for the ISTQB exam, I have shrinking down to a more summarised text to help me understand and remember the topics at the exam.
Here's a bit of what I have shared in my blog last year.
Before all that you will need a TEST CONDITION.
What is a test condition?
A: An item or event of a component or system that could be verified by one or more ...
7
It depends.
To decide whether you are going to reference other test cases to avoid writing the same sets of steps multiple times, you need to consider:
the audience - If your test cases are written for unskilled manual testers who are expected to execute them without much if any thought, you may be better off with redundancy.
usage - if testers are working ...
7
A good test produces information whose value outweighs the cost of the test.
6
It is hard to say what your workflow will be. I've worked a few SDET/QA jobs, and it really seems to vary quite a bit. I'll try to cover some of my experiences, though, and hopefully that will be helpful.
Everyday Things
I usually like to start my day with a little bit of blackbox, just to get my brain into motion. I'll spend a little while every morning ...
6
I had the same issue when migrating tests from a legacy tool to TFS. It was simply not possible, independent of any choices offered by Excel and TFS (really, I tried them all and wrote a 43 page document about my test conversion efforts).
Finally I was able to workaround the issue like this:
In TFS, switch to the grid view
In Excel select all steps and ...
6
I am working as QA and also to write a test cases of mobile application and web application. In Both Application required in writing the test cases are :
Test case id
Test case(unit to test)
Preconditions
Input test data
Priority
Steps to be executed
Expected result
Actual result
Pass/Fail
Comments
and for more information see below of reference link in ...
6
Headless Chrome is not stable yet in comparison to "full" Chrome.
In my opinion there will always be problems with headless vs phantomjs (and others) vs full versions. And so there will always be place for phantomjs (and others) in the world of automated testing.
Consider your choice wisely.
Few possible limitations of Headless Chrome:
Headless mode is ...
6
Data:
Use each of the following payment methods: X, Y, Z, ...
Procedure:
....
....
....
I don't see how any professional tester won't understand that you want to validate with each payment method.
If for any reason the tester to whom you are writing this documentation gets confused, a 30-seconds conversation with you probably will solve any ...
6
What would you do?
I'd most likely hand in my notice working in such an environment.
Is there any reason why this has to be overengineered? Not in my opinion.
I'd simply create one test case and trust my coworkers. They should be able to communicate when it's needed.
Of course getting access to all three systems is a priority (it is really necessary in fact)...
6
Every person can have unlimited conversations and unlimited messages
in a conversation.
These are two use cases:
Every person can have unlimited conversations
Every conversation can have unlimited messages.
As one of the testing principle is :
Exhaustive testing is not possible .meaning you cannot test all the possibility for a system as the combination ...
5
www.slideshare.net/ErolSelitektay/test-link-jira-soap-integration and http://blogs.fcoos.net/integrate-testlink-with-jira/
give steps on how to configure JIRA on your Teslink.
Before you start, ensure you have Testlink 1.9.5 or above and JIRA 5.2 or above.
Test Link Screens involved:
The steps in the second link are:
Install and configure Testlink as per ...
5
If you have specifications that say a confirmation must be displayed, the test fails.
If you have user requirements or user expectations that there will be a confirmation dialog, the test fails.
In the situation you describe, I would create a bug from the test, but it would have a lower severity rating because it doesn't interfere with functionality. The ...
5
Requirement Traceability matrix maps the user requirements with the test cases. In simple words, the matrix helps in determining if all the requirements have been covered(i.e there are test cases which can be traced back to the requirements).
There are 3 types of RTM:
Forward:Requirements->Test Cases
Backward: Test Cases->Requirements
Bi-...
5
The question asks whether other test cases can cite smoke testing as a dependency. The answer depends on the purpose of the dependency.
If the purpose is to narrow down what your test cases need to cover, that's fine.
If the purpose is to exploit a side-effect of the smoke test, e.g. to take advantage of configuring the software in a certain way, or ...
5
When possible it is generally a good idea to break out the different assertions into separate cases even though they will repeat the same setup/teardown. The reason is that when one of the assertions fail you want to know that specifically, with text that describes the test and the specific assertion and if bundled together with other assertions, that may ...
Only top voted, non community-wiki answers of a minimum length are eligible
