The Agile Manifesto 

The agile manifesto states that you should value working software over comprehensive documentation, but as we all know, this does not mean no documentation. If you’re following an Agile approach for your programme of work or project then we would always recommend considering and documenting your Agile Test Strategy. Here are three things to consider when creating yours.

Creating a Definition of ‘Ready’

One of the first areas we look at is creating a definition of ‘ready’. The definition of ready has a huge impact on whether the project will be successful or not. It is all well and good having a set of requirements, but have you given thought to your acceptance criteria? Have the requirements themselves been tested? More so than in more traditional methods, you have a greater opportunity to uncover issues that will greatly reduce costs/impact to the project. This approach will reduce the chance of finding problems during the User Acceptance Test phase, avoiding expensive re-work. Consideration should also be given to any impact and risk from any changes.

The traditional Definition of Ready states that:
1. user stories or PBIs are useable
2. the team are able to determine the amount of work needed to complete them
3. the ‘done’ criteria and what tests will be undertaken to confirm that you are ‘done’.

Whilst all members of the team are responsible for quality, it makes sense to have dedicated testers within the team. To satisfy the second criteria, it is vital for the testers to be able to define how the PBIs will be tested – if they can’t answer this, how can they be developed?

If you have considered all of the above, you are ‘Ready’ to move forwards. If not, consider an impact assessment before implementing further changes.

Eat, Sleep, Test and Repeat!

If you’re ‘Ready’ to begin testing, you need to test as frequently and effectively as possible. This will increase the chances of uncovering defects, and improve overall quality. Given the rate of change, the only way this can be achieved is through Test Automation. Setting up an automation framework early in the project and creating the re-usable test artifacts will 100% add cost, but the benefit of reducing the cost of ownership of the system/application through improved quality outweighs the drawback.

It goes without saying how important Test Automation is here. It is also important to ensure TESTERS are creating the automated tests and not DEVELOPERS. Of course, developers have the right technical skills to create the Automation but they may not have the right critical mindset to create the correct tests that will yield the defects. Testers do have this mindset and organisations need to enable their testers to do this. There are several method and approaches to good testing. For example, test design involves good test case creation, and requires sound knowledge of the domain in particular, and of software development and execution in general. By creating good test cases your automation framework will be robust and reap benefits.

As every application is different so should the processes used to test them. As the world of IT shifts to a more Agile delivery model, Automation becomes more important and setting up a flexible framework for automated testing is crucial to the success of testing. There are many business benefits for adopting automation and choosing the right framework will bring enormous benefits.

Whilst I recommend testing as much as possible, thought should be given to what’s being tested. If there is a change to a cosmetic area of the application it may not warrant a full regression suite of tests being run, but if it’s a more important area, such as the payment platform, you would do. With Agile you want to try and test just enough for the scenario you find yourself in.

The Definition of ‘Done’

Right, you’ve done all of the above, your project is running smoothly and you have caught a lot of potential cataclysmic issues early in the project lifecycle and saved a lot of cost! You have also carefully balanced the need for effective testing with just enough to effectively validate the requirements. What next?! Well the output of any sprint should be a potentially shippable and releasable increment of the product. At the end of the sprint, it is important to decide which PBIs/user stories can be released and this can only be done when they meet the exit criteria.

Only when you have met the exit criteria will your PBI or user story be complete. This is fundamental to the success of the project. It’s of course difficult to come up with a single definition of done when the PBIs/User Stories are all so different. Things to think about here include the severity of the bugs, number of defects that are still open, the levels of coverage to name just a few. This must be completed before moving to the next sprint or iteration.

Don’t forget the users; production/installation/user guides for the changes are necessary. Everyone who uses the system needs to be made aware of what changes have been made and how it impacts them.

The Definition of Done should continue to evolve throughout the lifecycle of the project, being refined by the lessons learned of each sprint. Make sure time is scheduled in the sprint retrospective to discuss this. Now, you really are ‘done’.