Thursday, September 27, 2007

Celebrity Bug Watch


If you are a bug and you manage to escape the erstwhile testers, it must be a dream come true to become famous. What usually happens is that these bugs with dreams of becoming celebrities wind up becoming waiters or waitresses, or at best part-time models, while waiting for their "big break" that never comes. Every once in a while however, a bug gets the attention of the critics and the press and become famous.


That is happening now with the Excel 100000 Bug, or E100k as it is called among friends. This bug's talent is that if you multiply 77.1*850, Excel will display 100,000 instead of 65,535 as it should. I don't know about you, but it happens to me all the time. Joel Spolsky offers an explanation of why this bug occurs, in case you care.


I'm glad I am not the tester that let this bug get by. Given the press that this thing is getting, I'm sure the Microsoft execs are getting all in a dither, and are in turn getting the upper management stirred up, who are taking it out on middle management, who must be going after the 1st line manager of the Excel Multiplication QA Team. That means this manager will ask this poor tester "Why did you not find this bug?"


I hate that question because there is no good answer to it. There are lots of good reasons why bugs get missed, but when you have upper-management involved, every valid reason sounds like an excuse. What can this tester say ?


  • "I tested 77*850 and 77.2*850, and since they both worked, I thought it was good to go."

  • "I didn't know there would be any math involved"

  • "You mean 77.1*850 is not 100,000?"

  • "I assumed no one would want to calculate that product"

  • "Clippy told me it was OK"

So whatever the reasons for this bug getting out, and the consequences, let me just say Congratulations to E100K on making the big time.

Friday, September 21, 2007

Testing Outside The Black Box

Much of what we focus on as quality engineers is determining the quality of a given application. Software testers test software, but software is not all that software companies produce. Companies also produce web sites, demo applications, marketing material, and more. Who is responsible for the quality of this stuff?

Hopefully the teams that create these things have systems in place to ensure their quality. Realistically, you might as we that all bugs will fix themselves, the company stock will triple every year, and there will be pizza and chocolate cake every day. It could happen, but don't count on it.

As an example, my company just launched a book widget gallery. The purpose of this blog is to showcase our SmartLink widgets for books by a set of authors. The hope is that these authors and their fans will see these widgets, love them, and put them on their own sites. It uses our technology, but it is not one of our products. It would be an easy thing for test team (aka me) to say, "Well, that is a marketing thing, so we don't need to worry about it." The problem is, it is the testers that have the mad bug finding skills, so who better to do testing, even of stuff that is outside our "responsibilities". As such, I went ahead and did some testing on the gallery, and continue to keep my eyes on it.

So, ask yourself, where else in your company can things go wrong? For everywhere you identify, then ask yourself what you can do about it. This may mean venturing into areas that testers have never been, but any wise person in your company will appreciate your insights into how to make things better. Think of yourself as a missionary of quality.

Tuesday, September 18, 2007

When Quality Goes...

My current all-time favorite hobby is photography. Being a Web 2.0 guy, a large portion of the time I spend on this hobby and the enjoyment I get from it comes from sharing my pictures online as part of a community. For the past year or so, my photo sharing service of choice has been Zooomr. Last spring, Zooomr released Mark III, and said it would change the world. It was a very bumpy launch, the site was down for many days, and even now, many of the features we had in Mark II have yet to resurface.

Yet, I still stay with Zooomr, and so do many others. For every person however, there is a line past which they can't take it anymore, and will leave. Raoul Pop, a great photographer, longtime Zooomr advocate, and one of my "friends" on Zooomr has had nearly enough of the missing features and serious bugs that get promises instead of fixes, and that is why he is taking a break from Zooomr. If you read the comments of his post, you'll see that many other users are like minded, and unless something changes, Zooomr could be in trouble.

This blog is about finding bugs, but as Zooomr shows us, just knowing about the bugs is not enough. As testers, we can't just find a nice stack of bugs, then put our feet up on the desk, smoke a big cigar, and congratulate ourselves on a job well done. Instead, we have to make sure that these bugs get fixed.

What if there are no dedicated testers? In the case of Zooomr, the job of testing mostly falls to the user, since they have no QA staff, as far as I know. When quality is important, the tester serves as the first customer. When the customer serves as the first tester, there is a problem. A loyal user might tolerate bugs and missing features, report them, and even fight for the fixes. But most users aren't that loyal, and will instead just leave quitely.

When quality goes, so go the users. When the users go, so goes the company.

The point here is not to single out Zooomr as a company in trouble. Unlike Raoul, I'm not ready to take a break from Zooomr. At least not yet. Intead, this post should be read as a reminder, not just for Zooomr, but for all software companies, that the cost of not fixing bugs is usually much higher than the cost of fixing them.