How to Write a Test Case

Last Updated: February 16, 2023

A test case in software engineering is a single step or a series of steps to verify the correct behavior/functionality of certain features of an application. A test case basically determines whether the application or software system is working as it is supposed to. The point of writing test cases is to help standardize the testing process and to minimize arbitrary or ad-hoc approaches.^{[1]
X
Research source} It may take many test cases to verify that a software system has been sufficiently examined and scrutinized before it is released.^{[2]
X
Research source}

Method 1

Method 1 of 2:

Preparing to Write a Test Case

1
Consider whether a test case already exists. Before writing a new test case for your module, find out whether there are already existing test cases that test the same component. This can be a real time saver!
- If you do find existing test cases, consider updating test case, rather than writing a new one.
2
Know the characteristics of a good test case. Being aware of what constitutes a good test case will help you write a better and stronger test case.^{[3]
X
Research source} These characteristics include:
- Accuracy: The test clearly articulates the purpose.
- Tracing: The test is capable of being traced to requirements.
- Repetition: The test can be used to do the test as many times as necessary.
- Re-usability: The test be reused if necessary.
- Independence: Every test case you write should be able to be performed in any order, without any dependency on other test cases.
- Concision: The description of a test case should be simple and clear and have no extraneous steps or words. A tester should be able to understand it by reading it one-time over. The description should use action words, like "do 'x'" and "do 'y'."
Advertisement
3
Consider the different scenarios possible before writing. Concentrate on what could happen with the product when being used by a customer. Think about this carefully and design your test(s) accordingly.^{[4]
X
Research source}
- Scenarios should be concise. The goal of a test scenario is not to provide a lot of specific details, but to instead convey a specific idea about testing a particular case.
4
Give your self sufficient writing time. Because scenarios and cases form the base for future test cases and testing, you need to give yourself enough time to write a quality test as well as time to have the procedure thoroughly reviewed.^{[5]
X
Research source}

Method 2

Method 2 of 2:

Writing a Test Case

1
Select a tool for writing a test case. Excel spreadsheets are highly recommended for writing basic test cases and for manually testing them.^{[6]
X
Research source}
- When you plan to automate test cases, then get the licensing for tools like Test Director. There are also a number of tools that can be downloaded freely on the Internet.^{[7]
  X
  Research source}
2
Write a test case with your chosen tool. This will allow you to keep track of the case and its related data.^{[8]
X
Research source} A good template includes:
- Serial Numbers: This is the test case count.
- Test Suite ID: This is the ID of the test suite to which this test case belongs.
- Test Case ID: The ID of the test case.
- Test Case Summary: The summary or goal of the test case.
- Related Requirement: The ID of the requirement this test case relates/traces to.
- Prerequisites: These are any prerequisites or preconditions that must be fulfilled before executing the test.
- Test Procedure/Steps: This is the step-by-step procedure to execute the test. Be very detailed and specific here as this is the most important component. Each step can be written very directly using key words such as "enter," "verify," "click", "login", etc.
- Expected Result: The anticipated result of the test. While writing test cases, note what page/screen you expect to appear after the test.You could also attach screenshots or specification documents to the relevant step and note that the system should work as outlined to help simplify the step and anticipated result and to make the process easier to follow for the tester.
- Actual Result: This is the result of the test after it is performed.
- Status: This is the status that will occur in the test, e.g. "Pass" or "fail". Other status can also be used, such a "Not Executed" if testing is not performed and "Blocked" if testing is blocked.
- Remarks: Here you can add any comments on the test case or the execution of the test case.
- Created By: This is the name of the creator of the test.
- Date of Creation: This is the date when you execute the test.
- Executed By: This is the name of the person who actually carried out the test.
- Date of Execution: The date you performed the test.
- Test Environment: The systems in which the text was executed. Here you'd note, for example, the operating system and the web browser you used.
3
Write a basic test case statement.^{[9]
X
Research source} There is a typical format for these statements:
- Verify [what is being tested].
- Using [tool name, tag name, dialog, etc.] Instead of "using", you can also use "entering" or "selecting", depending on the situation of your particular test case.
- With [conditions of the test].
- To [what is returned, shown, demonstrated]
4
Review written test case. Your job isn't quite over once you've written the test case; you still need to review everything that has been written and evaluate that all of the steps are clear and comprehensible and that the expected results match those steps.^{[10]
X
Research source}
- You can review the case yourself and assess any gaps or missing areas by putting yourself in the role of Tester. But you can also have your test case reviewed by peer testers (known as ‘Peer Review’), developers, product owners or any relevant stakeholders.^{[11]
  X
  Research source}