Archive for September, 2011
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.
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’ve been involved in one way or another on many project teams, many of which are “going Agile.” Often these teams will look to the examples of other teams inside, or outside of the organization. One such team a few years back decided to model their process against a different project that had earlier adopted Agile. On the one hand it was good, because they could tap into the project team’s processes and experiences. On the other hand, it might be bad because of the differences between them — the new project is much smaller, with different people, a different organization structure, a different user community, and a different environment. Actually, it would have been better if they came up with their own processes rather than using those from the other team.
I understand that this seems counterintuitive.
Agile teams that have been working together for a some period of time make changes. As they move through Shu-Ha-Ri they inspect and adapt; they come up with new processes to improve the workflow. That’s how it should work! But sometimes there are circumstances and contexts that limit the amount of change. Examples include org structure, upper management buy-in, off-shoring, user availability, audit concerns, and many others. If a team doesn’t have the same constraints, they would be well-served in examining any borrowed processes and practices borne out of such an environment.
Here are the chief problems I discovered when I went to help out this team.
The team isn’t together physically — One of the most important things to do on an agile project is to move all the people on the team into the same area. Communication is the key issue. It appears this team is staying in their same cube structure — testers at the end of the hall, Dev in a section over here, Management over here or in a different building, etc. It doesn’t have to be this way for this team; they can sit together.
Testers aren’t involved (yet) — I talked with the QA manager (who is trying to manage the day to day work of testers on two agile projects plus a few others…hmm) who says that the her direct reports on the project had not been invited to any analysis or design discussions. It’s still early in the project, but testers are part of the team. They need to be involved now, not just after the first build (which was due out later that week). It’s a very common pattern where each “team” – analysis, dev, test – do their bit and pass it on. And really, that’s *exactly* the type of mindset that Agile attempts to break down, but it’s one of the most difficult habits to break.
Users aren’t involved — They still don’t have any users or representatives participating in any way, save being interviewed some time ago by analysts. The other team they modeled after didn’t either, but that’s because their users were unavailable and unwilling to participate. This team’s users are close by and, from after a little questioning, quite willing to participate.
We got this team to make some changes and they continued to adapt and get better, and that’s great. Transition is difficult; moving to Agile is more than just saying “I’m going to put out a release every x weeks.” There are important aspects of real-time collaboration and constant feedback that are of crucial importance to a successful implementation. It’s a great idea to look to other teams with experience to get some ideas, but simply adopting processes without understanding context or understanding the principles behind the methodology you’re implementing will make a transition even more difficult.