Cannot Reproduce

Image from : viZZZual

Call me old fashioned, but in all of my years working nothing has beaten a good old face to face conversation with a developer about an issue or bug in the software. Using a bug tracking system as the primary means of communication is a “no no” for me.

Yet, last week I was chatting with a seasoned test manager who was extolling the virtues of bug reports. Now, I’m a fan of bug reports (in moderation) and I’m a fan of tracking issues (though not necessarily in a bug report) and I’m also a major fan of communicating clearly, but I also like to get things done with the least amount of friction. But this test manager was suggesting that bug reports are the single best form of communication between developers and testers and therefore every single bug should be logged in a defect tracking system mainly for no other purpose than communication. Communicating through bug reports is “fundamental” apparently. 

 

In my view, communicating through bug reports is a sign of some deeper issue within that organisation. If you are using a lifeless remote system to communicate between two humans as your primary medium of communication then you are destined to have lost meaning, wasted time and rework. You have a problem.

 

When we write things down we often (not always) lose information and more often than not, in the case of defects, waste lost of time bouncing bugs backwards and forwards when a simple conversation might have cleared the whole thing up. It often means the bug reports themselves are more thorough and complete when the developer and tester have chatted about the issue in advance. Now I’m not adovcating badgering a dev each time we find something, but I am suggesting we stop and think about how best to communicate the issue. Think about The Purpose, The Audience and The Context.

Would it be easier and quicker to show the dev the issue and talk it through before raising a ticket for it?

Or would it be easier to raise the ticket and then talk it through?

Or would the ticket clearly explain the issue without talking it through?

Or should I raise the ticket and then sit back and wait for the inevitable bounce back with “cannot reproduce” or “as designed”?

Or do we even need a ticket in the first place?

 

Here’s an over the top example, but scarily it’s not far from the reality I’ve seen in the past,.

Read More

Translated in to Russian – I’m honored

I do feel honoured indeed to have had a blog posts translated in to Russian for the very excellent http://software-testing.ru community. Very honoured indeed and it was great to be in touch with Alexei Barantsev from the http://software-testing.ru community. I love what they are doing in the community. It also looks like the Russian testing community has some very exciting training and learning initiatives, so if you’re in Russia and want to learn more then check them out. I get a sense I may need to brush up my Russian language skills 🙂