Your relationship with testers
No one will argue the business benefits of testing. Reliability can mean the difference between a customer trusting you with his credit card details or moving to the competitor just one click away. But how do you, as a developer, work with a team of people whose full time job is to find your mistakes?
Not so long ago, Derivco dedicated their 4th Dev Evening to testing methodologies. I went home that night with one thing on my mind. The key issue that strains relationships between developers and testers is that we put a lot of effort into our code, and we don’t like being told it’s broken.
“We put a lot of effort into our code, and we don’t like being told it’s broken”
After giving it a little thought, and bringing in some tight deadlines alongside our testing team, I wanted to put down some dos and don’ts of communicating with your testers.
When you are surrounded by defect tracking systems and dashboards, it’s easy to lose touch with the human side of testing. If you are lucky, the testers will be sitting a few meters away from you. If you aren't, you will be working with teams that aren't even in the same country, let alone the same building as you are.
Regardless of your situation, seek out these people, sit with them wherever possible, and get to know them in whatever way you can. They will almost always be giving you bad news, so being able to balance that by laughing with them and working with them will make the process far less strained.
This effort really pays dividends when deadlines are tight and tempers are short. Your ability to communicate and effectively leverage off past experiences with your testing teams can mean the difference between a project’s success or failure
We have to trust our testers. They are our safety net, but the fact remains that their role asks them to be suspicious of everything that we do. Their responsibility is to reduce the risk that your work presents to the product.
“They are our safety net”
We can’t ask them to trust our code, but we can ask them to trust that we won’t affect areas of the product that lie outside of our scope of work. That we will deliver on time, and that the quality will be high when we do.
If they can rely on us to do this, testing can plan their test cases around an isolated piece of work. They can get bugs back to us faster and ensure that our code ships on time, as promised.
I don’t need to mention that this trust can be easily broken, and is very difficult to repair. This will only result in late defects, constant regression testing and never ending distractions once you have moved on to other tasks.
Don’t make excuses
If you are like me, the moment a defect is logged you will feel the need to justify yourself. Don’t. This can be one of the hardest things to do, especially at 2AM when all you want to do is go home. So does your tester, and finding this bug is just as bad for him as it is for you. He now has to wait for you to fix your mistake and then test it again.
Now is the time to smile, to understand the problem, and fix it, if you can.
It’s all too easy to point to configuration problems, caching or even network issues, but doing this without at least some investigation will turn every bug into a confrontation. Sometimes your code will be working exactly as it should, but you need to open youself up to the fact that you might have made a mistake.
Keep an open mind and try to remember that they aren't out to get you. We are all fallible, we all make mistakes, and even the best developers slip up. We just need to be grateful that we have testers to catch us when we do.