2016 has been my first year in the testing industry.  Prior to that, I was in the software development industry. For the most part, these industries share more similarities and differences, as they (should) go hand-in-hand. However, I have noticed that the testing industry seems to be lagging the software development industry with respect to how teams are able to quickly respond to change and to deliver software to the customer more often. In other words, the testing industry is less Agile than the development industry.

As a Tech Marketer, one of my responsibilities is to research industry trends in order to relate them to the business (my employer) and how it goes to market. From what I’ve learned over the past few years, here’s how I see Agile development and DevOps driving Agile testing.

Agile has gone mainstream in development with DevOps not far behind. Software testing may follow the same path.


This key finding from the 2016-17 The World Quality Report instantly resonated with me: Agile and DevOps continue to grow in adoption, with QA making a corresponding move[i].

Agile has been around for many years now (see the 2001 Agile Manifesto). Its popularity has ebbed and flowed over the years but it’s hard to deny that it now has mass appeal and is considered mainstream. In the past several years, we’ve seen mega-sized multinational companies in conservative industries such as financial services adopting Agile. As mainstream companies go Agile with their development, more and more companies will demand that their testing also be Agile. The ability to respond quickly to change is critical to many companies nowadays. This ability is now expected from IT. This means faster release cycles, which means IT structures with Agile development, DevOps that can keep pace with development (i.e. release software at a similar pace at which its developed), and testing that “shifts left” to keep pace with it all. (Shameless plug: read our piece on Agile Testing and/or DevOps Uncovered to learn more)

Test teams will further integrate with development, reducing the demand for Testing Centres of Excellence(TCOEs) but not eliminating them.


Coming from an Agile development background, I was surprised to learn that Testing Centres of Excellence were seemingly so popular because it seems like they were designed for traditional Waterfall development environments (and to save money by offshoring testing to lower cost locations). For testing to also be Agile, it needs to be integrated into the Agile development team, which means collocated (on the same site) or nearby. Testers need to get involved in sprints, daily-stand ups and other core components of Agile. It’d be difficult if not impossible to do so from a silo in a centre of excellence. While this poses a major challenge to many organisations that have global delivery models that have been setup for the purposes of cost savings, it does not mean that Agile testing is out of reach for them nor does it mean the end of TCOEs. It simply means that they will need to shift some of their testers from their TCOEs to delivery sites to find the right balance between quality and cost effectiveness  (Our partner Experimentus is also making this prediction in their Six Predictions for Software Testing article).

Testing departments may be circumvented by Agile development teams if they (Testing) don’t adapt


I’ll leave you with an anecdote that can be taken as a forewarning by Diego Lo Giudice of Forrester in a ComputerWeekly article:

Traditional testing practices were designed to optimise the operation of large, centralised testing groups using a testing centre of excellence (TCOE) model. But the shared-services approach breaks down at agile organisations because it cannot support the rapid delivery rates of agile development teams. For example, the US Department of the Treasury’s Financial Management Service had to completely isolate a major agile project from the regular IT department’s governance processes, including the TCOE. The team employed a testing and development process using a behaviour-driven development (BDD) approach with great success.

The development team selected and used Cucumber, an open-source testing tool, because it supported the new approach better than traditional testing tools. The result was a higher degree of automation and speed in testing than would have been possible had the team been forced to comply with TCOE governance and processes.

[i] https://www.uk.capgemini.com/thought-leadership/world-quality-report-2016-17

Joe Kevens