Warning: this post has almost nothing to do with testing and it barely has anything to do with software development.  Managers should read it however.

Last night, at the Atlanta Scrum Users Group, I saw Peter Saddington’s talk, “The New Role of Management for High-Performance Teams”.  Peter has three master’s degrees and claims to be Atlanta’s only Certified Scrum Trainer.

Here are some highlights from my notes:

• Managers should see themselves as “managers of inspiration”. Don’t manage issues.  Instead, manage inspiration.  Help people love what they do first, then you don’t need to manage them.
• Everyone can improve their job performance by taking time to reflect.  Few bother to, because they think they are too busy.
• Stop creating processes.  Instead, change the rules as you go.  The problem with process is that some people will thrive under it and others will die.  There are no “best practices”; (Context-driven testers have been saying this for years).
• The most important question you can ask your directs is “Are you having fun?”.  Happier employees are more productive.
• Play and fun at work have been declining for 30 years (in the US).
• Burn-out rate has been increasing for 30 years (in the US).
• Myth – Agile teams should be self-organizing.  Fact, marriages are about the only true self-organizing teams that exist; only about 50% are successful (in the US).  Instead of hoping your teams self-organize their way to success, get to know your people and put them on teams that make sense for them.  Try re-interviewing everyone.
• If you learn 3 things about a co-worker’s personal life, trust is increase by 60%.  “How did Becky do at her soccer game yesterday?”
• Motivate your teams with these three things:
• Autonomy – People should not have to give it up when they go to work.
• Mastery – Ability to grow one’s craft.  Help people make this happen.  Put people in places where they can improve their work.
• Purpose – People do their best work when they know why they are doing it.
• Any manager who asks their directs to work on multiple projects at once, should be fired.  Study after study shows that multi-tasking and switching contexts burns people out and causes them to work poorly. 

Peter did a fun group exercise to drive home that last point.  He had some of us stand in a circle and take turns saying the alphabet or counting by multiples of 3 or 5.  He began forcing us to switch patterns on the fly, as we worked.  Afterwards, we all hated him and his stupid exercise.  …He was representing a manager.

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.

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.