What is a QA testing checklist?
A QA testing checklist turns the test pass into tickable steps on the work item: environment ready, functional coverage, edge cases, browsers, security checks, and sign-off. The list is the same shape for every bug or story; only the ticks and evidence change.
The pass sits next to acceptance criteria: those rows describe the promised behavior, and the QA testing list records how you proved it. Definition of Done can require this list to be complete before the story ships.
Why teams keep QA testing on the issue
A test pass that lives in a spreadsheet, a Confluence page, or a Slack thread is easy to lose when the next person opens the ticket. A checklist on the work item keeps setup, coverage, and evidence where the work already lives — testers set item statuses such as In Progress and Blocked, @mention an owner on a stuck row, and the board shows remaining work.
The same pass applies whether you are verifying a bug fix or a story: you open the issue, see what is left, attach screenshots or logs on failures, and write the result on the ticket. High-risk changes keep the security and platform rows; a copy tweak can drop them.
When to apply it
Use a QA testing checklist on bugs, on stories that need a structured pass before Done, or when status becomes Ready for test. Auto-apply it by issue type for Bugs, or on that status change so testers always get the same scaffold. Trim rows for low-risk changes; keep security and regression coverage when the change touches auth, payments, or a shared path.
QA testing vs Acceptance criteria vs Definition of Done
Acceptance criteria describe what this story should deliver — the examples you will demo. The QA testing checklist is how you prove those examples: data, browsers, regressions, and notes. Definition of Done is the shared exit bar every story owes at the end — tests, review, and release readiness. Keep all three as separate checklists on the work item so behavior, the test pass, and ship quality stay distinct.
QA testing — an example to start with
To build your first QA testing checklist, start with the example below. Copy the list and paste it into the Checklist for Jira input field on a bug or story. Ideally, save it as a template and auto-apply it when Bugs are created or when work moves to Ready for test — that gives testers a consistent scaffold and reuses the same headings each time. Trim rows your team skips; add ones your process needs.
QA testing pass
- Setup
- Test environment, build, and feature flags match the work item
- Test data and accounts are ready, including permission edge cases
- Known bugs that are out of scope for this pass are linked on the issue
- Functional coverage
- Happy path matches the acceptance criteria on this work item
- Validation, empty states, and obvious error paths are exercised
- Permissions and role differences are checked when access matters
- Edge cases
- Boundary values, empty collections, and concurrent edits are covered when they apply
- Interrupted flows resume or fail cleanly — timeouts, retries, and cancelled requests
- Regression and platforms
- Adjacent flows that share this code path still work
- Primary browsers or devices agreed by the team are covered
- Accessibility smoke: keyboard path and visible focus on new controls
- Security
- Authorization holds: a user cannot see or change another tenant's data
- Sensitive values stay out of URLs, logs, and error messages
- Evidence and sign-off
- Screenshots, recordings, or log links are attached for failures
- New defects are filed and linked, with severity filled in
- QA result is written on the work item: pass, fail, or blocked with owner
That scaffold belongs on every bug and on stories that need a structured pass. In Checklist for Jira you add or tick items on the issue panel, save the headings as a project or global template, and auto-apply it when Bugs are created or when status becomes Ready for test — or apply it manually from Add → Add from template whenever you need it.
Put this on the work item with Checklist for Jira
Templates, automation, workflow gates, and a Rovo agent — free for teams of up to 10 users.
Save a starter, automate the pass
- Checklist for Jira adds a checklist panel on the issue view. Paste the example above on a bug or story, adjust rows for your process, then save the shape as a project or global template in Checklist settings.
- Mark the template Protected if you want the step list locked while testers tick items and set statuses such as In Progress and Blocked.
- Use per-template automation to attach the QA testing scaffold when a Bug is created, or when status becomes Ready for test. These automations are built into Checklist for Jira and run without Jira Automation credits.
- If your team wants a reminder before Done, add a completion validator on that transition, scoped to this template only, so the work item stays open until the pass is finished.
- Pair with acceptance criteria for the examples the pass is proving, Definition of Done at the end, and the release checklist when the change is ready to ship — see the automation guide.
Pair it with the rest of the delivery set
Keep acceptance criteria on the same issue for the promised behavior. Attach Definition of Done when work enters the sprint so the ship bar is visible from day one. Use Definition of Ready during refinement if intake quality helps your team. Continue with the release checklist when the change is ready to ship. Browse the template hub for the full set.
FAQ
Should every test case be a sub-task?
Open a sub-task when a case needs its own assignee, estimate, and workflow. A structured QA testing checklist on the parent is the lighter way to run a standard pass.
How is QA testing different from acceptance criteria?
Acceptance criteria are the examples you will demo — what correct looks like. The QA testing checklist is how you proved them: environment, cases, evidence, and sign-off on the same work item.
Can we report on incomplete QA lists?
Checklist for Jira exposes progress on the issue, on boards, and in JQL so incomplete QA work is filterable.
Should bugs and stories use the same QA list?
Start from one template, then trim. Bugs often keep the full pass. Stories can drop security or platform rows when the change is low risk. Save a second template by issue type when the two lists stay different.
Put this on the work item with Checklist for Jira
Templates, automation, workflow gates, and a Rovo agent — free for teams of up to 10 users.