You Don't Want to Hire a Tester

Testers can be a real pain. As a developer, you are hiring someone to complain. And not about life in general, or The Establishment, but about the application you have spent long hours lovingly crafting out of bits. You spelled a word wrong, that text box isn't quite aligned with its label, and the whole thing takes just a little too long to load. The documentation's rather terse, and shouldn't the icon be just a little less shiny? 

Testers ask questions. Annoying questions. Where are the release notes? Does that change affect this other thing? If the app can do this, why can't it do that? Which third-party apps do we need to be compatible with? Where did this half-baked, unplanned, crazy new feature come from? 

Testers check the quality of things besides the software you told them to work on. They clog the network stress-testing an app. They accidentally delete your source control repository if the permissions aren't set right. They critique the bug-tracking database. They suggest changes to the lunch-ordering process. 

Testers delay releases. They always seem to find a serious bug when you're just about to push a new version. And now you're elbow-deep in backtraces, rather than basking in the warm fuzzy feeling of a release. 

Testers cost money. Besides their paycheck, they want a Mac to test the app. And maybe a second one, to use while they're re-installing the OS on the first one. And then a Wacom tablet, because it sends different events than a mouse. 

Testers are trouble. You don't want to hire a tester. 

Summary and Questions

So far, it seems to me that there are a few different broad topics this presentation needs to cover: 

• The difference and trade-offs between beta testing and internal testing.*
• How to utilize beta testing most effectively.
• What internal testers can and should be doing to test your applications. 
• What skills, experience, and other traits you should be looking for when hiring a tester.
• What tools and resources are available for testers and their bosses. 
• How to get along with your tester and make them more efficient.

A few of these topics will require further thought and research on my part, but I think they're all things you need to know. And please let me know if there's something I've missed that you'd like to see addressed. In other words, let's do this presentation backwards, and start with the questions. 

-----

*By "internal" testers, I mean both direct employees and contractors/consultants–people who are using your software because you pay them to, not because it helps them get other things done.

Inspired by C4

I went to C4[2]*† this weekend. I've been interacting with Mac developers all wrong. I should not be apologizing for being a tester, and participating in spite of my profession. It is because of my talents and experience that I can and should attend these events and discuss software, and everything related to it, with Mac developers. 

Several people at C4 suggested there should be a talk on testing next year. But as @arclite tweeted, C4 is a state of mind. So I'm not going to wait until next year. I'm not going to make you wait until next year. You, Indie Developer, need some advice on testing your Mac apps now. As I develop my talk for next year (which may or may not actually occur), I'll post the content here. Expect the first installment within a week. 

*Is there a better link for people wondering what C4 is?

†Some people have trains of thoughts. Mine seem to be closer to trees. Footnotes seem less distracting than parenthetical commentary.