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.