A quick guide to writing better test cases

This topic has been touched many times over on the internet; I'll leave out the advise of keeping simple, your test cases and the language of your test cases. Without going into methodologies and techniques used in testing, I'd like to outline a few principles of test case writing that you should bear in mind the next time you're writing test cases.

1. Design scenarios

Firstly, don't think of writing test cases.. :) Or anything related to test cases.
For the particular application / unit under test (AUT), take time to think through and identify possibilities of:

• Inputs - All possible inputs that can be given to the AUT. Your inputs can be data or a certain action to be performed, like clicking a button
• Outputs - All possible outcomes / behaviours of the AUT in response to the input 
• Trigger points - Conditions that when activated, cause the AUT to perform certain action(s)
• Alternate flows - When testing workflows, always ensure you identify flows other than the easy path / normal flow
• Error conditions - Conditions that cause a defined error to occur / be displayed

Once you have this wealth of information with you, arrange them in an order that makes sense to you. Do this and you'll have a whole new view of the various kinds of scenarios and cases to test the unit.
You could try mixing and matching to develop various combinations of scenarios. This can become overwhelming. In such a case, I would recommend that you use the Orthogonal Arrays or some form of pairwise combinations to select only those combinations that provide the most coverage.

The difficult part's done. :)

2. Identify and define dependencies and preconditions 

Failure to identify and document these during test planning will eat into your test execution time causing you to re-execute cases properly. If dependent on data from other teams, or on outage timings, make sure you document these for awareness.

3. Don't let a test case test more than 1 desired behaviour 

Using one test case to test multiple system behaviours is a good way of landing in trouble. Not only will you find it difficult in tracing the test case back to its requirements, you will also find it difficult to place where exactly a defect lies.

4. Write test cases that are independent of each other & executable in any order

One test case should not be dependent on any other test case as far as possible. What this does is reduce the number of test cases that could potentially be blocked in case of a defect. And in turn, you'll be better positioned to wrap up testing within a tight time frame.

I am a bit under the weather as I write this post. And hence have not elaborated too finely on the points.

Now that you are aware of the finer points of test case writing, be sure you don't commit these 3 common mistakes while testing.

Is your test phase dragging along? Identify and optimize these activities that slow you down.

Let me know what you think through the comments.

Till the next post,
Savio Saldanha

Please note that my team is available to undertake software testing assignments. You may reach out to bureauofquality@gmail.com with your needs.