Reviewing Software Requirements for Testability

Modern software development approaches like Agile and Scrum support a strong collaboration between all member of the software development team, software testers and business analysts included. Even if you don’t use a method like Behavior-Driven Development (BDD) or Specification by Example, checking the fact that you will be able to actually test your requirements is a good thing. In his article, Richard Ellison share some best practices to reviewing requirements for testability from the point of view of a software tester.

Testability is the degree to which a system, component, requirement, or design makes it easy to design, execute, and evaluate tests that reveal faults. High testability means faults are easier to find and diagnose; low testability makes testing slow, costly, and unreliable. Software systems built for testability let software development teams detect and fix defects earlier, shortening release cycles.

The main advice of this article is that the software testers should review requirements before the formal reviews and send questions to the business analyst in advance. Unanswered questions should be written down to have a reference point to get clarification with the larger team. He recommends documenting everything in requirements review meetings. He uses a spreadsheet and lists the requirement number and the comments. If a new requirement will be added, an additional row in the spreadsheet is added with the comments about the new requirement. You can add a second column to identify as testable or not.

Read the complete article about the best practices to review requirements for testability on https://www.softwaretestingmagazine.com/knowledge/best-practices-reviewing-requirements-for-testability/