Look through any combination of today’s IT news feeds and you could quickly gain an impression that software testing is dead. Feeds are full of stories claiming that with so many companies going Agile, all the testing is either going to be done by developers or via testing robots. At the same time, you’ll also find dramatic news about the latest epic software failures and their resulting negative financial implications. And what’s the first thing that everyone says when they hear about a failure? They should have done more testing…

Clearly, in today’s fast-moving digital economy, quality and testing are going to be more important than ever. What we’re seeing is that to keep pace with inevitable change, more and more companies are adopting an Agile approach – and consequently testing is becoming everyone’s responsibility.

We’re finding that more testing is now being done in development, but this in no way should negate the need for highly professional Quality Assurance teams and testers. As ever, organisations need to think hard about their testing requirements. What are they going to be testing? What types of tests will they need to run? And what are the likely risks that are going to be involved?

Thinking About What Needs To Be Tested

One of the big drivers for shifting testing from QA to development is the adoption of Agile. But consider the origin of Agile. It’s a methodology that was originally developed to help developers create code faster, in parallel. Each developer is assigned a single story for delivery in a two-week sprint. But what happens when there is no development – for example in the case of an SAP transport? Who writes the test script when there is no story or code to test against?

Without a testing team in place, this responsibility always falls back to the business. As a result, business users are being pulled away from more productive work to document existing processes and run manual/exploratory system tests. When they find a defect they start the tedious process of documenting, taking screen shots and submitting to the supporting IT team. All of this detracts from business users’ primary jobs – and inevitably reduces the value that they can bring to the business.

So What Types Of Tests Should You Be Running?

For a single feature or application, a range of tests – unit, component, and functional – may be run by development. But what happens when the new feature or update is part of a larger ecosystem that stretches across multiple applications in the cloud and on premise? Who is then responsible for building regression test libraries and running end-to-end tests to ensure downstream systems aren’t impacted by change?

Documenting these complex processes alone can take weeks. Effective testing also needs input from multiple groups who may not have visibility into the entire process. And then there’s the growing demand to run these tests more frequently – monthly, weekly or even daily. Who is responsible for maintaining automation and ensuring cross-functional documentation is kept up to date when tests are updated?

Are You Taking Account Of All The Risks Involved?

With many industries now operating under increasingly strict legal and regulatory regimes, it’s critical for them to carefully document any system changes to meet audit requirements. And that’s increasingly challenging. In a recent presentation on compliance given by a major airline, they discussed how they have some 45 automated controls within their SAP deployment, made up of 58 different documents. Every three months, these controls have to be validated by capturing the document and comparing it to expected results. Work this significant and detailed clearly requires a centralised team.

In addition to legal risks there are also the risks of a catastrophic failure, including major loss in revenues and negative public perception. Whether it’s the recent British Airways software failure that led to disruption for 75,000 passengers, or the recent international cybersecurity attacks, organisations simply can’t afford to carry business risks on this scale. They also can’t afford to wait until something breaks in order to make a fix.

Establishing A New Role For QA

As more organisations adopt Agile methodologies for the deployment of custom applications, more unit/component/functional testing will continue to “shift-left” to developers. But this doesn’t eliminate the need for centralised change management and QA teams. Application landscapes will continue to become more complex — not less. It’s not about any single piece of software working. Today, it’s about the business working.

And with today’s organisations increasingly turning to packaged applications such as SAP, Salesforce and Workday to manage underlying business processes, development teams are having to focus their efforts on custom applications that touch the customer directly. Change management for applications like SAP requires a higher level of orchestration and management. This simply can’t be achieved in an ad-hoc fashion, or using Agile scrum methodology. The adoption of a Scaled Agile Framework (SAFe) is one way the role of QA teams is quickly evolving.

Whatever the approach, one thing is for sure – as long as organisations continue to rely on complicated networks of software to get business done, QA has a vital and important role to play!