Shift-Left Testing: Bring QA Into Requirements and Design Reviews

“Customers can cancel an order before dispatch” sounds ready for development. Then QA asks what happens when dispatch starts while cancellation is being processed. Product expects cancellation to win; engineering expects the first saved state change to win. Neither interpretation is written down.

Finding that disagreement during a requirements review gives the team a chance to choose the behavior before it becomes code, test cases, support guidance, and a customer complaint. Shift-left testing brings suitable testing activities earlier in development, including reviewing requirements and design with QA. The useful change is earlier feedback on decisions that still have room to change.

Start With Decisions That Can Change Before Coding

A requirements review can reveal an ambiguous rule, an omitted failure path, or an expectation nobody can observe. A design review can reveal that the proposed architecture makes those outcomes difficult to create or inspect during testing. These activities produce corrected specifications, questions, and testability work before a complete application exists.

They also produce a different kind of evidence from running software. ISTQB's Foundation Level syllabus distinguishes static testing, which does not execute software and includes reviews, from dynamic testing, which does. Reading a cancellation rule can expose a contradiction. It cannot demonstrate that a deployed cancellation service handles simultaneous requests correctly.

Early execution still belongs in the approach. A prototype can help investigate a confusing interaction, and an available component can be tested before the whole feature is assembled. Keep the conclusion within the scope of what was examined. A successful prototype exercise does not establish production reliability.

Moving the final QA deadline forward without changing how decisions are made leaves the original problem intact. QA needs access to developing requirements, relevant design discussions, and the people authorized to settle questions. Product and engineering retain responsibility for their decisions; a tester should not have to invent business policy to make an expected result writable.

Turn Requirements Into Rules, Examples, and Owned Questions

Bring the current story, acceptance criteria, relevant user flow, and known constraints to the review. Where a change depends on an existing service or policy, include that context too. A tester who sees only a short story title cannot reliably distinguish a missing requirement from behavior defined elsewhere.

Use concrete examples to test the team's understanding. Cucumber's Example Mapping guidance separates rules, examples that illustrate them, unanswered questions or assumptions, and stories that need to be split or deferred. The conversation is useful without adopting Cucumber or automating anything immediately.

A practical review can follow this sequence:

1. Identify the user outcome and the business rule being changed. Ask which existing behavior must remain unchanged.
2. Walk through an ordinary example with specific starting conditions, an action, and an observable outcome.
3. Challenge the rule with a denied action, a boundary condition, and a plausible interruption or dependency failure.
4. Separate agreed behavior from unanswered questions. Give each important question an owner and identify what work depends on its answer.
5. Update the source requirement and decide what needs a design change, a test, a specialist review, or a separate investigation.

Questions should lead to decisions rather than an ever-growing checklist. “What happens on an error?” is too broad. “If the refund provider times out after accepting the request, how will the customer and support team learn its actual status?” identifies a particular uncertainty and the people who need an answer.

Include nonfunctional expectations where they affect the user outcome. “Fast” needs a defined operation, workload, measurement boundary, and acceptable result. “Secure” needs relevant access and data-protection rules. QA can expose missing conditions, while product, engineering, and specialist owners agree what those conditions should be.

Review an Order Cancellation Before Dispatch

Consider a fictional online retailer. Its initial requirement says: “Customers can cancel orders before dispatch and receive a refund quickly.” The following decisions are illustrative assumptions for this example, not universal retail rules or results from executed tests.

The reviewer first asks who can cancel, what counts as dispatch, and whether cancellation and refund completion are the same event. The team then examines the customer's view alongside the warehouse and payment workflows.

Ambiguity to Resolve	Illustrative Agreed Rule	Evidence to Plan Later
Who may cancel?	A customer may cancel only their own eligible order. Support cancellation is outside this story.	Authorized and denied requests, with checks that another customer's order and private data remain protected.
When does eligibility end?	Cancellation is eligible while the authoritative order state is Ready to Ship. Dispatch Started makes it ineligible.	Checks on both states and on the transition between them, using the authoritative saved state.
What if cancellation races with dispatch?	The service must accept only one of the competing transitions. A rejected cancellation must explain that dispatch has started.	Controlled concurrent attempts, final order state, warehouse activity, and the customer-facing response.
What if the response is lost?	The client must establish the cancellation outcome before presenting another attempt as a new cancellation.	An interrupted response after processing, recovery behavior, and checks for duplicate business effects.
When is the refund complete?	Accepted cancellation and completed refund are separate states. The customer can see a pending refund and its eventual outcome.	Provider success, delayed response, and failure scenarios, with agreement on observable completion and escalation.

The table changes the implementation conversation. Engineering now needs a state-transition decision rather than a vague instruction to disable a button. QA can plan checks around ownership, concurrency, and uncertain outcomes. Product must decide what the customer should be told when cancellation succeeds but the refund remains pending.

Some questions may remain open. The team still needs an agreed refund timing expectation, supported by the provider's behavior and the business's commitments. Writing an arbitrary deadline into a test would conceal that gap. Record it as an owned decision, and identify whether the unresolved answer blocks implementation, customer messaging, or release readiness.

The review has not proved that duplicate refunds are impossible. It has specified a risk and the behavior the team intends to verify. The concurrency and interrupted-response checks require an implemented service, suitable controls, and observable business effects before they can produce meaningful results.

Ask Design Questions That Make the Outcomes Observable

A testable requirement can still be expensive to verify if the architecture hides state, makes setup unpredictable, or cannot represent dependency failures safely. Review how evidence will be obtained alongside how the feature will work. Microsoft's testing guidance recommends planning testing with the architecture and revisiting it as the architecture changes.

