In the software testing process after requirement analysis and test plan we have a Test design phase. In this phase we need to write the test cases from different test scenarios as per the requirement of an application. Test cases are instructions for testers to follow to ensure programs are functioning properly. Test case writing converts user requirements into a set of test conditions and descriptions that indicate how a system is functioning. Applications must be tested through these test cases to find out how the system behaves under all possible conditions. A clear understanding of application and the testing process can make writing test cases that identify defects easier.
While writing such test cases we need to follow some factors that make it perfect for all the perspectives. Here are some factors to get through the process.
Writing test cases in an effective manner is a very important thing. Many people think that writing too many test cases covers all the use cases. But in actuality it increases the load of the resource and also wastes too much time. So we need to think effectively while writing test cases so that it provides maximum coverage with fewer test cases. It could be further improved by dividing them into subsets like there is such test cases be common for some test scenarios.
Test cases should be written in simple words. No complex things should be included regarding inputs and outputs of the test case. For that everyone involved in the test case writing process should use the same format for designing them. We should aim to write them in a way that even a non-technical person can also understand the purpose of a test case.
Before writing a test case we should have a proper understanding of a requirement. For example, there could be many common things in each application that are sure to bring out errors. For that we did not need to handle it specially.
Test cases should be written in a way that they become reusable units for the future for creating new test cases. Testers can refer to the previous test cases to create the new one that makes it easier. So while creating a test case we should also keep in mind that it might be reused in a different scenario, a different but similar project. It saves time and efforts of resources.
5. Regression testing
When new features are added old test cases should be rerun to make sure nothing tested has affected and outputs are the same as expected. These regressive test cases are part of test case policy. When test cases are re-run, some may give unexpected results which may not always be because of new changes in the code but rather a test case that is inappropriate under new criteria. Therefore, having regressive testing in mind it would help rewrite a test case when changes are made
6. Self review
After test cases are written, review it from tester perspective, Verify that the test case appropriately addresses the scenario and would be easy to execute. Make sure the test case is understandable to everyone and the results are appropriate.
7. End–user perspective
Software testing provides user quality software. Errors that are found through test cases are removed during the testing process. When writing a test case, think of the end-user and how the user experience would be affected should the test case fail to cover a scenario from the end user perspective.
Most test cases are written to test the features offered by an application. However, it is also necessary to test for not-features, i.e. those abilities of the software that should not exist and may be used to exploit the application. These kinds of test cases are part of exploratory testing.
Use of proper management tools and systems is important for test cases because the count of test cases increases very fast. So it is important to use a proper management tool from the beginning. We can use simple spreadsheets or specialised tools which are available in the market as per our budget to manage test cases more effectively.
10. Peer review
If you review the test cases which are written by yourself then no matter how many times you go through it. It is possible that you will not find anything. For this, peers should review the test cases from the others or developers for the better result. After review is done by others, the tester should make the changes that are suggested. It makes our test cases more reliable and consistent.
11. Backward Approach
Initially when we write a test case we have expected the result or the output, and we write in that aspect to get that output. But in the backward approach instead of thinking what the result would be for a certain input, we can think of what inputs could be for a certain output. In this way, we can try with invalid inputs to get the same output.