The expectation
What should happen in this situation? A clear description gives people the same question to discuss.
VERIFICATION
What can you check?
An expectation becomes useful when you can compare it with what happens. The limits matter as much as the result.
The observation
What actually happened? Compare the outcome with the expectation and describe the difference.
The boundary
A check covers particular situations. A passing check does not establish that an entire system is free of defects.
A result concerns the situations that were examined. The conditions and limitations belong with its explanation.
Beyond a green tick
An outcome needs context.
‘It works’ leaves plenty of questions open. What was done, with which data, in which version and under what conditions?
A useful check begins with a specific expectation. You can then discuss what was actually observed. A difference calls for investigation. The software may behave differently, but the expectation or the data used may also be unclear.
As a client, you need to be able to follow both sides. Seeing only the outcome does not tell you which question was answered. Reading only a description does not tell you what happened in the software.
Questions for a review
What should accompany the result?
Use these questions when discussing a delivery, a change or a check report. They help you understand which conclusions a result does and does not support.
Which situation was examined?
Ask about the starting point, the action and the relevant rule. ‘An employee can complete a request’ still leaves open which employee and which request.
Which version and environment?
A result belongs to the software version, settings, data and environment in which it was produced. A different combination may produce a different outcome.
What was actually observed?
Distinguish the intended outcome from the recorded observation. Ask how any difference was investigated and what uncertainty remains.
What was not examined?
A check of one process rule does not, by itself, establish anything about every other rule, performance, accessibility or security. Each subject needs an appropriate assessment.
Rules change
A change asks a new question.
When a rule changes, the expected behaviour needs to be clear again. Work already in progress may also need different treatment.
Before the change
Record the agreement that applies and the situations it covers. Include exceptions and work that has not yet been completed.
After the change
Discuss when the new rule takes effect, which existing behaviour must remain and which situations need another look. Earlier results do not automatically answer these new questions.
Verification has a boundary: the situations described and examined. That boundary belongs alongside the explanation of a result.
How we use this.
Before we build, we describe the expected behaviour in plain language, including exceptions and limits. While we build, we discuss with you how the result will be assessed, which situations that covers and what falls outside it.
QUESTIONS & ANSWERS
Useful to know before you start.
Does a passing check mean the software is free of defects?
No. A check answers a particular question under particular conditions. Undescribed situations, different data or a changed environment may produce different behaviour. Coverage and limitations therefore belong in the discussion.
Is a demo the same as a check?
A demo can show how an action unfolds. It does not necessarily establish which expectation was assessed, whether the outcome was recorded or which other situations were examined. Ask for that context before basing a decision on it.
Can the same check cover every concern?
A process rule, the readability of a screen and behaviour under heavy use ask different questions. A result in one area is not a conclusion about another. Agree on what needs to be examined for each subject.
A GOOD START
Where does work get stuck?
Start with one situation.Get in touch