In the world of software development, there's a development methodology called, "Test-Driven Development" aka ("TDD") where you basically write the test BEFORE you write the actual functional code. There are other tenants of TDD, but the notion that you write the test first is the main focus here.
By writing the test first, it forces you to look to see where your "goal posts" are.
I actually have no opinion on TDD other than to point out that it exists, and there are some principles with strong parallels in the FDA-regulated markets with respect to computer system validation.
The V-Model refers to the way in which (software) systems are validated and verified:
The only reason (I can think of) for why this is called a "V-model" is because someone is being clever with the Verification and Validation. But I digress.
The point of the V-model is that someone actually went through and documented what the users/stakeholders wanted. Then, they went through and figured out what functions match with those user/stakeholder desires. THEN, they went through and figured out how to make those functions happen:
You first write the URS, then the FS, then the DDS. After this planning phase is over, there's the testing phase during which time you draft the IQ, OQ (and sometimes PQ). And by the time you get to executing these tests, you may find nonsensical tests or deviations.
By writing the test first, it forces you to look to see where your "goal posts" are.
I actually have no opinion on TDD other than to point out that it exists, and there are some principles with strong parallels in the FDA-regulated markets with respect to computer system validation.
The V-Model refers to the way in which (software) systems are validated and verified:
The point of the V-model is that someone actually went through and documented what the users/stakeholders wanted. Then, they went through and figured out what functions match with those user/stakeholder desires. THEN, they went through and figured out how to make those functions happen:
- User Requirement Specification (URS)
- Functional Specification (FS)
- Detailed Design Specification (DDS)
That's the downstroke of the V.
The upstroke is the part where you go about proving that what you designed actually made it into the actual system. And the functions you said are available are actually available:
So in the world of computerized system validation (CSV, not comma-separated variable), the Installation Qualification (IQ) is what verifies that the items of the detailed design got into the system. So the battery of tests that prove the correct software configuration was inputted.
Operational Qualification (OQ) is the battery of tests that prove that the functions specified perform as specified. For example, if your functional specification says that your impeller speed has to operate between 60 to 255 rpm, you should have a test in your OQ that runs the impeller at the boundary and within that operating range.
- Installation Qualification
- Operational Qualification
So what does any of this have to do with test-driven design? Well, anyone who has validated a computer system knows that for the most part, the V is executed exactly as it's drawn: first the downstroke, then the upstroke:
You first write the URS, then the FS, then the DDS. After this planning phase is over, there's the testing phase during which time you draft the IQ, OQ (and sometimes PQ). And by the time you get to executing these tests, you may find nonsensical tests or deviations.
And the reasons may be that you ran into these issues is because you didn't start with the tests (IQ/OQ) first.
The TDD methodology is saying that you start with the URS (what the stakeholders/users want). Then you skip ahead and write what a passing test looks like (IQ and OQ). Then you go backwards and fill out the specification and perform the build.
The thinking seems backwards on first-pass, but it isn't without merit.
