Skip to content
L-SYSTEM

Same Prompt, Different Test Suite

Preview unit: this one is open without enrolling. The rest open after you enrol.

Priya runs a prompt against the ENGAGE timesheet story and gets eleven test cases. Marcus runs the same prompt, same model, same afternoon, and gets nine — with two she did not have and three of hers missing. Neither of them changed anything.

Priya and Marcus compare two printouts of different length produced by the same prompt
FigurePriya and Marcus compare two printouts of different length produced by the same prompt
Description

Two QA engineers sit at one table with a single teal laptop between them. Priya, on the left, holds a printout so long that it spills across the table; Marcus, on the right, holds a single half-page. They look at each other with raised eyebrows and a half-smile — puzzled, not alarmed. The picture shows that one prompt, sent twice to one model, produced two different test suites. It does not show which suite is correct: neither length is evidence of quality, and both need review.

In a test tool, this is a defect. Here it is the specified behaviour, and a tester who does not know that will spend a week filing a bug against a model.

Why the output moves

A language model does not retrieve an answer. It predicts the next token, repeatedly, from a probability distribution — and then samples from that distribution rather than always taking the most likely token. Two runs walk two different paths through the same probabilities, and once they part at one token every later token is predicted from a different history.

prompt Your prompt (text) tok Tokenization text → tokens prompt->tok emb Embeddings tokens → vectors tok->emb tr Transformer weighs every token against every other emb->tr dist Probability distribution over the next token tr->dist samp Sampling pick one token dist->samp out Output so far samp->out out->tok append and repeat
FigureHow a model produces text: tokenize, embed, transform, predict a distribution, sample one token, append, repeat
Description

A left-to-right pipeline. The prompt is split into tokens, tokens become embedding vectors, the transformer relates every token to every other one, and the result is a probability distribution over the next token. The highlighted step is sampling, where one token is picked from that distribution. The picked token is appended to the output and the whole loop runs again for the next token. The sampling step is where two runs of the same prompt can part ways.

The word plausible is doing the work here. The model produces text that is statistically likely given its training data and your prompt. Likely is not the same as correct, and nothing in the mechanism checks the difference.

Turning the temperature down narrows the distribution but does not make the model a function. Even at temperature 0 providers do not guarantee identical output across calls — batching and floating-point arithmetic on shared hardware can tip a near-tie between two tokens. You will take this apart properly in u15; for now, plan for variation rather than hoping to switch it off.

This has a consequence you will use for the rest of the course: an LLM's output on a test task is evidence, not a result. It is reviewed the way you would review a colleague's first draft — not because the model is junior, but because you cannot tell from the output alone which parts it knew and which parts it constructed.

What the model actually reads

Your prompt does not reach the model as words.

Tokenization splits the text into tokens. For ordinary English prose a workable rule of thumb is about four characters, or three-quarters of a word, per token. Identifiers break that rule: login is likely one token, ENGAGE_TIMESHEET_SUBMIT_BTN is likely six or more. Test artefacts are full of identifiers, stack traces and GUIDs, so they cost more tokens than their word count suggests.

Embeddings turn each token into a vector positioned so that tokens used in similar ways sit near each other. This is why a model can connect "the submit control" in your prompt with submitButton in your code without being told they are the same thing — and why it will sometimes connect two things that merely look similar.

The transformer is the architecture that lets the model weigh how every token relates to every other one across a long passage. It is the reason a model can hold a whole user story in mind rather than reading it a line at a time.

The window, and what happens at its edge

The context window is how much text, measured in tokens, the model can consider at once — your prompt, your input data, and its own answer, all together. In 2026 windows of 128,000 to 1,000,000 tokens are common. That sounds unlimited until you estimate:

  • a 400-case regression suite at ~120 words per case is ~48,000 words — roughly 64,000 tokens before identifiers push it higher;
  • a full nightly run log of run 2891 is tens of megabytes — millions of tokens. It fits nowhere.

What happens when you go over depends on which layer you are talking to:

  • Directly through an API, an oversized request is rejected with a context-length error. Loud, and easy to handle.
  • Through a chat tool, IDE assistant or agent, the tool manages the window for you. It may drop the earliest turns, truncate an attachment, summarise it, or retrieve only the chunks it judges relevant — and then answer with exactly the same confidence as if it had read everything.

The second case is the one testers meet, and the dangerous one: nothing in the answer tells you part of the input was never read. Check it the way you would check any unverified claim — ask about something you know sits at the end of the input, or compare the failure count the model reports with the count in the file.

