There’s no shortage of articles on how to improve software quality via process improvement. Today I want to look at things from the other side, from the software developer’s point of view. I’ve been a developer for 30+ years and still write code every day. I enjoy designing something new, and I like the challenge of debugging a problem. Debugging is pretty satisfying for me, and I’m positive that most developers feel the same way.
We like mental challenges and problem solving; it’s what brought us into this industry, so I don’t mind someone finding bugs in my stuff. They’re almost always the result of some dependency or workflow that I didn’t consider. What drives me nuts though, is when it takes an hour to figure out the right setup to recreate a problem that I can debug and fix in 2 minutes. I’m not talking about the hard to duplicate intermittent problems and race conditions, just regular logic bugs. The actual debugging is satisfying, figuring out the setup is not. It wastes a lot of time, and I hate wasting time.
Time gets wasted because most bug reports are just a list of the steps; and maybe a general overview of the system state when the problem occurred. Defining bugs this way means that there will always be ambiguities in the setup, and as a result, bugs bounce back and forth between “active” and “cannot duplicate”. I promise that we’re not being lazy by marking bugs “cannot duplicate,” we want to fix bugs, really!
How can we make things better?
To eliminate this “ping pong” of bugs, and create a better relationship between development and QA, get your team to “speak the language of test,” which means they communicate with test cases, not with descriptions.
The key to enabling this workflow is to develop a test collaboration platform that makes it easy for all stakeholders to create and run automated tests. If you give your developers an automated test that demonstrates a problem, I’m positive that you’ll get quicker fixes and have happier developers.
Further reading
Daniel Graziotin, Xiaofeng Wang, Pekka Abrahamsson: Are happy developers more productive? In: Product-Focused Software Process Improvement
