Most of the issues in Agile projects typically surface during the Testing phase. Due to the short Sprint cycles, by the time the issues in the project bubble up, the code is undergoing testing. Hence the testing team not only has to deal with meeting the timelines for a working code, but also have to accommodate the spate of advice from experts.
Agile or not, fundamentally, testing as an activity is still focused on Verification and Validation. Hence there is not much change in terms of the testing activities per se, but the planning needs a definite focus.
Since the application is built over several Sprint cycles, there must be a lot of effort spent on regression testing to ensure that nothing is broken. Testing the product on multiple deployment configurations adds an additional level of effort. Hence the effort estimation needs to be done keeping in mind the repetitive cycles of testing.
When there is repetition, there is a temptation to automate things. Automation of testing has to be based on the Return On Investment rather than focusing on saving time alone.
I have given below 3 different models in which Agile Testing can be integrated into the Sprint cycles:
The teams can adopt the appropriate model depending upon:
- The Implementation milestones of working code
- Testing for multiple configurations
- Type of project – Software, Hardware, Embedded systems
- Sprint cycle times of different vendors and end-user testing cycles
Irrespective of the model that you choose, the most important aspect is that, the Test suite/cases needs to be prioritized based on Risks and complexity of Requirements. This ensures that most important pieces of functionality is tested first, so that developers get adequate time to fix defects in them (Now that is Collaboration !!!!!)
Happy Agile Testing!!!
– Kumareshen Chidambaram