Field Note: From Testability to Assessability

Testability is a familiar quality concern. A testable product makes it easier to create conditions, observe behavior and determine whether the product works as expected. Interfaces can be controlled. States can be inspected. Failures can be reproduced. Relevant outputs can be observed. Without testability, testing becomes slower, more expensive and less reliable.

But if quality is understood as something broader than conformance to specified behavior, testability may not be enough. A product may be testable and still be difficult to assess.

Testing Produces Only Part of the Evidence

Testing can provide evidence about many important product qualities. It can show whether functionality behaves as expected, whether performance meets defined thresholds and whether known risks have been addressed before release.

But some quality claims cannot be judged fully through testing alone:

  • Can users complete their actual work successfully?
  • Does the product create the intended business outcome?
  • Does it remain reliable under real operating conditions?
  • Can incidents be understood and recovered from?
  • Are decisions and changes traceable?
  • Do larger customers use the product differently from smaller ones?

These questions require evidence from operation, users, support, monitoring and business results.

The broader question is therefore not only:

Can this product be tested?

It is also:

Can its important quality claims be assessed?

Assessability Extends Testability

Assessability is the product’s ability to provide the evidence needed for a meaningful quality judgment. Testability is part of this. So are observability, inspectability, traceability and measurability.

A product is more assessable when we can understand:

  • what it is doing;
  • why it behaved as it did;
  • whether important conditions were met;
  • how users experienced it;
  • whether intended outcomes occurred;
  • what changed when results differed from expectations.

This evidence does not appear automatically:

  • If auditability matters, relevant actions and decisions must be traceable.
  • If resilience matters, failures and recovery must be observable.
  • If performance matters, representative measurements must be possible.
  • If business outcomes matter, product behavior must be connected to suitable outcome measures.
  • If usability matters, there must be ways to observe real user success rather than only confirm that screens function.

Evidence Has Design Implications

intent → quality claim → required evidence → design implication → assessment

This means that evidence should not always be considered after the product has been built. The ability to produce evidence may itself need to be designed into the product.

The chain becomes:

Suppose the product reference model states that a service must recover reliably after a failure. That claim implies evidence about detection, interruption, recovery time and data integrity. Producing that evidence may require monitoring, logging, controlled failure mechanisms and clear state information. Without those capabilities, the expectation may remain valid but difficult to judge.

The same applies beyond technical qualities. If the intended outcome cannot be measured or observed, the organization may never know whether the product delivered the value that justified building it.

Quality Must Be Assessable by Design

Testability asks whether evidence can be produced through testing. Assessability asks whether sufficient evidence can be produced to judge the product throughout its lifecycle. That includes evidence before release, but also evidence from real use and operation. A product that cannot produce evidence about its important qualities cannot be assessed with confidence.

Designing for assessability does not mean instrumenting everything or measuring every possible outcome. It means beginning with the important claims in the product reference model and asking:

What would we need to know in order to judge this?

Sometimes the answer will be a test. Sometimes it will be a log, a metric, an audit trail, an operational signal or feedback from users.

Testability helps us determine whether the product can be tested. Assessability helps us determine whether the product can be understood.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *