Test Case Review
The review should verify whether, the purpose, scope and the content of the test cases are correctly documented. These test cases cover all the positive and negative scenarios involved with the application and its performance.
o It should describe every input, action, or event and an expected response, to help determine if every feature / functionality of an application is working correctly.
o Proper understanding of requirements
o Impact areas are identified and brought under test
o Test data is correct and represent every possible class of the domain
o Test coverage is adequate
A. Review Checklist for Functional Test cases
1. Standards & procedures are followed
o Template [with info like Requirement reference, Description, Author’s name, Date created, Setup Procedure, Pre-requisites etc]
2. Identified test conditions (scenarios) with the Risk factor (if applicable)
3. Have all the scenarios specified in the requirement – both explicit and implicit, been converted into Test conditions?
4. Identified impact/related areas that could possibly be affected by the implementation of the requirement been identified
5. Test case Organization
6. Has equivalence partitioning been done? Have all the classes of the domain been identified correctly?
7. Generated Test data set
8. Have the boundary values, special values and invalid values been identified and included in the Test data set?
9. Has the Test data been embedded into the test cases?
10. Identified the required negative scenarios in the test conditions?
o Steps in appropriate sequence for each test scenario.
o Steps/Actions should state very clearly the sequence of actions to be carried out on the system by the user.
o All statements should be definite.
o Ensure that terms like “If”, “In case” etc are not used.
o Statements should be report format (should not have - I, we, you)
11. Identified tests by Error Guessing [Asking questions like what if…?]
12. Identified the Expected Results correctly
o Expected Results should clearly state how the system should respond to the user actions given in each step/action.
o Ensure that too many things are not included to be verified under one expected output.
o Ensure that separate cases are written for multiple verifications of the application’s behavior.
o Vague statements like “Appropriate message/value/screen” etc, should not be part of expected result.
o Every detail should be clearly spelt out.
13. Statements should be free from grammatical errors
B. Review Checklist for UI Test cases
1. Field Validation for all the fields
2. Look & Feel/Guidelines
3. Application/UI Navigation
C. Review Checklist for Database Test cases (if any)
Test Conditions
Example:
During Test Execution
PS: To take care of the defects those are not in the test case
Avoid duplication of defects
Defect Verification
There should be a peer review before a defect is closed.
Also,
1. Defects are found and the test cases status are set to Fail
2. When the defects come with a fix for retesting, it is not always updated in the sheet.
3. Postponed issues still show as fail in the test execution cycle and so, they had to be made as NA
The review should verify whether, the purpose, scope and the content of the test cases are correctly documented. These test cases cover all the positive and negative scenarios involved with the application and its performance.
o It should describe every input, action, or event and an expected response, to help determine if every feature / functionality of an application is working correctly.
o Proper understanding of requirements
o Impact areas are identified and brought under test
o Test data is correct and represent every possible class of the domain
o Test coverage is adequate
A. Review Checklist for Functional Test cases
1. Standards & procedures are followed
o Template [with info like Requirement reference, Description, Author’s name, Date created, Setup Procedure, Pre-requisites etc]
2. Identified test conditions (scenarios) with the Risk factor (if applicable)
3. Have all the scenarios specified in the requirement – both explicit and implicit, been converted into Test conditions?
4. Identified impact/related areas that could possibly be affected by the implementation of the requirement been identified
5. Test case Organization
6. Has equivalence partitioning been done? Have all the classes of the domain been identified correctly?
7. Generated Test data set
8. Have the boundary values, special values and invalid values been identified and included in the Test data set?
9. Has the Test data been embedded into the test cases?
10. Identified the required negative scenarios in the test conditions?
o Steps in appropriate sequence for each test scenario.
o Steps/Actions should state very clearly the sequence of actions to be carried out on the system by the user.
o All statements should be definite.
o Ensure that terms like “If”, “In case” etc are not used.
o Statements should be report format (should not have - I, we, you)
11. Identified tests by Error Guessing [Asking questions like what if…?]
12. Identified the Expected Results correctly
o Expected Results should clearly state how the system should respond to the user actions given in each step/action.
o Ensure that too many things are not included to be verified under one expected output.
o Ensure that separate cases are written for multiple verifications of the application’s behavior.
o Vague statements like “Appropriate message/value/screen” etc, should not be part of expected result.
o Every detail should be clearly spelt out.
13. Statements should be free from grammatical errors
B. Review Checklist for UI Test cases
1. Field Validation for all the fields
2. Look & Feel/Guidelines
3. Application/UI Navigation
C. Review Checklist for Database Test cases (if any)
Test Conditions
Example:
During Test Execution
PS: To take care of the defects those are not in the test case
Avoid duplication of defects
Defect Verification
There should be a peer review before a defect is closed.
Also,
1. Defects are found and the test cases status are set to Fail
2. When the defects come with a fix for retesting, it is not always updated in the sheet.
3. Postponed issues still show as fail in the test execution cycle and so, they had to be made as NA
1 comment:
very informative but this need to be more organized or categorized
Post a Comment