One of the questions I am asked the most is “how do we fit testing into an Agile lifecycle?” this is a big question, and it is something that requires a true understanding of Agile values and principles by the entire team. I think it is a big question because people don’t really understand how pervasive Agile makes testing. If testing is treated as a separate part of the development process it is just like trying to fit a square peg into a round hole. Testing is not something that should be added in at the end, testing is a vital and constant part of Agile development. Testing should not need to be “fitted in”, it should be assumed to be part of the process and treated as such.
From the manifesto itself, we can see the testing built-in …..
Individuals and interactions over processes and tools – this means getting feedback from the customer/users as we build the solution, and as the solution is being built. We talk about whole team engagement, customers working together to define quality and the focus on good “enough” instead of perfect. This means that if there is a need for more testing then we will do less development per iteration, if there is a need for automation, there will be support for it.
Working software over comprehensive documentation – this means putting together proof that the product delivers, getting real users involved, and not spending too much time working on documentation but maximising time spent on proving the solution delivers what is required.
Customer collaboration over contract negotiation – this means active and comprehensive involvement of the customer in the development lifecycle, short feedback loops and timing of feedback to allow the customer to understand what is being built and then work with the team to build the best solution for the customer.
Responding to change over following a plan – this is what testing is all about – delivering the team information that allows them to make informed decisions about risk, quality of the deliverables and suitability of the process.
When these values are applied at team level we then see a focus on the definition of quality, the clear understanding of “done” for the project, release, iteration or story through all the phases of an Agile project. We would see static testing being done on the features, epics and stories as they are identified, we would see that each of these would have clearly defined acceptance criteria. Each of the acceptance criteria would be translated into testing approaches and techniques and supported by all the team members, not just the testers. I would expect to see Iteration Zero focused on setting up and managing the test automation, including the development of a test framework to support the capture of automated unit testing, API testing, GUI testing and the development of test data sets that were extensible with the ongoing iterative development. The regression test suite would be automated from Iteration 1, and one of the first priorities of the team each iteration would be to run and add to the regression suite (at all test levels) as each piece of code was developed. The UAT at story level would also be focused on growing the regression suite from an ATDD mindset.
One of the key indicators that the testing and quality attributes of a solution have been evolved “agiley” is the distribution of the test execution throughout the entire team. For example, developers would be working with the testers to define and automate unit testing. Business Analysts and the Business SMEs or Product Owners would be working with the testers to define and execute the acceptance testing for each story, each iteration and each release. There would be a focus on automating as much of the testing as possible and an understanding that the tester is part of the team to help everyone design their testing, not to focus on test execution.
When testing is not considered part of the development cycle, but is considered an add-on, and it is pushed outside the iteration by late delivery of code, when it is not planned as part of the definition of done, and when people in the team do not apply the discipline to all of the work products to ensure technical excellence we find that testing does not fit. But then I also think that without these things Agile does not really fit either.