How We Handle Bugs Found During Development
Bugs are an inevitable part of software development. What matters is how they are identified, prioritised, and resolved. This article explains our bug management process.
Types of Bugs
- Functional bugs: The software does not behave as specified (e.g. a button does nothing when clicked)
- UI/Visual bugs: The interface does not look as designed (e.g. misaligned elements, wrong colours)
- Performance bugs: The software is too slow or uses too many resources
- Security bugs: Vulnerabilities that could be exploited (treated with highest priority)
- Data bugs: Incorrect data is stored, displayed, or processed
Bug Triage & Priority
When a bug is reported (internally or by you during UAT), we triage it:
| Severity | Definition | Target Fix |
|---|---|---|
| Critical | System unusable or data loss risk | Same day |
| High | Major feature broken, no workaround | Within current sprint |
| Medium | Feature impaired, workaround exists | Next sprint |
| Low | Minor cosmetic or edge-case issue | Backlog / as capacity allows |
Who Logs Bugs
During development, our engineers and QA team log bugs internally. During UAT, you log bugs via the portal or shared UAT tracker. After go-live, bugs are raised as support tickets.
What Counts as a Bug vs. a Change Request
A bug is something that does not behave according to the agreed specification or acceptance criteria. If the specification was correct but you want something to work differently, that is a change request — not a bug. Your Project Manager will help identify which category applies when there is ambiguity.