Once in a while, when I claim that there are fools out there who want to destroy the culture and craft of testing, some people don’t believe me. So, here is a good example of what I’m talking about: Tests are Bad for Developers.
The post is by Stephan Schmidt. He says he has 40+ years of development experience. I also have 40+ years (it will be 41 on January 1st, 2024, the anniversary of my first day at Dale Disharoon, Inc. My first project was writing Hey Diddle Diddle for Apple II and C64.) A difference between us may be that I’ve spent most of my career in the testing field itself, whereas he says he “writes tests” as part of his developer job. In between writing tests I’m guessing he wrote production code, which is not testing. So, at most he’s dabbled in testing.
In his post he says that “QA” people should not do testing. Only developers should do testing. Let me expand that: he thinks the world would be better if developers, who at best test a fraction of their time and rarely receive any training for it, are the only people who test. He says this is part of developer accountability. I say this a shockingly stupid idea.
Note: When I use the word stupid I’m following a protocol I developed from reading The Triumph of Emptiness. In this book, Mats Alvesson defines “functional stupidity” not as the inability to think, but rather as “a socially supported lack of reflexivity, substantive reasoning, and justification. It entails a refusal to use intellectual resources outside a narrow and ‘safe’ terrain of adaptation to and exploitation of a given social situation. It has nothing to do with low intelligence—people can be intelligent (be good at IQ tests) and be functionally stupid.” (Triumph of Emptiness, p. 216)
The testing field within the computing field has been around for at least 60 years. There are many books and countless scholarly papers about software testing. There are testing conferences, testing companies, and people who are recognized as experts in testing. There are people– me for instance– who have dedicated their careers to testing. No one with 40 years of experience has ANY EXCUSE for not knowing this. But Stephan ignores it. He dismisses us all with a wave of this pen. This is functional stupidity in action.
Schmidt repeatedly refers to the activity of “writing tests.” This tells me he thinks testing is a mechanical process of output checking and nothing more than that. What about test strategy, test design, and testing that embraces the entire user experience? I’m going to guess that Mr. Schmidt’s eyes glaze over when serious testers want to talk about the governing heuristics, structures and skills of testing. How can I possibly know that? Because people who are excited to study and think about testing understand that the test process is not encodeable; they understand that output checking is not the goal or soul of testing. People who enjoy testing understand that most important bugs are NOT found by ANY highly scripted process. Want proof? Just keep track of how bugs are found and you’ll see for yourself. The proof is happening all around you. Just look! I’ve been looking for decades.
Here’s an example from YESTERDAY. I am writing an extension for Chrome (yes, I’m a developer, sometimes). I read lots of documentation and followed online tutorials. I got my extension to work reliably on my machine. But when my brother tried it, it was very flakey. After two days of experiments and lots of different theories, we realized what was going on and I believe I have fixed it. Developing an automated or otherwise scripted check to reveal this problem would have been a great waste of time. Not only would I not be sure (before I knew that there was a problem) what such a check should be, but any check that could have found the problem would have needed expensive GUI-level automation. Due to the nature of this specific bug, the problem would have occurred probabilistically, depending on the architecture of a particular website being browsed at the moment the extension was invoked.
You shouldn’t “write a test” for that, unless you want to waste your company’s time and money. You should perform experiential, highly exploratory testing. If you are a developer, you don’t have a lot of time for that. There is, however, a different kind of person who has both the time and the desire: a tester.
Recommendation: Never use the phrase “write a test.” Procedures can be written, but a test is not a procedure. Instead, a test is a performance. You can say “I created a test” or “I designed a test” or “I wrote a test procedure” or even “I wrote some test code.” None of those phrases imply that testing is an algorithmic activity.
My father was a fighter pilot. He said the most common mistake new fighter pilots make is that they think in only two dimensions. I remember that when I hear people confuse checking with testing, and when people think there is nothing more to testing than the bit of coding that a developer feels like doing (while dissing the entire field of skilled testing). These people are living in flatland.