Novell Cool Solutions

bug=bad. many bugs=bad product?


June 29, 2006 1:36 pm





bug in my last post i stated that we fixed over 900 bugs since designer 2.0m2. after posting i realized that i probably painted an inaccurate picture of what 2.0m2 was and what the overall product quality was. at least for people who are not familiar with the way we use bugs to manage the designer project it may be difficult to correctly interpret my statement. designer is high quality, extremely customer focused and constantly evolving.

most of novell engineering uses bugzilla as a development process, problem and enhancement tracking tool. bugzilla holds records – referred to as bugs – that are assigned to a responsible person and categorized into products and feature areas per product. each of these records (or bugs) has a severity and a priority assigned. the severity is set by the reporting party and is meant to indicate how important the record is where as the priority is assigned internally and determines the attention (importance) the record gets.

the severity field divides the records into two different groups: problems and enhancement requests. if a record’s severity is set to “enhancement” it describes a non-existing but desired functionality. all other levels assume a problem and indicate the importance of the problem.

now what makes the difference between an enhancement request and a bug? at first this seams obvious but very often it is not: designer does not currently provide any team enablement features like version control. a record (bug?) which asks for team enablement and version control would thus be given a severity of “enhancement”. if designer during a deploy was going to destroy data, a record (bug?) reporting this issue would probably be assigned a severity level of “major” or “critical”. but there is a lot of space between these two examples. imagine designer behaves in a way that is unexpected (wrong?) for you. if you reported this and requested a change of behavior would that be an enhancement request or a problem report? difficult to say.

we in the designer team use bugs for release planning, too. whoever has an idea enters a bug. often the severity level doesn’t even matters. then, when we get loaded to do our next milstone, we pull up all the open bugs and prioritize them. this way we make sure no idea is being forgotten. you as a customer can do the same. our bugzilla system is open for you. you have an idea or a problem? go to and tell us about it.

back to my original post: over 900 bug fixes does not mean we had 900 critical problems we fixed. it means that we worked down a queue of over 900 records in our bugzilla database who describe our current release. from the over 900 bugs approx. 110 were marked as enhancement requests right away. this leaves us with over 790 records. most of these are bugs reported by our internal test team. they try every day to break our code and report every success they have. this way we make sure what we ship is of shipping quality. so 2.0m2 was not a milestone that had over 900 problems, but 1.2 (2.0m3) is a release with loads of new features and many, many adoptions requested by you and many, many, many problems fixed before they even were able to hit you, the customer, because they were found by our internal test team.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.


  1. The actual breakdown for 2.0 M3 (Designer 1.2) is as follows:

    Blocker- 5
    Critical- 13
    Major- 98
    Normal- 686
    Minor- 56
    Enhancement- 110

  2. […] the designer part is much easier for me because we have our bugzilla database open to the public. this way you can easily create a changelog for yourself by running the appropriate query. to get all the bugs (remember that bugs are not always bugs) we fixed for 1.2 run this query. […]