8f59166de4
- Add .gitignore to ignore system files like .DS_Store - Add empty CLAUDE.md and GROK.md files - Add initial articles on software testing topics: Agile-Or-Whatever-You-Call-It.md, Testers-As-Explorers.md, The-Various-Uses-Of-Vegetable-Condiments-In-Testing.md, five-essential-lessons.md, perfection-and-testing.md, resources-for-testers.md, the-categories-of-testing.md, the-logic-of-software-testing.md, the-perturbation-theory-of-exploratory-testing.md, what-is-a-competent-tester.md, what-makes-us-better.md - Include assets for articles in assets/ directory
6.8 KiB
The testing function in software development has many analogues in “real life”.
Testers are like home inspectors, in one sense. We’ve been tutored on a set of criteria that must be satisfied according to a standard, and taught where to take measurements to test those criteria. We are tasked with entering the home and taking the appropriate measurements, and then reporting when the measurements fail to satisfy the criteria.
In another sense, testers are like scientists. We are handed a world constructed by developers, told what we should expect the world to be like, and then we’re tasked to set up experiments in that world that test those claims by developers, using a method of scientific falsification.
In a third sense, we’re like exemplary software users. Our job is to exercise every feature and facet of the application before us. We function as avatars of various different kinds of users, taking on goals and tasks as if we were users ourselves, and reporting when we fail at those pursuits.
But the analogy that evokes the most mystery (and perhaps the most controversy) is that of the explorer. The tester as explorer is a wilderness expert, a survivalist, a tracker, and a DIY tinkerer. Unlike the scientist, whose experiments are based on carefully constructed interrogations of the environment, the explorer has only a direction of travel in mind. Unlike the software user, that direction of travel need not be pre-determined or identify any particular destination (e.g. ‘let’s go north today', rather than ‘let’s go to the mall today’). Like the inspector, the explorer is definitely looking for things that are odd or out of place, but unlike the inspector, the explorer is not constrained by an authority telling him what to look for.
The Right Kind Of Explorers
Exploratory testing has often been reputed to be voodoo nonsense or simply an excuse to avoid the rigour of a test plan. Sympathy for this view is understandable, since testing has always been anchored in a concern for meeting requirements, or avoiding defects, or insuring customer satisfaction. This is something done against a standard of measure and the explorer does not appear to have a standard.
But then, how could he? The whole point of exploring an unexplored terrain, is discovery. An explorer would be hard-pressed to explain to his financier, exactly what it is he was going to discover. When Christopher Columbus provided just such an attempted justification to the queen of Spain, it completely skewed his interpretation of what he ended up discovering. Believing he’d landed on an unpopulated shore of the Indies, by way of the Atlantic, he thought he was encountering residents of India.
Still, exploratory testing is not quite that intrepid. As Elisabeth Hendrickson carefully explains, the exploratory tester is not embarking on a purely blind escape into the wilderness, but a chartered expedition. It’s the difference between what Columbus did with Spain’s blessing, and what Louis and Clark did, on the instructions of Thomas Jefferson. To be more specific: Columbus imagined a new route to the East Indies, and set sail to prove it real (he didn’t, but arguably, what he did find was better anyway). Whereas, Jefferson told Louis and Clark to get to the west coast, and in the process of getting there, catalogue everything they encountered and make a report when they return.
The Right Kind Of Exploring
What differentiates the modern test engineer from Louis and Clark, however, is that the charter isn’t spelled out for us by political luminaries like Thomas Jefferson. We have to do quite a lot of investigative journalism, before we can begin the expedition: moving with purpose between team members and between teams, and asking lots of questions as we do. That process exposes the unspoken assumptions, the mismatched expectations, and the insecurities of the development process pointing in the direction the expedition will need to head. In other words, exploratory testing begins with exploring what we think we’re building*,* and only then proceeds to explore what we actually built.
The charter is, therefore, something drawn in silhouette around the “requirements”. It is the shadow cast by expectations and intentions, and when that shadow does not fall on the ground where the requirements claim it should, then we have our falsification.
To clear away all the metaphorical language, this is essentially the work of the exploratory tester: to triangulate the truth about the software, from expectations, requirements, and the material reality, as his data points. That truth may be that “the requirements are not met”, but it also may be that “the requirements are insufficient”, or that “the expectations are incongruent with the requirements”, or “the product owner didn’t understand the customer”, or “the api doesn’t accommodate enough volume”, or “there’s a typo in the client class”, or any number of other possibilities in the open landscape of a software development project. This makes him not just an explorer, but (at least in certain respects) an investigative journalist, a scientist, and an engineer, at any given moment.
It’s Not As Glamorous As It Sounds
Before I puff myself up too much, I should point out that investigative journalists are not very well liked by the people they’re investigating. Also, actual explorers are much more likely to be eaten by bears and tigers, than I am. Exploratory testing may not involve grinding through rigorously crafted procedural scripts, or filling out extensive reports for management, but it nonetheless requires discipline to execute well, and that means attentively engaging in the good habits of both engineering and testing, on a regular basis. Exploratory testing is just one more useful means to the same end we all have in software development: a quality product.