If you’ve read “Everything I need to know about Manufacturing I learned in Joe’s Garage” then you’re familiar with the part where they’re discussing power drills. Having many tools in use at the same time means that, statistically speaking, it is more likely that one will break at any given time. Thus, if you become reliant on a lot of drills, you must have lots of backups.
Having too many fields in a defect entry form, or any workflow for that matter, is like having too many drills in your shop. If you ask people to use so many fields, you’ll probably get very few of them right all the time. Suddenly, just opening a defect requires you to fill out dozens of fields, when in fact nobody runs are report off any of those fields at all. I can’t think of very much that you need to enter into a defect field:
- who opened it (which the system can figure out from who is logged in)
- when it was opened (which the system can figure out as well). I don’t see a need for a separate “when was it found”. Although there’s probably a lag between found and opened, I’m not sure that it’s so critical that you need people to enter it. Also, probably a date/time for each change to the ticket, but the system can automatically do that too.
- what test phase were you in (or production if you didn’t catch it). Useful for containment calculations.
- what system were you working on. Yes, I know you could include build numbers, etc, etc. but the combination of the date and the system ought to be enough to clue a developer in to what version was being run at the time in test. For production, if you allow various versions to be in the field at the same time this might be more useful.
- a status (open, closed, ready for restest). Notice there’s no cancel or deferred. A cancelled ticket is a closed ticket that didn’t get a code change (or some other resolution). A deferred defect is open… it isn’t fixed.
- a description of the problem.
What else do you really need? Keep it simple and minimize the risk of a field being full of useless junk. Think really, really hard about whether you truly need that field you are adding. Start by studying a random sample of tickets. Add the new field on a spreadsheet only and classify the sample. Mock up some reports – figure out what you think that information would tell you and if there’s any action you would take on it. If not, you don’t need it. Let the system auto-populate anything it can to minimize data entry.
Avoid too many fields in your system, just as you should avoid too many drills in your shop.