More on the “commoditisation of testing”

I recently saw an article about UBS centralizing its “QA”:

http://qa-financial.com/knowledge-bank/qa-testing/ubs-centralises-qa-raises-expectations-vendors

A few parts of the article stood out for me:

…One major issue that vendors of outsourced testing and quality assurance will have to grapple with … is that they too will have to show that automation will lower their headcounts and the costs they pass on to UBS.

It’s an interesting idea that automation will lead to lower headcounts and reduction in cost. It seems more likely that overall headcount would remain much the same, as additional effort is spent on automation and less effort spent on “manual” testing. Or maybe the goal here is to replace manual testing with automation? The article reads like cost reduction is the goal but automation is not a direct means of cost reduction (though it does give you lots of other great benefits when done well).

Automation … means testing is becoming commoditised and cheaper, and that in turn means vendors should be able to pass on their lower costs.

Really? Testing has become commoditized in the sense that it’s become a race to the bottom in terms of cost, at the expense of real testing skills. Certification has helped the commoditization cause to some extent too, why wouldn’t you hire tester A with certification X in a low cost location over tester B with the same certification X in a high cost location, you’re getting the same thing for less money, right? Well, though they come with the same X Factor, you’re probably not getting the same skills and there are other costs associated with running testing teams in geographically distant locations.

I don’t see the relationship between increased levels of automation and commoditization, as I see the benefits of automation as being different from “testing”. We can automate a lot of “checking” work and we can leverage automation to enhance our abilities to perform testing, but it doesn’t follow that more automation leads to commoditization of what I think of as “testing”.

Quality assurance staff currently represents approximately 20% of the total UBS headcount of staff employed in software engineering and it’s a proportion that Adams expects to fall, and the reason is simple. The automation of app testing and development means fewer human testers, in proportion to the development team as a whole.

OK, so now we’re getting there, the expectation is that they can replace what humans are doing by automation on machines. If all the humans are doing is checking work and not adding any other value that we know great testers can add, then maybe they’re right. But if they’re right, surely it would be worth looking at having more skilled humans doing the value-add work?

“If we were running a music streaming business and our website went down, then we wouldn’t be in the same kind of trouble that a bank would be in if the same thing happened. In QA, we are the the last stop in the process of making sure that doesn’t happen.”

Another shop where “QA” are seen as the “last line of defence”, in 2016. This centralized QA team can look forward to lots of blame being directed their way in the future – and most of it will be blame for things they had little or no control over. A great model!

…the restructuring has established that skills in test engineering are fungible across the major business lines of UBS, and that will accelerate our automation and performance engineering.

Yes, I had to look up what “fungible” means (dictionary.com definition: “being of such nature or kind as to be freely exchangeable or replaceable, in whole or in part, for another of like nature or kind”). The idea appears to be that all the major business lines of UBS in which these testers will be responsible for testing apps are so similar that testing skills are transferable between all of them. This is a best/common practices notion that either doesn’t believe – or simply refuses to acknowledge – that individual project context is one of the most important factors in determining how a tester should operate in that project in order to be of the most value. I strongly believe that test approaches and skills are context dependent – and maybe that’s why I had no idea what “fungible” meant.

This move to centralize will no doubt be followed by a move to decentralize as the circle of testing life goes around. It’s much like the test outsourcing push of recent years, but that tide is already turning as companies like Doran Jones show how local high quality testing talent can be more effective (both in terms of doing good testing and costing less money) in what’s becoming known as “reshoring”.

In some ways, articles like this one from another big company like UBS are just noise and we shouldn’t worry too much about them. But in other ways, this kind of article gets picked up by other big companies and seen as promoting good ideas, big companies tend to follow the lead of other big companies. So maybe we’ll see more “centralized QA” departments following the UBS lead, but it’s just a matter of time before we start reading about the “decentralization of QA”. For those of us with a passion for good context-aware software testing that genuinely adds value to projects, all we can do is publicly state our cases, critique articles like this one, and connect with others of a similar mindset to influence the decision makers within our organizations.