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
![Testing1.jpg]()
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".
![Testing2.jpg]()
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:
- 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.
- Study the all requirements
The Tester needs to have a clear understanding of what he/she wants to test for the requirement.
- Maintain the Risk and Query register
Ask Question on requirements for clearing the doubts with developers and mitigate the risks, if any.
- 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.
- 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.
- 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.
- Do not Assume
Do not assume functionality and features of your software application while preparing test cases. Stick to the Specification Documents.
- 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.
- 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.
- 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.
- 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.