A practical guide to quality as a team sport with a specialist spine. Standards describe what good looks like for public services. Methods describe how you design tests, explore, automate and report risk. Keep those ideas separate so you do not bury the team in cases, or ship on vibes.
MAP-01Quality maps
MAP-01
Quality maps & methods
You cannot test everything. Make the risk trade-off explicit.
Civil Service + Universal
Testing mixes design techniques, exploration, automation strategy and public-service quality floors. Pretending coverage is complete creates false confidence. Every framework below answers a different question. Use the lightest one that unlocks the next honest release decision.
Maps you will actually use
Map
Answers
Shape
Risk-based strategy
Where does failure hurt most?
Likelihood × impact, conscious de-scopes
Test pyramid
Where should feedback live?
Many unit/API, few brittle UI E2E
Exploratory charters
What will scripts miss?
Timeboxed missions with notes and bugs
BDD / Given-When-Then
What behaviour must we prove together?
Shared examples before code hardens
WCAG & NFRs
Is it usable, fast and safe enough?
AA floor · performance · security smoke
DORA / CI gates
Is quality improving with pace?
Fail fast in pipeline, not in UAT week
Choose in practice
High user or legal harm: deep path tests plus accessibility and security attention.
Fast-changing UI: push logic to API/unit layers; keep E2E thin.
Ambiguous AC: stop and rewrite with BA and PO before automating fog.
Public service: WCAG and Service Standard evidence are part of Done, not polish.
Release decision: residual risk narrative beats a pass-percentage vanity metric.
If everything is high risk, you do not have a strategy.
In DDaT terms, testing and quality roles run from Associate through Lead and Head of Quality. Titles vary: Tester, QA Engineer, SDET. The accountability does not: someone must make residual risk visible before go-live. If that person is "whoever runs UAT at the end", you do not have a test strategy.
Accountability ladder (typical digital testing path)
Associate / Junior Tester: learning design techniques and exploration on a contained slice.
Software Tester / QA: accountable for strategy and evidence on a product or service area.
Senior / Lead Tester: complex risk, coaches others, holds automation and NFR bar.
Head of Quality / Test: owns the profession, hiring bar and quality operating model.
What you stop and start doing as you grow
You stop doing
Being the only person who "does QA" at the end
Measuring your week by cases executed
Protecting flaky suites because "they sometimes catch things"
You start doing
Coaching developers and BAs so testability arrives earlier
Publishing risk trade-offs and inviting challenge on de-scopes
Measuring your week by risk reduced and feedback sped up
Three questions to run every day
What is the biggest risk if we ship today? What feedback is still too slow? What will we consciously not test, and why?
If any answer is muddy for more than a week, that becomes the priority over adding more cases.
A useful strategy names scope, environments, data, roles, entry/exit ideas and the risks you accept. A binder of templates nobody reads is not a strategy.
Strategy contents that earn their keep
Section
Good looks like
Fail mode
Risks in focus
Named user/business harms with owners
"Test everything"
Approach mix
Scripted, exploratory, automated, NFR
Only one technique forever
Environments & data
Who provisions, what is synthetic
Shared chaos late in the Sprint
Gates
Pipeline and release checks with teeth
Optional checks everyone skips
Evidence
What go/no-go will see
Pass % with no residual risk
Strategy fits on a few pages and is reviewed when risk moves.
PO and DM know what you are not testing this Increment.
Escape defects update the strategy, not only the bug tracker.
Score likelihood and impact with the PO, BA and developers. Spend deep testing where harm is high. Consciously thin coverage where harm is low and recovery is easy.
Risk lenses
Risk lens
Examples
Response
User harm
Wrong payment, inaccessible journey
Deep path + a11y tests
Reputation / legal
Data leak, incorrect advice
Security + rule tests
Change hotspots
Modules with high churn
Targeted regression
Integration
Supplier APIs
Contract tests + monitoring
Operability
Hard to diagnose in live
Observability checks in Done
Write down what you will not test this release, and why. Silence is not a de-scope.
Revisit risk when scope or architecture changes mid-tranche.
Pair risk scores with mitigation: test, monitor, feature flag, or accept.
Never hide accepted risk from the SRO at go/no-go.
Shift-left means testability and examples arrive before code hardens. It does not mean the tester narrates every story in refinement until the room dies.
High-value early moves
Moment
Your move
Red flag
Refinement
Ask one risk and one edge the AC misses
Reading a 40-case list aloud
Three amigos
Turn ambiguity into Given/When/Then
BA alone after the meeting
Design review
Challenge observability and error states
"We'll test that later"
PR / pipeline
Fast suites as the default feedback
Only manual testing tomorrow
Challenge untestable AC before estimating, not after coding.
Prefer questions that change the story over questions that show you prepared.
Partner with developers on unit and API hooks; do not wait for UI only.
Timebox charters. State the mission, the risks in focus, and the data or persona. Take notes that another tester could follow. File bugs with impact, not only steps.
Template · Exploratory charter
Mission: Explore [area] to discover [risk / behaviour]
After automation passes but confidence still feels thin.
Before release when residual risk needs a human smell-test.
Never as an excuse for zero strategy or zero automation on stable critical paths.
Session notes and debriefs are evidence. "I clicked around" is not.
Prefer many fast unit and API tests, fewer integration tests, and a thin set of UI journeys for critical paths. Put gates in CI that the team trusts enough to stop the line.
Pyramid hygiene
Layer
Use for
Watch out
Unit
Rules, calculations, edge logic
Testing only mocks of nothing
API / contract
Service behaviour and supplier contracts
No auth or data realism
UI E2E
Critical user journeys
Brittle selectors, pyramid upside down
NFR smoke
Perf, a11y, security basics in pipeline
Optional jobs everyone ignores
CI gate rules
Flaky tests are defects: quarantine with an owner and a kill-by date, or fix today.
A red build means stop and fix, not "rerun until green".
Track suite time; slow feedback quietly kills shift-left.
Partner with DevOps on environments and secrets; never hard-code credentials in tests.
A flaky suite trains the team to ignore the pipeline. That is a quality incident.
Accessibility, performance, security and operability are part of Done. In public services, WCAG 2.2 AA is a floor, not an aspiration. Service Standard evidence should not be invented the week of assessment.
Automated a11y scans catch some issues; manual keyboard and AT checks catch others.
Performance budgets belong in AC where user harm is latency-sensitive.
Security smoke and dependency checks sit in CI with owners.
Logging and monitoring hooks are testable when operability matters.
Done checks you can defend
Acceptance criteria met and evidenced, including agreed NFRs.
Critical path automation green, or conscious waiver logged.
Known defects have severity, impact and release decision.
Accessibility evidence exists for changed public UI.
Give the PO, DM and SRO a short narrative: what was tested, what was not, what failed, what is mitigated, and what you recommend. Late UAT should not be the first time risk appears.
Template · Quality risk brief
Scope tested: …
Conscious de-scopes: … (why)
Open defects: severity, impact, workaround
NFR / WCAG status: …
Residual risk: …
Recommendation: go / go with conditions / no-go
Conditions / owners / dates: …
UAT without the ambush
Bring business users into Ready and mid-Increment checks, not only end gates.
Freeze AC before coding where possible; log changes explicitly.
Separate "finding defects" from "accepting business outcomes" so ownership is clear.
The information does not change between a bug report and a go/no-go board. The altitude, the framing and the ask do.