Still Life

A Series of Mental Snapshots

Dealing with Bugs…

Posted by Steve on November 21, 2007

Filing Bugs / Bug Scrubs
—————————-

I have been giving thought to how bug scrubs go and it seems like there is some room for improvement. From what I have seen bug scrubs are done every day and they last about an hour, and have ~4-5 people in them. Say at an average of 40$ an hour, it wastes about 1000 dollars a week (which I guess isnt terrible) but there are bug scrubs for each product, so say 3-4 products we are up to 4000 dollars a week, which equates to about 200K a year, now we are talkin! Other then the money this wastes TIME, time that could be spent testing, developing, getting the product out the door etc… It just seems that there is a more efficient way to go through bugs. So I gave it some thought and came up with a possible algorithm.

The plan I came up with is as follows:
——————————

At the beginning of the test cycle introduce a few key things. I am going over what to introduce and what I think that would accomplish

The Testers and developers should know each other.
–> Face to face communication(encourage through a meeting with all developers and testers) can save a lot of misunderstanding and time.
–> When people know who they are working with they are more likely to work harder (because they know what they are working for).
–> Might result in more collaboration and idea sharing. Also a better team environment.

Testers should also know what area each developer works on.
–> This will allow a tester to assign a bug to a certain developer, and skip the bug scrub step for that bug
–> Less bugs in bug scrubs means less wasted time.

The Developers should know the testers
–> If a tester files a bug that they think is by design, they can face to face with the tester to find out if that is correct or not
–> If there is a disagreement, it can be placed in with other cases to be scrubbed.

How to assign Priority of Cases should be clear
–> If the priority of cases is clear, testers can assign priority on their own.
–> If the tester is not sure they can assign it to the developer and he can assign priority based on his thoughts
–> If the developer does not know, then it can go to the unscrubbed pile

Developers should be clear on what they desire in Bug reports
–>when are diags needed, when are stack traces needed, is a video always good?, should there always be screenshots?, what level of detail is needed?
–> This will allow for greater efficiency because no information will be missed (for example, I missed a stack trace that was needed once, simply because I didnt know I needed it)

I think that putting these processes in place could help do the following

–>Build a better sense of fellowship between developers and testers

–>More efficiency in bug resolution and bug scrubs

–>Less bugs to go through in bug scrubs

Any comments are always welcome

–Steve

Advertisements

