To write and prepare effective test cases, testers and QA engineers should review the software specs documents carefully and raise as much queries as they can.
The purpose of Software Requirement Specification Review is to uncover problems that are hidden within the specification document. These problems always lead the software to incorrect implementation. So following guidelines for a detailed specification review is suggested:
1. Always review specification document with the entire testing team. Discuss each point with team members.
2. While reviewing specification document, look carefully for vague/fuzzy terms like – “ordinarily, most, mostly, some, sometimes, often, and usually” and ask for clarification.
3. Many times it happens that list values are given but not completed. Look for terms: "etc., and so forth, and so on, such as." And be sure all the items/list values are understood.
4. When you are doing spec review, make sure stated ranges don’t contain unstated/implicit assumptions. For example: “The range of Number field is from 10 to 100.
But is it Real, Hex or Integer? Ask for Clarification.
5. Also take care of vague/fuzzy terms like - skipped, eliminated, handled, rejected, processed. These terms can be interpreted in many ways.
6. Take care of ambiguous pronouns like – “The ABC module communicates with the XYZ module and its control flag is set.” But whose control flag?
7. Whenever a scenario/condition is defined in paragraph, then draw a picture of that in ait to understand and try to find the expected result.
8. In the specification document, if a scenario is described which hold calculations, then work on its calculations with minimum two examples.
9. If any point of the specs is not clear then get your queries resolved from the Business Analyst or Product Manager as soon as possible.
10. If any mentioned scenario is complex then try to break it into points.
11. If there is any open issue (under discussion) in the specs (sometimes to be resolved by client), then keep track of those issues.
12. Always go thru the revision history carefully.
13. After the specs are sign off and finalized, if any change come, then see the impacted areas.
Also Read:
SPONSORED LINKS
Comments :
0 comments to “Software Requirement Specification document Review Guidelines and Checklists”
Post a Comment