Why this matters
QA can add value before any code exists by testing the idea itself. Questions about examples, boundaries, data, permissions and failure behaviour expose gaps while they are still inexpensive to change.
This is not about writing test cases in the meeting. It is about helping the team create a shared, testable understanding of the intended outcome.
How to do it well
Clarify the user and goal
Identify who performs the action, why and what successful completion means.
Ask for examples
Create concrete normal, boundary and invalid cases that everyone can discuss.
Map data and rules
Define sources, transformations, validation, ownership and permissions.
Explore failure behaviour
Specify messages, retries, partial completion and recovery.
Check observability
Agree what evidence will show that the feature is working in testing and production.
Record decisions
Update acceptance criteria and open questions so assumptions do not remain only in conversation.
What to avoid
- Accepting “the same as the old screen” without defining behaviour.
- Discussing only the happy path.
- Leaving data ownership and permissions until implementation.
- Writing criteria that describe implementation instead of user outcome.
- Treating QA questions as blockers rather than risk discovery.
Practical example
A requirement says “allow CSV import”. Refinement reveals unanswered questions about encoding, duplicate handling, partial failure, maximum size and user feedback.
Resolving these points before development prevents contradictory assumptions between frontend, backend and support.
Lesson for practice
Early QA is prevention through shared understanding. Concrete examples, boundary questions and observable outcomes reduce rework and make later testing more focused.
A good practice does not have to be complicated. It should be intentional, repeatable and explainable: the team should understand why the control exists, what evidence it provides and how feedback will improve the next iteration.
A real case: Horizon and assumptions about system correctness
In the Horizon Issues judgment in Bates v Post Office, delivered on 16 December 2019, the UK court examined defects, data and system reliability. In 2024 the Criminal Cases Review Commission described the associated prosecutions as a widespread miscarriage of justice. These are documents about a real British case, not a substitute for examining each individual decision. This article is an analytical discussion, not a legal assessment.
For requirements analysis, the case raises a question about a person’s ability to challenge a system result. “Calculate the correct balance” is insufficient unless the requirement also explains how correctness can be checked, what happens when a discrepancy arises and what evidence is available for investigation. This is my general analytical lesson; I am not claiming that one improved requirement would have prevented all the consequences of the case.
A hypothetical requirement: importing customer records
“The user uploads customers from a file” admits several important interpretations. Must the whole file succeed or fail together, or should valid rows be saved while invalid ones are rejected? What happens if the connection is interrupted, and how is a repeat submission identified? In a financial application these choices can alter customer counts, application states and the ability to trace information back to its source.
Suppose a file contains 100 rows, three with invalid identifiers. One implementation saves 97 records and another saves none; both could be described as satisfying the original sentence. I would clarify the business decision with the process owner before defining the test. A tester should not independently decide which treatment is acceptable for the bank. Their contribution is to expose the missing decision before competing assumptions become implemented behaviour.
How I would refine the requirement
I would start with the intended outcome and the user’s role, then define input rules, partial-failure behaviour and confirmation. Acceptance examples would cover an empty file, a duplicate row and a customer already present in the system. Each example should connect to a business rule rather than merely describe an imagined technical implementation. The team then has a shared basis for choosing and verifying the solution.
For repetition I would ask how the system identifies the same request. Acceptance is not necessarily completion. If a user resubmits after a timeout, does the service resume the existing job, safely reject a duplicate or create a new run? The process owner and developer both need the answer. Otherwise each can build a coherent interpretation that produces a different business result when the network behaves unexpectedly.
Failure behaviour belongs in the requirement
I would pay particular attention to what the user sees when processing cannot finish. They should be able to distinguish saved and unsaved information and know their next step. An error download should not automatically become an unnecessary copy of all sensitive inputs. The requirement needs to define access and safe delivery as well as the wording of the error message and the technical status code.
For financially significant processing, I would want a way to reconcile the outcome to an independent summary. Input counts, successes and rejections should be explainable for a particular run. Matching numbers on two screens are not independent confirmation if both display the same incorrectly computed total. Analysis therefore includes the origin of the evidence that will later be used to claim that processing completed correctly.
When I would consider the requirement ready
I would not demand certainty about every detail. I would expect shared answers about critical outcomes, risky exceptions and responsibilities. Less significant open issues can have owners and dates, while unresolved duplicate handling may block a specific part of implementation. That distinction prevents minor uncertainty stopping all development without allowing a fundamental business ambiguity to disappear into a backlog of small questions.
After drafting, I would arrange a brief example walkthrough with the process owner, developer and tester. Each should explain the same example in their own words. Different answers show that the text may look clearer than the team’s understanding actually is. At this stage the correction may be a better rule or example, rather than repair of an already deployed process and the records it created.
I would retain the reason for the agreed choice, especially where several reasonable alternatives exist. A future maintainer needs to know why partial acceptance was preferred or forbidden. Without that context, a later simplification might accidentally remove a protection. This is not a call for documenting every conversation; it is a focused record of decisions whose loss would materially change interpretation of the requirement.
Summary and recommendations
Involve QA when clarifying essential outcomes, exceptions and evidence of completion. Use concrete data, consider repetition and give discrepancies an investigation route. Horizon warns against unquestioning trust in a system output, while the proposed process here builds shared understanding before implementation. A useful requirement should make the result not only producible but also explainable, verifiable and, where evidence justifies it, safely open to challenge.