One of the things I will always have with me on my first day in any job is a USB memory stick with Joel’s list on it. A colleague and friend brought it to my attention a while ago now and it’s a great point of reference for any software team. Sitting at number 10 on the list is “Do you have testers?”.
I’ve had at least a dozen discussions with people who don’t believe that dedicated testers are necessary. Many of them sit in the “the developers should be testing their own work” court. Spolsky says that teams should have dedicated testers so that you don’t have a $100/hour programmers doing work that could be done by $30/hour testers. I don’t agree entirely with either of these positions.
Of course developers should be testing their own work to a point, the first test of which is “does it build?”, but would I expect a developer to want to build and run dozens of test cases every time they produce some new piece of functionality? No, for a number of reasons:
- There is a good reason by the QA function in any walk of life is very rarely performed by the person(s) who produced the work in the first place – people are very bad at finding fault in their own work.
- Developers and testers are different beasts and have a very different focus in life. Devs are naturally impatient, I don’t think I’ve met one who isn’t itching to move on to the next module/product. Devs, once they’ve solved the problem in their mind, written the code and got it working, they’ve done most of the “fun bit” of development. Testers aren’t so restless and their challenge is different. All of the good testers I’ve met have a dogged determination to ensure that the software as a whole is the best it can be, no matter what it takes. These two sets of personality characteristics are not natural bedfellows and the result of this is that a great developer is unlikely to even be able to do the work of a tester, let alone willing.
- Testers make developers more productive. The more time developers get to occupy that “solving mental problems” space (see 2 above), the more you’ll get out of them. The more confidence that they have that there is a good testing team (or single tester) behind them, the happier they’ll be in that space and the less anxious they’ll be about the code they’ve already produced.
- Testers make product owners less busy. If anyone in your team needs a clear, full understanding of the big picture, it’s the tester. Invariably, in my experience, it’s the testers that “get it” where quite often the developers don’t (perhaps because they tend to make the mental jump straight from User Story (or equivalent) to implementation). The testing team are often the first point of reference for the developers when there’s a choice to make or an ambiguity to iron out.
- Testers give you confidence come roll-out. Anyone who has ever been up at 3am on a Sunday hitting the “go” button on a deployment doesn’t need me to elaborate here.
As for hiring testers on a purely financial basis (they’re cheaper than developers), again, I don’t agree. Testing is a highly skilled profession. Sure, anyone can “have a go” but great testers are just the same as great developers – worth their weight in gold and rewarded as such.
In our scrum team at KashFlow the testing function isn’t just about test cases and their execution, it’s much more than that. Our testers are a proxy for the voice of our customers. Sure, the customers come up with the product backlog pretty much on their own, but when it comes to implementation it’s our testers who can balance the combined requirements of several thousand customers to achieve the right result for the vast majority.
I’m sure there are loads of other reasons why testers are a good idea, but these are the important ones for me and, sorry Joel, “cheap” isn’t anywhere on my list. Any I’ve missed?