You are handed a feature with no specification and two days to test it. How do you spend them?

First hours: build a model, do not start clicking

Two days of undirected clicking produces a list of cosmetic defects and no statement about risk. The reason is that testing is comparison, and you cannot compare until you have something to compare against. So the first block of time goes on constructing a model of what this feature is meant to do, from whatever sources exist even though the specification does not.

Those sources are usually richer than people assume. The pull request and its commit messages say what the developer thought they were building, and the diff tells you which existing code paths the change touches, which is the fastest way to find the regression surface. The UI itself declares intent through its labels, validation messages and disabled states. Analytics or logs from the surrounding feature tell you what real users do next. The ticket, however thin, names the problem somebody wanted solved. And the person who asked for the work will answer questions in ten minutes that would take you half a day to infer.

Write the model down, briefly: the entities involved, the states each can be in, the transitions between them, who is allowed to do what, and what the feature integrates with upstream and downstream. This artefact is what makes the rest of the session directed rather than random, and it is also the thing you hand over afterwards, because it is the specification that did not exist.

Name your oracles before you need them

An oracle is whatever lets you decide a behaviour is wrong. With no specification you have no authoritative oracle, so you work with several weak ones and stay aware of how weak they are.

Consistency with the rest of the product is the strongest available: if every other date field in the application accepts a two-digit year and this one rejects it, that is a defect regardless of what any document says. Consistency with a comparable product sets a reasonable expectation for things users have learned elsewhere. Consistency with the feature's own claims catches the case where a tooltip promises one thing and the code does another, which is always a defect because one of the two is wrong. Standards and law give hard oracles in specific areas: currency rounding, accessibility, data retention, tax. And the absence of an oracle is itself information — a behaviour you cannot judge is a question for the product owner, and questions are a legitimate deliverable from an exploratory session.

State the oracle when you file the finding. "This is inconsistent with how the settings page validates the same field" survives a conversation with a developer. "This looks wrong to me" does not.

Charters, not a checklist

Structure the two days as a sequence of timeboxed charters, each a single sentence naming an area, a technique and a purpose: explore checkout with an expired card to discover how payment failures are surfaced; explore the import screen with malformed CSV files to discover whether partial imports are possible. Sixty to ninety minutes each, and a short debrief after every one to decide what the results change about the plan.

The charters earn their place by risk rather than by area. Rank by what would hurt most if wrong, which for most features means money movement, data loss, anything irreversible, anything touching permissions or other people's data, and anything that runs unattended. Then weight by where defects are likely: newly written code, code with a history of bugs, integration points between two teams' components, and anything the developer described as tricky. The intersection of high impact and high likelihood is where the first day goes.

What this ordering buys you is that if the two days are cut to one, you have already done the work that matters. A plan that walks the feature evenly from top to bottom has the opposite property, and being interrupted destroys it.

Techniques that find what clicking through does not

Within a charter, the yield comes from deliberate technique rather than thoroughness. Boundaries and near-misses on every input, because off-by-one and empty-collection handling are where hand-written code fails. Interruption: navigate away mid-flow, hit back, refresh, submit twice, open the same record in two tabs and save from both. Data that is legal but unusual — a name with an apostrophe, a right-to-left script, a quantity of zero, a file at the size limit. Time: a session that expires mid-form, a subscription that lapses between two screens. And permissions, which are worth explicit attention because the interesting question is never whether the button is hidden but whether the endpoint behind it refuses.

The pattern behind all of these is that they attack the assumptions a developer makes when there is no specification to contradict them: that the user proceeds forward, that input is well-formed, that one thing happens at a time, and that the client controls access.

The specification's absence is a finding, not just your problem

There is a professional judgement embedded in this scenario that interviewers listen for. Testing without a specification means every judgement you make is provisional, and the honest response is not to silently invent the acceptance criteria and then test against your own invention. Record the decisions you had to make on the product's behalf, list the behaviours you observed but could not judge, and put them in front of the product owner. Half of them will be confirmed as intended, and the other half are usually the most valuable output of the session, because they are the ones nobody had noticed were undecided.

Where the gap is systemic rather than a one-off, say so once, without turning the report into a process complaint. Naming the pattern is useful; relitigating it in every report is not.

Reporting two days honestly

Close with a report that a release decision can be made from: what you covered, expressed as areas and charters rather than a count of test cases; what you did not cover and why; the defects, ranked; the open questions; and your assessment of residual risk in the areas you touched least. That last section is what separates a tester who has been busy from one who can be relied on, because it tells the reader where the report is thin instead of implying uniform confidence.

Resist converting the session retrospectively into a tidy set of numbered test cases so it looks like planned work. It was not planned work, the value came from following what you found, and rewriting it as a checklist both misrepresents the coverage and loses the reasoning that led to each discovery. The notes, the charters and the model are the artefact. If the feature is worth a permanent regression pack, derive it afterwards as a separate, deliberate exercise.