What this template is for
Test plans are how mature teams stop having the conversation that goes ‘is this ready to ship?’ ‘I think so’ ‘me too’ ‘okay, let’s ship’. A written test plan converts implicit judgement into an explicit, queryable record of what was tested, what wasn’t, and what we agreed counts as ‘done’.
This template structures the discipline:
- Required fields on the create screen - scope, environments, entry criteria, exit criteria, risk areas. The exit criteria field is the keystone: it’s the document the team refers to on release day when someone asks ‘are we sure?’.
- STM-created execution sub-tasks - prepare environments, execute tests, triage bugs, run exit-criteria review, sign off. The exit-criteria review is the step teams skip when they’re behind schedule; making it a sub-task with an owner prevents that.
When to use it
Use this template for any release with non-trivial customer impact: new features, schema changes, major refactors, performance-sensitive areas. For routine patch releases, a lightweight smoke-test checklist is usually sufficient.
Don’t use this template to test individual stories - acceptance criteria on the story handle that. The test plan is for release-level testing that crosses stories.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Test plan: Checkout v3 release - regression + new flows | Yes |
Linked Epic / Release | RELEASE-4130 or EPIC-228 | Yes |
QA Lead | @qa.engineer.who.owns.it | Yes |
Test Scope (custom) | What's being tested - by feature area, not by ticket | Yes |
Out of Scope (custom) | What this test plan does NOT cover | Yes |
Test Environments (custom) | Staging / Pre-prod / Specific data sets | Yes |
Entry Criteria (custom) | What must be true before QA starts (e.g. all stories Code Complete) | Yes |
Exit Criteria (custom) | What must be true before QA signs off (e.g. zero open Sev1/2 bugs) | Yes |
Test Types (custom) | Functional / Regression / Performance / Security / Accessibility | No |
Linked Test Cases | Link to the test-case repository or attached spreadsheet | No |
Risk Areas (custom) | Code paths flagged for extra attention; recent regressions | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Define entry criteria with engineering - what must be true before QA starts
- Identify and document risk areas with engineering input
- Prepare test environments and test data
- Execute test cases - log results in the linked test tool
- Triage discovered bugs - log as bug-report tickets linked to this plan
- Run exit-criteria review with product and engineering
- Sign off and update release ticket with the QA outcome
Common questions
What should a Jira QA test plan include?
Scope, test environments, entry criteria (when QA can start), exit criteria (when QA is done), linked test cases, and explicit risk areas. The entry/exit criteria pair is the most useful: it makes 'when can we ship?' a written agreement instead of a meeting.
Should test cases live in Jira or in a dedicated test management tool?
Most teams use Jira for the test plan and a dedicated tool (Xray, Zephyr, TestRail) for the test cases themselves. The Jira test-plan ticket is the orchestration layer - what's in scope, who's executing, what passed - and links to the cases. Keeping test cases in Jira issues works at small scale but stops scaling around 100+ cases.
Who owns exit criteria for a Jira test plan?
The QA lead drafts them; the product owner and engineering lead sign off. Exit criteria are negotiation: 'zero Sev1 bugs' is non-negotiable; 'zero Sev3 bugs' is usually a compromise to 'documented in release notes'. Put the signed criteria on the ticket so the release-day conversation isn't 'wait, what did we agree?'.
How do you automate test-plan sub-tasks in Jira?
Build an STM sub-task template containing the plan / execute / report / sign-off sub-tasks. Wire it to an Executor that fires On Create Issue scoped to the test-plan issue type. Every new test plan gets the same workflow and the same accountability for the exit-criteria review.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →