Template
Industry test scenario matrices
Worked planning prompts for SaaS, healthcare, finance, e-commerce, logistics, manufacturing and startup releases, with boundaries and first-engagement suggestions.
Download editable MarkdownHow to use this
Useful for: Teams translating sector-specific consequences into observable testing scenarios.
Select the scenarios that match your product and its users. Sector labels are an entry point to the conversation; they do not establish which regulation or technical obligation applies.
Use synthetic data and agreed expected results. Where amounts, permissions or state transitions matter, obtain the governing rule before implementing an assertion.
Choose a first engagement around the biggest unresolved question. A focused API review, a release plan or an accessibility investigation may be more useful than a broad framework build.
Add product-specific conditions and exclusions to the worksheet. Review the matrix when an integration, supported market or role model changes rather than assuming the original scope still fits.
Scope and limitations: Fictional planning examples. They are not regulatory interpretations, medical validation, financial assurance or certification for any sector.
Document preview
# Industry scenario matrices ## SaaS: tenant and entitlement boundaries | Scenario | Expected rule to agree | Evidence | | --- | --- | --- | | Member reads another tenant's object | Deny without disclosure | Role/object matrix | | Subscription changes an entitlement | Access changes at the specified boundary | State-transition results | | Repeated billing callback | One agreed business effect | Integration evidence | First engagement: a critical-journey and tenant-boundary review. Keep unrelated billing-provider certification outside its scope. ## Healthcare: traceability with synthetic records Link each requirement to a test, build and reviewed result. Exercise clinician, administrator and patient-like test roles with fabricated data; verify refused access and record changes. Identify untested clinical decisions explicitly. First engagement: a traceability and access review of the named application layer, with specialist validation separately scoped. ## Finance: precision and repeat requests Check integer minor-unit or agreed decimal precision, rounding boundaries, refused roles, expired authentication and repeated requests using isolated accounts. Compare the observable business effect as well as the HTTP response. First engagement: a focused contract and negative-scenario suite for the named API; keep claims about the financial organisation outside this test scope. ## E-commerce: checkout variations Enumerate supported payment methods, countries, tax/delivery rules and viewports. Cover cancellation, provider refusal, retries, basket changes and keyboard navigation. Record the rules governing totals independently of the code. First engagement: a checkout release plan with performance and accessibility observations, not a guarantee of payment-provider availability. ## Logistics: partner and event state Exercise malformed records, duplicate delivery, delayed and out-of-order events, retries and unknown identifiers. Record the sandbox differences from the production partner. First engagement: a partner-contract and event-state assessment with a controlled replay data set. ## Manufacturing: reconciliation and shop-floor clients Compare source and destination counts, identifiers and units; report rejected and transformed records separately. Check the supported shop-floor browser/device combinations and interrupted connectivity. First engagement: an integration reconciliation worksheet and targeted web-interface checks; device firmware and safety validation require separate expertise. ## Startups: a bounded launch decision Name the three journeys that carry the greatest user or commercial consequence. Confirm ownership, access boundaries and recovery. Separate launch-critical checks from improvements that can wait. First engagement: the readiness assessment followed by a small release evidence plan, with explicitly deferred automation or feature work. For every sector record: build, expected rule, starting data, observed result, evidence, limitation, owner and review date.
Read alongside this worksheet
- Test data management: five strategies and what each one costsHow a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
- Broken object level authorisation: the API risk no scanner will find for youThe top entry on the OWASP API Security Top 10 returns a perfectly normal 200 to the wrong person. Why tooling cannot see it, and how the testing actually runs.
- DORA’s testing programme: what a financial entity has to prove, and how oftenDORA asks for a documented testing programme over the systems behind critical functions, and a much heavier threat-led test for entities singled out for it. The two are not the same product.