Test Case Design and Execution Tips

Test Case Design

Test Case Design

I have heard the phrase used in the testing community “A test case can only be considered a success, if it finds a bug”. I personally don’t agree with that statement, as in my opinion, there can be many different reasons for creating and executing a test. While, sometimes we may actively attempt to create test cases to find defects, I think that most of the time we are aiming to ensure the software is meeting our expectations in a positive manner.

Stand out from the Crowd!

40% OFF – Mobile App QA e-Learning Course

Order Now

When designing test cases, I often a take a three-phase approach; firstly, designing tests to ensure the software satisfies the original requirement in a positive way. Then, typically think from a negative (almost malicious) perspective, actively seeking out ways to ‘break’ the software. Lastly, I attempt to think ‘outside-the-box’. There are different ways to achieve this, but I often like to give myself the task of coming up with three alternate paths to take to achieve a certain result. While often, there may only be one path to take, it does get you thinking in a different way.

In my experience, I have seen also noticed that testers vary quite considerably when specifying an input value. Some will be specific and state the value to be entered, while others will be more vague and state something like “Enter a valid value”. I much prefer the latter, as it will effectively be a slightly different test each time it is ran. Also, most testers (including myself) tend to write one good test and then copy it to make similar ones. While this saves time, it does prevent tests being created that take different routes or approaches to achieve the expected result.

It’s not just designing tests that we can think in a different way, but also when we come to execute them too. When test cases are re-ran in the form of a regression test, testers often fall into the trap of just blindly following the test steps within each test case, checking the ‘Pass’ box as they go. While this is a valid exercise as part of a regression test, more could be obtained from it. We should expect the test cases to pass at this stage, as if a defect was found when originally executed, it should have been fixed and verified. But, what we could do when executing these ‘sure-to-pass’ test cases is to take a step back and look at original goal of the test case, and from there we can then perhaps achieve the same goal but by a different route.

By varying the journey we take to reach the goal and subsequent expected results, we are not only verifying the existing functionality has not been adversely affected, but we are also transforming a ‘stale’ test case into a ‘fresh’ test case. This different approach taken to testing push the boundary of the original test and may highlight issues that may have stayed undiscovered by simpler re-running the original set of tests.