Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /bug-and-issue-tracking.md or by requesting this URL with the header Accept: text/markdown.
Bug and issue tracking

Bug and Issue Tracking, Connected to Delivery

Log a defect with the detail your team actually needs, route it through your own workflow, and keep it linked to the task, sprint, and test case it came from.

Available inCloudSelf-HostedOpen Source

Free forever plan · No credit card required · Set up in minutes

What is bug tracking?

Bug tracking is how a team records defects, decides how serious they are, assigns them, and follows them to a fix. Orangescrum keeps defects in the same system as the delivery work, so a bug is always connected to the task that introduced it, the sprint it affects, and the test case that found it, instead of sitting in a separate tracker.

The problem

Why bugs get lost

Bugs live in another tool
Defects are tracked separately, so the sprint board looks healthy while the bug list grows.
Defects sit alongside tasks in the same project.
Not enough detail to act
A bug says it is broken, with no severity, steps, or evidence.
Structured fields capture severity, priority, root cause, and attachments.
No link to what caused it
Nobody can tell which change or release introduced the defect.
Defects link to tasks, sprints, versions, and test cases.
What you get

Defect tracking with real structure

Grouped the way a defect is handled: what the record holds, how you classify it, how it moves, what it links to, how you work the list, and what you can prove afterwards.

01Defect record

  • Title, summary, and steps

    Every defect carries a title, a short summary, and a full description of how to reproduce it.

  • Severity and priority kept apart

    How damaging a defect is and how soon it should be fixed are two separate fields, so triage stays honest.

  • Reporter, assignee, and owner

    Three separate people on the record, so who found it, who is fixing it, and who owns it are never confused.

  • A due date and four estimates

    A due date, plus original and remaining estimates kept separately for development and for QA.

  • Environment, component, and impacted area

    Record where the fault appeared, which component it sits in, and what else it touches.

  • An automatic defect number

    Each defect gets its own running number, so people can refer to it in a conversation.

  • Labels

    Tag a defect with as many labels as you need and filter the list on them.

  • A corrective action note

    Write down what was actually done about it, kept separate from the description of the fault.

02Classification

  • Severity, issue type, and category

    Three separate lists that say how bad it is, what kind of defect it is, and which area it belongs to.

  • Phase, origin, and root cause

    Record where the defect was introduced, where it came from, and what actually caused it.

  • Resolution and activity type

    Close a defect with a reason from your own resolution list, and record the activity that produced it.

  • Fixed and affected versions

    Say which version the defect affects and which version the fix lands in.

  • Every list is yours to edit

    Add, rename, and remove entries in all ten lists, with a separate permission controlling who may.

03Workflow

  • Your own defect statuses

    Defects follow the custom status groups you define rather than a fixed set nobody can change.

  • Reopen a closed defect

    A fault that comes back is reopened on the same record instead of being logged all over again.

  • Control which moves are allowed

    The Self-Hosted edition lets you define which status can follow which, and demand a resolution before anything closes.

  • Response targets by severity

    In the Self-Hosted edition each severity carries a target time, and the list shows how long is left or how far past it you are.

  • Reopen count and closing times

    The Self-Hosted edition records how often a defect was reopened and exactly when it was resolved and closed.

04Traceability

  • Link a defect to a task

    A defect points at the task it came from, and you can search for and link several tasks at once.

  • Raise it from a test case or a step

    A failing test case, or one individual step inside it, can raise the defect and the link is kept.

  • Attach it to an epic or a feature

    Defects can sit under the epic or feature they belong to, not only under a single task.

  • Pull defects onto the sprint board

    Switch defect planning on and defects appear in the backlog and sprint board next to your stories.

  • Link one defect to another

    The Self-Hosted edition records that a defect duplicates, relates to, blocks, or is blocked by another.

  • Merge duplicates

    Close a defect as a duplicate of another in one action, in the Self-Hosted edition.

  • File a defect from another system

    The Self-Hosted edition exposes a token authenticated endpoint so another tool can raise a defect directly.

05Working the list

  • Filter on the fields that matter

    Narrow by issue type, severity, phase, category, status, assignee, owner, reporter, activity type, linked task, or due date.

  • Sort and group it

    Sort by any column, and group the list by status, severity, phase, root cause, fix version, or date.

  • Twenty three columns you can toggle

    Choose exactly which columns the defect list shows, and your choice is remembered next time.

  • Search by text

    Type a word and the list narrows to the defects whose title or detail matches it.

  • Saved views

    The Self-Hosted edition lets you save a set of filters and keep it private or share it with the team.

  • A board as well as a list

    The Self-Hosted edition adds a board where you drag a defect between status columns.

  • Change many at once

    The Self-Hosted edition lets you set severity, priority, status, assignee, or resolution across a selection.