Control Preconditions Without Unsafe Test Backdoors

For the cancellation flow, ask how a tester will create an isolated order in each relevant state. Identify who supplies synthetic customer accounts, warehouse fixtures, and payment-provider test access. If these prerequisites arrive after implementation, the team may have test cases but no usable way to execute them.

Ask whether a dependency can be replaced or controlled in an authorized test environment. Engineering might provide a replaceable payment client or a simulator with agreed responses for acceptance, delay, and rejection. The implementation choice belongs to the design team; QA's contribution is to explain which conditions need to be created and why.

Do not demand a universal test hook for every theoretical failure. Dependency substitution and fixture infrastructure introduce complexity and maintenance. Invest first where a failure would damage money, privacy, availability, or an important user journey. Keep test-only controls scoped and protected rather than introducing an unrestricted production backdoor.

Observe Business State and Failure Recovery

A cancellation confirmation on the screen is insufficient if the warehouse continues processing the order. Agree which record or supported diagnostic view establishes the authoritative outcome, and what access a tester needs to inspect it. For asynchronous work, define the completion signal and observation limit before execution; an empty queue at one instant does not establish a permanent non-effect.

Distinguish a technical failure from an unknown business outcome. A lost response might follow an accepted operation. The design review should cover status recovery, how repeated delivery is recognized if that protection is required, and what evidence supports the eventual decision. Logging should help correlate the operation without exposing credentials, payment details, or unnecessary customer data.

Mocks make early checks possible, but their responses encode assumptions. Passing against a simulated refund provider does not establish that the real provider accepts the same request or behaves identically under delay. Plan appropriate contract and integration checks against supported interfaces, and assign someone to keep the simulation aligned as dependencies change.

Include Security, Accessibility, and Operational Constraints

Invite specialists when the risk needs their knowledge. For customer-owned orders, a security review can examine identity, resource ownership, data flow, and trust boundaries. OWASP's threat-modeling guidance recommends early, iterative analysis and asks whether agreed mitigations can be tested and measured. A general QA review does not replace specialist security assessment.

Design reviews can also ask how keyboard users reach the cancellation action, how status changes are communicated, and how a pending refund differs from an error. Those questions can influence the interaction before it is built. The implemented experience still needs appropriate accessibility and usability evaluation.

Operational questions deserve the same treatment. Who investigates a refund that never reaches a final state? Which signal identifies it, and what customer-safe recovery is permitted? Record the required behavior and ownership early, then validate the actual diagnostics and recovery procedure in a suitable environment.

Leave the Review With Owners and Versioned Outputs

Shared ownership works when responsibilities are explicit. In a typical team, product or a business analyst owns policy clarification, engineering owns design and implementation decisions, and QA leads risk-focused examples and the verification approach. Security, design, accessibility, and operations specialists contribute where needed. Agree the allocation locally rather than treating job titles as a universal approval hierarchy.

Leave the review with a small set of usable outputs:

• Updated acceptance criteria and examples tied to the reviewed source revision.
• Unanswered questions with owners, consequences, and an agreed point for resolution.
• Testability tasks covering necessary fixtures, environments, dependency controls, and observation access.
• A risk-based outline of checks, including which evidence must wait for implementation or deployment.
• A decision record stating what was agreed, what remains uncertain, and whether development can proceed within that scope.

Review approval is scoped to the reviewed material. A significant requirement or design change should trigger reconsideration of affected decisions and tests. It should not silently inherit an earlier approval because the story key stayed the same.

Carry each important rule into the relevant test specifications, then associate later results with the case revision, build, and environment that were examined. A linked test case establishes planned coverage, not a passing result. For Jira-based teams, a requirements traceability matrix can help keep those relationships and missing evidence visible.

Sherlock Test Management offers an app-specific way to carry reviewed requirements into test design. Its current product description covers editable testing briefs, source-linked AI case proposals, human approval, and versioned baselines. In the cancellation example, reviewers could assess proposed cases against the agreed ownership and state rules while leaving unresolved refund policy for the responsible person to decide. The Sherlock product workflow describes this model. These are Sherlock capabilities, not native Jira functionality; approving a proposed case does not execute the application or establish a passing result.

Keep Later Testing and Feedback in the Plan

Shift-left testing changes when useful feedback starts. Integration behavior, real dependency responses, deployed configuration, accessibility in the implemented interface, and performance under representative conditions still require suitable execution. Preserve regression, exploratory, specialist, and acceptance work rather than cutting it because requirements received an early review.

Microsoft's production-testing guidance also identifies limits to what pre-production environments can establish. Real workloads and evolving infrastructure can expose behavior that earlier checks did not reproduce. Plan controlled operational validation with the people responsible for production safety, using explicit scope, observability, and limits on customer impact. Early QA involvement does not authorize unrestricted experiments on live systems.

Start with a risky feature where late ambiguity has caused rework. Make room for QA in its requirements and design discussions, and allocate time for the resulting clarification and testability tasks. Another meeting without capacity to act on findings will add overhead without resolving uncertainty.

Judge the change by whether important questions are answered while decisions remain changeable, whether reviewers can explain expected outcomes, and whether later testing has the prerequisites it needs. Review recurring late discoveries and unresolved decisions alongside delivery context. A larger count of review comments or an earlier defect discovery date does not, by itself, measure better quality.

For the next feature review, ask another team member to recover one important rule, its boundary example, the decision owner, and the planned evidence. If that chain breaks before anyone writes code, repair it there. If it holds, carry it forward to actual execution rather than treating the review as the end of QA.