My 2009 advice for programmers (on making - or keeping - testers happy)
A commenter on a previous post stated:
As a programmer I don't like to see bugs (and I don't like the QA ranting about the qaulity of my work either).
Could you post your "2009 advice to programmers" on how to make testers happy
I’m always open to suggestions, so I’ll share some thoughts. First, however, I’m a bit concerned over the word “ranting” above. I hope that the commenter has dealt with some poorly communicating QA testers who ranted rather than report issues, but I worry a bit that the commenter may be taking bug reports too seriously – bug reports are about the quality of the product – not the programmer. We testers understand that people make mistakes and want to take an equal part in making a quality product. If we point out a bug, it’s so we can all make the product better.
And now, on to my post. If you are a programmer and you want to make the testers around you happy, here are a few of my tips. Feel free to add yours in the comments.
Don't talk down to testers – they’re not bottom feeders lucky to have a job, and they’re not developers who couldn’t cut it. Most of us have chosen to be testers because we’re good at it and it gives us an opportunity to have a huge impact on software quality. The better we work together, the better job you’re going to do in the end. Software development is a joint effort between programmers and testers – if you want to be successful, you need a good relationship with your testers.
Write unit tests – Don’t make it easy for me to find bugs. Testers aren’t asking you to find every single bug, but at least test enough of your own code that testers won’t find bugs in basic functionality. The harder it is for testers to find bugs in your code, the more they will respect you. When testers begin finding complex bugs that you never thought could exist, you will respect them more too.
Think about testability – testable software is well designed software. Consider the SOCK model (Simple, Observable, Control, and Knowledge). Think about testing during design and implementation – ask yourself “’how will we know this works?”
Don’t avoid conflict - Conflict is fine (and expected), but everyone needs to feel that their voice is heard. When you disagree, explain why you disagree, and don’t expect to resolve every conflict.
More communication - Spend time talking about challenges of your roles. Understanding the other side helps you both do your job better.
Don't take bug reports personally - (note to testers: bug reports are NOT your avenue for belittling developers). Bug reports are a necessary side effect of the testers job. Bugs are just bits of information that you need to act on.
Don't get mad at a tester for finding a bug in your code - you should be surprised, or maybe even embarrassed depending on the details of the issue.
Feel free to offer testing suggestions - e.g. "It's going to be important to test how the string fields are translated between component x and component y", or "I’m worried that the component we’re leveraging from team z will cause compat problems, can you spend some time investigating?"
That’s a good start. Now, tell me what I missed.
Comments
- Anonymous
January 03, 2009
PingBack from http://www.codedstyle.com/my-2009-advice-for-programmers-on-making-or-keeping-testers-happy/ - Anonymous
January 05, 2009
Provide Real Information In Your Bug Report CommentsIn my shop, when a Developer marks a bug report as FIXED, she/he must also add a comment.Often I see terse, less-than-useful comments like "it's fixed", or "fixed in next build".Far better would be to:indicate what went wrong with the code that lead to the bugindicate what was done to fix the problem if the same problem was found and fixed elsewhere, indicate that provide any suggestions for extra testing when the bug fix is verified (hopefully more meaningful than "test everything") (Note: I don't allow my team of professional testers to rant about developers. And I won't accept developers ranting about my team, either)