How to write good Test Cases with examples
Test cases are an integral part of the testing process. But how can one write good test cases? They are used to verify that when a software application is being tested when it comes in contact with input, the output is what is expected.
The test cases are executed by a tester. The tester should have enough knowledge about the software being tested so that he/she can identify the prerequisites that are needed to proceed with the execution of the test cases. Having sufficient knowledge is key because it saves time, effort and money for both the individuals executing the test cases and also for teams who have to write test cases.
This information can help them know what value each hypothesis they write should have so that they don’t waste time implementing solutions not applicable or not suited for their use case.
Prerequisites are to be satisfied before the test case can be executed.
A test case generally has two parts:
1) Inputs
They describe what should happen when they are given different inputs — these will be given in different combinations to see if they produce the correct output. For example, one input might be “One plus One” and another input might be “2 minus 1”. These inputs would be combined with all other possible inputs to see which ones produce the desired results.
2) Outputs
describe what an application should produce when given a certain input. For example, if the input is “One plus One” the expected output would be “Two”.
Most Test cases are generally created or written by Quality Assurance/Quality Control (QA/QC) testers. However, programmers also document test cases for themselves to ensure that they are testing each part of their application.
The difficulty in writing good test cases lies in the fact that creating good test cases requires thorough knowledge of the application’s normal behaviour — without knowing this, you can’t know if your tests are covering enough input combinations or putting the application in strange circumstances which you don’t expect it to work properly.
Tips to write good test cases
1) Avoid test repetition — it is difficult to determine if you have covered all possible input combinations or not. It is even harder to determine if a program has worked properly for each scenario.
2) Verify the application works properly under different conditions — this helps ensure that your application will work properly after a change has been made to it. For example, if a calculator is being tested and the programmer implements a new feature that doesn’t work as intended, the users of that calculator can check whether it works as expected or not by running tests created before and after the change was implemented, this is known as regression testing — see more here.
3) Have someone else read your test cases(peer reviews) — this can catch errors in logical thinking as well as typos that may have been introduced when writing test cases manually.
4) Consider a test-driven development approach — this allows the test cases to be created by developers so that they can create a complete set of test cases for a demo/prototype rather than manually creating all the scenarios the software has to be tested against.
5) Tests should be simple and easy to understand.
6) Tests should be easily identified by the title — Avoid writing vague titles like “Test for Input” or “Test for Output 2”. Keep in mind that your goal is to communicate what the test case does to the reader in the most concise manner possible.
7) Never assume any test scenarios — user stories, acceptance criteria or use cases should be written to describe expectations of the application. Do not write test cases without considering these as they can lead to you executing incorrect tests. Covered by other tests is a good Cucumber term, i.e., this scenario covers all those scenarios which are already written in the past
8) Create a standard testing template for the team to follow — this can help keep the team members consistent in their test cases.
A proper testing plan should contain Minimum Viable Product (MVP), User Acceptance Testing (UAT) and User Acceptance Testing with Regression Testing (UAT+R).
Best practice to write good test cases:
1) In most cases, Test cases should be written against the requirements and not against the design.
Let’s take a look at some examples of good and bad test cases for the same scenario. Here we have a webpage that needs testing on basic login — logout functionality.
Good Test Cases:
Let’s take a look at the same scenario but for bad test cases
Good test cases are easy to understand and specify clearly what is expected when input is given to the software. They are also easy to read because they are properly written. Bad test cases leave it difficult for testers, developers, and even managers to determine how tests were written or what they should do when testing them.
Can you spot the differences between the good test cases and the bad test cases?
What details should be in a test case?
- A test case should provide specific input and then expected results.
- What software was being tested
- Test pre-requisites — what should be set up before the test begins(e.g login, user registration etc)
- They should contain the date, names of testers and developers
- Location of where test was being performed(give web links, or app locations and how to access them)
- Test steps that should be taken to run/replicate the test
- An Acceptance Criteria(AC) for when the test should pass/fail — this is very important as it defines the validity of the test being performed
- What tool and environments to execute it — for example, which devices, operating system etc
- Requirement specifications for the feature under test
- Nature of the test case (positive/negative test, manual, automation)
- Timelines for the tests to be done
- Priority of the test in question
Test cases should also be written in a way so that the reader understands what the goal of the test is.
They should have supporting pictures or screenshots so that testers can easily identify them — this ensures that they are not executing something which they are not supposed to be doing.
Originally published at https://senseitechtips.com on October 15, 2021.
