Testing, in every company the world over, has always been under threat.
Facebook famously didn’t hire them. Yahoo were the same. Plenty of companies, borne from when they were startups, or when they transitioned from Waterfall to Agile, decided that once they had developers writing tests in code plus POs to UAT, testers were just an expense.
First hand, I can say that testers are often deemed an unnecessary expense in a time of recession. In the global recession of 2007/8, many got laid off, couldn’t get rehired, and went into other fields. When a couple of years had passed, and software quality had suffered, hiring more testers was hard.
So why are testers expendable?
Well, they aren’t. But clearly they look like they could be. What’s their output, really?
If a tree falls in the forest, but there’s nobody around to hear it, does it make a sound?
This old philosophical riddle is about perception and observation.
If you add beer, it’s about metaphysics and the nature of existence.
If you add beer to software engineers, it’s about whether that part of our simulation is even rendered when not in a playable characters field of vision.
If a tester performs some testing, but there are no actionable results, does it make a sound?
If the testing isn’t broadcast to the team, then perhaps they’re observed as having done no work.
Similarly, if the testing finds nothing actionable, did it have value? Sure, the tester wasn’t doing no work, but were they doing the right work? Surely their job is about finding the stuff that doesn’t work?
Of course the above is nonsense. The role of a tester within a team or project is to ask questions of the software. Confidence that the questions have been asked is as valuable as the answer. We know more about how it actually operates than we did before, and we can compare that to our overall goals and to our specific intent.
In 1986, Clarion and others said that CASE tools (Computer Aided Software Engineering) would remove most of the effort and all of the testing needs from the SDLC, removing the cost of those expensive humans from the poor businesses struggling to make some money.
Of course it didn’t happen. When people tell me that a new IDE will automate all of the testing, or when they say that ChatGPT can interpret the sum of human knowledge and “think” up the correct test cases, I know that the promise is old, the premise is unsound.
Testing isn’t about pushing buttons, or TEST ALL THE THINGS!!!!1!! but about the thought that goes into it, the risks that might be around it, and asking all the right questions of the software until they have a reasonable confidence that they’ve uncovered enough information about the software operates through creative and critical thinking. We’re some ways off from a computer taking on those skills.
A story from Ford Motors, applicable to so many contexts:
Ford, whose electrical engineers couldn’t solve some problems they were having with a gigantic generator, called Steinmetz in to the plant. Upon arriving, Steinmetz rejected all assistance and asked only for a notebook, pencil and cot. According to Scott, Steinmetz listened to the generator and scribbled computations on the notepad for two straight days and nights. On the second night, he asked for a ladder, climbed up the generator and made a chalk mark on its side. Then he told Ford’s sceptical engineers to remove a plate at the mark and replace sixteen windings from the field coil. They did, and the generator performed to perfection. Henry Ford was thrilled until he got an invoice from General Electric in the amount of $10,000. Ford acknowledged Steinmetz’s success but balked at the figure. He asked for an itemized bill. Steinmetz responded personally to Ford’s request with the following:
- Making chalk mark on generator $1.
- Knowing where to make mark $9,999.
It’s the thought that counts.