Q34 of 38 · Test design
How do you build a test strategy when there are no written requirements?
Short answer
Short answer: Reconstruct intent from available signals — user stories, design mocks, stakeholder conversations, and existing behaviour — then create a lightweight specification collaboratively before writing tests. Use risk-based reasoning to prioritise gaps.
Detail
The absence of requirements is common, not exceptional. The strategy: don't wait for a specification document that won't come.
Mine existing signals. Jira tickets, Figma mocks, API schemas, and similar features in production all contain implicit requirements. Extract them explicitly and write them down.
Run a brief three-amigos session. 30 minutes with a developer, a QA, and a product owner to walk through the feature and surface ambiguities. The output is a list of scenarios and edge cases — not a formal spec, but something to test against.
Apply risk heuristics. Without a spec, use risk-based judgement: focus first on the paths that handle money, personal data, or irreversible state; then on the primary user journeys; then on edge cases. Document what you chose not to test and why — this is your coverage decision log.
Automate the oracle. When you cannot specify exact expected values, test relative properties: the response time is not worse than the baseline, the output contains required fields, the error message is not a stack trace.