Exploring without Requirements

This is not finished, but roughly sharable. I wrote the articles for (some) links.

Why to explore, without requirements

Requirements are handy.

They're also seen as unquestionable, complete, and so necessary to testing that testing cannot start without requirements. This fetish is a barrier to starting work, particularly where the context makes it hard or dangerous to take a decision to start work.

Which is silly, because testing reveals requirements. And because your requirements are wrong.

Testing involves judgement, and judgement involves comparison. If you typically judge against a model built from requirements, you'll feel uncomfortable without them. A decision not to test may seem reasonable. Your decision may not be as clear-cut enough to relax into, every time: I'll write about that shortly, in Testing Without Requirements.

Exploration, on the other hand, can proceed merrily without requirements. If you're holding off looking at a system because you don't know what it's for, you're denying yourself the pleasure of exploration. Hedonism aside, your're denying your organisation the your perspectives on what that software system is building / installing / using / changing / deleting / corrupting / allowing / hindering. Get over yourself.

Ways to explore, without requirements

How do you explore without requirements? You work with what you've got. Exploration requires an artefact. That artefact will reveal itself to you in different ways, depending on how you approach it.

Here are a few general ways to explore a software system:

• Explore the system as it is now, to look at how it transforms information
• Explore the system as it is now, to look at its parts and their interrelations
• Explore the data that the system contains, how it is represented, and what it satisfies
• Explore what the system naturally does, gather evidence about the intent of its makers and its apparent purpose.
• Explore the underlying technologies of the system, their capabilities, and the constraints that those technologies impose on the system
• Explore for shortcuts that the system takes to be responsive / performant / low-impact, and the ways that it might be hardened to be usable, to be secure, to be resilient.
• Explore the system as it is now, looking at how it interacts with external things – users, other systems, filesystems.
• Explore the system as it is constructed, installed and set in motion
• Explore the system's history – how it has changed, who made those changes, and why.
• Explore the system in a human context – what do people feel about it? What do they use it for? How are they disappointed? How do they misuse it?

You'd find analogous approaches if you're testing a document or a map or a library or a building or a process. I expect you can add to this list, from inside or outside testing. Do add a comment with your own example. I may add it to this page.

We can all explore without requirements, and we can all build model of what we find.

The trick is to start.