In a recent conversation with one of my developers, I asked when he will be sending me the latest version of the software he is building so I can test it. The answer surprised me: “Never, I’m making sure it works right first time.”
Let me qualify this by saying we encourage our developers to integrate a much higher level of testing as part of their development processes so that quality is baked into each product. However, I still wasn’t expecting such an honest response!
It made me think about the perceived role of professional testers, not only in our organisation but also in the broader software development world. After all, one of the hottest topics in the industry at present, and something I’ve been blogging about as well – digital transformation – has at its core the need to work faster and more efficiently. Moreover, by its very nature, professional testing is the diametric opposite of fast and efficient (not if we want it done properly).
This view is well supported by CapGemini’s ‘World Quality Report 2016-17’, now in its eighth edition, which states that: “When combined with the relentless push for speed through rapid release cycles enabled by Agile and DevOps, digital is resulting in an escalating volume of new developments, technologies and interconnected systems. We see organisations increasingly struggling to find the right approach to quality validation and testing for these systems and technologies.”1
However, is it possible, or even practical? Can we rely on developers to go about their work, through the various product cycles, deploying multiple versions, and fixing issues as they happen to the point where the outcomes don’t need the extra – arguably prudent – step of professional testing?
The short answer is yes; the longer answer is maybe but probably not. (Not very helpful, I know, but read on…).
I’m part of a development team, in and among my various management roles, and have met or worked with every level of developer. Some – the very best ones – have had only limited issues with the code they submit to the development repository. But they are the exception. Most will have small issues, or, if they’re still inexperienced or lacking the necessary skills, almost every piece of code they submit is somehow broken.
After all, we’re only human, and it’s human nature to cut corners, to not test our work, or worse, to regard our work as little more than a day job or side job. However, if you have an elite squad of developers, business analysts and product owners that can work together as a Scrum team of highly talented, dedicated, passionate and committed people, they could probably also be counted on to test their work. Put conversely; professional testing would add little value to the team’s work, given the time and expense.
So there, in a nutshell, you have the quick answer. Yes, you can find situations where professional testers are surplus to requirements. However, more often than not, you won’t. If you take some precautions and enforce certain quality conditions, you may be able to get your not-so-perfect teams to test their work, saving time and money in the process.
Just don’t mistake my position as one where testing can be made redundant. No matter how good your developers or business teams, a lot of time – and I do mean a lot – needs to be spent on testing and re-testing your code somewhere along the line. Almost 26% of project budgets goes towards quality assurance. We also can’t skip the user acceptance phase – so some testing must always take place, be it website testing, user experience testing or device testing, and even though developers should be doing much of this themselves, most of them don’t.
Whenever smaller teams books in a piece of code, they first put it through its paces, using arbitrary data sets, multiple records and numerous devices. This works particularly well on smaller projects with smaller teams, where fewer ‘issues’ can potentially slip through the cracks. In this way, the extra step of ‘professional’ testing has already been done, by professionals, during the build.
The real need for professional testers comes with much larger projects that are either more complex, require massive (and often dispersed) development teams, or those projects with unclear requirements that need to be continuously tested along with the client.
In these cases, even the most skilled developers will struggle to check every box, and then even if they’ve checked their boxes against quality issues, they couldn’t possibly mitigate against potential issues in other parts of the project and with someone else’s code.
Take the analogy of a construction site. Every person on the team is expected to test their work as they go along; the bricklayer, the concrete mixer, the electrician, the roof tiler. Quality checks are built in to each individual’s jobs. The foreman checks on progress from time to time, and it’s taken for granted everyone has checked and double-checked their work before moving on.
If they do, chances are you wouldn’t need a separate team of professionals to come in and inspect the work before signing it off. But what if they don’t? It then becomes a matter of risk – not only the risk of the whole building collapsing but also parts of it failing over time, resulting in ongoing maintenance costs.
When it comes to software, this approach presents a risk in a different sense. If developers know their software has the ‘safety net’ of professional testing before it goes live, are they just as likely to pay attention to quality during the build as, say, those developers committed to quality from the first step?
If your answer to that is “of course they are,” then professional testing might indeed be a step too far. I’d wager that for most companies, especially those that outsource their development or, more commonly, won’t hire elite developers because software development is not their core business, the answer is closer to “probably not.”
Today, the whole approach to digital transformation, driven by “instant-everything” millennials, demands that everything must just work, and fast. I see it every day on the training floor – young developers confidently submitting PHP ecommerce sites they’ve put together in minutes, only to spend the next few days watching testers poke holes in their projects.
The same thinking supports the common wisdom that the first company to market with a new product or service gets the lion’s share. While there’s an advantage to be had by getting to market first, it’s quickly eroded if the product can’t meet your user’s requirements, in which case they’ll have no issue switching to competitors that were slower to market but more committed to quality.
So no, professional testers, your job is not under any threat, and won’t be for quite a while yet.
1 World Quality Report 2016-17, p.7