Dedicated Tester on an Agile Team
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.
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
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
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
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: tinyurl.com/dkyqjs
. An example checklist for serious ScrumMasters: tinyurl.com/cvdwor
Re: Dedicated testers