I recently got an email from a developer/tester from Norway asking for an opinion about the typical relationship between developers and testers and any advice for testers on how to work together with developers.
Let me start by saying: I think it’s complicated.
The first job I had, there weren’t any testers. Naturally, there weren’t any testing processes. There were no development life cycles. There was a whole lot of nothing where you got some kind of requirement, worked on it, fixed your bugs and hoped and prayed that it would work.
The second job was completely different. We had a test department with three full-time testers and a few students working part-time. There was a development life cycle supported by the tools needed to get a requirement all through from specification to implementation to testing to bug fixing to release. There was not a feature going out, not a bug fixed that didn’t go through testing first. This also meant that testing (together with product management) had the power to stop a release from happening.
Of course, there was more involved business-wise, but from the development’s point of view, the testers job was just as important as the developers. I’m not saying that testing is more important than writing code. It’s as important. You don’t have one without the other. If you do, you’re doing something wrong.
I hope I’m not speaking for myself, but I’d say that there was neither rivalry nor one role looking down on the other. We worked as a team trying to release a product and we had to work together to do so successfully.
So, that’s how it should be.
As a developer I’ve worked with pretty amazing testers. The kind you give your feature to and know they will come back to you with bugs you never could imagine. The kind you trust to test your feature so well that it really will come out with as little bugs as possible (because as we all know, there’s always one more bug). The ones that will save you from utter embarassment because they will remember what you forgot before it gets released to customers.
There are a couple of things I am thankful for in testers:
a) They’re doing something for me that I don’t want to do. Testing is not for every developer. Some are crappy at testing, some are doing a fine job, some are actually pretty good at it, but still don’t feel especially thrilled when having to do some testing.
b) They’re my net of safety. I would like to say that when I’m done with a feature it is ready for release, but I know that it isn’t. There is one basic rule that you should never test your own code and that rule is there for a reason. But it also helps if you have dedicated testers instead of developers, because they don’t have the same impatience that developers do. Give a developer something to test and they want to be done with the testing and move on to the next feature to implement. Give a tester something to test and they want to FIND. THE. BUGS. Of course I’m generalizing here, but I think I’m not too far off.
But it remains that there are a lot of developers who seem to NOT be thankful for testers. Or – equally worse – those who look down on testers as second-rate teammate just doing the monkey work that nobody else wants to do. Having seen a development cycle were testing as well as testers were taken serious as hell, this screams utter bullshit to me.
Sure, release testing is a tedious, tedious thing that everyone hates. EVERYONE. And writing up a test script and ticking it off isn’t something that sounds especially awesome.
But here’s something that a tester from my last job told me: It’s like actively and creatively destroying something that wasn’t meant to be destroyed. It’s taking apart something that should hold together. And as a developer and a quarter-time tester (thanks to Scrum) I must say that I know the tickling feeling when you found a bug that was carefully hidden, but you still managed to drag it out into the open and smash it.
The same tester also said that sometimes it is hard working with developers. As a tester you can’t help but telling someone they made a mistake. And developer’s seem to be a sensitive species who like to take criticism of their feature rather personally. Instead of „I found a bug here“, they might hear „You did something wrong, stupid“. Which is not what the tester said, but still.
Developers might see a tester as an obstacle to having their fine and working code released. I’ve actually had consultants try to circumvent testing because it took too much time and the customer wanted that feature NOW. Well, the customer unsurprisingly always wants their feature NOW, but they also want it to work. Naturally, features who don’t go into at least a somewhat proper testing phase will always be buggy and in the end will cost you more time than if you had given that tester the extra day they said it would take them to test it properly.
Now as to the actual question on how to approach developers as a tester, I first want to give the advice one of our QA managers said I should give: He called it The Mom/Dad Approach and it boils down to somehow making the developers understand that you really mean them no harm, you just want them to be better and you want the feature to be as bug-free as possible. (Hint: Don’t be patronizing though. Developers will pick up on that and hate you for it.)
Also, make sure that you understand the technical side. You might not have the same technical background and you might not understand the details of the implementation, but try to understand that there is something technical going on and the small bug you just logged might mean a load of work for the developer.
Maybe offer to sit down together and look at what you found together (this might also help you weed out the „works on my machine“ replies). Communicate. Ask.
After all, you are working towards the same goal. Nice, working software. It’s a mystery why some managers and developers think that this can be achieved without testers, because it can’t. Testers are testers because they think differently. Because they are willing to dig deeper into the software than everyone else. And because they take a job that will piss off others by nature.
There was an awesome web comic I found once about typical developer replies to bug reports, but I can’t find it again. Instead, have fun with this one, it’s equally close to reality:
Maybe I should have called it "uncle/aunt approach", parents *can* be quite patronizing at times…
One thing developers (and development managers) oftentimes forget is that writing a good test script is not easy. It takes years of practise to ask all the right questions and forget none. It requires you to read between the lines of the specification, look behind the facts and think around the obvious. Developers often are focussed only on the "new", on the change – they fail to see the big picture and consequently miss important risks or details. That is not saying all devs do, I just think good testers have a way of thinking outside of the box and gently reminding everyone there is a product to build, not just a feature.