Excel as a Test Management Tool

Because you're going to use it anyway...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Managing Knowledge Transfer Sessions

Read the article, grab the templates

Ask questions

If you don't ask, you won't learn. You won't teach either.

Tuesday, 17 August 2010

Bugs, why are we raising them?

It’s troubled me for while – that we’re not clear on why we’re raising bugs. Sure, to get them fixed we say but there’s a whole bunch of ulterior motives.

One is to show how good we are as testers as we need to demonstrate how clever and effective our testing is right? I’ve pondered before whether a test case that doesn’t find bugs during the development/testing phase was a useful test case. That’s another discussion for another post.

A second reason to raise bugs is to beat developers over the head with them. Isn’t that how we often say it too? In partially comprehensible terms when we really mean it’s to show the developers they’re not as good as they thought and make sure they see we’re as good at what we do as they are at what they do. Pathetic point scoring nonsense.

When we raise a bug we’re identifying a task for a developer to work on. They work on it, the quality issue is resolved, proven to be so by our re-testing, rinse and repeat and we all help deliver working software. That’s why we raise bugs, to record tasks that need to be done and help deliver working software.

Now we can do other clever things such as creating bug taxonomies and carrying out root cause analysis to address systemic quality issues, improve productivity and reduce costs. However, in my experience that’s never done, memories are too short to care. Find the bugs, fix them, deliver working software in collaboration with your project colleagues not in confrontation with them.

Mark