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.

In response to my Don’t Forget To Look Before You Log post, bugs4tester asked how to prevent duplicate bug reports in large project teams that have accumulated >300 bug reports.

That's a pretty good question.  Here are some things that come to mind:

• Consider not logging some bugs.  One of my project teams does all new feature testing in our development environment.  The bugs get fixed as they are found, so bug reports are not necessary.  Exceptions include:
• Bugs we decide not to fix.
• Bugs found in our QA environment.  We are SOX compliant and the auditors like seeing bug reports to prove the code change is necessary.
• “Escapes” – Bugs found in production.
• Readers Ken and Camal Cakar suggested it may be better to err on the side of logging duplicate bug reports, than taking the time to go dupe hunting or worse, mistakenly assuming the bug is already logged.  I agree.  Maybe we can use a 120-Second-Dupe-BugReport-Search heuristic; “If I can’t determine whether or not this bug is logged within 120 seconds, I will log it.”
• Yes, it takes time to "look before you log", but you may gain that time back.  If, every so often, you find that a bug report already exists, you are saving the time it would have taken you to log the bug.  You are also saving the time it would have taken other team members encountering the bug report to sort through their confusion (e.g., “Hey, didn’t we already fix this bug?”).  IMO, dupes cause people to stare at each, trying to determine the difference, long after their context has faded.
• "Look before you log" time can be reduced with bug report repository organization.  Examples include:
• Can you assign bug reports to modules or other categories?
• Can the team agree on a standard naming scheme? For example: always list the name of the screen or report in the bug report title.
• Does your bug repository provide a keyword search that can only search bug report Title or Description?   If not, can you access the bug repository DB to write your own?
• Can you use keyboard shortcuts or assign hotkeys to dupe bug report searches? 
• Sometimes you don’t have to “look before you log”.  When testing new functionality, I think most testers know when they have discovered a bug that could not have existed with prior code.  On the other hand, some testers can recognize recurring bugs that have been around for years; in these cases the tester may already know it is logged.

Thanks for the fun question.  I hope one of my suggestions helps.

Shortly after logging a bug this morning, my business analyst kindly asked, “Is this the same as Bug10223, that I logged in October of 2011?”.

…It was!

Ordinarily, prior to logging production bugs that have been around for a while, I run a bug report query to search for open bug reports by keywords.  It takes about 10 seconds to determine if the bug I’m about to log has already been logged.  This morning I got lazy (and cocky) and just logged it.

It probably took 20 minutes of my time and my business analyst’s time to create a bug report that already existed, communicate about the confusion, and reject my duplicate bug report.

Look before you Log!

This sucks.  I’ve been testing all day and I haven't found a single problem. 

No, wait…

This is good, right? Clean software is the goal.  Alright, cool, we rock!  Looks like we’re deploying to prod tomorrow morning…just one more test…Dammit! I just found a problem!  I hate finding problems at the final hour.  This sucks.

No, wait…

This is good, right?  Better to have caught it in QA today than in prod tomorrow.  That’s what they pay me for.  Hey, here’s another bug!  And another!  I rock.  I just found the mother load of bugs.  This is awesome!!!

No, wait…

This is bad, right?  We’re either going to have to work late or delay tomorrow’s prod release.  I totally should have caught these problems earlier, it would have been so much cheaper.  I suck. 

What’s that?  The product owners are rejecting my bugs?  Really?  How humiliating.  I hate when my bugs get rejected!

No, wait…

This is good, right? It’s great that my bugs got rejected.  Less churn.  Now I don’t have to retest everything.

No, wait…I want to retest everything.

No, wait…maybe I don’t.

Ahhhhhhh!

Every once in a while, progs amaze me by casually offering some off-the-cuff solution to my major testing headaches.

I was trying to recreate a complex user scenario involving precise timing.  I needed a way to make a service hang (blocking other services), sneak some specific test actions through in the meantime, then unhang the service.  After assuming this would be way too complicated for me, my prog offered, “just use a SQL hint to put an exclusive lock on the table”.

A SQL hint is an addition to the query that instructs the database engine to do something extra, overriding its normal decisions.  The tabblock hint, wrapped in a transaction, allows you to put an exclusive lock on a table, preventing other transactions from reading or modifying said table.  I’m using MS SQL but Oracle supports a similar technique.

Here is how it works in a generic test example:

1. State A exists.
   
2. Lock the table:
   
   begin TRANSACTION
   UPDATE        tblCustomers
   WITH (TABLOCK)
   SET           Name = 'Fred'
   WHERE        (ID = 10)
   
   Note: The transaction remains open.  The update statement is irrelevant because we are going to roll it back.
   
3. Trigger the action you want to hang.  For example: maybe the current UI state is ready for female customers. You trigger a service that returns female customers from tblCustomers to display them on the UI.  Take your time, it won’t complete due to the tablock.
   
4. Perform the action you are trying to sneak in.  For example: maybe you  change the UI to expect male customers.
   
5. Now State B exists instead of State A.
   
6. Unlock the table:
   
   ROLLBACK TRANSACTION
   
   Note: execute the above statement in the same query session as the query in step 1 was executed.  The action that was hanging in step 3 completes, and in this example, female customers attempt to load into a screen expecting male customers.

So the next time you have a test idea that is too complex to execute in real time, try doing it in bullet time (using a tablock hint to slow things down.)

In Part 1 I focused on removing misleading details and unnecessary repro steps from bug reports.  I tried to make the case that a tester’s job is to narrow a bug’s repro steps down to only those actions or data that are actually required to experience the bug.

Now let’s discuss the exceptions and how to handle them.  Here are two reasons to include non-required data in bug reports:

• It is not feasible to rule out certain data as relevant.
• It is helpful for the person following the repro steps to reuse data already identified by the repro steps author, to save time.

IMO, the repro steps (and the bug report itself) should reflect that said data is or may be non-required.  I do this by providing the extra data in a comment for a specific repro step.  For example:

1. Create a new order.
2. Add at least two line items to the new order. (I added Pens and Pencils but it appears that any two line items cause the bug)
3. Submit the new order.

Expected Results: No errors are thrown.
Actual Results: “Object reference not found” error is thrown.

In some cases, there may have been significant searching to find data in a specific state.  One can save time for the bug report reader by providing tips on existing data.  For example, maybe the bug only occurs for orders in an “On Hold” state:

1. Open an “On Hold” order.  (I used Order# 10054)
2. Add at least two line items to the new order.
3. Submit the new order.

Expected Results: No errors are thrown.
Actual Results: “Object reference not found” error is thrown.

Again, the core repro steps more or less capture the relevant data pertaining to the bug.  The notes, speed up the repro process.  Look at how the opposite approach may mislead:

1. Open Order# 10054.
2. Add at least two line items to the new order.
3. Submit the new order.

Expected Results: No errors are thrown.
Actual Results: “Object reference not found” error is thrown.

The above instance makes the bug look like it is just a problem with order# 10054.  A skilled tester should have figured out the “On Hold” order state is key.

In conclusion, start with some repro steps.  Question each of your steps until you narrow them down to only the required data.  Then add any notes to aid the reader if necessary, being careful to offset those notes from the core steps.  That’s what I do.  What’s your approach?