A larger window is not free either. More tokens mean more computation, latency and cost per call — a thread you will pick up in u21 when you estimate what a task costs to run every night. And models attend less reliably to material in the middle of a very long context than to its beginning and end: a critical constraint buried at token 80,000 is weaker than the same constraint at the top.

Where GenAI sits

You will meet four terms, and they are not synonyms. Each is a subset of the one before it in how it learns.

cluster_ml Machine learning — learns from data cluster_dl Deep learning — learns its own features sym Symbolic AI explicit rules (defect routing by keyword) cml Classical ML human-chosen features (severity predictor) sym->cml rules → data dl Deep learning (screenshot classifier) cml->dl features → learned gen Generative AI produces new content (LLM drafting test cases) dl->gen classify → generate
FigureThe AI spectrum: symbolic AI outside machine learning; classical ML, deep learning and generative AI nested inside it
Description

Symbolic AI stands in its own box on the left: it encodes explicit rules, such as routing defects by keyword. To its right, a frame labelled machine learning contains classical ML — learning from data with features a human chose, such as a severity predictor — and a nested frame labelled deep learning, where the model learns its own features. Inside deep learning sit a screenshot classifier and, highlighted, generative AI, which produces new content such as test cases drafted by an LLM. Dashed arrows name the line crossed at each step: from rules to data, from chosen to learned features, from classifying to generating.

  • Symbolic AI encodes knowledge as explicit rules. Deterministic, inspectable, brittle.
  • Classical machine learning learns from data you have prepared and features you have chosen. Defect triage models are usually this.
  • Deep learning learns the features itself from large datasets.
  • Generative AI uses deep learning to produce new content — text, code, images — by modelling patterns in what it was trained on.

The reason GenAI arrived in test teams and the others mostly did not: it is pre-trained. There is no dataset to assemble and no training phase before you get value from it on Monday. That convenience is exactly what makes the risk units worth a third of this course.

One more consequence of "generates rather than retrieves": unless a tool has explicitly given the model a document — through retrieval, an attachment or a connector — the model has not looked anything up. A sentence that sounds like it came from your Confluence page was produced from patterns. You will meet the tools that do fetch material in u18 and u19.

What you now know

Non-determinism is designed in, and temperature 0 narrows it without removing it. Tokens are what the model reads and what you pay for, and identifiers are expensive. At the edge of the window an API fails loudly while a tool fails quietly. And "plausible" is the model's actual objective — correctness is yours.

Practice

Checking here changes nothing: answers start counting once you enrol on the course.

  1. Two testers send an identical prompt to the same model minutes apart and get different sets of test cases. What best explains this?

  2. Marcus sets temperature to 0 and writes in the test plan: 'Model output is now deterministic, so one review of the generated suite is enough for every future run.' What is wrong with this?

  3. In the token-loop diagram, at which step can two runs of the same prompt first part ways?

  4. In the opening illustration Priya's printout spills across the table while Marcus holds half a page. What is the right conclusion for the test lead?

  5. Which of these is likely to consume the most tokens?

  6. Tom's script sends a whole nightly run log to a model directly through the provider's API. The log is larger than the model's context window. What happens?

  7. Priya pastes the same oversized log into a chat assistant. It answers fluently with a list of failures. What is the real risk?

  8. A 47-minute nightly run log does not fit your model's context window, and you are working in a chat assistant. Describe how you would detect that part of the log was not read, and what you would do instead of pasting the whole log.

    This one is judged by the author’s rubric — your assistant does that, not the site.

  9. The ENGAGE regression suite has 400 test cases averaging about 120 words each, with many element identifiers in the steps. Estimate its size in tokens and say whether you could send it in one call to a model with a 128,000-token window together with a 2,000-token prompt and room for a 10,000-token answer. Show your assumptions.

    This one is judged by the author’s rubric — your assistant does that, not the site.

  10. Nadia's prompt is 150,000 tokens long, and the constraint 'do not invent acceptance criteria' sits in the middle of it. What is the risk?

  11. In a plain chat with no attachments, no connectors and no search, a model writes: 'Per your Confluence page, the timesheet must be submitted by Friday 17:00.' What does this tell you?

  12. Place each system in the right part of the AI spectrum.

    1. A rules engine that routes defects by keyword
    2. A model trained on your labelled defect history to predict severity from features you chose
    3. An image classifier that learns its own features from screenshots
    4. An LLM that drafts test cases from a user story
  13. Complete: the transformer generates text that is statistically , which is not the same as correct.