Resolved To Test

Bug reports vary greatly in length and complexity depending on your product, corporate culture and needs but there are some fields that I believe are a must for any bug report. A bare minimum, if you will. This happens to be my own list and other testers will have different fields they consider mandatory but I tend toward a bit of minimalism.

Title
A clear and concise title helps everyone. I make it a practice of putting unique information in the title like error codes or exe names. This makes it easier to later search the bug tracking system for duplicates or regressions rather than file a new bug.

Environment
A summary of the environment the bug occurs in as it relates to what you are testing. It could be as simple as the operating system or as complex as the os, browser, version of flash, etc.

Priority
How important do you think this bug is to fix? This should be important to the overall product and it may be higher priority if it’s blocking other testing or progress.

Product or Feature Area
What product (in a shared tracking system) or what feature area this bug occurred in. This serves to help when deciding who to assign bugs to or what areas of the product need concentrated attention.

Assigned To
This is the current owner of this bug and who is responsible for the next action with it.

Repro Steps
These are the steps, in order, required to reproduce this bug. They should be complete enough that someone unfamiliar with that bug can accurately reproduce it. I recommend a numbered list. If an additional file or script is needed to reproduce the bug, the location of that should be noted here or the file or script attached if the bug tracking system supports it.

Summary
This is a clear statement of what the issue is and why this is a bug. This is the place to make a case for this bug to be fixed so customer impact as well as expected behavior should be listed. If the bug is not high priority, that should be listed here as well. This is not a place to try to game the system and artificially cry wolf on bugs that really don’t deserve it.

Opened By
Who opened the bug. This allows questioning of the person, if necessary.

Opened Date
Date the bug was opened. This is useful for determining bug age.

Opened Version
This is the version of the product the bug is being reported for. It tracks what version was tested, no matter the date the bug was filed.

Fixed By
Who fixed the bug.

Fixed Date
Date the bug was fixed.

Fixed Version
Version of the product the fix will appear in. This allows the person verifying the fix to know when to expect it to be fixed instead of guessing.

Closed By
Who verified the bug was fixed.

Closed Date
Date the bug fix was verified.

The basic purpose of creating and tracking bugs is to improve the product you are testing. It seems really simple, almost too simple, but every other purpose bugs and bug tracking is made to serve in addition to this one can dilute this focus and create problems. You have to take each choice to use the bugs and your bug tracking system and consider what that choice can mean to the goal of product improvement.

Here are several real-world examples of situations where a secondary use for the bugs and bug tracking system affected the primary focus:

• Zero Bug Mandates
  There’s a very common rule on teams I’ve worked on that the product cannot be shipped if there are any open bugs. Obvious and makes sense, no? It does make sense in theory, but what I’ve seen happen in practice is that the team focus shifts from making the right decision for the product to making sure that bug count is at zero and stays there. Good bugs are discarded with inadequate investigation or review. Bugs are closed instead of deferred. Bugs aren’t filed because the tester doesn’t believe they will receive the correct attention and instead they are forgotten or scrawled on a notepad so the tester might file them later-if they remember to do so.

  If your project has a Zero Bug Mandate, you have to make sure you have a process that supports bug retention, addressing the bugs that don’t make the cut for the current release but which do need to be addressed. You also need to encourage people to still file the bugs they find right away. Depending on how you track bugs, you may want to create a new database or release for the next iteration of the project for these bugs. If you are using an agile process, this are part of the product backlog.

• Bug Metrics as Indicators of Individual Performance
  Sometimes a decision is made to use bug metrics as a way to measure the performance of team members. The typical logic is that bug activity correlates to “work” on the part of the various team members and there should be a way to use these concrete bug metrics to judge how much work any team member is doing relative to other team members. It sounds good, but what it does not take into account is that all bugs are not created equal in terms of severity, work to find, work to fix or effort to find or regress. The effort moves from a focus on finding and solving bugs as expeditiously as possible to finding and fixing a large quantity of bugs, regardless of their quality or the quality of the fix.

  If you are using bug metrics as a measure of individual performance, you need to insure it’s not the main way performance is judged. Bugs should be assessed for root cause and similarity and duplicates or related bugs identified as such to prevent cluttering the bug tracking system and unduly influencing your measurement process. Honestly, bugs are a very poor measurement of performance and I never advocate using them for that purpose for individual team members.

Stay tuned for Bug Report Basics!

I was reading a blog post on uTest.com by James Whittaker called Thoughts on the Future of Software Testing and one thing that really jumped out at me from it is the issue of mentoring in Software Testing.

I’ve had the benefit of several very good mentors and, in turn, have mentored other testers over the course of my thirteen years in software testing. I know James has put out a call to testers to take mentoring seriously and I’d like to second that but also offer a short list of does and don’ts from my own experience:

• DON’T wait for someone else to break the ice. If you have another tester your respect and would like to learn from, go ahead and ask if they can spend a little time teaching and mentoring you. If you see a promising tester you think you can help, ask them if they’d like you to mentor them. The worst thing that can happen is that they turn you down.
• DON’T treat a mentor/mentee relationship as if it were a marriage for life. Even informal or short term mentoring relationships can have considerable value without having to sign up for a long-term or potentially unsustainable relationship.
• DO set expectations on both sides. Part of a good mentor/mentee relationship is having a clear and upfront agreement on expectations from both mentor and mentee. Lack of this typically leads to disappointment, resentment and a failure of the relationship.
• DO keep an open mind. If you go into a mentoring relationship, you won’t get much out of it if you aren’t open to other ways of doing things or the learning opportunities you may encounter.
• DON’T limit yourself to only other testers as mentors or mentees. Learning from other disciplines and teaching test theory and techniques to other disciples can be valuable as well.

Mentoring can be a great help to any professional, and testers in particular.