I see so many people lately talking about the “death of manual testing.” Opinions obviously polarize on this but what I don’t see is testers engaging at all with why this perception is there. There is a form of indoctrination that happens across the industry. And testers, by and large, do nothing to combat it. Largely because they ignore where it’s coming from. Let’s talk about this a bit.
This indoctrination is by no means some insidious, planned out mechanism for the destruction of all manual testing or those who specialize in testing. Rather, it’s a natural outgrowth of the way information is presented in a rapidly changing technical and social context. It manifests most in a rising technocracy within the testing field, wherein to survive, you must learn automation and you must basically become as much like a developer as you can.
But then many other testers often wonder why their discipline is talked about in terms of automation only or why some may job opportunities are seemingly focused only on automation.
Let’s Look at Some Evidence
Well, consider this line from the book Continuous Delivery with Docker and Jenkins:
“Automated Acceptance Testing: This replaces the manual QA phase and checks if the features implemented by developers meet the client’s requirements.”
Many such books say statements very much like that. So a lot of people reading these books — and these are going to be developers and development managers — are seeing that “QA” (conflated with “testing” usually) is something that is on the decline.
Consider the book Infrastructure as Code, which says:
“Every problem discovered in manual testing — and in production — may be an opportunity to ask whether an automated test would catch a similar error earlier.”
Somewhat benign, you might think. But if you read the book it’s very clear that building the automation is really what you want to do. And if manual testing does have to happen and if it does happen to find something, consider how automation could have caught it.
In the book Production-Ready Microservices, you’ll read this:
“One of the key principles of software engineering in practice is this: if you have to do something manually more than once, automate it so that you never have to do it again.”
That doesn’t sound terribly bad necessarily. Until you realize some could say that this is why you “automate away” any manual testing, treating one round of testing the same as any other. After all, what’s the difference, right?
And if you combine that with the thought from Infrastructure as Code, you might think that this is the way to gradually reduce “manual testing”. And if you read the Continuous Delivery book, you may feel that you should replace that “QA Phase” entirely anyway.
There is a progression of thought there.
Consequences of the Evidence
Imagine you are a development manager or a developer or a new person coming into the field and these are the things you are being presented with because these are the books you are likely to read to stay relevant in your career. So you are constantly being reinforced in your view that anything “not automated” is probably a waste of time. And thus anyone not working towards automation is likely a waste of space.
And developers — who are building the things that add revenue and deliver value to customers — tend to have the ear of management and the business more. After all, it is true: if the business didn’t have the development (and thus ultimately production code), there would be no business.
So you have business who listens to a particular group (development) who are telling them a message they want to hear (automation can get things out continuously and we can fix and deploy immediately). And that group who is telling them this is constantly reinforced in their view by numerous authors, blogs, podcasts, conferences, and so forth. And the materials provided by those authors, bloggers, and casters are entirely reinforced by an industry that does want to move faster and sustain a much more rapid pace to be competitive.
The Tester Complicity In This
Testers often aren’t aware of these sentiments if they don’t read these books and don’t participate in the places where these books are discussed. And I find many testers who never read these books; who never attempt to learn how (or even if) their discipline is being well-represented.
Instead what testers are doing is regurgitating ideas like “testing and checking” (usually to each other, patting themselves on the back for a distinction well made) or decrying the prevalence of automation (to a wider audience that isn’t listening), or quoting folks like Boris Beizer, Cem Kaner, W. Edwards Deming (to an audience that struggles to see the relevance). Testers are often fighting battles on the wrong battlefield, using the wrong weapons, and part of that is because they’re not engaging in the wider discipline around them or understanding how their fellow peers, particularly developers, understand, consume, and articulate that wider discipline.
I’m not saying these ideas, in the broad strokes, would come as a surprise to testers. But what I am saying is that there is a sustained progression of these ideas throughout the industry. And those ideas are, if anything, gaining more and more traction. Participating in the places and times where those ideas are being discussed is necessary. There needs to be more of a point-counterpoint approach to giving people different ways to look at things and put some nuance into what testing is.
I talked about project forces before and the above is one that we are dealing with all the time. It’s an external force that is operative on our industry and I hope I’ve presented it in a way that is fair. Because it’s really easy to see. If you look, that is.
Testers: Broaden Your Horizons
I feel comfortable pontificating on this with my normal opinionated stance because I’ve been talking about the need for testers to be cross-discipline associative for quite some time and in that post I talk about development-level thinking as informing test-level thinking.
Taking another data point, how many testers do you know who have read the book Developer Testing: Building Quality into Software? It’s an excellent look at how some developers view testing and I would argue it’s a book that has a lot of value, particularly because it is not at all dismissive of human-focused testing. But has the phrase “Developer Testing” caused many testers who are not developers to simply not check out the book, and thus learning some valuable insights into testing as perceived by developers.
Testers need to broaden their horizons and understand that, in many cases, where they are choosing to wage their battles is not where the war is even being fought. Testers are often planting their victory flags on hills that no one was trying to take anyway.