2 Responses to “Dealing with Bugs…”

  1. Adam White said

    Bug scrubs may not be known to the world by this name. Some people call them bug triage meetings or simply triage meetings.

    Face to face communication *can* prevent misunderstandings. It can also cause misunderstandings if people don’t ask questions. People’s personality comes into play more with face to face communication so even if you are sitting down with someone to discuss – you may still not be as productive if you had sent them an email.

    Your premise that people work harder when they know who they are working for (and what they are working for) is a false cause fallacy. The idea that testers and developers knowing each other might result in more collaboration and idea sharing also falls into this.

    I’m not sure what you mean by a better team environment. One thing I notice is that when people get working well in a team they tend to talk alot about non-work related things, the take more breaks together, spend more time at the begining of meetings chit-chatting. This is a loss in productivity (if one adopts the view of an old-school manager).

    So having a better team environment might reverse into exactly the same problem you are trying to solve in the first place which is wasting time and decreasing productivity.

    BTW – the previous 2 paragraphs are used as a thinking exercise not as a complaint or greivance. I mean to show that things are rarely that black and white – and while we think that one course of action might fix the problem – once you push that course to it’s limits you can come full circle back to where you were.

    Bug scrubs don’t only serve as bug reviews. They are also a
    convenient place to discuss features, roadblocks, scheduling,testing, development, legal issues, concerns. Product decisions get made on the fly in these meetings. Sometimes this is where the reall “Action” takes place.

    Regarding priorities of cases and assigning of bugs. Testers can assign bugs directly to a developer but what happens is you get another reversal of desired effects.

    – the project manager doesn’t know what’s going on.

    – the development manager doesn’t know what’s going on.

    – the developer may not know the priorities that were discussed at the last bug scrub meeting or hallway run-in.

    – the testers don’t know if the developer has looked at his bug yet and has no idea where it is on the priority list.

    – product management has no insight into the key issues going on.

    – stakeholders get nervous and more time is spent in meetings trying to calm them down.

    Around info in bug reports. The answer to “being clear on what goes in a bug report” is that “it depends”.

    You didn’t know a certain stack strace was useful but now you do. This isnt’ the first time a tester forgot to include something that might be useful and it certainly won’t be the last.

    We could spend tons of time to document what should go in a bug report but then different types of bugs would require different amounts of information. So what do we do then? Write a document of each type of bug?

    Take our software for instance – you can’t attach job diagnostics when the install fails but you can attach the install log file.

    The overhead in documenting all the variations is staggering and wouldn’t be an effective use of time. We’d rather sit with you when you start here and coach you rather then burry you in 4 stacks of paperwork describing what to add to a bug in any given situation. You would spend an hour just looking up what to
    collect.

    I’m glad you are thinking about this problem.

    What we used to do in bug scrubs to save time is.

    – Everyone would review the bug list before coming to the meeting.

    – Developers would put time estimates in the bugs so we could get an idea of how long a fix might take. It was very rough estimate.

    – We wouldn’t edit bugs in the bug scrub so there aren’t 7 people sitting around watching someone type. This was done afterwards by the person running the meeting. (Think of all the time we waste watching people move bugs around and typing messages out.

    Here’s an experiement for you to do (if you want). Go to a bug scrub and record
    – how much time is spent watching people edit bugs.
    – How many interuptions there are.
    – How long it takes to get the meeting back on track after an interuption.
    – How many people are attending
    – How many people are late or don’t show up.

    Maybe do this through a few bugs scrubs and see what you come up with. I am willing to bet your results will be interesting.

  2. Fortune said

    Hey Adam,

    Thanks for the well though out response, and I almost feel like its a daunting task to respond to it = ), but I’ll give a few points I feel strongly about a go.

    First I want to quickly address what you used to do in bug scrubs to save time. I agree with reviewing bugs before the meeting. When people do not do that it seems that half the meeting is trying to explain what each bug is. Furthermore there are issues with bugs getting pushed because the people in the bug scrubs may not be the people who filed the bugs and therefore may not understand the issue properly, leading to it being assigned improperly.

    The other things that you did for scrubs I agree with…. less so. Firstly I think that people should put comments into bugs, too many times I have looked at a bug and have no idea why it was marked wont’t fix or by design. I am usually sure there is a good reason as I trust the team lead, but since there are so many bugs, many times it is forgotten after the fact why each bug was marked won’t fix or by design. This leads to a giant pain for when it comes time to close bugs, because personally I do not like closing bugs marked by design or wont fix without a good explanation!

    With respect to time estimates, I think that is a decent idea if the estimates are rough. An idea I just had would be to give estimates in days, as in it will be done by November 27th, instead of number of hours.

    Now looking at your point of view on the bug reports, I think I agree more with your stand point then mine. In general it seems that mistakes when filing a report will be made once or twice, and would be much less of an issue than putting a huge process in place that may or may not be correct when it is complete.

    I do agree that bug scrubs help let the key people informed, but I think there may be a better approach then have them all at a meeting. It may be helpful to devise a schedule so only key key people are at each scrub, and someone keeps loose notes, this does add some overhead to one person but it might be a viable solution. THen these notes are sent out with high priority to the people who need them so everyone is informed and if there are any questions an email/walk over could solve that. I am just throwing an idea out there, i dont know if its that great but might work = ).

    I feel strongly about a good team environment and the benefits it can bring, but I am feeling a little tired at this point, so I am thinking of writing a seperate post on team environment, hopefully it will be up tomorrow or tuesday at latest.

    Till then,

    later days
    –Steve

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: