So you want to transition to agile, and have started reading about how there are only a few roles in an agile team: Scrum Master, Product Owner, or Team Member.  In particular, you may be getting thrown off by this line from the Scrum Guide:

Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

If you’re a purist adhering to the letter of the law, this means you can’t have anybody in your team that is performing only one function, like a quality assurance analyst.   However, “Being Agile” is about learning, changing, and improving, not being rigid.   To succeed you need to take the framework, your team, and what works for you and adjust from there.

QA is a Team Member

There are people who have the skills and experience to be a QA analyst.  Not everyone can do this effectively!  Your team needs to be balanced, and it needs to have people who are experienced at:

1. Identifying boundary conditions
2. Executing performance tests
3. Making use of professional testing tools
4. Effectively recording and communicating problems to the rest of the team

Maybe you have some developers or business analysts that can do this.  Maybe you don’t.  However, if you are in a company transitioning from a more traditional system into agile, you probably have a whole team of people who already know how to do this.  Why waste this precious resource?

QA is in the Sprint

When initially transitioning to agile, there may be some old habits that are hard to break.  Developers write code, finish up the iteration, and “throw it over the wall” to a QA environment where the QA team tackles the build, reports the bugs, and then waits for the next batch.  This habit needs to be broken.  Some basic guidelines:

1. Dedicated Team Member. Ideally, the QA resources on the project team should be assigned to the project completely, and should be available to the team during the entire iteration. (This goes back to the concept that QA is a Team Member).
2. Ongoing Feedback. QA shouldn’t be waiting for the end of the sprint to get their first taste of the release.  They need to be able to provide feedback during the iteration.
3. Fully Embedded.   QA is a Team Member, so they should be in your estimation, retrospective, daily meetings, etc.   This helps keep the communication lines open, and also allows for QA team members to highlight possible risks or issues early on, before development even starts.

Most of this is managed via resourcing and scheduling, but there are some things you can do to support this process and help make it succeed.

QA needs You

Specifically, your QA team members need to see your features.  This means getting access early, and often, to the stories being developed so they can provide the ongoing feedback that ensures high quality is delivered within the sprint time box.  In most organizations this requires a change from a release package being delivered to QA every few weeks or months to something more immediate and regular.  There are many tools you can use to help accomplish this, but here are a few things you can setup to help you succeed in making QA part of the sprint:

1. Continuous Integration.  Ensure you have a build server, and ensure it is running compilations and unit tests when folks are checking in.  This keeps the silly ‘oops, I didn’t merge that right’ problems from getting to QA and causing them to have to lose time dealing with broken builds in their environment.
2. Daily Build Environment.  I’ve heard this called all kinds of things, from ‘Development Lab’, to ‘Staging’, to ‘Dev Test’.  Essentially, this is a place where QA can test things as they are being worked on.
3. Automated Deployments.  Your build server should be running regular (daily) deployments to your Daily Build environment.  If you can, give your devs and QA folks the access to push on demand as well.  This works particularly well when you need to get some rapid feedback for a bug fix.
4. Regression/UAT Environment.  Just because QA has seen things throughout the sprint, that doesn’t mean that something they saw on Day 3 is still working on Day 9.  Ensure you have a stabilization period of your sprint and during this time release to a separate Regression environment where QA can run through everything prior to your demo.  This environment can then also be used to run your demonstration and for any UAT that may be running while the next sprint is being developed.