06Evidence

  • Screenshots, logs, and files

    Attach whatever the developer needs to reproduce the fault, and remove anything that turns out to be wrong.

  • Replies on the defect

    Discussion happens on the record itself, so the history of a defect includes what people said about it.

  • The assignee is emailed

    When a defect raised from testing is assigned, the new owner gets an email with the detail.

  • Watch a defect

    The Self-Hosted edition lets you follow a defect you did not report and be told when it moves.

  • Every field change is kept

    The Self-Hosted edition records each field change with the person who made it and the time.

  • Announce it in Slack

    The Self-Hosted edition can post new defects and status changes into a Slack channel.

07Reporting

  • A defect trend over time

    See how defect volume moves across a date range, bucketed the way you choose.

  • Breakdown by status

    See how many defects are sitting in each status right now.

  • Breakdown by severity

    See the split across severities, so you can tell whether the serious ones are being cleared.

  • Export the list

    Export the whole defect list, or only the rows you ticked, to a spreadsheet.

08Access

  • Four separate bug permissions

    Separate rights to view your defects, view everyone's, edit the lookup lists, and open the reports.

  • Members see their own scope

    A member without the view all right sees only the defects they are involved in, while owners and admins see everything.

  • A permission set of its own

    The newer Self-Hosted test and defect module carries seventeen permissions of its own, including separate rights to create, edit, and delete defects.

How it works

How a defect gets resolved

1
Raise it
Log the defect with steps, severity, and evidence, or raise it straight from a failed test case.
2
Triage
Set priority and assign it, so the team knows what to pick up first.
3
Fix and link
The fix is done as normal work, linked back to the defect and the version it lands in.
4
Verify and close
The test is rerun, and the defect closes with a full history of what happened.
Who it's for

For teams that ship software

Software and QA teams
Defects tracked alongside sprints and test cases, with full traceability.
Learn more →
Support and operations
Issues raised by customers routed into the delivery team's real workflow.
Learn more →
Agencies
Client reported issues tracked transparently through to a fix.
Learn more →
Availability

Which edition includes what

Orangescrum runs as managed cloud, self-hosted on your own servers, or as the open-source Community Edition. Here is exactly what each one includes.
Bug and issue tracking is in the Cloud and Self-Hosted editions. The rows below show where the deeper parts sit.
CapabilityCloudManaged SaaSSelf-HostedOn-premise / private cloudOpen SourceCommunity Edition
Defect records with severity, priority, and estimates
Ten classification lists you can edit
Root cause, phase, and origin
Fixed and affected versions
Filters, sort, group by, and 23 columns
Attachments and replies
Link defects to tasks
Trend, status, and severity reports
CSV export of the defect list
Custom defect statusesPro
Raise a defect from a test case or stepPremium
Defects on the backlog and sprint boardPremium
Configurable transitions and severity targets
Defect board, saved views, and bulk actions
Defect to defect relations and duplicate merge
Watchers, field history, and Slack posts
Public endpoint to file a defect
Tasks and subtasks
Frequently asked questions

Bug and issue tracking FAQ

Does Orangescrum have a bug tracker?

Yes. Orangescrum includes defect tracking with severity, priority, issue types, root cause, and custom workflows. Defects live in the same project as your delivery work and link back to tasks, sprints, and test cases.

Which editions include it?

Bug and issue tracking is available in the Cloud and Self-Hosted editions. Linking defects to test cases is part of Test Case Manager, which is on the Premium plan in Cloud and included in Self-Hosted.

What is the difference between severity and priority?

Severity is how damaging the defect is. Priority is how soon it should be fixed. Keeping them separate stops everything being marked critical and makes triage meaningful.

Can I raise a bug from a failed test?

Yes. When a test case fails you can raise the defect directly from it, and the link between the test, the step, and the defect is kept.

Can I use my own defect workflow?

Yes. Defects can follow custom statuses, and in the Self-Hosted edition you can design the allowed transitions, demand a resolution before a defect closes, and set a response target for each severity.

Can I track which version a bug affects?

Yes. Defects record the affected version and the version the fix lands in, which matters when you support more than one release.

Does it report on quality trends?

Yes. There is a trend chart over time and breakdowns by status and by severity, and the whole list exports to a spreadsheet.

Is bug tracking in the open source edition?

The Community Edition covers projects, tasks, and Kanban boards, which many teams use for simple issue tracking. Full defect tracking is in the Cloud and Self-Hosted editions.

Track bugs where the work is

Bug and issue tracking is in the Cloud and Self-Hosted editions. Every plan includes unlimited users.