Search the web. You’ll find a plethora of content created on “How to Write the Best Test Cases”. Though, how many of them actually pinpoint the mistakes made while writing test cases that can bring down your app?
Not many.
Using our technical expertise, we decided to review thousands of test cases and ask our QA engineers to help us create a list of the most common mistakes that testers are likely to commit while writing their test cases.
Here is the list:
Writing Test Cases Covering Multiple Independent Sub-Functionalities
Writing multiple test cases is mostly considered inappropriate by testers. As a replacement, they tend to combine various requirements in one test case. This initially saves them from a lot of effort. However, they do not realize that doing this increases their work burden.
To explain it in more simple words, take an example of regression testing. During regression testing, testers are required to select a test case and integrate all the sub-functionalities, even in case the mistakes don’t negatively impact any area. As a consequence, unnecessary efforts will be required. To avoid this ambiguity, a tester can break down the requirements into individual testable units. This process is called making test cases ‘atomic’.
Skip Important Steps
When writing test cases, we observed that a majority of testers skip important steps that according to them are too obvious to compose. This situation occurs at the initial stages when users are shifted to the first screen that appears in the beginning of the testing process. It takes them longer to identify ways to reach to a particular screen, as coherence and continuity goes missing.
This creates difficulties for the Quality Assurance team. They can’t make a chain of the events and wonder what led to the undesired outcomes.
Writing Test Cases Focusing Only on Positive Scenarios
The main aim of a developer is to make programs that perform unfailingly. During an app testing process, it is important for us to also include negative cases regardless of the stage (initial, middle, and end) it is at. This demonstrates that the app works as expected and its behavior is observed and tested properly.
Writing Steps in a Very Difficult Language
For creating effective test cases, use easy-to-understand English language. This is because using technical jargons might not be well understood by all the testers and this leads to unnecessary hindrance among team members.
Using Passive Voice
You are recommended to use active voice. This is because the conciseness and clarity of the test case suffers in passive voice. Therefore, active voice phrases like “run ABC command”, or “Do this” are preferred while writing test cases.
Writing Only Test Cases- Not Thinking Anything Regarding Execution
Test cases are written when the application is not completed. Therefore, the testers have to base their test cases on FSD (Functional Specification Document) that further leads the teams to write test cases thoughtlessly. As a result, the test data does not exist in the system at the time of the execution. So, it is required to be created. To overcome this difficulty, you are required to think regarding real-world aspects and data conditions to run this test case while execution.
Stopping Yourself After Creating a Test Suite and Getting It Signed Off
The best practice is to create a test suite and then consider it a starting point for a version of the app being tested. As a result, you wouldn’t need to update the entire test suite. You simply update the type and get the baseline for that app. Keep all the earlier test case forms in your central repository.
Writing Test Cases That Cannot Be Traced
Traceability is important in every step of development and testing. No one will assist you in selecting the right test cases required for fixing defects. Traceability can help you easily help you map your relevant test cases with your requirements. However, in some test management tools, the mapping is offered as a default feature. Take Kualitee as an example! Kualitee gives you the ability to easily import your test cases.
Just in case of absence of any test management tool, a simple excel spreadsheet can be utilized to check traceability.
Writing Test Cases Without a Clear Focus
The main objective of creating a test case summary is to give an overview of the test conducted. It should be somewhere in the middle neither too non-methodological not too technical. Hence, it should on point and focused.
Writing Unmaintainable Test Cases
Picture a scenario where the requirement alters at the end of test case writing. In this case, the tester should be able to modify the affected test cases. The change request will perhaps have the affected requirements and the tester should be able to trace them back to the test cases, but only if the test cases are well defined and can be easily traced.
