Hey guys,
We're getting a QA for the first time in our project. We're not sure how to best use him.
We work in an Agile environment. Pair programming, user stories, short sprints (two weeks), daily stand-ups, retrospectives, planning meetings, quick releases etc.
One obviously way to use a tester is to verify bugs fixes and user stories every sprint. Are there any better ways for an Agile team to utilize a tester.
Thanks, Sri
This is a big topic, but I'd recommend the Wikipedia entry on agile testing as a starting point; there are some good links at the end, especially the Bret Pettichord presentation. Sounds like your tester should fit right in since you are already practicing Agile in your development process.
Verifying bug fixes and user stories every sprint is definitely useful, but if your tester has previous experience I'd recommend just letting hime or her talk to the dev team, product manager, support people and customers and let them make their own analysis of test priorities. The biggest problem they'll have will be figuring out what a single tester can do in the time available.
Definitely verify the fixes. Also have an ongoing effort to automate regression using the previously verified fixes as test cases.
One obviously way to use a tester is to verify bugs fixes and user stories every sprint. Are there any better ways for an Agile team to utilize a tester.
IMO, this wouldn't be very efficient. Mary Poppendieck summarize this very well: "the job of testing is to prevent defects (essentials), not to find defects (waste). She wrote a lot on this topic, see for example this presentation or her books. But how to do this?
My suggestion is to embed testers into the team and to work on automated acceptance testing right after the start of the iteration. Develop these tests in parallel of the implementation of Product Backlog Items, User Stories, whatever and provide them as soon as possible to the rest of the team. Use acceptance tests as DONEness indicator: the team knows something is DONE when acceptance tests are passing and acceptance tests are parts of the deliverable. Tools that can help here, have a look at Fitnesse, Cucumber, Selenium, SoapUI, etc.
This is IMO mandatory in order to be DONE DONE at the end of each Sprint (and to achieve "potentially shippable").
Input from QA can be utilized to drive the scrums. There are lot of things QA can see before even testing starts. One example is dependencies and impact of change on the existing application. Also QA can guide building more relevant sprints.
Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory is my go-to reference for this sort of question. Among the things that they discuss: having people with a strong testing background as part of the Planning Meeting is a good way to make sure your Stories are testable.
Lisa Crispin is definitively one of the best resource for software testing. Look at her article on how developers and testers should work together in agile projects.
I have a rather different opinion to most of the other answerers, i'm afraid. I think the QA guy should stay as far away from the development team as possible. Rather, the QA guy needs to hang out with the business people.
The agile process (any software development process, really) is driven by a two-stroke engine. The first stroke is the planning game, where the business hands the stories to the development team, and the development team accepts them as suitable for implementation The second stroke is end-of-iteration release, where the development team hands the software to the business, and the business accepts it as satisfying the stories. These two acts of acceptance are closely linked: the stories define whether the software is acceptable; the ability of the stories to do that defines whether they are acceptable.
These two strokes are the interface between the two tribes involved in the process, the business and the developers. That interface needs to be a tight fit if the system is to work as a whole. In my experience, where it doesn't, it's because there's looseness: stories are written which don't communicate to the developers what the business really want, and releases are accepted which don't really fit the stories. QA guys can clamp down on that, and make the fit tight. During planning, they can contribute to making stories concrete by working out how to test them; a testable story is implementable. During release, they can use those concrete stories to verify the software.
But to do this, they need to understand what the business wants, not what the development team is doing, and that means being part of the business tribe.