I see a lot of vocal pundits in the testing world saying that artificial intelligence (by however they choose to define that) is no threat to future testing. I’ll ignore for a moment that most of these pundits get AI wrong — equating it, as they do, with “better algorithms” — but I won’t ignore that they seem to forget a key point: will there be a perception that AI can handle future testing?

We already have this debate with automation, don’t we? So for those pundits dismissing AI, with their half-baked knowledge of what it is, let’s at least realize that this is an area that testers do need to get ahead of. We can’t wait until the problem is here and then engage in the equivalent of “testing vs checking” debates about it.

As a case in point, I’ll remind about my post on testing and AI, where it is demonstrable that, in games at least, AI has found bugs and/or exploits that humans have not.

Framing the Angst

So let’s frame this angst about AI a little differently. Do testers even understand why some people think that testing, as an activity, can be wrapped up in AI or, more specifically, machine learning? Do testers understand why that perception might exist? It’s worthwhile asking this because, as one example, testers often don’t seem to truly understand how the perception of the “death” of manual testing is being reinforced. So there’s at least reason to be skeptical.

Let’s argue it this way. Testing, as an execution activity, could be said to be fundamentally about applying sample inputs to a system and then measuring the outputs to determine the correctness of the system’s behavior. Testing input and output functions is basically what the concept of training does in current machine learning systems.

Let’s further argue this point. Testing, as an execution activity, has remained largely as a linear function with respect to test coverage over functionality. By contrast, complexity in product design and implementation has grown almost exponentially.

Okay, so apply your tester hat. If all of that’s true, what does that mean?

It means no system we design or implement could be tested anywhere near efficiently and perhaps, as time goes on, not even effectively. In other words, if complexity is growing as it is, then our ability to test these systems is far being outstripped by our abilities to design and implement them.

If complexity has become exponential and testing has remained linear, that is one very logical conclusion. Particularly if you only focus on testing as an execution activity.

Reframe Away the Angst

But if testing is framed as a design activity does that change this thinking? If you read me regularly or hear me talk in various places, you’ll know that I’m often talking about this distinction: testing as design activity and testing as execution activity.

The discussion here, in part, is why. That distinction is based on my understanding of the fundamental issues around why testing is often dismissed, marginalized or conflated with programming activities. This is why arguments like “testing vs checking” — which I’ve often been against — simply do not resonate with people. Or, rather, they do resonate for the people already inclined to believe that distinction matters: mainly testers.

I don’t mean to pick on just that argument. It simply happens to be one of the most visible among the industry today. But there are plenty of others, such as testers not evolving well into contexts like Agile or DevOps. Yet that’s all those things are. Contexts. They are ways of thinking and doing. They are not inherently bad or good. They can bring their own problems with scale and, with that, some inefficiencies. But they can also bring the ability to scale with efficiency.

Yet, that being said, I’ve seen many of our most vocal test pundits complaining about Agile or DevOps. Just as much as they complain about automation. And just as much as they now have started complaining about AI and machine learning and the future of testing.

Wherefore the Angst

Thus is the future angst being driven into a whole generation of up-and-coming testers.

Rather than bemoan these contexts, or inaccurately frame them, let’s figure out the fundamental issues of why testing is sometimes viewed the way it is. Let’s understand the distinctions between a testing role and a testing activity. Let’s not conflate those two things. Let’s realize that everyone does test. But not everyone is a specialist tester. But what does that mean? How does that impact the ability to get services and products into the hands of users where value is added and competitive advantage is retained or strengthened?

The specialized testing industry is rapidly becoming one that listens to a series of consultants that need something to rail against by positing that something — automation, DevOps, AI — is the enemy of testing and quality and is thus causing a decline in both.

Apply Counter-Pressures

Far from acting as a counter-pressure to a wider industry that itself views testing with angst, this kind of thinking and articulation is adding to the very pressures that are diminishing testing. Not just diminishing, but making it that much more difficult for testers to become a type of developer and for porting development lessons to testing.

I’ll remind folks of my context: I’ve been in this career since 1990. I’ve been a full-time employee, I’ve been a contractor, and I’ve been a consultant. I’ve also run my own test consulting company. I remind of this only to show that I don’t have an axe to grind in terms of something I haven’t done or participated in myself.

And I want be very clear here: what all that experience has shown me as I’ve watched the trends — particularly since about 2009 — is that the future angst testers are feeling is coming from within. The danger to our discipline, and how it is situated, is coming from within our own ranks. There is a kind of testing fundamentalism that has set in; often, ironically perhaps, from groups that say everything is driven by context. That is unless your context doesn’t happen to agree with theirs. In which case, in their eyes, you’re usually just “wrong.”

While I sound very certain about the above — and I am — what I’m less certain of is whether I’m still part of the problem or I’m starting to become part of the solution.