While exploring whether system testing can be reframed as a specialized form of quality assessment, I stumbled upon another interesting possibility.
An assessment requires both an assessment model and a reference model. The reference model defines what the object is assessed against. The assessment model describes how evidence is gathered and evaluated.
If requirements form the reference model for testing, then what role do test cases actually play?
Over the years, I have encountered several observations that suddenly seem connected. I once heard that detailed test-case specifications add little value because they merely rewrite existing requirements in executable form. I have seen test-management tools embrace BDD and Gherkin, making test cases resemble structured requirements. I also remember the argument that testers who produce highly detailed test specifications are effectively performing business analysis.
Viewed separately, these observations seem unrelated. Viewed through an assessment lens, they may point to the same phenomenon. Perhaps many teams begin testing with an incomplete reference model.
The requirements describe the desired functionality, but leave important rules, examples, boundary conditions, exceptional situations and quality expectations unspecified. Testers then discover these gaps while designing tests and fill them by creating detailed test cases. In that situation, the test cases do more than describe how the product will be tested. They complete the description of what the product is expected to do. Part of what we call test design may therefore be delayed requirements analysis.
But this does not mean that every test case is simply a late requirement. A test case can contain elements from both sides of the assessment. The expected result, business rule or behavioural example may belong to the reference model. It describes what should be true. The selected data, execution conditions, observation points and comparison method belong more naturally to the assessment model. They describe how evidence will be produced.
A detailed test case may combine both:
- a missing expectation about the product;
- and a plan for gathering evidence about whether that expectation has been met.
This may explain why test cases sometimes feel ambiguous. They are treated as testing artefacts, but part of their content actually defines the criteria against which the product will be judged. The practical question is therefore not whether test cases are requirements or tests. It is whether we can distinguish the two functions.
When a tester discovers an unstated rule, edge case or quality expectation, should it remain hidden inside a test case? Or should it be added to the shared reference model so that product owners, analysts, developers and other stakeholders can review it?
If important expectations exist only in test documentation, the team may have two reference models: the requirements used to build the system, and the test cases used to judge it.
That separation creates avoidable risk.
Perhaps the value of many test cases is not only that they verify the product. Perhaps their deeper value is that they reveal what the reference model should have said in the first place.
Leave a Reply