My Job As A Programmer Is To Make Testers Miserable

It's not what you think.

When I deliver something to a tester or QA person, I want them to suffer terribly, to fear coming to work, to wish they had never become a tester, to be drained by the end of the day.

Yes, I want them to find nothing wrong except for the gnarly edge cases only a fiendish user would ever consider. That has always been my goal, that the last stop before userville is a short painful journey through QA where nothing much happens.

Now I've worked with some truly magical QA/tester folks at various times would could find a bug without even seeing the app run at all. The battle to make them pay for every bug report is a war between my ability to design, code and test in such as a way that they get nothing easy. To find something wrong should require every ounce of their imagination, perseverance and skill. No way should they ever get a fair break in this clash of perfection-seeking. I want to deliver pain, and when they do find something wrong I want them to enjoy telling me about it.

Bugs happen, it's rare for anything to be bug-free and even if it appears so it's more likely than some subtle bug simply wasn't found. Twice in my life have I delivered something substantial that never had a single bug identified in it (the consumer magazine product search engine in 1999 ran for 18 months without a single issue of any kind, and my C/C++ memory allocator HeapManger never had a single issue found in the runtime code by any customer (1997)). Of course I've had bugs but I've always hated giving anything to someone that might not work correctly at any stage of development. Everything I've learned over my 32 years of programming has been applied to designing and writing code that is as resistant to failure as possible.

Even though I despise bugs and have had some success in limiting them, having a good tester/QA person or team is still absolutely necessary QA! QA? We don't need no stinking QA! because no matter how dedicated you there will always be something that you never thought of. That's what a good tester is, a yin to your yang, who doesn't think like you do, who is desperate to prove you wrong, who feels personally responsible to the users if anything is missed. It's a team of opposites.

I've always said that testers should start soon after any project commences, just to keep programmers honest. It always helps as well with UX and finding those irritating features that need to be smoothed out or removed long before anyone thinks of shipping them. A good tester should not be an afterthought, yet in many companies (especially larger ones) testing is often just a step before shipping. Agile development really requires both continuous deployment/building and continuous testing. Having sufficient testers shouldn't be a lower priority than developers, designers, managers and product people. After all, users shouldn't be your testers!

Still, as a programmer I don't want to think of testers as an easy way out, just code some crap and they will find it. In my one and only job as a chemist where we tested products involved in lawsuits I always tried to write clearly, with correct spelling and grammar. My boss however insisted that I throw it together and "the girls" would clean it up. Besides the obvious sexist comment, I didn't like shipping crappy text and I like bugs even less now. I like that clean feeling that I did myself.

I've worked in places where products and systems were utter crap more often than the opposite which always made me both sad and mad. Sometimes people have the attitude that software or business is hard and terrible quality goes hand in hand with that. Sometimes programmers don't have the tools or knowledge or experience to find a way to deliver quality, or receive no encouragement from managers to do it. Many places skimp on quality professional testing/QA staff as an unnecessary expense. One place I worked actually had the business side demand that no QA be done because it took too long.

I'd rather challenge the testers to work hard trying to find issues in what I deliver. It means I have to work hard to design clean code that I can test correctly myself. It means the testers have to be fiendishly clever to point out the issues that always live hidden in the bowels of the product. I'd rather the users delight in the product and enjoy all the effort than went into making it work well.

This was a lot easier in the old days when we shipping software on floppies and the only interaction the product had was the computer itself. In today's highly interconnected world where everything lives on networks, use many frameworks, and talks with multitudes of servers you can't control it's much harder to deliver high quality. Sometimes you write a nearly flawless product and yet it still sucks because someone else's webservice was a disaster. That makes things so much more painful today.

You can only control what you can control and that's where you and the tester live. Just make sure you keep them challenged and bored. Your attitude should be on quality before the quality people ever see it.