Writing effective test cases is crucial to any software project, because it is the first step in any testing cycle. If anything goes wrong in this step, the impacts are extrapolated as you move forward in the testing cycle.

This blog is intended to provide the steps to writing effective test cases.

Here are the basics:

What’s a test case?

Test-Cases-Pt-1-1

Fig – 1: Documenting test cases in a test plan.

IEEE Standard 610 (1990) defines a test case:

(1): “A set of test inputs, execution conditions, and expected results developed for a particular objective, that exercises a particular program, path or verifies compliance with a specific requirement.”

Traditional approach:

Test cases are developed by individual testers based on use case, the feature, story or the requirement to be tested. The test cases contain a list of steps and the respective expected results. The test cases are normally written in a test management tool such as TFS, MS Excel or Word. There could be other metadata associated with a test case apart from the test case ID, test name, description, steps and expected results.

Inefficiencies in the traditional approach:

Listed below, are inefficiencies in the test case development:

1): Test cases are focused mostly on the functional requirements only.

Most of the test cases are functional in nature, directly deriving from the expected functional behavior mentioned in the feature or story. Non-functional requirements are barely mentioned in test cases.

2): Lack of perspective – the test cases are a reflection of the respective tester’s perspective only.

Test cases are written by a tester and only the tester’s perspective is the main source. Test Cases can be enriched if different perspectives are also factored in.

3): Disconnect between thinking test cases to writing test cases.

It is observed that the tester is more focused on writing the test case with all the required metadata that the test case repository expects, rather than spending more time thinking about test cases.

4): Inefficient reviews

Test case reviews are tedious and inefficient as the context and the essence of the test cases are not very clear given the complex reports generated by the test case repositories, and the flat hierarchy of the test cases.

Best Practice for writing effective test cases:

  1. Test Cases need to be simple and transparent:

Create test cases that are simple. They must be clear and concise, because the author of the test case may not execute them.

Use assertive language like: go to home page, enter data, click on this, etc. This makes understanding the test steps easy and the test execution faster.

  1. Create Test Case with End User in Mind

The ultimate goal of any software project is to create test cases that meet customer requirements and are easy to use and operate. A tester must create test cases with the end user perspective in mind.

Test-Cases-Pt-1-2

Fig -2: See things from different perspectives

  1. Avoid test case repetition

Do not repeat test cases. If a test case is needed for executing some other test case, call the test case by its test case id in the pre-condition column.

  1. Ensure 100% Coverage

Make sure you write test cases to check all software requirements mentioned in the specification document. Use a Traceability Matrix to ensure no functions/conditions are left untested.

  1. Do not assume

Do not assume the functionality and features of your software application while preparing test cases. Stick to the Specification Documents.

  1. Test Cases must be identified uniquely

Name each test case with a unique id so that they can be identified easily while tracking defects or identifying a software requirement at a later stage.

  1. Implement Testing Techniques

It’s not possible to check every possible condition in your software application. Testing techniques help you select test cases with a maximum possibility of a defect.

  1. Self-cleaning

The test case you create must return the test environment to the pre-test state and should not render the test environment unusable. This is especially true for configuration testing.

  1. Repeatable and self-standing

The test case should generate the same results every time, no matter who tests it.

  1. Peer Review.

After creating test cases, get them reviewed by your colleagues. A second eye can uncover defects in your test case design, which you may easily miss.

Conclusion:

The proposed approach described in this blog is a rapid, effective and efficient test case development. The inefficiencies prevailing in the traditional approach can be overcome by using other innovative tools and techniques like Equivalence Partition (EP), Boundary Value Analysis (BVA), and Path Analysis. If a tester is familiar with the system under test, they are able to write more effective test cases. Test cases should not focus only on the specifications given by the client, but also consider the user perspective. Effective test cases will definitely help the tester identify problematic loopholes in the application.

Reference Materials:

  1. IEEE Standards for writing test cases: https://en.wikipedia.org/wiki/Software_test_documentation
  2. Test case design techniques: http://www.softwaretestingbuzz.com/2012/01/test-case-design-techniques.html
  3. Quality Attributes. http://msdn.microsoft.com/en-us/library/ee658094.aspx