A Test Case is a documentation which specifies input values, expected output and the preconditions for executing the test.
A sequence of one or more sub tests executed as a sequence because the outcome and/or final state of one sub test is the input and/or initial state of the next. The word ‘test’ is used to include sub tests, tests proper, and test suites.
Objectives behind writing and executing the Test Cases:
Below mentioned are some of the objectives behind running the test cases.
1. Find the defects in software products
2. Verify that the software meets the end user requirements
3. Improve software quality
4. Minimize the maintenance and software support costs
5. Avoid post deployment risks
6. Compliance with processes
7. Help management to make software delivery decisions.
3. Improve software quality
4. Minimize the maintenance and software support costs
5. Avoid post deployment risks
6. Compliance with processes
7. Help management to make software delivery decisions.
Following are the typical design techniques-
1. Deriving Test Cases directly from a requirement specification or black box test design technique. The Techniques include:
- Boundary Value Analysis (BVA)
- Equivalence Partitioning (EP)
- Decision Table Testing
- State Transition Diagrams
- Use Case Testing
2. Deriving Test Cases directly from the structure of a component or system:
- Statement Coverage
- Branch Coverage
- Path Coverage
- LCSAJ Testing
3. Deriving Test Cases based on tester's experience on similar systems or Testers intuition:
- Error Guessing
- Exploratory Testing
How to write Test Cases for software:
Use a Strong Title
A good Test Case starts with a strong title. As a best practice, it’s good to name the Test Case along the same lines as the module which you’re Testing. For example, if you’re Testing the login page, include “Login Page” within the title of the test Case.
Include a Strong Description
The description should tell the Tester what they’re going to Test and include any other pertinent information such as the test environment, test data, and preconditions/assumptions.
Include Assumptions and Preconditions
You should include any assumptions that apply to the test and any preconditions that must be met prior to the test being executed. This information can include which page the user should start the test on, dependencies on the test environment, and any special setup requirements that must be done before running the test. This information also helps keep the test steps short and concise.
Keep the Test Steps Clear and Concise
The Test steps should include the data and information on how to execute the test. This is perhaps the most important part of a Test Case. Keep this section clear and concise, but don’t leave out any necessary details.
Include the Expected result
The expected result tells the Tester what they should experience as a result of the test steps. This is how the Tester determines if the Test case is a “pass” or “fail”.
Make it Reusable
A good Test Case is reusable and provides long-term value to the software testing team. When writing a Test Case, keep this in mind. You can save time down the road by re-using the Test Case instead of re-writing it.