Over the past few weeks, while working on assessment models for QA capability and Data Quality, I stumbled upon an idea that has been difficult to shake off.
The observation itself is surprisingly simple: the structure of a QA capability assessment and a system test is essentially the same. The only thing that changes is the object being assessed.
At first, this felt like an interesting analogy. The more I thought about it, however, the more it began to feel like something more fundamental.
Starting with System Testing
Most of us who have worked in testing have been taught a familiar model:
- Requirements define what the system should do.
- Test cases verify those requirements.
- Defects are reported.
- A release decision is made.
Nothing controversial there.
But viewed through a different lens, the process can be described in another way:
- Requirements define a reference model.
- Testing is an assessment process.
- Test results are evidence.
- Defects are findings.
- The test report is an evaluation.
- The release recommendation is decision support.
In other words, system testing can be described as a quality assessment of a software system. That may sound like a semantic distinction, but it has interesting consequences.
Looking Beyond Testing
Around the same time, I was working with assessment models for QA capability and Data Quality.
Those assessments typically look like this:
- Define a reference model.
- Gather evidence through interviews, reviews and metrics.
- Identify gaps.
- Evaluate current capability.
- Recommend improvements.
Structurally, the process is identical. The only difference is that the object being assessed is no longer a software system. Instead of assessing a product, we assess:
- A QA organization
- A data platform
- An operating model
- A security posture
- An architecture
The pattern remains the same:
Object → reference model → assessment activities → evidence → findings → evaluation → decision support
Once you see it, it becomes difficult to unsee.
Is QA Already Solving This?
One could argue that Quality Assurance and later Quality Engineering have already attempted to broaden testing into something larger. There is certainly truth in that:
Testing evolved from defect detection. QA expanded the focus toward process quality. Quality Engineering expanded it further toward prevention, automation and quality built into delivery. Yet even Quality Engineering remains largely anchored in the vocabulary of testing:
- Test automation
- Test coverage
- Test strategy
- Test management
- Test environments
The underlying mental model often remains:
Software → testing → quality
What if the model should instead be:
Object → assessment → evidence → quality evaluation
That is a subtle but important shift.
A Different Perspective on Testing
If assessment becomes the primary concept, testing becomes one assessment technique among many.
Consider the following examples:
| Object | Assessment Technique |
| Source Code | Unit Testing |
| Software System | System Testing |
| Architecture | Architecture Review |
| Data Platform | Data Profiling |
| Security Posture | Penetration Testing |
| QA Organization | Interviews and Document Review |
Different techniques, same assessment pattern.
This perspective also changes the questions we ask.
Instead of how many test cases have we executed, we ask: have we collected sufficient evidence?
Instead of what is our test coverage, we ask: which quality attributes have been assessed?
Instead of how many defects remain, we ask: what is our confidence level and residual risk?
These are fundamentally different conversations. They are also conversations that executives tend to understand much better than traditional testing metrics.
A Broader Quality Assessment Framework?
Perhaps the most interesting implication is organizational rather than technical. Many consulting organizations offer services such as:
- System testing
- Data quality assessments
- Security reviews
- Architecture assessments
- QA capability assessments
These are often positioned as separate offerings with separate methodologies.
But what if they are all instances of the same underlying discipline? A generic quality assessment framework could potentially provide:
- A common assessment model
- A common reference model structure
- A common evidence model
- A common reporting approach
- A common maturity model
The assessed object changes. The assessment pattern does not.
An Open Question
I do not yet know whether this idea is genuinely new or merely a reframing of concepts that already exist within Quality Engineering.
What I do know is that it has changed the way I think about testing. For years, I viewed testing as a discipline concerned with finding defects.
Today, I increasingly see testing as one technique for generating evidence about quality. That may sound like a small distinction. I suspect it is not.
If the observation holds, then perhaps testing is not the overarching discipline after all. Perhaps quality assessment is. And testing is simply one of its most visible techniques.
Leave a Reply