A test case is a set of conditions defined by the tester to determine whether the system performs or not under the given condition. The test case is written so that to check the working of an application under different constrained environment. This ensures that each and
A test case is a set of conditions defined by the tester to determine whether the system performs or not under the given condition. The test case is written so that to check the working of an application under different constrained environment. This ensures that each and every feature is of the application is working
In today’s blog, we will see in detail on how to write the test case effectively. Below are the 11 factors that have to be considered for writing a test case effectively.
1. Naming the test case
Naming the test case plays a major role in making it perfect and easy to access. It is always a good practice to name the test cases in a way that it makes sense to anyone who is going to refer the test cases in future. A best practice is naming the Test Cases to represent the module name or functional area we are going to verify in that test case. This can be explained with an example.
Consider a project called “Online” which has a functional area named “Login”
Now, we want to write a test case to verify a simple check whether the user is able to login to the website using an email and password.
To keep things simple, instead of naming the tests as TC_01, we could use the below-naming convention for our test case so that it gives a brief idea of what the test is for just by looking at its name.
TC_01_Online_Login_Success or, TC_01_Online_Valid_Case and likewise…
Quick Note: As a best practice, name the Test Cases to represent the module name or functional area you are going to verify in that test case. This will really help the peers or new testers.
2. Test Case Description
The description of the test case is where we mention all the details about what we are going to test, and the particular behaviour being verified by the test. What needs to be verified, which test environment it needs to be verified in, which test data is to be used – all this information goes into the description.
We should enter as much information as possible in the Test Case description! Mainly, we would find the below information in a well-written test case description:
• Test to be carried out / behaviour being verified
• Preconditions and Assumptions (any dependencies)
• Test Data to be used
• Test Environment Details (if applicable)
• Any Testing tools to be used for the test
3. Assumptions and Preconditions
While writing test cases, we should communicate all assumptions that apply to a test, along with any preconditions that must be met before the test can be executed.
Below are the kind of details we would like to cover as part of this section:
• Any user data dependency (e.g. the user should be logged in, which page should the user start the journey, etc.)
• Dependencies on test environment
• Any special setup to be done before Test Execution
• Dependencies on any other test cases – does the Test Case need to be run before/after some other Test Case?
We should add as much information as possible for any conditions to be met before running the test case.
Quick Note: Include as much information as possible for any conditions to be met before executing the test case.
4. Test Data Input
Identifying test data can be really a time-consuming activity – many times test data preparation takes most of the time in a testing cycle. It may sometimes need we create a test data afresh as creating a new data might take lesser time compared to identifying it
Also, we can give Test Data to be used for the Test Case within the test case description or with the specific Test Case step. This saves a lot of time in the long run as we won’t have to hunt a new test data every time we need to execute the test.
If the test only involves some values to be verified, we can opt to specify the value range or describe what values are to be tested for which field. We can do the same for negative scenarios as well. Testing with every value is impractical so we can choose a few values from each equivalence class which should give good coverage for the test. We could also decide to mention the type of data which is required to run the test and not the real test data value. This applies to projects where the test data keeps on changing as multiple teams use it and may not be in the same state when we use it the next time.
5. Cover all Verification Points in Test Design Steps
Another important part of a well-written test case is the properly defined Test Case Steps covering all the verification points for the behaviour under test.
The Test Design Steps should not only cover the functional flow but also each verification point which must be tested! By comparing the Test Case steps with the artefacts (Requirement Documents, Use Cases, User Stories or Process Maps) given for the project, we can make sure that the Test Case optimally covers all the verification points.
6. Expected Result
A well-written Test Case clearly mentions the expected result of the application or system under test. Each test design step should clearly mention what we expect as the outcome of that verification step.
So, while writing test cases, mention in detail about the page/screen we expect to appear after the test and, any changes we expect to be done to any backend legacy systems or Database. We can also attach screenshots or specification documents to the relevant step and mention that the system should work as outlined in the given document to make things simpler.
7. Divide Special Functional Test Cases into Sets
For effective test case writing, we should consider breaking down the Test Cases into sets and subsets to test some special scenarios like browser specific behaviours, cookie verification, usability testing,