A framework is just a named way of working. Pick the lightest one that answers the question you have today. Each card below says what it is, when to use it, how a Software Tester might apply it, what goes wrong, and where to read more.
Cards start folded. Expand one at a time. The open card fills the width and the rest move below.
Strategy
Risk-based testing
Prioritise test effort by likelihood and impact of failure so coverage decisions are explicit and defensible.
When to use it
Time is limited and everything cannot be tested
Stakeholders need transparent de-scopes
Escape defects suggest wrong focus
Example for a Software Tester
Facilitate a short risk workshop with PO, BA and developers. Publish what you will and will not test this Increment, and bring residual risk into go/no-go.
Things that go wrong
Everything scored high so nothing is prioritised
Scores never revisited when scope changes
Accepted risk hidden from the SRO
Automation
Test automation pyramid
Prefer fast, numerous unit and API tests with a thin layer of UI end-to-end journeys for critical paths.
When to use it
UI suites are slow and brittle
Feedback arrives too late in the Sprint
You need a shared shape for automation investment
Example for a Software Tester
Move business rules into unit/API tests. Keep E2E for critical journeys only. Report suite time and flake rate next to coverage vanity.
Things that go wrong
Inverted pyramid of UI-only tests
Automating unstable AC
Ignoring flake until the team ignores CI
Design technique
Exploratory testing
Simultaneous learning, test design and execution under timeboxed charters, with notes and debriefs as evidence.
When to use it
New or high-churn areas
Scripts pass but confidence is thin
Complex rules and unexpected interactions
Example for a Software Tester
Run charters against the highest open risks before release. Debrief findings into bugs, AC gaps and strategy updates the same day.
Things that go wrong
Ad-hoc clicking with no mission
No notes, so learning dies with the session
Using exploration to avoid automation on stable paths
Specification
BDD / Given-When-Then
Shared examples of behaviour that bind product, analysis, development and test before code hardens.
When to use it
AC historically ambiguous
UAT invents the real rules
Automation can reuse living examples
Example for a Software Tester
Join three amigos sessions. Insist on observable outcomes. Automate stable examples at the right pyramid layer, not as brittle UI scripts by default.
Things that go wrong
Scenarios written after coding
UI-click novels instead of behaviour
Untestable or tautological Then clauses
Operating model
Shift-left testing
Move testability, examples and automated feedback earlier so defects are cheaper and release risk is visible sooner.
When to use it
Testing is the end-of-Sprint bottleneck
Refinement skips testability
UAT is the first real feedback
Example for a Software Tester
Bring one sharp risk question into refinement, freeze AC before build where possible, and partner on unit/API hooks so feedback is not UI-only.
Things that go wrong
Turning refinement into a test-case reading
Shift-left posters with no pipeline investment
Blaming testers for late involvement they were not invited to
Engineering practice
CI / CD quality gates
Automated checks in the pipeline that can stop the line: tests, lint, security smoke, a11y scans, with trusted signal quality.
When to use it
Need fast feedback on every change
Manual regression cannot keep up
Flaky or optional jobs undermine trust
Example for a Software Tester
Define which jobs are gates versus advisories. Quarantine flakes with owners. Never hard-code secrets. Partner with DevOps on environments.
Things that go wrong
Rerun until green culture
Optional checks everyone skips
Gates so slow nobody waits
Delivery performance
DORA metrics
Deployment frequency, lead time for changes, change fail rate, and failed deployment recovery time as signals of healthy delivery.
When to use it
Debating speed versus stability
Need evidence that quality practice helps flow
Platform or product teams with deployable software
Example for a Software Tester
Report DORA trends next to quality RAG. Use change fail rate and recovery time to justify investment in tests, rollback and observability.
Things that go wrong
Gaming metrics without improving user outcomes
Applying raw DORA to non-deployable work without adaptation
Accessibility
WCAG
Web Content Accessibility Guidelines. AA is the common public-sector floor for inclusive interfaces.
When to use it
Public-facing interfaces
Service assessment or equality duty risk
Inclusive design evidence needed for release
Example for a Software Tester
Put WCAG 2.2 AA into acceptance and Done. Combine automated scans with keyboard and assistive technology checks. Block inaccessible work from being called Done.
Things that go wrong
Automated scans alone
Bolting a11y on in the final Sprint
Treating AA as optional polish
Civil Service standard
GDS Service Standard
Fourteen points on meeting user needs, providing a good service, and using the right technology for UK public services.
When to use it
UK public service build or iteration
Service assessment preparation
Need a shared quality bar across product, design and test
Example for a Software Tester
Attach testing evidence to relevant Service Standard points continuously. Make accessibility, performance and security visible in reviews, not only in assessment packs.
Things that go wrong
Paperwork-only assessment prep
Leaving performance and a11y to the last Sprint
Treating the Standard as design-only
Test design
ISTQB techniques
Structured techniques such as equivalence partitioning, boundary value analysis, decision tables and state transition testing.
When to use it
Rules and boundaries are dense
Need defensible coverage of combinations
Training or assurance asks how cases were designed
Example for a Software Tester
Apply techniques where risk justifies them. Pair decision tables with BA rules harvests. Do not generate combinatorial explosions for low-risk fields.
Things that go wrong
Technique theatre on low-risk areas
Cases without oracles
Ignoring exploration where scripts are weak
Integration
Contract testing
Consumer-driven or schema contracts that catch integration breaks without waiting for full end-to-end environments.
When to use it
Multiple services or suppliers integrate
Shared environments are slow or flaky
API changes break consumers late
Example for a Software Tester
Partner with developers on contracts for critical integrations. Use them as CI gates, and keep a thin E2E smoke for journeys that still need the full stack.
Things that go wrong
Contracts that never run in CI
Ignoring auth and realistic errors
Replacing all journey tests when user flows still break
Team methodology
Scrum
Lightweight agile framework with a usable Increment each Sprint. Testers help protect Definition of Done and Sprint Goal honesty.
When to use it
Stable team with Sprint cadence
Need refinement and review hooks for quality
Thin vertical slices each Sprint
Example for a Software Tester
Challenge Ready items, keep Done honest including NFRs, and surface quality risk in Review so stakeholders see evidence, not only demos.
Things that go wrong
QA as a sub-Sprint after developers 'finish'
Daily Scrum as status to the tester
Done that ignores accessibility and regression
Team methodology
Kanban
Visualise work, limit WIP and manage flow. Strong fit when test demand is interrupt-driven or continuous.
When to use it
Unscheduled BAU and defect load
Flow metrics matter more than Sprint commitments
Classes of service need to be explicit
Example for a Software Tester
Make test WIP and blocked age visible. Use classes of service so expedite defects do not silently erase strategic regression and exploration.
Things that go wrong
Invisible test queue that bottlenecks release
No WIP limits on 'ready for test'
Ignoring aging blocked items
Security
OWASP testing awareness
Practical awareness of common web risks and smoke checks that belong in quality strategy, alongside specialist security testing.
When to use it
Public or authenticated services
Handling personal or payment-adjacent data
Need a baseline before deep penetration tests
Example for a Software Tester
Add security smoke and dependency checks to CI. Escalate specialist testing for high-risk changes. Never store secrets in test code or logs.
Things that go wrong
Assuming functional QA replaces security testing
Ignoring dependency vulnerabilities
Logging credentials or personal data in defect tickets