For many years our IT development group subscribed to the waterfall software development methodology with segregated pods of programmers specializing in database development, logic layer and presentation layer development. Of course we also had a small quality assurance group which handled all testing responsibilities. Requirements, tasks and bugs were handed back and forth electronically, very little conversation took place, and the process ground painfully on.

In 2010 we made the monumental shift to Agile with Scrum and after some serious growing pains we've truly began to excel as a whole team. Communication is constant, people are growing and learning from each other every day, and our releases more stable and much more aligned with true business priorities.

One area we're still trying to grow in is in sharing software QA responsibilities amongst all development team members to get away from the toss-it-over-the-fence attitude that still seems to persist when it comes time to test a feature.

Does anyone have any advice as to how to grow a development team towards collective application quality ownership? We currently practice XP so we've begun to do more pair programming between developers and testers when creating unit and integration tests. But it still is challenging to get the whole team to proactively think about testing strategies for each sprint. Inevitably one or two "Write Test Cases" tasks are thrown into the sprint backlog with no forethought as to what will be tested and how it will best be achieved and organized so the entire team is aware of what testing has been completed, what's currently being tested, and what's left to test.

Sorry for the long-winded question, but any advice would be much appreciated.

  • Are you discussing QA (Assurance) or QC (Control) - testing is a QC Activity,...... QA is the group who ensure the processes are followed, usually only found in large organizations.
    – mattnz
    Commented Mar 9, 2013 at 19:54
  • @mattnz A little of both I suppose, but with an emphasis on how quality assurance and control can be owned by both developers & testers. Ultimately the goal is to get to the point where we don't specifically need to rely on a "tester" per-se to test a sprint feature, instead hoping that testing can be accomplished by any team member. Commented Mar 9, 2013 at 20:16

1 Answer 1


I think your question really has two aspects to it:

1) How does a traditional software QA/QE group fit into an Agile development environment?

In my experience, you're correct. Separating the testing team from the development team creates some issues. The "throw it over the fence" method doesn't work very well in Agile. What we've done is make the testing team just part of the Agile Team. If your quality team is more technical, maybe easing them into development is a possibility. Maybe one member of the quality team is interested in becoming the Scrum Master. Maybe some members of the quality team are looked at as specialized testing resources on the Team. I think it's important in any case that they are full-fledged Team members, though; they come to all of the standard Scrum meetings, help with estimation, contribute to the Retrospective, etc.

2) How is the testing responsibility spread throughout an Agile Team?

This has to do with your Team's Definition of Done. The testing effort for a Story should be part of the acceptance criteria. Testing (both automated and manual) should be parts of the tasks toward completion of the Story. That way, the dedicated testers can be assigned pieces of the Story that are an actual part of their completion. Of course, this means that development tasks need to be granular enough that there are testing tasks available throughout the Sprint. For testing resources, maybe the first couple of days of a Sprint is spent on maintaining automated tests, or grooming the bug database. We've decided that bugs found on a Story during the Sprint it's being developed in need to be fixed for the Story to be accepted. Bugs reported after the Story is accepted become part of the product backlog and are prioritized.

Hopefully this gives you one possible answer. As always with Agile, you'll find that what works for your Team will be unique in some respects.

  • Thanks for the response, it closely aligns with how we're currently handling our approach. Our failings are mainly in the depth of thought being put into test planning for a sprint and providing transparency to all team members as features are being tested. Our test tasks right now are very high-level and generic, as a feature is being tested it's very difficult to know what the testing status of a feature is. I'd love to easily see not only what features are being tested but also by what means those features are being tested, empowering developers to engage fully in test tasks. Commented Mar 9, 2013 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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