What are your views for QA integration in an Agile environment?

That was a question posed to me via email. This was my response:

Testers are part of the team. They should not be thought of as a different group and somehow apart. Testing is their primary role, but they should contribute in any way they can to help the team. That means analysis, configuration, coding, whatever. Many struggle a lot with the concept of blurring the lines between testers and programmers. I think it would be great if testers could be writing code, specifically pairing with developers, writing test code while programmers write feature code. Most places I know of don’t have testers with that expertise. Testers don’t need to be able to code to contribute as an integral part of any team.

Here’s my current view on how to do it:

• Testers should be greatly involved in the story creation process with the customers/product owners. Not only is it important that they understand what the customers want, but at this stage they should be able to point out testability of stories and help contribute to the Acceptance tests associated with the story. It is important that the tester *drives* this Acceptance test creation. It’s important for all to understand that just because they are tests doesn’t mean the tester is responsible for them! They aren’t – that’s up to the customer, or whoever is accepting the output of the team – but the tester can make sure that they are written, that they are relatively comprehensive, and that they are testable. For more information see Elizabeth Hendrickson‘s article on ATDD and Gojko Adzic‘s books on Executable Specifications
• Testers should enage frequently with programmers with what I call Dev Shadowing. Not quite pairing, the tester should sit with the programmer as they write code. That brings the testers’ skill to bear as they help the programmers with logic, tests, or anything they create. I know that many testers are apprehensive for fear of looking incompetent or resentment from programmers. I’ve found through experience that these fears are largely unfounded. Over time, as trust is built, perhaps this effort can be scaled back…as the lines blur.
• Testers, at the sprint planning stage, should determine which of the Acceptance tests, and surrounding tests, if necessary, they will implement and which the programmers will implement. If you’re using some kind of Fit-style framework, this could be a collaborative effort where the tester writes the tests and the developer writes the necessary fixtures. Or, if skilled enough, the tester could do it all. If you’re not doing something like this, the tests should be written using a unit test framework.
• Testers, again at the sprint planning stage, should be clear on which tests need to be at the UI level and which are purely related to business logic (which should exist at a mi imum in the UI). If the test doesn’t need to happen at the UI level, it is likely best handled as an automated Acceptance test (by that, I mean a test written using the unit test framework, or using a Fit-style framework). If it must be tested at the UI level, then the tester must decide if it needs to be automated or should be done manually. If you want to automate it, then hopefully you have the tools in place and the expertise and the appropriate story points/work effort assigned to account for the automation. If manual, it’s likely that BAs, and other members of the Product Owner team could assist with this effort. After all, it may just be manually running the Acceptance test as written which is up to the Customer to approve anyhow. This type of testing amounts to validation/verification and can be characterized as checks.
• Testers should engage in exploratory testing. This type of testing goes beyond the Acceptance tests, but not necessarily to their exclusion. This is the area where a trained tester can provide great value over and above the manual testing you get from other members of the team. Session-based testing I’ve found is a good method of organizing this effort so that everyone knows what areas of the system were covered in a given session.
• All tests should be run on checkin! If this is too time-consuming, at least all unit tests should be run at checkin (they should be very fast!) and all unit, automated functional and acceptance, and all automated UI tests should be run on migration to the various server environments, and perhaps nightly or on-demand. Obviously, the trick here is to make sure the tests are robust enough to not overload you with false negatives — but that’s better, imho, than the alternative.

So that’s what I would suggest in terms of integrating testers into an Agile environment. I know Lisa Crispin and Janet Gregory, respected members of the community, have published a book on this very topic.

That’s my new title.

For the last 10 years or so I’ve been a “Quality Assurance Analyst” and a “Quality Assurance Manager.” We all know now, or should, that those roles have nothing to do with quality assurance. I didn’t write feature code as a QA analyst and I didn’t dictate to programmers how to do their jobs (well, of course I did both of those things — with varying levels of success/influence — but it wasn’t part of my job description). As a QA manager I was a “resource” manager; I wasn’t responsible for teams or projects, but rather a group of testers that worked on various projects. The primary responsibility in that job description was to be aware of the availability of the people on my team through forecasting and monitoring so that when new work came up, I could assign someone to do it (and I did everything I could to make this responsibility moot).

So I was a Tester and then a Test(er) Manager. And while I did other things, my focus was always on testing – how to do it better, how to do it earlier, and how to get the most appropriate information possible to the decision makers on projects. I would not, however, characterize my current title as “Test Architect.” I’m not solely focused on testing. I’m also focused on business analysis, and programming, and sales, and support, and management and the SDLC and…well everything we do that has an affect on the quality of our work. While I attempted to have this kind of influence in my former role, I couldn’t. I didn’t have the authority, and often, the support, of others in the organization. Now, I do.

Here are some of the things I’m doing now:

• Leading an Agile transformation
• Helping the business understand internal capabilities and identify needs in the marketplace
• Helping teams coordinate efforts between local and off-shore employees
• Helping dependent project teams work together without hindering and/or blaming each other (it’s nice to finally be able to make a difference in something like this…)
• Modifying the organization structure to better facilitate small, permanent teams of cross-functional developers (analysts, testers, programmers, et. al.)
• Implementing an Executable Specification framework (with the full knowledge that they ultimately function as rejection checks)
• Integrating and aligning Security and Performance teams with project teams

I still have issues with the word “assurance” but I know that I have a lot more influence on Quality – using a variety of definitions – than I’ve ever had before.