Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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?
share|improve this question
add comment

5 Answers 5

up vote 8 down vote accepted

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

share|improve this answer
add comment

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.

share|improve this answer
    
Are you saying that there is no need for a QA person in a Scrum team? I understand that they do not play a traditional role, but surely you don't expect developers to perform all of the QA responsibilities themselves? I agree that it is up to the whole team to come up with code coverage, type of testing, etc. But I didn't think that QA was eliminated from the equation entirely. –  BenK Dec 2 '11 at 9:54
    
A Scrum team is a self-organizing, cross-functional team, not necessarily a team of cross-functional people. I would argue that it's not dangerous, but beneficial, to have a single person with an expertise in a certain area, as long as you do have some cross-training. A single person can not necessarily manage all quality aspects, but they can take the lead in managing the quality aspects and ensuring the team has the knowledge needed to do the job, as well as be the experienced voice when it comes to quality decisions. The same applies to business decisions, system administration, and more. –  Thomas Owens Dec 2 '11 at 12:05
    
@durzagott In my personal opinion, there should not be a wall dividing QA and development. I believe that developers can and should be responsible for the quality of the software they're creating as a matter of professionalism. My answer doesn't suggest that you should eliminate QA, I'm only suggesting that it's dangerous to specifically define the roles of members of a scrum team. –  Clayton Dec 2 '11 at 16:04
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
+1 Exactly, SCRUM teams are supposed to be cross-functional developers. User stories are not ready for QA until the sprint is over. Having a QA team that tests the outputs of one or more development SCRUM teams (at a lag of one sprint) makes the most sense. –  Danny Varod Jul 10 '12 at 19:08
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.