Managing Bugs

Good Product Managers are also good testers. They look at a product through the naive eyes of their target customer, temporarily ignoring all the assumptions that have gone into the design and development, and they find all the "holes" that customers may fall into. No matter how well written the product requirements are, or how good the developers are, the software product under development will always have a hole or two. Finding and fixing holes in the development process means fewer customer service contacts after the product is launched.

Holes are usually one of three types:

Broken functionality - ranges from a broken link to a complete crash.
Unexpected behavior
Cosmetic issue

Anyone engaged in software product development uses some kind of bug tracking system to capture and track any issues that are found during testing. Depending on the number of holes you're tracking, this can range from a spreadsheet to a high-end commercial system. In all cases, the most useful template I've found for reporting a hole is as follows:

STEPS TO REPRODUCE
1.
2.
3.
What are the specific steps on the path this issue? Note that there may be more than one path that leads to the issue; I usually report the one or two I have found and let the professional testers find any others. Also, if there is no way to reproduce the issue, it probably doesn't belong in the bugbase. In that case, it's best to talk to someone in the testing department about what you've seen.

EXPECTED RESULT
What were you expecting to happen next?

ACTUAL RESULT
What happened instead? What looked broken? What did and didn't work?

I've seen quite complicated bug categorization systems, but the following two categorizations have always worked for me:

SEVERITY
Critical: Prevents access to functionality.
Major: Has a major effect on functionality, but a workaround exists.
Minor: Small and/or cosmetic bugs.
Enhancement Request: Nice to have as time permits.

PRIORITY
Priority 1 (P1): High severity issues that impact many or some customers.
Priority 2 (P2): High severity issues that impact few customers, and medium severity issues that impact many customers.
Priority 3 (P3): Medium severity issues that impact some customers, and low severity issues that impact many customers.
Priority 4 (P4): Medium severity issues that impact few customers, and low severity issues that impact some or few customers.

Holding a Bugfest

An interesting idea that I've tried in the past when QA resources were limited was holding a bugfest. A couple of hours on a weekend were blocked aside for employees and their families to come in to the offices and, by following a specific series of (relatively fun) tasks we created for them, find as many bugs as they could. We even held a contest for the person who found the most bugs. We held ours in the morning and brought in bagels, muffins, and other breakfast treats. Everyone had fun, and we also got some great general product usability feedback from one of our first non-employee audience of users.