Tips For Writing Test Cases


A Test Case is a document and has a set of conditions or variables under which a tester verifies whether an application or system software is working correctly or not, containing all possible scenarios to test the application as per the user specification or requirement.

Designing Test Cases

A test case is a detailed procedure that fully tests a feature or an aspect of a feature. Whereas the test plan describes what to test, a test case describes how to perform a particular test. You need to develop a test case for each test listed in the test plan. The following figure illustrates the point at which a test case design occurs in the lab development and testing process.
Create a test plan


A test case includes:

  • The purpose of the test.
  • Special hardware requirements, such as a modem.
  • Special software requirements, such as a tool.
  • Specific setup or configuration requirements.
  • A description of how to perform the test.
  • The expected results or success criteria for the test.

Test cases should be written by a team member who understands the function or technology being tested, and each test case should be submitted for peer review.

Organizations take a variety of approaches to documenting test cases; these range from developing detailed, recipe-like steps to writing general descriptions. In detailed test cases, the steps describe exactly how to perform the test. In descriptive test cases, the tester decides at the time of the test how to perform the test and what data to use.

Most organizations prefer detailed test cases because determining pass or fail criteria are usually easier with this type of case. In addition, detailed test cases are reproducible and are easier to automate than descriptive test cases. This is particularly important if you plan to compare the results of tests over time, such as when you are optimizing configurations. Detailed test cases are more time-consuming to develop and maintain. On the other hand, test cases that are open to interpretation are not repeatable and can require debugging, consuming time that would be better spent on testing.

Test Case Design

  • Test Case ID

    It is a unique number given to a test case in order to be identified.
  • Test description

    The description of the test case you are going to test.
  • Revision history

    Each test case has to have its revision history in order to know when and by whom it is created or modified.
  • Function to be tested

    The name of the function to be tested.
  • Environment

    It specifies the environment you are testing.
  • Test Setup
    Anything you need to set up outside of your application; for example printers, network and so on.
  • Test Execution

    It is detailed description of every step of execution.
  • Expected Results

    The description of what you expect the function to do.
  • Actual Results

    pass / failed
    If pass - What actually happens when you run the test.
    If failed - put in a description of what you've observed.

How do test case templates look like?

Software test case templates are blank documents that describe inputs, actions, or events, and their expected results, in order to determine if a feature of an application is working correctly. Test case templates contain all particulars of test cases. For example, one test case template is in the form of an 8-column table, where column 1 is the "test case ID number", column 2 is the "test case name", column 3 is the "test objective", column 4 is the "test conditions/setup", column 5 is the "steps Name", column 6 is the "expected results", column 7 is the "Actual results" and column 8 is the "Remarks".


All documents should be written to a certain standard and template. Why? Because standards and templates do help to maintain document uniformity. Also because they help you to learn where information is located, making it easier for users to find what they want. Also because, with standards and templates, information is not accidentally omitted from the documents.
Guidelines or Tips for writing test cases

For writing good test cases the tester needs to follow some necessary tips:

  1. Understand the domain and Business Needs

    The Tester has a good knowledge of the domain and a clear understanding of the business needs as per customer specifications.
  2. Study the all requirements

    The Tester needs to have a clear understanding of what he/she wants to test for the requirement.
  3. Maintain the Risk and Query register

    Ask Question on requirements for clearing the doubts with developers and mitigate the risks, if any.
  4. Test Cases need to be simple and transparent

    Create test cases which are as simple as possible. They must be clear and concise since the author of the test case may not execute them.
    Use assertive language like go to home page, enter data, click on this and so on. This makes the understanding of the test steps easy and test execution faster.
  5. Create Test Case with End User in mind

    The ultimate goal of any software project is to create test cases that meets customer requirements and is easy to use. A tester must create test cases keeping in mind the end user perspective.
  6. 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.
  7. Do not Assume

    Do not assume functionality and features of your software application while preparing test cases. Stick to the Specification Documents.
  8. 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.
  9. Test Cases must be identifiable

    Name the test case ids such that they are identified easily while tracking defects or identifying a software requirement at a later stage.
  10. Implement Testing Techniques

    Testing techniques must be used for effective testing. Suppose you encounter a scenario to test a good deal of values. In such a case apply both Boundary Value Analysis and Equivalence Partitioning techniques. This will aid in covering a good range of value and avoid unnoticed defects. In case the application has many pages/integrations then create test cases for each State Change by implementing the State Transition Technique.
  11. Peer Review

    After creating test cases, get them reviewed before moving the test cases into the test lab. Fixing or Incorporate review comments. Take approval and store test cases in the repository.

Up Next
    Ebook Download
    View all
    View all