automated testing tools for regression and performance testing of each iteration. At the end of each iteration you want to have something that your customer/client can "see." Automated testing allows quick identification and isolation of development defects as well as the ability to test development work completed in previous iterations. Expect the candidate to talk about automated regression testing, continuous integration and even performance testing techniques and tools. Also expect them to discuss the need for manual testing as well as automated regression testing, due to the ever-changing nature of the code base in Agile.
4. Have you done continuous integration on a project before? Describe.
Here you want to get a pretty detailed explanation of how the candidate has used continuous integration on previous projects. Continuous integration is a set of automated build, integration and test steps that executes against the code base in a configuration management repository. For instance, if you were using Java and CVS, the CVS repository would have a set of triggers that automatically built, integrated and unit tested the code often, perhaps each night, perhaps a few times a week, or even every time someone checked in new code. Each of these is a valid continuous integration story.
5. Did your iterations overlap? For instance, were the testers still testing Iteration 6 while Iteration 5 was being designed/developed?
There are many views of how iterative/incremental projects should run under Agile. Overlapping iterations is certainly one strategy. Pay attention to the candidate if they say "iterations should never overlap." This may tell you that the candidate is used to having what is called "multidisciplinary teams." This type of team consists of a set of generic team members who all have the skills and enthusiasm for requirements, design, coding and testing and who each participate in those activities almost equally. If your company has defined roles (business analyst, test analyst, etc.) and career paths then this candidate may have a tough time fitting into your structure. They will want BAs to code and testers to do design. Is that okay? It is your decision. Again, nothing wrong with multidisciplinary teams, but your organization must be able to handle the change if you decide to go that way.
6. Have you used story cards or use cases? Explain how that worked for the team.
Often, Agile projects are associated with the use of story cards. However, our goal is to simply understand if our potential team member is comfortable implementing a project (designing, developing, testing, etc) with business information that has been documented in some way. The requirements (story cards or use cases or a combination of both) should have enough information to provide guidelines for developing and testing and also allow the development team to come up with a creative and effective solution. By asking this question, you want to understand if your potential team member is comfortable working with requirements in a structured development environment versus brief summaries augmented with face-to-face communication, from which the developers build code. Again, this is a matter of matching the Agile candidate's experience with your organization's needs.
7. How did you manage traceability of the requirements to testing?
The point here is to make sure testing goes all the way back to requirements for validation. Not only is it important to test that the functionality a developer has created during an iteration actually functions, it is also important to determine if it functions the way the business wanted it to function. Does it meet the requirements defined in the story card / use case? Your team members should understand