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