Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars.

based on an article titled “Broken Windows” by James Q. Wilson and George L. Kelling in March 1982. You can find a bit more about the background here.

It is my belief that the same thing happens with products and product development. When bugs start to accumulate in an area and where the bugs do not get fixed, you will as a tester lower your standard on what is a bug or not by comparing the new found ones to the vast amount that already exist. Eventually you might get the feeling that you might not even bother reporting bugs, because you know that they won’t get fixed anyhow.

I think this is mainly a managerial problem. Examples of these kinds of problems can be when…

• focus is on implementing new features, just getting them in there
• covering an area with tests is more important than actually finding bugs and getting them fixed
• the threshold for getting a bug fixed in the late stages of a project requires earth quakes or miracles

Many other testers talk about this phenomena as when products are going rotten or something similar.

How serious is this problem for testers? What do you think?

What is essence of the discussion on release team/showstopper meetings?

I am assuming that there is a meeting. I’ve been to many different kinds of showstopper meetings and most companies handle them differently. One important item on the agenda for the meeting is usually the bugs that are found late in the project, thus at the end phase where they might be considered showstoppers.

When these bugs are discussed if they are to be fixed or not, I’ve seen cases when the argument is a bit vague. The actual topic is sometimes not brought to the surface, instead it is someone who “feels” that this should be fixed or it should not. What is it that they feel? Articulate those feelings and try to be clear on what it is you see. Why should it be fixed or why shouldn’t it?

In these cases I think it is best to be clear that we talk about cost, at least in most cases, in one sense or another, thus the cost of not fixing it or the cost of fixing it. Some costs will affect support, others will affect marketing and sales and some will affect development itself. I can recommend trying to get everyone attending the meeting to focus their thoughts on what the bugs will cost you. Is a few days slip perhaps worth it? In some cases the date for the release is extremely important, this is most often the case for bigger organisations. Instead it is easier to make some changes after the release decision and make a few patches afterwards. The actual release will not reach the customer the same day anyhow. Either way it is cost you discuss and you most often decide based upon it.

Cem Kaner has written an article on this that I’ve used many times when setting up these meetings. You can find the article here.