If it’s possible to determine which Feature/Story/Requirement introduced a new bug, it’s probably valuable to use a bug report’s “Link” attribute to link the bug report to said parent Feature/Story/Requirement.  Here are some reasons this is valuable:

• It tells the programmers roughly where the bug was created.
• It may help to decouple “Escapes” from “New Feature Bugs”.  Escapes are usually more difficult to trace back to specific Features.  Perhaps your team does not count linked bugs as part of WIP but unlinked Escapes are counted as part of WIP.
• It tells the team the bug is a dependency to its linked requirement’s deployment (e.g., the bug will follow the Feature into other environments if it is not fixed).
• If you can link to the Feature from the bug report, the Feature may provide more context for the bug report.

Another way I like to use the bug report “Link” attribute is to associate bugs to each other.  When BugA get’s fixed, it introduces BugB; linking the two together allows us to use briefer language in the bug report like, “this bug was created by the linked bug’s fix”.  Generally the link itself makes it easier to view the linked bug report, than merely referencing the Bug Report ID.

Two other bug report attributes I find useless are “Version” and “Iteration”.  We no longer bother to populate these.

I used to think these were important attributes because the team could use them to answer questions like:

• How many bugs did we find in Iteration 16?
• We think Bug1001 is fixed in version 1.2.7.  What version were you testing when you found Bug1001? Oh, you were testing version 1.2.6, that explains it.

Now days, I realize counting bugs found in test is not a helpful measure; especially since we’ve focused more testing in the Dev environment and often fix bugs without logging bug reports.  In addition, many of my project teams have switched to Kanban so “Iteration” is a seldom used term.

Regarding the second bullet above, I came to realize that most bug report templates have “Created Date”, an auto-populated attribute.  I also learned every version of the software under test has an auto-populated build deployment history.  If we cross-reference a bug report’s created date with our build deployment history, we can always identify the version or iteration of the code the bug was found in.  I would rather fall back on existing information (in the rare cases we need it), than capture extra information every time (that normally gets ignored).

In practice, questions like the second bullet above, never get asked.  As long as one populates the Environment bug report attribute, confusion rarely occurs.