✍️ Prompt Engineering

Prompt Engineering: A prompt is the "steps to reproduce" field of a bug report — and the mechanism matches one-to-one.

A prompt is the "steps to reproduce" field of a bug report — and the mechanism matches one-to-one. When you write a vague repro ("login is broken"), the developer returns "cannot reproduce" and you lose a day; when you write exact steps, browser version and test data, the fix starts in minutes. A vague prompt ("write tests for login") gets the AI equivalent of "cannot reproduce": a generic answer that fits every login form on earth and helps with none. So here is the question to sit with: Claude has read millions of pages — why does it still depend on YOUR five lines of context? Because it has read everyone's login rules, and without your acceptance criteria it cannot know which of a thousand possible login behaviors is yours. Java comparison: an interface contract — the more specific the method signature, the more precisely the compiler binds the call; a prompt is the type signature you hand to the model. The QA stake: teams that skip prompt discipline get generic test suites, generic suites create fake PASS confidence, and fake confidence is how the untested lockout rule reaches production on a Friday evening.

The 4 Ingredients of a Strong Prompt

Every strong QA prompt carries four ingredients. 1) ROLE: "You are a senior QA engineer" — sets the perspective and vocabulary of the answer. 2) CONTEXT: the user story, acceptance criteria, code or logs — the only project knowledge Claude will ever have. 3) TASK + CONSTRAINT: what to produce and within which limits ("6 test cases, negatives included"). 4) OUTPUT FORMAT: table, Gherkin, JSON — so the result drops directly into your test management tool instead of needing manual reformatting. Missing ingredients are not a style problem; each absence measurably degrades the answer, as you are about to see in the lab below.

Step by Step: How a Weak Prompt Gets Strong

"Write tests for login" is sent; the answer is 3 generic bullets that fit everyone and match no project.

"You are a senior QA engineer" is added — the answer language turns technical; concepts like severity and prioritization start appearing.

The acceptance criteria are added to the prompt — the answer now tests YOUR lockout rule, not an imaginary form.

Give format + constraint

Ask for "6 test cases, table: ID | Scenario | Expected | Type" — the output becomes copy-ready for a test management tool.

Put the first and last answers side by side: the question was the same; the only thing that changed was the prompt. A tester who SEES this difference once never writes a weak prompt again.

Prompt Lab — Experience the Difference Yourself

Reading about prompt quality is passive; below you will EXPERIENCE it. Write a real prompt for the login scenario and watch the simulated Claude respond. Send a lazy one-liner first — see the generic answer. Then add the ingredients one by one and watch the same question produce a professional, copy-ready test case table. This simulation is deterministic and keyword-based (it is honest about that), but the lesson transfers one-to-one to the real Claude.

Send your first prompt — whatever you write, let simulated Claude answer

Add a role to your prompt ("You are a senior QA engineer...") and resend