Ask HN: How do you track bugs filed against an in-review feature? | Hacker News Reader

Ask HN: How do you track bugs filed against an in-review feature?

2 pointskareemm1 comment

I've built software project management software and still haven't seen a great solution for this.

Here's the scenario:

1. You wrote a new feature and opened a PR 2. Your UAT/QA people test it 3. They find bugs / issues to address

Where do they put those issues? Some options:

1. They add them as comments on the original feature ticket. This seems like a bad idea because comments don't have a state (needs doing, done, won't do) so it's hard to track how much work is left to do.

2. They add them as tasks on the original feature ticket. Not terrible but hard to record repro steps (with images etc if necessary) as a task

3. They add them as NEW issues and link them to the original issue. Still not a great option: if linking doesn't happen, the new issues are orphaned. Plus it's a bunch of work to relate issues (in some issue trackers).

I default to #3 solution but wanted to see if there were other approaches I hadn't considered.

My goals are:

1. Capture bugs with repro steps and urls/pictures if necessary

2. Be able to triage them (will do / won't do), assign them, and have state (open, in progress, closed, etc) to see how many are left to ship the original feature

3. Do it with as little pain as possible.

How do you solve this problem?

Just my two cents, but I think you're taking a good approach with #3.

Reasoning:

In addition to the task-state problem you mention, it's nice to treat written feature requests as near-immutable. Updates to them after they're written -- especially when initiated outside the development team -- can lead to the classic complaint around "ever-shifting requirements". So that's another reason to avoid #1.

Subtasks (approach #2) is a bit better, but again it involves changing an object/document that may have previously been considered relatively stable.

Perhaps you had estimates and sprint scopes attached to the parent task -- if so, adding/modifying subtasks could invalidate (or at least confuse) those.

Under these considerations, #3 therefore wins as a kind of 'append-only log' of tasks.

If you can, and if your organizational culture supports it, you could ask QA to indicate whether they feel that the issues they raise reflect problems in the original requirements, or implementation problems.

That way you may be able to align product managers with precise requirements authorship, and developers with quality implementation by identifying and improving the areas where bugs are being raised.

Of course, QA intensity and output could vary as well, so it's not foolproof. And as with any theoretical work process, it often falls apart due to practical considerations like staffing changes, project/company direction shifts, and so forth. So you shouldn't cling to it at the detriment of the team's health and progress.

But the long and short of it is that #3 seems like a good approach to me :)

Reply on news.ycombinator.com