Requirements Test Coverage

Ensuring that testing covers all requirements may not be as complicated as you think….if you have good requirements or use cases.  But, what if they are lacking or non-existent?  How do you gather requirements?  How do you plan test coverage?  The bottom line is that you still must plan test coverage.  Along with that, you must be able to provide metrics and statistics, even in the simplest form, that assures project sponsors test progress, and ensures that all testable features have been addressed.

Sources of Requirements

  • Interviews with project team; the business analysts, developers, business users, etc.
  • Prototypes, storyboards, wire frames, existing application (expecting modifications), etc.
  • Technical documents such as data models, flow diagrams, comments in existing code, etc.
  • Training manuals (expecting modifications), etc.

The “etc.” indicates that the above list is not exhaustive.  Rather, it indicates that you can assure test coverage without formal requirements or design documents in a decomposition form.

Decomposition

The definition of decomposition — No, not the process by which organic material is broken down into simpler forms of matter.  But rather, the process by which requirements are broken down into testable units from high-level to detail-level.  Think of this as outlining the book you read for your grade school reading class.  Structuring the decomposed test requirements into outline form provides the foundation for easy test reporting.

Test Matrix

Test Matrix is known by many names such as Validation Matrix, Traceability Matrix, Requirements Matrix, etc., but always includes a list of things that must be tested.  Each requirement from high-level down through the outlined detail-level requirement ideally would trace to a formal test case.

What happens if time doesn’t permit creating formal test cases? The matrix, can be used during testing to track coverage.   Include ability to mark pass, fail, not applicable, or, when left blank, would indicate not tested. 

Time Estimates

The matrix is a good method for providing accurate test time estimates.  Knowing the depth of coverage enables estimates for writing formal test cases/scripts and test execution

Start with a good Excel spreadsheet that contains columns for every type of information you will track, from the requirements, status, results, priorities, and what have you……….and derive the coverage metrics into charts and reports.

IQS can help you build the matrix to track your testing needs.

Comments are closed.