QA of software has rapidly become a complex industry with:
Automation tools, Devops, CI/CD, test strategies and test plans, agile methodologies, source control and performance tools.
Yet, at the heart of it all is a basic skill that gets overlooked, the art of designing test cases.
As we focus on the various approaches, tools and technologies that we are required to test, test design gets lost.
So, what is a test case?
Simply put, it’s an experiment that either proves or disproves a fact.
However, designing them correctly and ensuring that they provide a specific answer to the question is a learned skill.
Not everyone can do it, and the tester/analyst mindset is what drives good test design.
Systems are now very complicated, and the risk of failures are high. Everything is integrated and connected to multiple other systems. Strong technical understanding, curiosity, communication skills and attention to detail are vital. The bigger the change the bigger the risk.
Essentially the test designer wants to ensure that as many scenarios as possible are covered.
In turn, this will increase the chances of finding issues or defects and decrease the risk of the product going live with critical or major defects.
Here are some issues we regularly encounter;
- Non-existent test cases
- Test case content too general and high level, more a requirement than a test
- Written as one line that depends on an in-depth system knowledge and “David” who wrote the tests in 2011 has now left the organisation.
We teach our consultants the following best practises for Test case design:
Test cases can have one or many steps.
Test steps contain several components.
- Pre-requisite/starting point
- Action to take
- Expected result
- Actual result
The prerequisite or starting point, sets the context for the test, i.e. what state the system or application needs to be in before running the test. Some system knowledge can be assumed, but it is always better to inform the tester with as much information as possible. The person writing the test should assume that they will not be the person executing the test.
When the test steps are followed, they provide the tester with an instruction (action to take) and details of what the system should do as a result (expected result) of that action.
If the expected result and the actual result are a match, then the test step is passed, and test execution moves on to the next step.
If the expected result and the actual result do not match, then the test has failed and the reason for the ‘failure’ needs to be investigated.
Breaking the test case structure down into simple steps allows you to properly identify which step has failed and pinpoint the exact issue. A good test case structure gives more details about the defect and why it failed.
Well documented test cases that are reviewed by other persons within the business and updated regularly will save time and effort as the QA function matures.
Storing test cases in a central location where they can be found with ease and naming the test case correctly will make is easier to identify and understand its objective.
Providing expected results, Positive and Negative, and details of post conditions will make it easier to determine if the test has passed or failed.
In Essence a well written test case should be:
- Easy to understand and execute
- Accurate
- Easy to trace as per requirements
- Repeatable
- Reusable
In essence, investing time upfront in creating effective test cases and establishing a company accepted standard will increase the effectiveness of the entire testing process and save you time and effort while increasing efficiency. Strong test design = Reduced risk.
