Do you even need a software tester on your agile team?

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’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.

3 thoughts on “Do you even need a software tester on your agile team?

  1. WOW!! Your timing could not have been better. Just the other day I got into a discussion with a client about this very topic. My argument on this is always a financial one: it costs less $$ to fix bugs early in the SDLC. Having defects found by clients in production can be disasterous; sometimes even a finacial death blow not to mention the reputation hit. Facebook doesn’t care about either of these factors. They have more $$ than they know what to do with, a defect in production isn’t going to kill their bottom line, and it won’t impact their reputation. A bug that gets into production @Amazon could take down their web site and cost them Millions; a bug that gets into production @JPMorganChase could cust them Millions and potentially cause customers to leave. Both of these are significant and legitimate concerns. So much so that they NEED dedicated testers. And if you are a company with limited purse strings and a reputation to uphold, my opinion is you too need dedicated testers.

  2. We used to test a framework team and their project manager was so confident about their extended unit tests coverage that he thought they never need a tester. When we saw some of the issues found at the outer layers coming from the lower layer, we dedicated one tester for last 2 months or so of the release. The amount of serious issues tester found really took the project manager to the back foot and he later confessed: “I wish I could have a tester before”.
    Lesson: a dedicated tester with just testing thinking hat adds more value than programmers switching between coding and testing hats.

  3. Good post, I think testers are important and always will be but we perhaps need to be able to do more than just test to be seen as a valuable resource to some projects/businesses.

Comments are closed.