During quality assessments, I have often found myself making recommendations that seem to sit outside the testing domain. Instead of focusing only on test automation, test processes or testing skills, I sometimes recommend strengthening Product Ownership, business analysis and requirements capabilities.
At first glance, this may appear indirect. If the goal is better testing, should we not improve testing? Recently, while exploring testing as a form of assessment, I started to see a clearer explanation.
An assessment depends on a reference model: a structured description of what the assessed object is expected to be.
In product development, an important part of that reference model is expressed through requirements, acceptance criteria, business rules, quality expectations and other descriptions of what success looks like.
Requirements are not the complete reference model for system quality. Important expectations may also come from architecture, operational needs, regulation, user research, risk analysis and the intended business context.
But requirements work is one of the main ways in which those expectations are made explicit and shared. When that part of the reference model is incomplete, testing becomes harder.
Testers spend time clarifying expectations, identifying missing scenarios, discovering hidden assumptions and resolving ambiguities. Test design becomes partly an exercise in completing the model against which the product will later be assessed.
This creates an important distinction. Some testing problems originate within testing. The team may lack appropriate skills, techniques, environments, tools or automation.
Other testing problems are inherited from upstream. The team cannot assess the product efficiently because the expected outcome was never made sufficiently clear.
Improving the test process alone will not remove that second kind of weakness. This is why a quality assessment may need to look beyond the formal boundaries of testing.
The Product Owner and business analysts do more than produce user stories. They help clarify the purpose of a change, align stakeholder expectations, make business rules visible and determine what success should mean in a particular context.
They also help ensure that quality concerns are considered before implementation begins:
- What level of performance will be sufficient?
- Which failures would be unacceptable?
- Which users and operating conditions must be supported?
- Which assumptions still need to be validated?
- What trade-offs are acceptable?
- What evidence will be needed before the product can be judged ready?
These questions strengthen the reference model on which developers and testers both depend.
The effect is broader than better testability. Developers gain a clearer basis for implementation. Testers gain a clearer basis for evidence collection. Product Owners gain a better basis for prioritisation and acceptance. Stakeholders gain a more explicit understanding of the risks and trade-offs involved.
Seen this way, recommending stronger Product Ownership or requirements capabilities is not an excursion beyond the scope of a quality assessment. It may be a response to the actual cause of the observed testing weakness.
An assessment should not be constrained by the label attached to the problem. It should follow the chain of dependency far enough to identify what needs to improve. Sometimes that leads to test practices. Sometimes it leads upstream.
Perhaps some of the most effective ways to improve testing are not found within the testing discipline itself. They are found in the capability to define, align and communicate what success looks like before the assessment begins.
Leave a Reply