Projects which run within an agile framework typically have faster product releases and better customer satisfaction, teams work more efficiently, and projects comfortably meet deadlines and budget targets.

But does it suit every industry? Can risk-averse sectors such as finance also benefit from bringing testing into an agile methodology, or is there simply too much red tape and regulation to allow it to work successfully?

At first glance, agile testing and finance seem incompatible, with the greatest risks appearing to be incomplete testing and slower development. The fear that agile testing will be incomplete testing seems logical at first glance: how could you possibly test everything if you’re working iteratively in short sprints? Agile testing can seem haphazard, but, of course, that’s not the case. In a waterfall approach, a tester will have a list of requirements, which they use to define test cases. Yet, bugs are found with regular frequency in live systems even after these ‘comprehensive’ test cases have passed. Little thought is given to how and where applications will fail – the interest is just that it has passed a particular check. There is a fundamental difference when testing with agility. Testing with agility makes it possible to use modern tooling, gain quick feedback, and execute the same level of checks without relying on heavily documented and time-intensive test cases.

Waterfall vs. agile

The second fear, that testing will slow development, can be true – in a waterfall approach. Managers who only know testing from waterfall will think of testing as a long process. Testers write a test plan and approach based on the requirements, followed by test suites and cases to meet the coverage demand. It’s a very labour intensive process. Bottlenecks are created when the development and testing are not done in parallel, and then at the end of a lengthy test period, the development team are presented with a long list of problems to resolve. This process is repeated and repeated as code changes introduce more, new and different bugs, leading to increased costs and missed delivery dates.

But agile testing takes the opposite approach. Testing with agility produces frequent feedback based on shared models and information, and constant questioning as development is ongoing. Even simple changes to the development cycle, such as testing on development branches, allows testers to give frequent feedback, which developers can immediately incorporate into their own work to produce effective results.

Mind maps can be an excellent aide memoir, and extremely useful alternatives to writing out full test cases. Recording exploratory journeys can provide useful evidence and the ability to replay this execution can give a greater scrutiny to spot problems. Where possible, replacing manual test cases with automation will reduce the need for manual testing for regression.

Testers can also ensure good unit and integration tests are used and new ones added when code is changed and bugs are fixed, to avoid future regression.

Sprint planning

A noticeable factor in the finance industry is its reliance on reports – which is at odds with the agile manifesto’s ethos of ‘working software over comprehensive documentation’. Bringing clients into the agile process is the best way to help them realise that they don’t necessarily need or want highly detailed documentation and that sharing knowledge with minimal documentation actually speeds up development and creates a culture of action and accountability. By being involved in the project from the beginning, finance clients see the efficacy of our testing, they understand how and why we’ve tested, and they have the confidence to be able to replicate similar tests if they do any more development in the future.

We want to avoid over-documenting and we need to feel confident that we can share the right knowledge with clients and other testers who may work on the project in the future. Projects need to uncover what information is valuable or useful. Bug counts will tell you little about the state of the application, but providing usable software to demo and use can display progress – and also build confidence that you are building the right thing.

The traditional view of testing is that it follows on from development: it’s a final quality check before the code is further developed, or released. In a regulation-heavy industry such as finance, this presents a real risk for development. Bringing testing in early gives your project a high level of quality and confidence from the start. If you’re working in two-week sprints, you’ll immediately see the benefits of starting testing in the first week, instead of in the middle of week two. Bugs will be found and driven out early in the cycle, smoothing the delivery towards the end of the sprint.

Testing with agility is not only suitable for the finance industry, it’s critical. It’s the best way to deliver robust, reliable software, and an essential part of any financial software development.

Written by Head of Testing, Scott Logic, Laurene Pisani