Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Dedicated Tester on an Agile Team

Dedicated Tester on an Agile Team

Leia em Português

This item in japanese


The need for dedicated testers on an Agile team has been long discussed and debated. In many Agile teams, dedicated testers play a pivotal role where as in others developers double up as testers. A recent discussion on the Scrum Development group tries to revisit the need for having a dedicated tester on the team.

Brian started the discussion about the need for having a dedicated tester who could look at the application from a different angle. Most members on the group agreed that having a dedicated tester on the team does bring significant benefits.

George Dinwiddie suggested,

I've found that having a dedicated tester (or several) on the team pays big dividends. They bring a viewpoint similar to the product owner angle, bit with more depth and variety of considerations. This is really helpful for coming up with acceptance criteria for a story that will hold up under real-world usage.

On a similar note, Adam Sroka added

People with a background in testing definitely bring something unique to the table. At the very least they: a) are familiar with methods and tools for testing that aren't strictly related to TDD. b) have spent a lot of time thinking about how to break things and where things might be likely to break. c) understand how to think about and communicate about quality.

Adam further reiterated his thoughts by pointing out that there is a huge body of knowledge specifically related to QA. There are conferences, papers and a lot of literature specifically dedicated to the activity of testing and QA. This indicates that people versed with all this knowledge bring a lot more to the table than just developers who are well versed in TDD.

Many Agile teams are of the opinion that if the developers are building the code using TDD then the need for a dedicated tester is diminished. To this Cenk Çivici suggested that,

TDD with unit testing is for building the code right

Acceptance Testing and QAs are for building the right code..

Most members on the group also agreed that the dedicated testers are more productive when they are included as a part of the team rather than acting as an external entity. Sean Hart suggested that apart from being a part of the team, the tester needs to be involved with the PO and the customer during the backlog creation process. This helps a lot of requirement related ambiguities to be resolved before they get to the team.

Ryan Shriver added a real world example in favor of having dedicated end-to-end testers on the team. According to him,

Before adding the "end-to-end" testers, we completely relied on the agile team testers, but got bitten by a few nasty bugs that got shipped. Adding this team, especially because they had deep domain experience, was a big help in improving release quality.

On similar lines, while documenting the best practices for testing in offshore Agile projects, Peter Vaihansky and Anna Obuhova suggested that dedicated testers on an Agile team add a lot of value. According to them,

Contrary to what some hardcore XPers believe, our experience shows that XP teams benefit tremendously from having dedicated testing professionals. Experienced testers add value in many ways, including manual exploratory testing, working with the customer to produce more consistent requirements, and exploring new ways to improve the automated testing.

Thus there seems to be enough evidence to support the need for having dedicated testers on the Agile team. The key is to best utilize their potential by having them as an integral part of the Agile team and giving them enough support and flexibility. This would help them bring the desired angle to testing with enough depth and variety of considerations.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Dedicated testers

    by Jack Milunsky,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There is absolutely a need for dedicated testers on a Scrum team. Firstly, as already mentioned they bring a unique set of skills to the table and with their inate ability to figure out how to break things, they definitely contribute to the overall quality of the deliverable as one would expect. Testing however in Agile projects must move to the start of the project. i.e. They need to be involved in the drafting of the acceptance test criteria. And they most definitely need to be part of the planning poker estimation as testing needs to be accounted for in the overall sizing of stories.

    Testing on Scrum projects also presents new opportunities and challenges for testers as well as a new career path. If they're up to it they can pair with developers, and write the unit tests.

    My two cents

  • Re: Dedicated testers

    by J. Tyson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If you're using SCRUM, don't waste your time or money on testers. I'm a professional tester that has recently joined a SCRUM team and I can tell you that SCRUM and quality are incompatible.

    SCRUM is all about speed, which means no documentation and no quality (the fact that there's no management doesn't help either - please don't tell me a SCRUM Master is a manager). If you think you can sit down with Product Owners and find out what you need for testing, that doesn't always work - they are too busy. You may think that the tester can follow the dev around when they meet with PO's. If you have a 1:1 ratio of testers to developers, that might work. I've always been in environments where 1 tester supports 4 - 8 developers.

    No documentation means no assets, no (or few) artifacts and a hugh risk for the company. User Stories (in the form of "As a ___, I want to ___, so I can ___") make a great first sentence and a pathetic excuse for requirements.

    If you believe the nonsense about "self-directing teams" that will always work in the best interest of the company, then let me sell you some oceanfront property in Kansas.

    Short sprints (every 2 weeks) can be disastrous, especially if you are attempting to introduce testing to a legacy product (i.e. you aren't starting from ground-up) of any complexity. SCRUM allows no time for the testers to develop and/or run test cases, as they are busy will the current sprint.

    SCRUM is an extremely high overhead methodology due to the lack of quality. You are working on the current sprint, but then bugs come in for the sprint in UAT and/or production. You now have to suspend work on the current sprint, fix the problems, test them, roll it out to production and hope it doesn't happen again. This constant context switching disrupts everything.

    As for Jack's comment about loving the idea to have a tester pair with devs to write unit tests, this just shows how testing is misunderstood. Unit tests are written by developers - by definition. SCRUM is great at letting developers escape the necessary but unfun tasks associated with development. This is just another example (I don't want to test; give it to Mikey).

    SCRUM is another software development silver bullet in a long line of silver bullets. Humans love to search for a one-size-fits-all solution for a myriad of problems. Add SCRUM to this list.

  • Re: Dedicated testers

    by Vikas Hazrati,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It is ironical that Scrum and quality are seen as a tangent. The Agile processes advocate quality as one of the most important things.

    I am not sure what did not go well in your scenario but 2 week sprints and testers within the team have been a boon in our case. Before we start on a new story we discuss with the testers on how it would be tested and create a automated test case for that even before we start the story. Then start working on the story and keep adding unit tests.

    This not only helps in creating a solid test to test the individual story but we also get an enhanced automated regression suite which is executed every day. This reduces the post production defects to almost Zero.

  • Re: Dedicated testers

    by Michael James,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    SCRUM is all about speed, which means no documentation and no quality

    Wow, I'm sad to hear this has been your experience of Scrum. It's certainly not how *I* teach teams to do it, nor does this description match Ken Schwaber says about expanding the definition of "done" to include full testing (not just unit testing) every Sprint, reducing the scope to the most valuable items, and building a *potentially shippable* product increment.

    The move to Scrum/Agile at a medium-sized organization a few blocks from my home was driven by the Director of Quality Assurance, specifically to increase the amount of testing his teams were doing, and reduce the surprises they were getting from waterfall-style delayed testing.

    We're on *your* side here!

    . 5-page illustrated summary of Scrum:
    . An example checklist for serious ScrumMasters:

  • Re: Dedicated testers

    by Esteban Garcia,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Sounds like your team has taken the wrong approach to Scrum. Scrum is all about quality, not all about speed. Speed is something that the team achieves and improves with each iteration and the goal of each iteration (sprint) is to have release-ready quality code. QA becomes a very important part of the team and should never be seen as an afterthought, as that would really be a failure. One of my favorite parts of Scrum is that it is fairly structured, even if it's agile, it is not and should never be used as an excuse to throw all processes out the window.

    Esteban Garcia

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p