Software Has Desire Paths

Walk across almost any campus and you’ll find them: thin brown lines worn into the grass where people cut a corner the pavement didn’t. Planners call them desire paths. They’re a record of what people actually wanted to do, written by their feet, and they’re usually more honest than the original plan.

Four months into quality assurance, I’ve started to think testing is mostly the work of finding software’s desire paths before users wear them in.

The Spec Is the Pavement

A feature arrives with a story. The user opens the form, fills it in, presses Save and sees a confirmation. That story is real, and it’s also a small fraction of what will happen. In practice, people:

• press Save twice, because the first press felt slow
• open the same record in two tabs and edit both
• go back after submitting, then submit again
• paste text from a document, invisible formatting included
• leave a form open over lunch and come back to an expired session
• rotate the phone halfway through a step

None of this is misuse. Each one is a reasonable thing to do, and from the user’s side there is nothing “edge” about any of it. It’s the middle of their afternoon.

Edge Cases Are Mostly Middle Cases

The phrase “edge case” quietly suggests these situations are rare and peripheral, so they can wait. Testing changes that picture. The paved path tends to work, because it’s the one everyone tried while building. The bugs live on the shortcuts: in the transitions between features, in orders of operations nobody planned, in the state left behind by the step before.

So the more productive question isn’t “what does this feature do?” It’s “what can be true right before someone uses it?” The record might already be deleted. The user might have lost permission a minute ago. The network might drop the response after the server has already saved.

Pave It or Fence It

Finding a desire path leaves two honest options. You can pave it: support the behavior properly, because users have already voted for it with their feet. Saving drafts so that an expired session loses nothing is paving. Or you can fence it: prevent the behavior gracefully, with a clear reason. Disabling a submit button while the request is in flight, and having the server reject the duplicate anyway, is fencing.

The dishonest option is the most common one: pretend the path isn’t there. Users walk it anyway, and the software does whatever it happens to do, which is a fair definition of a bug.

A path that many people walk is also information. When users keep opening a second tab to compare two records, they aren’t misbehaving. They’re asking, in the only language they have, for a comparison view. A good bug report sometimes turns out to be a feature request in disguise.

What Testing Is For

It’s tempting to describe QA as checking that software does what it says. That matters, but it’s the smaller part. The larger part is closer to fieldwork: watching how people really move through a product, or imagining them carefully enough to predict it, and mapping the paths before they turn into complaints.

Anyone who has done that work for a while builds differently afterward. The paved path is still the first thing to make work. It’s just no longer the only thing you picture when you imagine someone using what you made.