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.

My bug report template includes a Severity attribute but my teams don’t bother populating it.  The severity choices on my template are:

We leave it on the default.

Try as you may, to objectively define Severity, and it is still arguably subjective.  “Loss of Functionality w/Work Around”…well, if we are creative enough, we can always come up with a work around; let’s use the legacy process.  “Data Corruption”…well, if we run a DB script to fix the corruption is this bug still severe?

From my experiences, it has been better for humans to read the bug report description, understand the bug, then make any decisions that would have otherwise been made based on a tester’s severity assessment. 

As an example, if the bug report description does not indicate the system crashes, and it does, it is likely a poorly written bug description.  One shouldn’t need a Severity to pigeon hole it into.

My advice?  Save the tester some time.  Don’t ask them to populate Severity.  Benefit from the discussion it may force later.

IMO, Priority should not be populated by testers.  My teams use a customized version of Microsoft Team Foundation Server’s bug work item template.  For whatever reason, Priority is a required attribute upon logging bugs.  It defaults to “Medium” and I never change it.

From my experiences, testers often overstate bug priority, wanting to believe the bugs they found are more important to fix than other work that could be done.  Some testers see themselves as the saviors of the user-in-distress.  I see myself as the information gatherer for my development team and stakeholders.  I don’t understand the business needs as well as my stakeholders, thus I remove myself from making claims about bug priority.

• Priority is a stakeholder question and it’s always relative to what else is available to work on.  A High priority bug may be less important than a new Feature.
• From my experiences, Priority does not lead decisions.  It follows.
• Tester: “Per our process, we will only patch production for High priority bugs”.
• Stakeholder: “Well, obviously we need to patch production today”. 
• Tester: “But said bug is only a Medium priority”.
• Stakeholder: “Then change it to a High”.
• IMO, Priority is all but useless.  The more High priority active bugs one has, the more diminished it’s label becomes.  A better label is “Order”, as in let’s rank everything we can work on, from most important to least important, where each item has a unique ranking order.

Reader, Srinivas Kadiyala, asked if I could share my bug report template.  A bug report template high level view might be boring so instead let’s examine bug report attributes individually.  Here’s Part 1.

Environment. 

Environment can be more or less useful depending on how one populates it.  Some testers equate Environment to the environment the bug was found in.  IMO, Environment is more useful when it equates to the lowest active version of our software the bug exists in.

If a skilled tester finds a bug in the QA environment, they will probably  next determine if it exists in the production environment.  If it does, IMO the bug report should have Environment = Production (even though the bug was originally found in QA). 

Now we have helped answer/trigger important questions for the team:

• Yikes!  Should we patch production ASAP?
• Are we going to break something in production if we deploy the QA build without fixing this bug? 
• How many bugs have escaped into production? We can query on this attribute to provide one of our most important measurements.