Today’s news feeds are full of articles claiming that software testing is dead. According to these articles, companies are going agile and testing will either be done by developers or by testing robots. On the flip side, there are just as many articles in the news that report epic software failures and resulting financial losses. And what is the first thing everyone says when they hear of a failure? They should have done more testing!
Clearly, in the new digital economy, quality and testing are more important than ever. To keep pace with change, companies are adopting Agile and testing is becoming the responsibility of everyone. As a result, more testing is being done in development. But does this all really negate the need for Quality Assurance teams and testers? I think this boil down to three key factors:
What Are You Testing?
One of the big drivers of shifting testing from QA to development is the adoption of Agile. But consider the origin of Agile. It’s a methodology that originated to help developers develop more code faster and in parallel. Each developer is assigned a single story that they set out to deliver 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, this responsibility falls back onto the business. Business users are then pulled away from their work to document existing processes and run manual/exploratory tests of the system. When they find a defect, they must go through 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 reduces the value they bring to the company.
What Types of Tests Need to Be Run?
For a single feature or application, unit, component, and functional tests 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 responsible for building regression test libraries and running the 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 – even monthly, weekly, or daily. Who will be responsible for maintaining the automation and ensuring cross-functional documentation is kept up to date when tests are updated?
What Are the Risks?
Many industries operate under strict legal regulations. Any changes to systems must be documented and meet audit requirements. In a presentation given by Southwest Airlines on SOX compliance, they discussed how they had 45 automated controls within SAP, comprising 58 different documents. Each quarter, these controls had to be validated by capturing the document and comparing it to expected results. Something this significant and detailed clearly requires a centralized team. In addition to legal risks, there are the risks of a catastrophic failure including a major loss in revenue and/or negative public perception. The Starbucks register malfunction which caused 60% of stores to close in the US and Canada is just one of the many examples that have taken place in the last few years.
The New Role of QA – Make Sure the Business Works, Not Just the Software
It is true that as more organizations 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 negate the need for centralized change management and QA teams. Application landscapes are becoming more complex -- not less. It’s not about anyone single piece of software working. Today, it’s about the business working. More organizations are turning to packaged applications like SAP, Salesforce.com and Workday to manage underlying business processes so they can focus custom development on applications that touch the customer directly. They are looking to differentiate themselves and their products from their competitors. Change management for applications like SAP requires a higher level of orchestration and management that can’t be achieved in an ad-hoc fashion or using Agile scrum methodology. The adoption of Scaled Agile Framework (SAFe) is one-way organizations are evolving the role of their QA teams. Whatever the approach, one thing is for sure - as long as organizations continue to rely on complicated networks of software to get business done, QA will be needed and important!