Željko Filipin's Blog on Software and Testing

Yesterday I blogged how TortoiseSVN 1.4.1 Crashes. I could not just click “Send” button at error report window because I have recently reinstalled windows and I did not have default e-mail client configured (I use Gmail only). As a tester, I know a value of error report, so I wanted to send it. Also, I really like TortoiseSVN so I wanted to contribute. Configuring Outlook Express to use Gmail servers took some time, but fortunately I have done it already, so I knew where to find documentation.

I usually send error reports (especially when all I have to do is click a button), but there is usually no response. The exception is Arachno Ruby IDE, but that is another story.

This morning, I was really (pleasantly) surprised when I found this in my inbox (posted with permission):

It’s a bug in Subversion when using the neon 0.26.2 library. I’m currently working with the Subversion guys on a fix for this. In the meantime, either deactivate SSPI authentication on the server or downgrade to TSVN 1.4.0. Sorry for the inconvenience.

Stefan

--
       ___       "De Chelonian Mobile"
  oo  // \\      TortoiseSVN
(_,\/ \_/ \     The coolest Interface to
   \ \_/_\_/>    (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net


Please notice the turtle in the signature, I really worked hard to reproduce it as in original, but with limited succes (I used SimpleCode).

Not only did I get the response, but there was also two workarounds for my problem. I do not have access to servers, and I have already downgraded to 1.4.0, but it was nice of him to let me know. Actually, after he gave me permission to post his response, he (once more) apologized for not having a fix “because we lack a test environment with a windows domain”. 1.4.0 works fine for me, I upgraded by mistake (that is also another story), so as far as I am concerned, they can take their time. Also, I will surely send them all error reports from now on.

If you treat your users with respect, they will help you make better software.

A few weeks ago, my developer resolved a case that was opened for two years and one day. It was minor bug (priority 4), but that does not matter. Our application has changed so much in that two years that, of course, it was not reproducible. But that does not matter, either.

What matters is – that bug was open for over a two years.

At that time, I just have read Joel Spolsky’s The Joel Test: 12 Steps to Better Code. There is question: “Do you fix bugs before writing new code?” No. To be honest, we did not have a feature freeze for a while.

Isn’t it demotivating to know that bug that you have reported would not be looked at for a while. When will it be resolved? Better not to think about it. I pointed that to my developer, and he promised that he would do his best.

Since then, he was closing many bugs. Just this morning, he said that he has resolved all bugs with priorities 1, 2 and 3 (showstopper, critical and major). I immediately checked our bug tracking software (all testers know that developers cannot be trusted ). Then, I have built the latest version of our application and verified that all bugs are resolved.

There are still over one hundred open bugs, but they are all minor and trivial (priorities 4 and 5). I think that we did not have this situation since I started working here. Over two years.

I have a strange feeling now. I am so motivated to find new bugs. I have noticed some strange behaviour in our application, but I did not have time to look into it. Until know.

There is always one more bug*.

I have just read a short article, Don’t Use Bug Counts to Measure Testers by Cem Kaner.

The last paragraph:

If you really need a simple number to use to rank your testers, use a random number generator. It is fairer than bug counting, it probably creates less political infighting, and it might be more accurate.

Brian Marick mentioned it at agile-testing@yahoogroups.com.