Software Design Verification

Trying to understand Software Design Verification … A QA’s takeaway on reading the General Principles of Software Validation for the first time.
FDA gives guidance in the General Principles of Software Validation guidance document, but in general:
  • Testing at different levels: units, integrated units, software complete
  • Testing types: negative, combinatorial, fault injection, risk controls challenge, boundary, corner cases, stress, power fail/low/intermittent,
  • Software testing coordinated with system testing: What should software do when subjected to EMI? What are acceptable failure states? Mix coverage
  • Platform (and hardware) variants and OS versions:  Use risk analysis to determine impact of variants and/or versions, then scale.
  • Planning and understanding of software testing prior to shipment versus built-in self tests (i.e., if software configuration can change in the field)
  • Coverage of requirements, coverage of risk controls
  • Planned exploratory testing

Software Design Verification is not just to satisfy the requirements of design, though it starts there. Testing must also include actual use environment, or simulated environment, prior to design validation activities.

Software Design Verification is not a substitute for design validation

Software that has a direct effect on safety should be tested and verified with more scrutiny.


About the author

Joel is a quality systems associate and researcher for SoftwareCPR. After working for 7 years in the medical field with the United States Army, he now spends his time exploring tech development and programming. He is the father to two wonderful children and avid fisherman.

Corporate Office

15148 Springview St.
Tampa, FL 33624
Partners located in the US (CA, FL, MA, MN, TX) and Canada.