Automation and the Race to Zero

One of the core goals we often hear at Tricentis when engaging with a prospective or existing customer is the desire to achieve the magical number of zero with the use of automated software testing. Zero production defects, zero risk to business or client operations and zero wasted time by development or project teams.

This lofty desire is often underpinned by previous problematic iterations or attempts where a different kind of zero is achieved: zero lasting results. Obviously not a result any government department wants. The burning question in these situations: was the use of software testing automation to drive efficiency, reduce costs and produce better quality software ever actually attainable?

Our recent global study How the World’s Top Organisations Test identified the sticking points where things can go wrong before they even begin.

One of the key metrics examined how businesses or departments identify what applications or processes are the right ones to target for software testing automation. Some 85% of respondents named Business Impact as the most important reason, indicating a strong and positive step in the process of implementing an automation strategy. Worryingly though, the study also found that that 93% of customers only presented the business results and success of their automation to their immediate department. In other words, the work they were doing was entirely siloed, yielding only minor benefits in the larger picture.

The reality is that most enterprise application landscapes are comprised of more than 900 applications, and a single complex workflow (such as a provisioning a customer) can interface with 82 different technologies. Given ownership of these differing technologies will lie with individual portfolios or departments, each with their own set of goals and business objectives, if the testing or automation of software testing is occurring in a silo and results are not communicated outside of the department, then unified success will not occur.

The answer is based in strategy — specifically a consolidated enterprise automation strategy. We find that most strategies are developed around an application, project, or portfolio level and while this is adequate as a starting point, it is not sustainable for the long term. After all, within a 36-month period, which is on average the standard for ROI of an enterprise automation rollout, projects can finish, applications be replaced and portfolios merged, or re-structured.

After all, the only consistency in organisations is change itself. That is why it is critical that a software testing automation strategy is aligned with higher goals than simply technical or short-term project ones. It should be aligned with business outcomes, and it must also be adaptable, able to flex and change when the business conditions force it to do so. Consistent review and adaptation are key to success. Indeed, well run agile projects with continuous retrospectives, and process change cycles are a great yardstick with which to benchmark the process.

For those who face resistance within the organisation to a large change like software testing automation, having a designated leader drive the change strategy is essential. They’ll need to use their skills of persuasion, negotiation, presentation, and compassion to achieve the best results, often managing resistance from those who believe their role may become redundant if software can perform most of the role they perform today.

Across all the enterprises we work with, including in Australia, Services Australia, Department of Foreign Affairs and Trade and Department of Finance, those that deliver successful implementations of automated software testing strategies have five strikingly similar characteristics.

1. Define the goal
2. Build the strategy
3. Execute on the strategy in manageable sprints or groups of work
4. Report the successes in common metrics; and
5. Continuously adapt

Software testing automation can greatly increase the efficiency of operations, remove costly production issues, and reduce idle project time. It’s certainly worth serious consideration because whilst the end goal of zero may not yet be achieved, it is certainly a realistic target.

Image credit: ©stock.adobe.com/au/NicoElNino