Table of contents
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
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 when you keep repeating tests. It is even harder to determine if a program has worked properly for each scenario. So avoiding repetition ensures your test cases are lean and deliver maximum value.
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) π€
Peer reviews help to 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 π
It’s very useful as it can help keep the team members consistent in their test cases by following a format that works for the entire team.
Good Test Cases are the foundation that is used to create proper test plans, i.e., test cases are used to decide what should be present in the test plan, therefore creating a good plan is essential for maintaining high-quality software.
Good tests cover all functionalities that are required for the application being tested and ensure that these applications implement all necessary functions.
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:
| Test Case # | Test Case Description | Pre-requisites/ Special Conditions | Test Steps | Expected Results/ Acceptance Criteria | Test Results | Comments | Test duration | Test Priority |
| 1 | A user should be logged in to the dashboard when they login with the correct username and password | – User should have correct login credentials | – Go to the test webpage – Login with the correct username and password – Click the Login button | The user should be redirected to the dashboard | PASS | 20 mins | High | |
| 2 | Users should get an error message if they log in with incorrect credentials – username | – Go to the test webpage – Login with the wrong username and correct password – Click the Login button | User should get an incorrect username error displayed | FAIL | No error was displayed | 10mins | High | |
| 3 | Users should get an error message if they log in with incorrect credentials – password | – Go to the test webpage – Login with the wrong password and correct username – Click the Login button | User should get an incorrect password error displayed | FAIL | No error was displayed | 10mins | High | |
| 4 | A user should be logged out when they click the logout button | – User should have correct login credentials | – Go to the test webpage – Login with the correct username and password – Click the Login button – Click the top left where the username is displayed – Click Logout | Users should be logged out to the main page, if they attempt to click the back button, they should not be able to go back to the dashboard | PASS | 21 mins | High |
Let’s take a look at the same scenario but for bad test cases
Bad Test Cases:
| Test Case Description | Pre-requisites/ Special Conditions | Test Steps | Expected Results/ Acceptance Criteria | Test Results | Comments | Test duration | Test Priority |
| User login | Login to the web app | User to be logged in | PASS | 20 mins | High | ||
| User login fail 1 | Login to the web app with a different username | Error on the page | FAIL | 10mins | High | ||
| User login fail 2 | Login to the web app with a different password | Error on the page | FAIL | 10mins | High | ||
| User logout | Logout from the web app | User to be logged out | PASS | 21 mins | High |
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.
Conclusion
Test cases are an important part of software testing. They give the testers, developers and managers a way to see what they expect and what they should be doing in order to determine if their software works properly.
Therefore, creating good test cases is an essential job for anyone in the software testing fraternity – it allows you to create a complete test plan for your application which can be used by developers and QA/QC testers to ensure that every aspect of the application has been thoroughly tested.