The Future of QA: The Role of Testers Is Rapidly Evolving
The Future of QA: The Role of Testers Is Rapidly Evolving
What does the current brave new world we live in have to say about the past, present and — more importantly — the future of quality assurance (QA)?
Join the DZone community and get the full member experience.Join For Free
We’re living through interesting times in the software world. Software teams can automate much of their development pipelines. Trends like DevOps and DevSecOps blur the lines between roles inside software organizations. Voice assistants, VR, and the Internet of Things are exciting trends that bring as much uncertainty as they bring potential. What about the testing front? What does the current brave new world we live in have to say about the past, present and — more importantly — the future of quality assurance (QA)?
You may also like: Who Is a QA Tester in the Future?
That’s the question this article aims to answer. I’ll do that by arguing in favor of a simple thesis: the role of testers is changing and evolving at an amazingly fast pace, and that’s okay.
We begin by covering the QA of the past. What did most organization’s quality strategies look like in the not so distant past? What are the challenges software organizations faced back then?
After that, we’ll go to our time. How is QA done today? How does automation affect it? What are the challenges software organizations are facing?
Then we’ll get to the future. We will examine why it is okay that the role of testers is changing, and how advanced tools, empowered by artificial intelligence (AI), can take QA to the next level.
QA in the Past: A Manual, Slow, and Error-Prone Process
How did organizations perform QA in the past? The short answer is: slowly and painfully. Stick around for the slightly longer answer.
Think of the traditional waterfall model, with its sequential phases, each flowing into the next one. In this classic model, testing and other quality verification activities are just phases like any other. Worse yet, they’re one of the final stages in the whole process. If bugs were found, they were quite expensive to fix at this late stage. Often the pressure to meet a release deadline meant that testing was shortened or worse, bugs discovered were simply pushed to production.
The general problems that the waterfall method causes are well documented and have been so for decades, so I won’t dwell too much on them or the other problems that late testing can cause.
I would like to say that these problems aren’t unsolvable. On the contrary: we can fix them, as long as we test more often and earlier in the software development process. Doing so manually, though, would be unfeasible. That’s where automation comes in handy. The next section will cover how automation changed the way organizations do QA, resulting in the QA practiced today.
QA Today: A Partially Automated Process
With the past out of the way, let’s cover the present. We’re going to see what contemporary QA looks like — what are its strengths, weaknesses, and major challenges.
Automation Enters the Ring
Automation empowers present-day QA, in such a way that it solves — or at least alleviates — many of the problems of past QA. How does that happen?
When most people think about automation, they think of speed as its main benefit. When it comes to automation applied to testing and to QA, there’s another crucial benefit: namely, that it enables organizations to adopt what is sometimes called shift-left testing.
Shift-left testing might sound sophisticated, but it just means that you perform testing and other quality-related activities earlier in the software development process. Automation allows testing to occur both earlier and more often in the software development process. However, some challenges still remain.
Automation Hasn’t Solved Everything
Automation has been an incredibly helpful aid to QA, but it’s far from being a panacea. There are still important challenges that QA teams face. For instance, testing maintenance is still a burden for many teams, and it threatens to jeopardize many software testing endeavors. When a test suite becomes a burden rather than an ally, it doesn’t take long until the team gives up on the whole effort.
The Future of QA: AI Will Play a Major Role
Now I want to discuss the future of QA and how the role of the tester is going through rapid changes. Before I do that; however, I’d like to describe how the current “era” in the history of QA is nothing but a transitory stage.
We’re Living Through a Transition Stage
We live in the “automation-assisted” era, where automation is used as an aid to improve testing. The era we’re heading to is the one of autonomous testing. In this future stage, testing tools will become autonomous tools. They’ll be able to oversee test creation, maintenance, and execution. They will also be able to learn from failed tests and, based on that learning, make decisions on how to create and execute new tests.
But right now automation only assists testing teams.
No One’s Sure Who Owns QA, and That’s OK
We’re living through a temporary stage, and one of the most interesting consequences of that is that no one seems to agree on who, inside a software organization, should own QA.
There are organizations where QA is the responsibility of a dedicated, full-time department. In others, it’s the job of a smaller QA department, which is a subset of the development team.
And finally, there are those where QA is just another responsibility of the developers—though that seems to be the least common option.
What does this uncertainty mean? It means that the world of testing and QA is evolving so fast there has been no time for standards to consolidate and consensus to be agreed upon. In other words, this is all very good news. The software industry doesn’t agree on who should own QA, and it shouldn’t. Things are changing so fast — and they will continue to change — that, by the time a consensus is reached, it’s already outdated.
Opinions expressed by DZone contributors are their own.