Requirement Specification document Review Guidelines | Techbirds

Posted on: May 22, 2014 /

Categories: Testing / Author Name: Vishal Tyagi

To 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. This is a part of defect prevention. 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 Decimal? 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 unclear pronouns like – “The ABC module communicates with the XYZ module and its value is changed to 1.” But whose value (of ABC Module or XYZ Module)? 7. Whenever a scenario/condition is defined in paragraph, then draw a picture of that in order to understand and try to find the expected result. If paragraph is too long, break it in multiple steps. It will be easy to understand. 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 through the revision history carefully.

13. After the specs are sign off and finalized, if any change come, then see the impacted areas.

546 total views, 2 views today

Share this On