Test Case
A Test case is a set of conditions or variables in which a tester will conclude whether an application or software system is functioning acceptably or not.
It may take many test cases to ascertain that, a software program or system is ready to be released.
Reasons for writing Test Cases:
- To confirm thorough test coverage of the application.
- To offer reliability in assessing the test effort
- To enhance output during test execution by decreasing the “understanding” time during execution
- To help the testers avoid missing out certain test conditions
Test Case acts as the starting point for the test execution.
There are levels in which each test case fall in order to avoid duplication efforts.
Level 1: Basic test cases are written from the available specification and user documentation.
Level 2: In this stage test cases are written based on actual functional and system flow of the application.
Level 3: Some Test cases are grouped to create/write a test procedure/test suite.
Level 4: Automation of the project, to reduce human interaction with system and thus QA can focus on current updated functionality rather than regression testing.
Test Cases Types:
[Figure: Types of Test Cases]
Writing Effective Test Cases:
For writing good test cases the tester should follow some essential tips:
- Understand the domain and Business Needs
- Tester should have a good knowledge of the domain and a clear understanding of the business needs per customer specifications.
- Study all requirements.
- Clear understanding of what he/she wants to test for the requirement.
Also Read: Test Design, Test Suite, Test Script, Test Plan
Elements of a Test Case
Below is a list of items that a test case template contains:
- Test case ID: This is a unique ID for each test case.
- Test priority (Low/Medium/High): Test priority can be low, medium or high. Test priority should be set by reviewer.
- Module Name: Mention name of the main module or sub module being tested.
- Test Designed By: Name of the tester who designed the test cases.
- Test Design Date: Date when the test cases are written. This will be useful to track updates and maintain versions.
- Owner: Name of the tester who executed this test. To be filled after test execution.
- Test Execution Date: Date when test executed.
- Test Case Title/Name/Description: Describe the functionality in words that is being tested by executing the particular test case. E.g. verify login page with valid username and password.
- Test Summary/Description: Objective: Describe test objective in brief.
- Test objects: An unambiguous feature or module is being test
- Product: Name and very short description of product being tested.
- Test Environment: mention the environment in which the product being tested.
- Pre-condition: Any prerequisite that must be fulfilled before execution of this test case. List all pre-conditions in order to successfully execute this test case.
- Dependencies: Mention any dependencies on other test cases or test requirement.
- Test Steps: List all test execution steps in detail. Write test steps in the order in which these should be executed. Make sure to provide as much details as you can.
- Test Data: Use of test data as an input for this test case. You can provide different data sets with exact values to be used as an input.
- Expected Result: What should be the system output after the test execution? Describe the expected result in detail including message/error that should be displayed on screen.
- Post-condition: What should be the state of the system after executing this test case?
- Actual result: Actual test result should be filled after test execution. Describe system behavior after test execution.
- Status (Pass/Fail): If actual result is not as per the expected result, mark this test as failed. Otherwise update as passed.
- Notes/Comments/Questions: To support above fields if there are some special conditions which can’t be described in any of the above fields or there are questions related to expected or actual results mention those here.
- Add following fields if necessary:
- Defect ID/Link: If test status is fail, then include the link to defect log or mention the defect number.
- Test Type/Keywords: This field can be used to classify tests based on test types. E.g. functional, usability, business rules etc.
- Requirements: Requirements for which this test case is being written. Preferably the exact section number of the requirement doc or information from traceability matrix.
- Attachments/References: This field is useful for complex test scenarios. To explain test steps or expected result using a vision diagram as a reference. Provide the link or location to the actual path of the diagram or document.
- Automation? (Yes/No): Whether this test case is automated or not. Useful to track automation status when test cases are automated.
Test cases can be considered as building blocks for Test scripts. Hence it very important to have all the necessary information in a test case description.
Do let us know if you agree with this information and help us keep this information relevant.