What is the role of a QA tester on a Scrum team?

Question

I've recently added a QA tester to our new Scrum team. The tester comes with a lot of experience in automated testing and is capable of scripting, light coding, etc. He will be using automation tools, such as Selenium, to assist with the QA process. However, I am a little unclear where to draw the line in his responsibilities. Also, how do I incorporate QA into the whiteboard?

1) Role and Responsibilies

• Should he be involved in helping the developers identifying what unit tests to write for a given module?
• Should he be involved in determining code coverage for testing?
• Should he be responsible for the Continuous Integration tool?
• Is he the person who declares a story as "Done"?
• Is he in charge of making sure that a story is testable, and therefore valid?

2) QA on the Scrum Whiteboard

• Should there be a separate column for QA on the whiteboard? Or is it better to mark a story in some other way to show that it is being tested?
• Should bugs be identified as tasks within the story, say on a red post-it, or should they be a separate story unto themselves?

Answer 1

In my experiences, the quality assurance staff typically handles system and acceptance testing, so I think that this would be a good place to start. This includes both manual and automated tests of the system against the requirements (functional and non-functional). Given how you describe the background of the individual, it sounds like this is an appropriate set of responsibilities for him. Because of this, yes, he would be the person who decides if and when an implemented requirement is done.

Personally, I would involve a quality assurance specialist at every phase of the lifecycle, from requirements through release. This would mean reviewing your requirements to ensure that they are good requirements and to provide early exposure to build test cases from, designs (with an emphasis on the testability and correlating design decisions with requirements), documentation (especially that which is shipped to the customer), code and tests, and released packages of material.

He could also be involved in measuring product quality through the use of appropriate measurements and metrics. These would include cyclomatic complexity, test coverage, Halstead complexity, defects, lines of code, and so on. He could then report on these for each iteration, identifying modules that are high in complexity (indicating that a possible refactoring is in order), have low test coverage (indicating that perhaps more unit or integration tests are needed), and defect density. Since he has some experience with writing code as well, he would be able to look at the code base, understand it, and be able to comment on its health in a manner appropriate for both technical and non-technical audiences, even if he isn't actively developing.

Other tasks would vary, and depend on the team, the project, the schedule, and the workload of the individual. You need to make sure that he can actually accomplish his tasks in the course of a normal week, as working overtime is generally seen as an antipattern in the agile community.

As far as managing QA on your project tracking system, it depends on what your team is comfortable with doing. In something like Kanban, when a developer feels that the feature is implemented and developer tested, it would get moved to QA. However, you might choose to only maintain a product backlog, a sprint backlog, and a set of completed items. In that case, it would remain in the sprint backlog until QA calls it "done", at which point it's moved to completed and you get your points. There might be some other system that your team develops that works better, as long as it makes sense for how you work and doesn't get in the way of everyone doing their job.

Answer 2

QA Must Not Be Separate

Clayton's answer was close. However, I'd go further and say that any team that excludes QA from the team, or treats the QA specialists as second-class citizens within the Scrum team, has entirely missed the point of the Scrum methodology and how agile practices like XP work.

The core concepts behind any agile methodology boil down to visibility and continuous communication. If your QA team members aren't working alongside the developers, you end up with code that's thrown over the wall at some point in the process.

Engage QA

Even if you have a team where the individual members aren't cross-functional, the team as a whole should be. QA should be actively engaged at every step. For example:

1. The QA folks should be in all planning and technical meetings so that they can help drive test-driven (or acceptance-driven) design.
2. They should be in all sprint reviews and retrospectives, so that they can contribute to the process improvement that lies at the heart of Scrum and XP.
3. They should be in every stand-up meeting, so that they know what new functionality is ready for testing, and can provide feedback to the rest of the team regarding technical issues or process roadblocks.

Tracking User Stories in QA

Once you've acknowledged that QA is part of the team, you need QA's tasks need to be just as visible as the rest of the work on the project. No invisible work--ever!

If you track sprint tasks on a Kanban board, then you need to track QA on the board, too. Whether it requires its own column is an implementation detail that the team can determine for itself and refine through retrospectives. Many teams find a separate swim lane or column for QA adds value, but it's certainly not a requirement.

All the Rest

Everything else in the original question is process for the team as a whole (including QA members) to define--and continuously refine--for themselves. As long as there's a "definition of done" that the entire team has agreed to, the implementation details don't really matter.

Answer 3

Scrum teams are made up of cross-functional members. It's dangerous to categorize one individual as the QA person (or DBA, or security expert etc.) You should strive to integrate this individual into the team so that they can share their expertise with others as a member of the team, not a specialized resource.

The entire team is responsible for determining an acceptable level of code coverage, what type of testing is done and what helps contribute to the official definition of done. Leave it up to the team to determine how to show testing effort on the board. They should be using their information radiators for their own benefit.

Answer 4

In my experience it works best to have QA members as observers to the SCRUM team but not members. A good SCRUM team is usually small (3-4 members, but 2 is common as well) and pretty much interchangeable (i.e. Bill is getting behind on his User Story which is higher priority than mine so I'll stop doing mine and help him). In addition its not fair to ask QA members to story point development stories. In my experience what works best is to have separate QA SCRUM teams who work 1 sprint behind the development team. That does require a commitment to quality from development though since the code must be solid enough that calling developers back to fix bugs is not super common. I've found that what works best is to create each developer to create a wiki page for their User Story and describe their testing (hopefully automated, its impact on testing coverage and Find Bugs). This wiki is part of "done done" and is reviewed in code review.

Answer 5

If you don't test during the sprint than you're going to be pulling your team back to fix bugs instead of focusing on the next sprint. It is imperative scrum teams have a QA resource and testing begins during the sprint and as early as possible. It is not scrum if you still have testing and bug fixing after the sprint is over.