Ivan Gavrikov

Test Case Definition

ISTQB defines a test case as A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

Test cases are step-by-step instructions to the tester to perform validation of specific aspects of the system or application functionality.

Why Do We Need A Test Case?

Test case should help us to check the product without a knowledge of all documentation. Well-written test-case would save a lot of time and effort for testers.

Test Case Attributes

Every test case should include:

• Unique test-case ID – required for comfortable organizing and navigation in our test-suit.
• Title/Name – main idea of the test case. Short description of the essence.
• Preconditions – description of the conditions that are not directly related to functionality being tested, but have to be done. For example, the user has to sign up before leaving the comment on the website. It means for “Creating comment” the test-case must have done with the preconditions: “user is signed in” and “user is authorized”.
• Steps – the description of the actions to lead us to the expected result.
• Expected result - it is the result that we expected to observe after the test case is done.

It is not necessary, but preferably to add into a test-case an attribute “edit history” – it can ease your work. A concise journal of changes with fields: who, how, when was editing the test-case.

What To Know Before A Test Case Creation?

At first, every completed test-case gives us one of the three results:

1. Positive result: if the actual result is equal to the expected result;
2. Negative result: if the actual result is not equal to the expected result. In that case the bug was found;
3. Blocked to test: if after completing one of the steps in the test-case we are faced with the issue and further testing is not possible. In this case we have found an issue as well.

Second, a test-case should check only one functionality and there has to be only one expected result for it.

What A Test Case Should Not Includes

1. Dependencies of another test cases

You should avoid using dependencies because every connected test-case can be deleted or modified and, in that case, it can be hard to understand how to pass the test-case with links to other test cases. Also, if dependencies were used, you might have the wrong feeling that the tested product is tested enough because of the passed dependent test cases.

2. Unclear description of the steps and expected result

The second point is already answered by itself. If steps and expected result description are not clear enough it would be a blocker to pass the test-case.

3. Lack of necessary information to pass the test-case

A test-case must have all the information to successfully pass it. For example, if we check any website’s login page, we need to have a login and password. Otherwise, we will not have the ability to pass the login scenario and other test cases can be blocked either.

4. Excessive number of details

You should avoid adding excessive descriptions to your test-case. For example, if we check the ability to create a comment, we don’t have to write where the login fields are. Redundant information complicates the passing of a test-case.

Best Practice for writing good Test Case

1. Test Cases need to be simple and transparent:

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

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

2. 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 is easy to use and operate. A tester must create test cases keeping in mind the end user perspective

3. 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

4. Do not Assume

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

5. Ensure 100% Coverage

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

6. Test Cases must be identifiable.

Name the test case id such that they are identified easily while tracking defects or identifying a software requirement at a later stage.

7. Implement Testing Techniques

It is not possible to check every possible condition in your software application. Software Testing techniques help you select a few test cases with the maximum possibility of finding a defect.

• Boundary Value Analysis (BVA): As the name suggests it’s the technique that defines the testing of boundaries for a specified range of values.
• Equivalence Partition (EP): This technique partitions the range into equal parts/groups that tend to have the same behavior.
• State Transition Technique: This method is used when software behavior changes from one state to another following particular action.
• Error Guessing Technique: This is guessing/anticipating the error that may arise while doing manual testing. This is not a formal method and takes advantages of a tester’s experience with the application

8. 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.

9. Repeatable and self-standing

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

10. Peer Review.

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

While drafting a test case to include the following information

• The description of what requirement is being tested
• The explanation of how the system will be tested
• The test setup like a version of an application under test, software, data files, operating system, hardware, security access, physical or logical date, time of day, prerequisites such as other tests and any other setup information pertinent to the requirements being tested
• Inputs and outputs or actions and expected results
• Any proofs or attachments
• Use active case language
• Test Case should not be more than 15 steps
• An automated test script is commented with inputs, purpose and expected results
• The setup offers an alternative to pre-requisite tests
• With other tests, it should be an incorrect business scenario order

Test Case Examples

Below is a format of a standard login Test cases example.

Test Management Tools

Test management tools are the automation tools that help to manage and maintain the Test Cases. Main Features of a test case management tool are

1. For documenting Test Cases: With tools, you can expedite Test Case creation with use of templates
2. Execute the Test Case and Record the results: Test Case can be executed through the tools and results obtained can be easily recorded.
3. Automate the Defect Tracking: Failed tests are automatically linked to the bug tracker, which in turn can be assigned to the developers and can be tracked by email notifications.
4. Traceability: Requirements, Test cases, Execution of Test cases are all interlinked through the tools, and each case can be traced to each other to check test coverage.
5. Protecting Test Cases: Test cases should be reusable and should be protected from being lost or corrupted due to poor version control. Test Case Management Tools offer features like
   
   
   • Naming and numbering conventions
   • Versioning
   • Read-only storage
   • Controlled access
   • Off-site backup

Links used

1. ISTQB Glossary - Test Case
2. Writing an effective Test Case
3. How to Write Test Cases in Software Testing with Examples