Forget developers in test, we need testers in development

Last year I started working on a small team with developers that really value testing and treat it as in integral part of the development cycle. I’ll never forget one of our first planning meetings when we were discussing a feature that we were about to build and a developer frowned and said “Yeah, but how are we going to test it?”. As a result they changed the whole design.

I think I just about fainted with shock, having never heard that in my career. The key part of this was that it wasn’t the team asking me, the tester, how *I* was going to test it. It was a question asked of the whole team – how are we as a team going to test it? How can we build this so that we have confidence that it will work as we build it?

As we built features, the developers would always write tests – everything from unit tests to browser level tests – and have another developer do some manual testing before it was passed to me for testing in a fully integrated environment. By the time it was handed to me this way, I rarely found bugs that were due to carelessness. Most of the bugs I found were due to user scenarios or system scenarios that hadn’t been thought of earlier.

So you might think, as a tester, did I really have much to do on a team like this? My most valuable asset in this process was still the way I thought about the product – from a testing standpoint, from a user standpoint. What I found was that my testing expertise became less valuable at the end of the cycle and much more valuable at the start. The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end because less bugs would emerge as a result.

I just want to break that last bit out into a big fancy font quote here because I think it’s quite important.

The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end

But the key part of this was that I knew that the development team was testing the product effectively by thinking about testing, writing tests and manually testing as the product was being developed. I could trust that if we had thought of a scenario during planning, it would be effectively developed and tested with automated regression tests in place by the end of the process.

I’ve had a lot of discussions this year around the role of the tester. Let’s put that aside from now and start thinking about the role of a software developer. A software developer needs to be able build a product with confidence that it does what it’s expected to do. Knowing how to do that at a basic level should be critical to the role of a good software developer. For that reason, we need more testing in software development. And it needs to be done by the people building the product.

Having a testing specialist on the team is a valuable asset, but the role of a specialist isn’t to restrict that responsibility to a single person. You might also have a database specialist on your team, but it doesn’t mean that they’re the only person working with databases. The same goes for testing. The specialist can help with the really difficult testing problems, knowing that the rest of the team is capable of dealing with the simple testing problems.

Then it’s shorter feedback loops, greater confidence and faster quality releases for all. Who doesn’t love that?

Special thanks to Chris, Bram, Tom and the rest of the Wildfire team at Google – you guys rock.

Special shout out to Alan Page who’s made me punch the air and yell “hell yes!” every time I’ve read his blog this year.