Call for Volunteers (experienced testers) to trial Preemptive Testing

 Check out the trial-reports and PT-resources pages.
 Volunteer or request more info by email to

Testers can do more than discover symptoms of human error i.e., implementation defects, they can discover the causes of these defects. Preemptive testing (PT) focuses on identifying and mitigating mistakes made during the development of requirements, designs, and implementations. The primary goal is to identify and mitigate the causes of major requirements defects.


When defective requirements contribute to significant system failures or expensive rework, consider using a preemptive testing strategy.

Assign the responsibility for significantly reducing requirements defects to software testers. Their job is not to develop requirements, but to identify the human causes of requirements defects and mitigations for these defects. In many organizations, no one “owns” requirements defect prevention and detection, but identified ownership is much more effective than project team ownership.

This added responsibility will require a focus on requirements quality as well as code quality, a broader understanding of requirements and their development, and a variety of new collaborative skills. It will also significantly increase the organizational value of testing, leverage the inherent strengths of skilled testers, and reduce requirements volatility.


Requirements defects can account for most of the defect costs on a project because they are plentiful and expensive when detected late. IBM and Bell Labs studies showed that 80% of all product defects are created during requirements definition. Many software problems begin with defective requirements that then breed defective designs, data, code, tests, and documentation.

The cost of a requirements defect discovered in production, is the total cost of:

  • Implementation failures, ranging from annoying to life-critical
  • Implementation defect isolation
  • Patches or corrections to designs, data, code, tests, documentation, and requirements
  • Change control and configuration management
  • Reverification and validation
  • Redistribution
  • Causal analysis
  • Hazard mitigation

But the cost of detecting the same defect during requirements development, is only the total cost of:

  • Early detection
  • Causal analysis
  • Hazard mitigation

Improved requirements is a natural side-effect of test strategies that entail early test design. Preemptive testing aims to make it a primary effect.


Before committing to PT, baseline your reality by performing human causal analysis on significant system failures happening during development or production. If  PT could help, monitor the number, impact, and nature of requirements defects.

To use preemptive testing, testers must:

  1. Learn
    • requirements fundamentals, including types, forms, and specification alternatives
    • types and human causes of requirements defects
    • causal analysis of major system failures
    • techniques for checking requirements
  2. Identify your requirements defects based on defects discovered by:
    • requirements checking
    • design or implementation checking
    • analysis of major failures
  3. Identify causes of the mistakes leading to your requirements defects
  4. Identify and implement mitigations for causes of major requirements mistakes
  5. Monitor and report mitigation effectiveness
  6. Repeat steps 2 – 5
See the implementation recommendations under the PT-Resources tab.