Quality assurance in Scrum is continuous work, not a testing phase at the end. The QA engineer helps the team understand risks, make stories testable, verify each change and maintain confidence from the first project discussion through production support.
On this practical guide
The complete QA flow
| Stage | Main QA focus | Typical result |
|---|---|---|
| Discovery | Understand users, architecture, risks and quality expectations. | Initial risk list and quality questions. |
| Planning | Define the testing approach, levels, environments, data and responsibilities. | Test strategy and practical test plan. |
| Backlog preparation | Make stories clear, testable and small enough for a sprint. | Acceptance criteria, examples and test ideas. |
| Sprint delivery | Test early, collaborate, automate and provide fast feedback. | Verified stories, automated checks and defect evidence. |
| Continuous integration | Run layered checks whenever the code changes. | Visible pipeline results and merge confidence. |
| Regression and release | Check important existing behaviour and release risks. | Release recommendation with known risks. |
| Production | Monitor real behaviour and learn from incidents and users. | Feedback for the backlog and improved coverage. |
Whole-team quality: QA leads and facilitates testing, but developers, product, operations and designers also own product quality.
Project start and discovery
QA should join before the first feature is developed. Early questions prevent expensive defects and shape the technical test approach.
Understand the product
- Who are the users and what are their critical journeys?
- What business loss could result from failure?
- Which browsers, devices, languages and accessibility standards are required?
- Which APIs, databases, queues and third-party systems are involved?
- What security, privacy, performance and availability expectations apply?
- How will the product be deployed, observed and supported?
Initial QA tasks
- Review business goals, architecture and early requirements.
- Create a product-quality risk list.
- Identify test levels and automation opportunities.
- Estimate environment, account, device and test-data needs.
- Agree defect workflow, severity definitions and evidence standards.
- Help define the project's Definition of Done.
- Raise testability needs such as stable locators, logs, feature flags and API contracts.
Test strategy and test plan
The terms are sometimes combined. What matters is separating stable direction from short-term execution details.
| Document | Purpose | Typical lifetime |
|---|---|---|
| Test strategy | Explains the overall quality approach and why it fits the product risks. | Project or product; updated when direction changes. |
| Test plan | Explains what will be tested, by whom, where and when for a release, milestone or scope. | Release or significant delivery period. |
| Sprint test notes | Records story-specific scenarios, data, dependencies and exploratory ideas. | One sprint or story. |
Typical test strategy
- Quality goals and main product risks.
- Test levels: unit, component, contract, API, integration and end-to-end.
- Manual, exploratory and automated testing approach.
- Functional and non-functional coverage.
- Automation principles, tools, ownership and maintenance.
- CI/CD quality gates and test execution frequency.
- Environment, data and service-virtualisation approach.
- Defect, reporting and traceability approach.
- Metrics and improvement process.
Typical test plan
- Features in scope and explicitly out of scope.
- People, responsibilities and required support.
- Environments, test data, accounts and dependencies.
- Planned test activities and schedule.
- Regression scope and release checks.
- Entry, exit and suspension criteria.
- Known risks, assumptions and mitigations.
- Deliverables such as reports, evidence and approval record.
Keep both useful: a short living document that guides decisions is better than a large document nobody updates.
Definition of Ready and Definition of Done
A team may use readiness criteria to decide whether a story is clear enough to enter a sprint. The Scrum Guide formally defines the Definition of Done as the shared quality description for completed work.
Example readiness checks
- Business value and user are understood.
- Acceptance criteria contain clear, testable examples.
- Dependencies, designs, API changes and data needs are known.
- Important risks and non-functional expectations are discussed.
- The story is small enough to build and test inside the sprint.
Example Definition of Done
- Acceptance criteria pass.
- Code is reviewed and merged.
- Required unit, API, integration and UI tests pass.
- Automation is added or its follow-up is agreed.
- Exploratory testing is complete for the relevant risks.
- No unresolved blocking defect remains.
- Accessibility, security, performance and compatibility checks are complete where relevant.
- Documentation, logging and monitoring are updated.
- The increment is deployable.
Backlog refinement
Refinement is one of the highest-value places for QA work. The goal is to prevent ambiguity before development starts.
- Ask what should happen in the happy path.
- Add negative, boundary and permission examples.
- Identify affected existing behaviour.
- Discuss error handling, empty states and interrupted flows.
- Clarify analytics, audit logs, notifications and stored data.
- Identify automation level and required test hooks.
- Estimate testing work as part of the story, not as a separate afterthought.
Example: password reset story
| Area | QA question |
|---|---|
| Valid flow | How long is the reset link valid? |
| Security | Does the response reveal whether an email exists? |
| State | What happens to older links and active sessions? |
| Limits | How often can a user request a new email? |
| Compatibility | Which browsers and email clients are important? |
| Observability | Can support trace the request without seeing the token? |
Sprint planning and daily work
During sprint planning
- Confirm the team can build and test each selected story.
- Make test activities, automation and environment work visible.
- Identify stories that depend on another team or service.
- Plan collaboration rather than assigning all testing to the final days.
- Reserve capacity for defect investigation, regression maintenance and technical quality work.
When development starts
- Pair with developers on examples, unit tests and API contracts.
- Prepare test data, accounts, mocks and environments.
- Draft or automate tests while the feature is being built.
- Review designs and early builds rather than waiting for a finished ticket.
- Test backend or API work before the full UI is available.
When a story is ready to test
- Check the deployed build and pipeline status.
- Verify acceptance criteria and important business rules.
- Run negative, boundary, role and error-path tests.
- Explore beyond scripted examples.
- Check affected APIs, data and integrations.
- Perform relevant accessibility, responsive, security or performance checks.
- Run focused regression around the changed area.
- Report defects with evidence and retest fixes.
- Add or update maintainable automated coverage.
- Record the result and remaining risk.
Avoid the mini-waterfall: if every story reaches QA on the last sprint day, quality feedback is too late. Work in smaller slices and test continuously.
Scrum events and the QA contribution
| Event | Useful QA contribution |
|---|---|
| Sprint Planning | Highlight risk, dependencies, test effort and whether stories are testable. |
| Daily Scrum | Share progress towards the Sprint Goal, blockers and collaboration needed. |
| Backlog Refinement | Clarify examples, edge cases, acceptance criteria and testability. |
| Sprint Review | Support the demonstration, explain quality evidence and listen to stakeholder feedback. |
| Retrospective | Use evidence to improve flow, automation, environments and defect prevention. |
QA does not need to report every test executed during the Daily Scrum. Focus on progress, risk and anything preventing the team from reaching the Sprint Goal.
How CI/CD supports quality
Continuous integration gives the team fast feedback whenever code changes. Continuous delivery or deployment moves a verified build through environments in a repeatable way.
| Pipeline stage | Typical checks | Feedback speed |
|---|---|---|
| Commit / merge request | Formatting, lint, type checks, unit and component tests. | Seconds to minutes. |
| Build | Compilation, package creation, dependency and security scanning. | Minutes. |
| Integration | API, contract, database and service integration tests. | Minutes. |
| UI smoke | Critical browser flows on the deployed test build. | Several minutes. |
| Extended regression | Broader UI, cross-browser, accessibility and selected non-functional tests. | Scheduled or before release. |
| Deployment | Environment health, migration and post-deployment smoke checks. | Immediately after deployment. |
QA work around the pipeline
- Choose which tests belong at each level.
- Keep fast, reliable checks as merge gates.
- Publish reports, traces, screenshots and logs as artefacts.
- Make failures visible in the merge request.
- Investigate flaky tests instead of hiding them with retries.
- Protect secrets and use safe test accounts and data.
- Measure duration and parallelise without creating shared-state failures.
- Run scheduled suites to find problems outside individual code changes.
Simple GitLab pipeline shape
stages:
- verify
- integration
- e2e
lint-and-unit:
stage: verify
script:
- npm ci
- npm run lint
- npm test
api-tests:
stage: integration
script:
- npm run test:api
playwright-smoke:
stage: e2e
script:
- npx playwright test --grep @smoke
artifacts:
when: always
paths:
- playwright-report/
- test-results/
Regression testing
Regression testing checks that existing behaviour still works after a change. It should be risk-based and layered, not one enormous UI suite.
| Suite | When | Typical scope |
|---|---|---|
| Unit and component regression | Every commit. | Logic and isolated components. |
| API and integration regression | Every merge request or deployment. | Contracts, services, data and business rules. |
| Smoke | After each deployment. | Application health and critical paths. |
| Focused regression | For each story or fix. | Changed area and direct dependencies. |
| Full automated regression | Nightly, scheduled or before release. | Stable high-value product coverage. |
| Manual exploratory regression | Before important releases or for risky changes. | New risks, usability and complex interactions. |
Select regression scope from risk
- Files, services and database tables changed.
- Critical user journeys affected.
- Shared components or libraries used elsewhere.
- Permissions, configuration and feature flags involved.
- Recent defects and historically unstable areas.
- Browser, device or integration impact.
Retries are not regression coverage: a flaky test reduces trust. Find whether the cause is timing, data, environment, product behaviour or the test itself.
Defects and retesting
- Confirm the issue and reduce it to clear reproduction steps.
- Capture environment, build, data and relevant evidence.
- Explain expected result, actual result and user impact.
- Agree severity and priority with the team.
- Link the defect to its story, test and affected requirement.
- Retest the exact fix when a new build is available.
- Run focused regression around the cause and changed code.
- Add a suitable automated test to prevent recurrence.
A developer should be able to investigate from the report. The product owner should be able to understand the business impact.
Sprint review and retrospective
Sprint Review
- Confirm the demonstrated increment meets the Definition of Done.
- Explain relevant known limitations or risks.
- Show quality evidence when it helps stakeholder decisions.
- Capture feedback as backlog changes and new test considerations.
Retrospective
Discuss the process, not only individual defects. Useful evidence includes escaped defects, late stories, pipeline failures, flaky tests, blocked test time and long feedback loops.
- Why did work arrive late for testing?
- Which defect could have been prevented during refinement?
- Which manual check should move to a lower automated level?
- What made the environment or data unreliable?
- Which one improvement will the team try next sprint?
Release readiness
QA provides evidence and a risk-based recommendation. Product or business ownership normally makes the final release decision.
Before release
- Release scope and included fixes are confirmed.
- Required pipeline and regression suites pass.
- Open defects are reviewed with impact and workaround.
- Database migrations, configuration and feature flags are checked.
- Rollback or recovery approach is known.
- Monitoring, dashboards and alerts are ready.
- Production smoke tests and responsible people are agreed.
- Release notes and support information are prepared.
Concise QA release summary
Build: 2.8.0
Environment: Staging
Scope tested: Checkout, payment retry and order confirmation
Automated results: 214 passed, 0 failed
Manual checks: Critical journeys and exploratory payment testing complete
Open risks: One low-severity mobile alignment defect
Recommendation: Ready for release with the recorded low risk
Deployment and after release
- Confirm the expected version and configuration reached production.
- Run a small, safe production smoke suite.
- Check health dashboards, errors, logs and critical business metrics.
- Verify feature flags and third-party connections.
- Avoid creating harmful production data or triggering real payments and messages.
- Escalate unexpected behaviour through the incident process.
- Turn incidents, support reports and analytics into new risks and regression tests.
The lifecycle does not finish at deployment. Production feedback improves requirements, observability, the test strategy and future sprint coverage.
Typical QA task checklist
Every day
Collaborate on stories, test current work, investigate failures, report risk and unblock the team.
Every story
Review criteria, prepare data, test behaviour, explore risks, automate suitable checks and record results.
Every merge request
Review test impact, inspect pipeline results and confirm failures have useful evidence.
Every sprint
Refine backlog, plan work, maintain regression, support review and propose one improvement.
Every release
Run risk-based regression, review open defects, provide a recommendation and verify deployment.
Throughout the project
Update strategy, improve testability, reduce flakiness and keep quality information visible.
Useful metrics
| Useful signal | What it may reveal |
|---|---|
| Defects found before and after release | Prevention and detection effectiveness. |
| Pipeline duration and success rate | Feedback speed and delivery stability. |
| Flaky-test rate | Trustworthiness of automated results. |
| Time from code change to feedback | How quickly the team can correct problems. |
| Risk or requirement coverage | Important behaviour that remains untested. |
| Defect reopen rate | Fix quality or unclear acceptance conditions. |
Avoid vanity metrics: test-case counts, automation percentages and bug totals need context. More tests or defects do not automatically mean better quality.
Useful links
- The Scrum Guide ↗ — Scrum accountabilities, events and Definition of Done.
- ISTQB Foundation Level ↗ — test planning, risk and core testing practices.
- ISTQB Advanced Agile Tester ↗ — whole-team quality, strategy and shift-left practices.
- Testing with GitLab CI/CD ↗ — test execution and merge-request feedback.
- GitLab test reports ↗ — publish failures and evidence in pipelines.
- Playwright CI guide ↗ — running browser automation in pipelines.