Writing as the primary interface

Ten years ago a tester's writing mattered mostly for the bug tracker. It still had to be clear enough for a developer to reproduce an issue without three follow up questions, but writing was one skill among many, behind test design, tooling, and domain knowledge. That balance has shifted, and it shifted faster than most job descriptions caught up with.

Two audiences reading the same sentence

Today the same sentence you write in a ticket or a spec is read by a person and, increasingly, by a model that will act on it directly. A prompt asking an AI agent to generate test cases from a user story fails in exactly the way a human tester fails reading a vague story. It guesses, fills gaps with assumptions, and produces something that technically matches the words but misses the intent.

The difference is that a human will usually ask a clarifying question. A model usually will not. It just produces an answer with total confidence and moves on, which is the more dangerous failure mode of the two.

That makes writing a genuinely technical skill now, not a soft one bolted on to the "real" work. A vague spec produces a vague test whether a person or a model writes it. The cost used to be a slow back and forth in a chat thread. Now it can be a plausible looking test suite that passes on the wrong behavior, and nobody thinks to double check it.

What changes when a model is the reader

Writing a bug report for a person, you can lean on shared context. "The login flow is broken again" lands fine with a teammate who was in yesterday's incident review. The same sentence handed to an agent tasked with triaging or reproducing the issue is close to useless, because the model has no memory of yesterday's incident unless the ticket spells it out.

This pushes toward a discipline that was always good practice and is now close to mandatory. State the actual observed behavior, the expected behavior, the steps that produced it, and the environment, every time, without assuming the reader already knows. It reads almost identically to a well written bug report that gets fixed, and that is not a coincidence.

Consider a logistics team's rewritten ticket template

A logistics company's QA team started using an AI agent to draft regression test cases directly from Jira tickets. For the first two weeks the output was inconsistent. Some tickets produced sharp, specific tests, others produced generic ones that missed the actual bug entirely.

Looking at the source tickets, the pattern was obvious. The sharp tests came from tickets that spelled out exact input values, the exact error message seen, and the exact steps. The weak tests came from tickets that said things like "search is returning wrong results sometimes," with no further detail.

The team's fix was not a better prompt or a different model. It was a rewritten ticket template that forced the reporter to fill in observed versus expected behavior, a specific reproduction case, and the exact error text, before a ticket could move to "ready." Test quality from the agent improved immediately, and so did the bug reports developers were reading manually.

Prompts are specs, and specs deserve the same care

Writing a prompt for a coding agent to generate tests is functionally the same exercise as writing acceptance criteria during refinement. Both require naming the inputs, the expected outputs, and the edge cases that matter, in a form specific enough that someone, or something, with no other context can act on it correctly the first time.

Testers who already write strong acceptance criteria tend to write strong prompts with almost no adjustment. The underlying skill, reducing ambiguity into checkable statements, transfers directly. The people who struggle with prompting are usually the same people who struggled to write a ticket a developer did not have to ask about twice.

• State the observed and expected behavior explicitly, never implied.
• Give exact values, error text, and steps instead of a general description.
• Write for a reader with zero shared context, not the teammate who was in the meeting.
• Treat a prompt for a model the same way you would treat acceptance criteria for a person.

FAQ