Bug tracking for small teams without a QA team

A screenshot lands in a Slack DM. A customer email gets forwarded with "is this us?" typed above it. The founder hits something on their phone at the weekend and mentions it on Monday, in a thread about something else. A fourth turns up during code review and gets fixed in the same branch, silently.

That is bug tracking for small teams as it actually happens: four intake channels, no owner, and reports in whatever form the person who noticed happened to type. The same bug gets filed three times because nobody can search the first two, and the fix ships without anyone closing the report, so the person who raised it finds out weeks later by trying the thing again.

The work does not disappear with the role

A team of six with no QA engineer still has QA work. Every bug needs four things done to it: reproduce it or establish that it cannot be reproduced, decide whether it gets fixed before the next planned thing, land it with one person, and tell the reporter when it is done.

None of those become optional just because they are nobody's job. They land on whoever noticed, which selects for the person least able to drop what they are doing, and is why the fourth one goes missing. Nobody forgets to fix a bug they care about. Everybody forgets to tell the support person it is fixed.

What the heavyweight setup assumes

Worth knowing what the processes real bug-tracking operations run actually require, before copying their shape.

Severity scales are calibrated by people whose job is calibrating them. Mozilla's severity field runs from S1, "(Catastrophic) Blocks development/testing, may impact more than 25% of users, causes data loss, likely dot release driver, and no workaround available", down to a trivial level for cosmetic issues. A new bug defaults to --, which "bug triagers for components (ie engineers and other core project folks) are expected to update" (wiki.mozilla.org). Four levels only mean anything if four people apply them the same way, and that consistency is maintained work rather than a dropdown.

Triage is a named role with a schedule. Mozilla's triage policy puts a triage owner on every component — "Engineering managers and directors are responsible for naming the individuals responsible for triaging all types of bugs in a component" — expects new bugs "quickly assessed on a daily basis" and "fully triaged, or under active investigation, within one week of being created", and runs rotations off a shared calendar (firefox-source-docs.mozilla.org). That is a function with an org chart behind it.

Every workflow state is a handoff. WebKit's documented bug life cycle moves through UNCONFIRMED, NEW, ASSIGNED, REOPENED, FIXED, VERIFIED and CLOSED, and getting a bug out of UNCONFIRMED needs "someone with Bugzilla canConfirm privileges" (webkit.org). Each state exists because a different person picks the bug up there.

None of this is bureaucracy. It is the right answer for a project with thousands of external reporters, where an unconfirmed report genuinely might be nothing. Copy it onto a team of six and you inherit the states without the people who move work between them — see the signs your workflow has too many statuses for what that looks like from the inside.

What bug tracking for small teams actually needs

Four things, and only one of them is a meeting.

One intake point. Not one intake channel — you cannot stop bugs arriving in Slack, in email or verbally, and trying to only produces fewer reports. The rule is about the destination: whoever receives a bug copies it into the tracker the same day, even badly. A two-line issue beats a perfect report that never got filed. For the quality of the reports themselves, hand people how to write a bug report that gets fixed once.

A priority field, not a severity taxonomy. Severity and priority are genuinely different questions — how bad is it, versus when do we fix it — and on a small team only the second gets acted on. Three or four values answering that one question. A matrix will not be applied consistently by four people who each fill it in twice a month.

Triage as a fifteen-minute weekly habit. Same slot every week, whole team, whole list of open bugs. For each one: is it real, does it matter now, who has it. A habit survives someone being on holiday in a way a role does not, and the fifteen-minute version gets done where the hour-long one gets moved.

Closing the loop with the reporter. The part people skip, and the one with a compounding cost. The mature processes formalise it — WebKit's verification step is "typically done by the person who originally submitted the bug report" (webkit.org). Small teams drop it entirely, and the effect is not that a bug stays open. It is that the support person, the designer and the founder learn that filing a bug produces no visible result, and go back to mentioning things in passing.

How this maps onto Kevta

We build a tracker, so treat this section as the advert it is; the details are checked against the product rather than the marketing.

Status and priority are not special built-in bug fields — they are select properties on the board, and a new board arrives with To Do, In Progress, In Review, Ready for QA and Done, plus Low, Medium and High. A team without a QA function will want that fourth status gone, which is a settings change rather than a workflow redesign. A Steps to reproduce field is a text property — one field on one board, not a scheme governing which screens show which fields. The tasks and fields documentation covers the seven property types.

The closing-the-loop part is the one worth knowing. Creating a task subscribes you to it, and so does commenting, so the person who filed the bug is on the thread without opting in, and a status move sends them a notification naming the status it moved to. Discussion and the full change history live on the issue, so the reproduction argument is findable a month later. And because a pull request is matched back to the issue by its key, the rule that ships enabled moves the issue to Done when the PR merges — the report gets closed by the merge rather than by somebody remembering.

Where it will not help: there is no error-monitoring integration and no crash reporting, so a human files every bug. There are no file attachments, so a screenshot goes inline in the description or a comment. Notifications are in-app only, so the reporter hears next time they open Kevta rather than by email. And there is no reporting layer, so if the question is "is our bug count going up", Kevta will not answer it. It is in beta, and it is a simple bug tracker rather than a QA platform.

The habit is the transferable part

Most writing about bug tracking assumes the thing a small team does not have: somebody whose week has room in it for triage. The four practices above work in a spreadsheet or in GitHub Issues just as well, and the order matters more than the tool — intake first, because a bug nobody recorded cannot be prioritised, and the loop back to the reporter last, because it decides whether anyone reports the next one. For every other field and ritual, ask what you would ask of a severity scale: who reads this, and what changes because of it. That is the same test worth applying to everything a small team tracks.

Kevta is in beta and opening to a few teams at a time, if you want to try the tracker side of it — join the waitlist.