Developers vs. Testers

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:

by David Wilborn /

Kindle – First Impression


Not nearly two weeks ago I finally ordered my Kindle. I’ve been wanting one since last year, but with the new job, the move and everything I pushed it further and further. I had convinced my husband that it would be a nice idea when we were still busy packing up box after box of books and bringing them to our storage. It’s very easy to convince your better half of the advantages of a device that is supposed to hold up to 3,500 books when you have been busy filling more than fourty boxes with books. (Actually, I don’t know how many boxes with books we have, but there are a lot of boxes in storage and I’d guess about 80 percent are filled with books.)

So. On that famous Thursday in February I finally went ahead and did it. It was delivered the very next Monday, which is pretty fast, considering it went all the way from the US to Germany and I immediately picked it up and loaded The Name of the Wind on it. (Mostly because I had listened to an interview with Patrick Rothfuss on the Sword and Laser podcast and he talked about Joss Whedon which is the maybe easiest way to make me like you.)

I was afraid that reading on an e-book reader wouldn’t be my thing. I thought that I might miss the feeling of a book in my hand. Miss actually buying books or having them sent to me in neat little packages and looking at the covers. Afraid that I liked the way a book’s weight changes from one side to the other while you’re reading it.

Fortunately, all this isn’t the case. Or, maybe it’s the other way round, I enjoy the advantages of the Kindle so much that I don’t have time to miss the real book feeling.

Let me first say that the screen is perfect. It really looks like a writte page, perfectly clear and readable in sunlight. There are a couple of reflections when bright light shines directly on it, but that’s all. When I first held it in my hand I was amazed at how small it is and even more, how incredibly light it is. You can hold it comfortably with one hand and press the next page button with your thumb to read practically anywhere.

It took me a couple of pages to get into it, but I very soon forgot that this was not an actual paper book I was holding. It might have helped that The Name of the Wind is such a great read, but I figure it is just that you need some adjustment time to get used to the feeling of an e-book reader. Then you easy like it or not.

I will keep up with more impressions or remarks as I continue carrying my Kindle around with me, but for now, here are a few early comments on the experience:


  • The delivery was awesomely fast. I expected at least two weeks, and it got here in five days. You pay for customs on checkout so that it gets through quicker. Very smart.
  • It is very comfortable to read with, mostly because it’s so light and you only need one hand to hold it and turn the pages. Which makes it easy to pretty much read anywhere, even standing up in a bus or so.
  • Can’t say much about the battery time, but there’s plenty. I have WiFi on all the time, which is supposed to drain the battery somewhat faster. I have charged it once since I originally got it (and not counting the first time I charged it), but that was mostly precautionary.
  • PDFs work okay. I haven’t tried the convert feature so far, just loaded some PDFs I had on my laptop to check how they looked. The font is usually smaller, but it looks generally okay.
  • Most of all: I love reading on it. I was afraid I wouldn’t, but I do. I hope it’s not just enthusiasm, but given that I read nearly 700 pages in less than a week, I’d say that it’s a pretty neat device to read on.

The only irk I had and sometimes still have is a usability issue that I think I just need to get used to (and probably already have). I used to press the „next page“ button on the left side to go back a page every now and then. Somehow the feeling of using a real book got mixed with how the buttons are adjusted. But I also realized that I like the fact that I can hold the Kindle with either hand and just keep turning the page, so I think this is really just something that you need to get used to (if you even have that problem to begin with) rather than faulty design.

Now I’d like for more and more books to be released as e-books as well as Amazon rolling out German books for it. I know there are already some available, but I couldn’t find any current books that I would like to read. And now I’d like to snuggle under the covers and continue reading The Passage.