Bug Report Attributes Part 4 – Version & Iteration
Posted by Eric Jacobson at Wednesday, March 06, 2013Two 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.
Nice post Eric !! I have seen this confusion quite a lot in my team where we didn't maintain build numbers. Then we created an assorted build number using the build date and time and then we switched over to SVN build numbers and revision numbers. That helped a lot in terms of categorizing the defects and primarily avoided the confusions you mentioned above.
- Rajaraman R
TDM Blog
Agile Blog