Shared QA responsibilities on an Agile team

Question

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.

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.