Quality starts with the question.

The first quality check is a conversation

A backlog item can look complete while creating different expectations. ‘An administrator must be able to approve a change quickly’ leaves open who qualifies as an administrator, which change is involved, what counts as fast and what happens when something fails. A test at the end cannot repair those missing decisions.

Quality Engineering therefore starts before the first line of code. The team examines the outcome someone needs, the risk that matters and the evidence that creates confidence. Testing becomes a way to understand the work at its source rather than a final inspection.

Turn a wish into an expectation you can examine

A useful question connects user, context and consequence. Do not begin with the proposed solution. Describe the moment in which someone needs to move forward, then make boundaries and dependencies visible together.

An initial version for approving a change could look like this:

As an authorised administrator
I want to review a proposed change,
so that only checked changes are applied.

When I approve, I can see what changes and for whom.
I cannot confirm when required information is missing.
Every decision can be traced afterwards.

We trust this when function, authorisation,
error handling and audit information demonstrably work.

Examine more than the happy path

The functional outcome is only one part of the expectation. ISO/IEC 25010 defines a product quality model with nine characteristics that can support requirements, test objectives and acceptance criteria. It helps teams ask not only whether something works, but how reliable, secure, usable and maintainable it needs to be.

OWASP ASVS can make the same conversation more concrete for security. It provides verifiable security requirements for web applications. The aim is not to adopt every item blindly, but to choose deliberately based on risk and context.

One vague request can then become a connected set of expectations: who may act, which information is required, how the system handles failure, which evidence is retained and how the experience remains useful in less than ideal conditions.

Review the work before it can run

ISTQB includes reviews of requirements and backlog items in static testing. Those reviews can find ambiguity and inconsistency before executable software exists. Just as valuable, product, design, development and quality build a shared understanding.

A useful refinement therefore produces more than acceptance criteria. The team states its assumptions, connects each important expectation to a risk and decides how that expectation will become visible or measurable. Sometimes that is an automated check. Sometimes it calls for a security review, an accessibility evaluation or observation with real users.

Five questions for every refinement

These questions are small enough for a regular conversation and sharp enough to reveal hidden work. They do not all need to end up in one document. They do need to produce decisions the team can retrieve and verify.

1. Whose problem are we solving, what is that problem and in which situation does it occur?
2. Which assumption or risk makes this change uncertain?
3. Which roles, data, dependencies and boundary cases affect the outcome?
4. What observable evidence will show that the expectation is met?
5. What must we learn before building becomes the most expensive way to find the answer?

The question remains part of the system

A strong question does not disappear when the ticket moves to done. It remains recognisable in the design, code, checks and production feedback. When the context changes, the team can see which expectation needs to be examined again.

That is quality built in: deciding together what reliable enough means before trying to fight uncertainty with more testing afterwards. The first question becomes the start of a continuous connection between intent and evidence.