This post is part of the Pride & Paradev series.
I admit this topic is a little strange to have in a book about software testing. But I thought I would include it nonetheless as it’s relevant to our industry and it’s good for you to have some background information about the reasoning behind hiring testers.
Do you even need a software tester on your agile team?
- You don’t need a software tester on your agile team
- You definitely need a software tester on your agile team
You don’t need a software tester on your agile team
You’ve probably heard the story. Facebook, of the most popular sites on the whole Internet (as of writing) has no testers. The Facebook engineer responsible for the feature is responsible for the testing.
This is because Facebook, by and large, does not need to produce high quality software. They ship quickly and as a result, they ship bugs. Sure, they’ve got a lot of automated tests, but we all know there is still a need for human testing.
Evan Priestley, an ex-Facebook engineer, explains that Facebook get around having no testers by doing a few things:
- They rely on extensive dogfooding by internal engineers;
- They have extensive real time production monitoring for faults;
- They release code to a beta site 24 hours before release where major clients are forced to do QA testing (to avoid integration problems); and
- They provide channels for ex-employees to report bugs.
What can we learn from this? If you don’t particularly care about quality, have good production monitoring, and can get internal engineers and major partners to do your QA then you may get away with not having a tester on your agile team.
You definitely need a software tester on your agile team
Most agile teams and product companies sooner or later realize they need a software tester.
Software testers provide a unique questioning perspective which is critical to finding problems before go-live. Even with solid automated testing in place: nothing can replicate the human eye and human judgement.
I’ve noticed that a lot of organizations that typically didn’t have any software testers have started to hire or dedicate staff as testers as they begun to see the benefits of testers, or have starting feeling the pain of their absence.
Take 37signals, the web development company founded in 1999, who only in 2013 created a dedicated QA role. This news was fairly well hidden in a 37signals blog post introducing a new support member:
“…You may have noticed a picture of Michael’s new working environment a few months ago. We recently integrated QA testing into our development process, with Michael taking the lead. His effort has prevented potential problems and bugs in every new feature in Basecamp. Look for more details about this in the future.”
~ Joan Stewart 37signals
Another example of relatively new introduction of testing roles is the Wikimedia Foundation who only recently hired a tester (or two) into their organization to take the lead on testing Wikimedia products including Wikipedia.
If your team is too small to support a full time dedicated tester, then look for somebody who can do both software testing and business analysis. That way you still have somebody who can be responsible for advocating quality, but don’t have to grow your team size unnecessarily.