Testing on an agile project is one of the most difficult aspects of agile project development. Traditionally, a business analyst's role is to wear many hats, and this is extremely important in an agile project. Within the agile application development projects that I've been a part of I've helped to design, test, UAT, integrate and sometimes code. As a BA, the hardest part of agile software development for me and my respective teams to adjust to is testing. Without fail the testing gets left to the final days, if not the final hours of the sprint. Why is this? Did the team plan incorrectly? Or did the developers just not do anything for the first part of the sprint? Who's responsible? Over and over again, these are the questions that reoccur within every project I've been a part of.
The key to testing within an agile framework is doing a thorough job on planning and estimating. Often when planning a sprint the testing aspect is overlooked. It's important to push for extra weight on a user story if the testing is deemed to be monumental. There are times when a team estimates a user story very low because building it will be fairly simple, but it is possible for testing to be extensive. This is one of the main reasons the BA needs to be involved in the estimating of user stories. Additionally, the BA can help divide the product back log items into smaller testable units. Once the back log is broken up, testing can start on smaller pieces of functionality earlier in the sprint. Getting the BA's input early has proven to alleviate some of the pain of testing within agile.
Another way to minimize the pains of testing is to have the testing resource(s) attend the design sessions. Not only will the BA be able to help with the technical limitations and capabilities, they can also provide important level setting when managing product owners' expectations. For example, the product owner may have the expectation that all security levels will be implemented when the module is delivered, but the BA will know that security has not been set up for a module within an application. Having the BA available during these sessions may bring to light that testing such an effort may not be feasible within one sprint. Instead, the BA could alter the definition of done and suggest that only one or two security levels be implemented for the next sprint. In this example, not having the BA in the design session could set the sprint up for failure, thus losing the product owners confidence in the team and the overall project.
Planning ahead as much as possible has also been a direct path to success for our teams. Knowing what is going to be developed in the next few sprints helps with creating test plans and level setting testing expectations. Using the beginning of a sprint to complete the next sprint's test plans is a good use of a BA's time. Generally speaking, functionality does not get to a testable level until the middle or end of a sprint, which leads to down time for BA's at the beginning of the sprint. That being said, the BA can only plan ahead if the backlog is properly groomed. It's possible that not every user story is sprint ready for the following sprint, but if the backlog is groomed the BA can start on a few that are ready.
Even with all of the proper planning and estimating, testing within an agile project is going to be difficult. Recognizing that this will be the case can help save frustration and set practical expectations. Planning ahead, estimating correctly and including the BA in the design sessions can help alleviate some of the pain points that occur within an agile framework. While testing within an agile framework isn't an exact science, using some of these tips will help create a more cohesive development cycle.