Testers and Developers don't have to hate each other!

Developers will make anything they work on sound more complicated than a lunar rendezvous while maintaining everyone else's work would only be a generous "2 points, max". They'll often care an unhealthy amount as they create their fresh branch, likely planning a new code pattern or finally getting an excuse to do the refactor that's been annoying them for 6 months.

Fast forward a few column transitions and "longer than anyone could have expected". Plus 1,234 rounds of design alterations. And "that person" interrupting their progress twice daily for a "progress update". Understandably, they're done!

The feature is done when the developer is done.
- Sappo

Enter a tester, someone whose job role always seems to have unique existential stress. If they miss defects, they might need a new job soon. If they find every defect but piss off the entire engineering team while raising them, they might need a new job soon. If someone wishes to try a profit-boosting strategy of offshore testing, possibly even-further-offshore testing, they might need a new job soon. And finally, if they proactively develop a fantastic engineering culture of high quality, they might need a new job soon.

Needless to say, testers can be quite incentivized to raise tickets. So, when a feature reaches a tester, they have the same energy the developer had when they started the feature. It's my observation they often have even more. Time pressures are typically higher at this stage, and everyone longs for the QA "green light" with as much patience as a 5-year-old at 6 am on Christmas morning.

Then they find something. A few may think "Yes, Ha, This code sucks!" but most seem to be somewhat nervous when discovering something and try to approach raising defects in a way to minimize friction. Sadly, quite often to the same levels of friction anyway.

I've been a developer for over two decades, then jumped into a dedicated QA role for a few years before co-founding DoesQA. I've worked in great and terrible teams and have a few tips that will hopefully help.

Tips for testers:

Increase your understanding of development.

Wherever your skills are currently, increasing your knowledge will only give you more empathy for how hard it is to work in large development teams with constant deadlines. Coding is the easy part of the job.

Talk to the developer BEFORE you start testing!

It doesn't matter if they're your best friends or if you've never spoken to them before; talk to them before you start testing. I cannot stress enough. Ideally, this will be a quick chat/huddle, but dropping them a simple message will go a long way if you raise issues. Cover the following:

1. Let them know you're about to start testing one of their features with a link to the ticket

2. Ask them if anything was more complicated than they expected.

3. Ask them if any areas deserve special attention.

4. Ask them if they'd like you to reach out before raising anything or if they would prefer to keep their head down on whatever they moved on to.

Avoid using words like Defect, Bug, and Regression,

These are valid technical words, but we're all human, and if you want a good working relationship, it's worth the effort to come up with some slightly more creative terms. I did a talk in Cardiff, Wales, where I made a case for using "Quirk". It's a little softer and sounds more like a question than a conclusion. "I found a quirk" vs "I found a defect".

Tips for Developers:

Increase your understanding of testing

I know you test your stuff, but in the same way development is more than just coding; testing as a job is more than just the testing part. You probably love coding but may, at least sometimes, hate your job. It's the same inside QA. Please understand that going long during the development phase will increase the pressure on QA. As a result, they may have less time but are expected to be just as thorough and confident. I've seen testers working late to make up for this all too often without anyone else noticing. When something goes long, try to support the testers. Just asking if they still have enough time will go a long way.

Allow a little overlap time

It's easy to neutralize yourself, Men In Black style, as soon as you move a ticket one column to the right. Have you had it where a defect gets raised, and you think, "Yeah, I vaguely remember working on that when I was just a kid" to be reminded you only moved the ticket two days ago? Stay involved in the tickets you've touched but are still in play; it'll help everyone if anything gets raised.

Caring looks great

In any team of developers, there'll always be some who care a bit more and others who care less. Everyone notices this. Arguing something isn't a defect looks much worse than saying "nice find" and then asking the ScrumMaster, Delivery Manager, or whoever is ultimately responsible for the team's output to triage the issue against everything else. Remember, quirks are a side effect of moving at pace; companies want you to move quickly and have QAs to allow you to do this.

Finally, here's one tip for everyone.

(if you only remember one, make it this one!)

Never say "hey", "hi", "yo", or whatever your go-to is in one message, then leave a long pause, then slowly start typing your actual message. Nobody likes watching those little dots bounce around with your "[YOUR NAME] is typing."

If you do this, you don't have a developer/tester relationship issue; you are just the worst! Please stop it.