Testability requirements and verification work

Testability and verifiability are a category of nonfunctional requirements. Expert Roxanne Miller explains how these concepts fit into software requirements engineering.

Our QA group has asked us to add a special report to a history load process so they can validate it. They want to make sure we give them what they need. It is not going to be used in production -- only for testing. Should this be a nonfunctional requirement or a functional requirement? And do you have any advice for how to write the report?

I can certainly appreciate an argument for considering special reports needed during testing as functional requirements, because some may view the creation of the report as a function the system delivers. However, I would side with industry experts and put in my plug for nonfunctional requirements. Specifically, testability, also referred to as verifiability, is a category within nonfunctional requirements.

What are testability requirements?
Testability is (1) the degree that characteristics that provide for testing exist, and (2) the degree to which economically feasible tests can be devised for determining whether the developed software will satisfy the requirements. (IEEE Std 610.12)

Alternatively, verifiability is the measure of effort to verify (via tests, inspection, demonstration and analysis) specified software operation and performance. (See Jeffrey Grady's book below for more.)

Testability requirements identify the process of verifying through inspections, tests, demonstrations and analysis that the designed and constructed product can meet the requirements.

Verification work is accomplished through comparison. That is, the characteristics of an element under inspection are compared to a predetermined standard. In making this comparison, Jeffrey Grady suggests applying four commonly accepted test methods as described in the following table: test, analysis, demonstration and examination.

Test A test element is subjected to a controlled series of stimuli, and the article response is monitored and compared with a standard, expected, predicted result.
Analysis Product item features are examined for compliance with requirements by understanding its elements and relations.
Demonstration A product is manipulated in accordance with a pre-determined process and specific set of instructions and the actual results are compared with planned results.
Examination (Inspection) A person (usually aided by tools) or mechanical device used for gauging and measurement, compares the measured or observed characteristics of an object with a standard.

Requirements gathering resources:
Software requirements specification and the IEEE standard

Reduce software defects with requirements-based function testing

Functional and nonfunctional requirements

For more information about testability and verifiability, see also: Customer-Centered Products: Creating Successful Products Through Smart Requirements Management, by Ivy Hooks and Kristin Farry. Chapter 10 presents an in-depth view of verification, including the following:

  • Table 10-1. Certain Words Flag Unverifiable Requirements. This is a lengthy list of example unverifiable words and possible solutions for writing clearer requirements.
  • Table 10-2. Rewrites for Unverifiable Requirements. A list of example poorly written requirements with suggestions for clearer statements.
  • System Requirements Analysis by Jeffrey O. Grady. Grady defines the activities that make up the Requirements Verification Management process in Chapter 6.6.

    Dig Deeper on Software development lifecycle

    Cloud Computing
    App Architecture