Tips For Writing Test Cases

Introduction

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.