Project template
Bug Tracking Template: A Board Built for Defects
Four stages out of the box, and a separate defect workflow you can point at your own status list. Most QA teams add three or four statuses in the first fortnight, and this page tells you which ones.
Bug and issue tracking is in Cloud and Self-Hosted · Unlimited users on every plan
What the Bug Tracking template sets up
Choosing Bug Tracking starts the project on a board with the Bug Tracking Workflow, which is four statuses: Backlog, Ready, In Progress, and Done. Work is grouped into task groups. It is important to be accurate about what it does not do: it does not switch on a separate defect module, and it does not enable sprints or epics. Orangescrum does hold defects as their own work item type with their own status workflow, and a project has a defect workflow setting separate from its task workflow, but you choose that yourself rather than inheriting it from the template.
The board
The four stages it starts with
Deliberately short. It is a queue you can start using in the first minute, and the statuses a QA team really needs are the ones you add after a week of real traffic.
01
Backlog
Reported, not yet triaged. Nobody has decided whether it is real or how serious it is.
02
Ready
Triaged, severity agreed, owner assigned. Waiting to be picked up.
03
In Progress
Somebody is investigating or fixing it right now.
04
Done
Fixed and verified. The queue no longer holds it.
Add your own statuses from the board or the status workflow page. The four most teams add are Cannot Reproduce, Duplicate, Awaiting Information, and Ready to Retest.
On day one
What you get on day one
Enough structure to start logging defects immediately, and no structure you have to unpick later.
A board as the landing page
The right first screen for a live queue, because you want to see where things are stuck at a glance.
A four stage defect workflow
Backlog, Ready, In Progress, Done. Short enough that nobody has to be taught it before the first bug goes in.
Drag and drop triage
Move a card from Backlog to Ready and the status changes. Triage becomes a fifteen minute pass rather than a meeting.
Task types and labels
Classify by component, environment, or severity, and filter the board by them.
A separate defect workflow setting
A project has its own defect status workflow, chosen independently of the task workflow. The template does not set it, but it is there when you want defects to move through different stages from tasks.
Room to add the awkward outcomes
Cannot Reproduce, Duplicate, and Deferred are real outcomes, and they need statuses or they clog the queue as pretend open work.
Who it is for
Who picks this one
QA teams
The main case. A queue that shows you what is untriaged, what is being fixed, and what is waiting to be retested.
Learn more →Support engineers
Customer reported problems that turn out to be product defects, escalated from a ticket and linked back to it.
Learn more →Teams running incidents
The same board shape works for live incidents, with the incident statuses on top.
Learn more →First week setup
What to configure after a week of real bugs
Do not configure this on day one. Log real defects for a week, then add exactly the statuses and fields you found yourself wanting.
Statuses to addUsually 4
- Cannot Reproduce, so failed investigations leave the queue honestly
- Duplicate, linked to the original rather than silently closed
- Awaiting Information, for bugs blocked on the reporter
- Ready to Retest, so QA can find what is waiting on them
Fields to addCustom fields
- Environment, so you can filter production from staging
- Affected version, so you know what shipped broken
- Severity, as a field rather than a label people forget
- Detection method, if you want to know how bugs are found
Rules to write downOne wiki page
- What critical, high, medium and low actually mean
- Who runs the daily triage pass, and when
- The rule for closing: retested, not merely fixed
- When a bug becomes a won't fix, and who decides
The built in templates set structure rather than content, so none of this arrives ready made. Once your defect project works properly, save it as your own template so the next one starts the same way.
The problem
What this template fixes
Bugs in three places
✓ One queue, on a board, with a status on every item.
No visible triage stage
✓ Backlog and Ready are separate, so the untriaged queue is a filter away.
Defects sit in the wrong workflow
✓ A defect workflow set separately from the task workflow.
How to start
Start a project from this template
Five minutes to create, and then leave it alone for a week.
- 1Create a project and choose Bug TrackingThe project opens on a board with the four stage defect workflow already in place.
- 2Invite QA, developers, and supportSupport are the people who find most of the bugs that matter. Unlimited users on every plan means they belong in the project.
- 3Log real bugs for a weekResist configuring anything. You will learn more from a week of real traffic than from an afternoon of planning.
- 4Add the statuses you actually missedUsually Cannot Reproduce, Duplicate, Awaiting Information, and Ready to Retest. Add them from the board.
- 5Add the fields you kept asking forEnvironment and affected version, as custom fields so you can filter and report on them.
- 6Write the severity definitionsFour sentences on a wiki page, linked from the project. This is what stops everything being marked critical.
- 7Set up a daily triage passTwo people, fifteen minutes, filtered to the Backlog status. Daily beats fortnightly by a wide margin.
- 8Set the defect workflow if you need oneIf defects should move through different stages from ordinary tasks, point the project's defect workflow at its own status list.
Pairs with
The features this template leans on
Custom fields are on the Pro plan and above, and in Self-Hosted. Advanced search is Self-Hosted.
Bug and issue trackingDefects alongside the delivery workCustom status workflowThe statuses you add in week twoCustom fieldsEnvironment and version as real dataTest case managementClose a defect against a passing testBug triage use caseThe full triage workflow, step by stepAdvanced reportingResolution time and where bugs come from
Frequently asked questions
Bug Tracking template FAQ
What statuses does the Bug Tracking template create?
Four: Backlog, Ready, In Progress, and Done. This is the Bug Tracking Workflow. Most QA teams then add Cannot Reproduce, Duplicate, Awaiting Information, and Ready to Retest once they have seen a week of real defects.
Does this template switch on a separate bug module?
No, and it is worth being precise about that. It starts the project on a board with a defect oriented status workflow. Orangescrum does track defects as their own work item type, and a project has a defect status workflow separate from its task workflow, but you set that yourself rather than inheriting it from the template.
Should I configure the statuses before I start?
No. Log real bugs for a week first. Teams that design the workflow up front consistently build stages nobody uses and miss the ones they needed.
Can defects follow a different workflow from tasks?
Yes. A project has a defect status workflow that is chosen separately from its task workflow, so bugs can move through Cannot Reproduce and Ready to Retest while ordinary tasks stay on a simpler flow.
How do I stop everything being marked critical?
Write down what each severity level means, in four plain sentences, and link it from the project. Severity inflation is nearly always a definition problem rather than a discipline problem.
Which plan do I need?
Bug and issue tracking is in the Cloud and Self-Hosted editions. Custom fields, which is how you capture environment and version properly, are on the Cloud Pro plan and above and in Self-Hosted.
Can I link a defect to the test case that found it?
Yes. Test case management lets you raise a defect from a failed test and link them, so a defect is closed against a passing test rather than a developer's word.
Can support tickets become defects?
Yes. A customer ticket that turns out to be a product defect can be raised as a defect and linked back to the ticket, so support can see the fix progress without chasing engineering.
Get your defect queue on one board
Four stages to start, the rest added when you know what you need.