Skip to content

Using AI agents to help

The role this course points at asks for it, so learn to use it well and out in the open. An AI assistant is a fast, tireless, confidently wrong junior colleague. Treated as a colleague whose work you review, it speeds you up. Treated as an oracle whose output you paste unread, it will embarrass you at the worst possible moment, which in testing is a special kind of irony.

The words, briefly

A little vocabulary, so the rest of this page and half the internet make sense. None of it is complicated once someone says it plainly.

  • Prompt. The instruction you give the model. It is the whole job, really. A vague prompt gets a vague answer; a specific one gets something useful.
  • Context. Everything the model can see at once: your prompt, the files or text you gave it, the conversation so far. It has a limit, so what you leave out matters as much as what you put in.
  • Model. The AI itself, the thing that turns your prompt into words. Claude, GPT, and Gemini are models. Each has versions, and newer is usually, not always, better.
  • Agent. A model given the ability to act in a loop: read files, run commands, check the result, and try again toward a goal. A chat answers; an agent does.
  • Skill. A reusable, packaged set of instructions an agent can load to do a specific task well, often written as a plain file the agent reads. Think of it as a saved recipe rather than re-explaining every time.
  • Markdown, the .md file. A plain-text format for writing with light structure: headings, lists, links. It is what READMEs are written in, and increasingly how agents are instructed, in files like README.md, SKILL.md, or AGENTS.md. It is readable by both you and the machine, which is the point.

What it is genuinely good at

Widening your thinking and removing blank-page friction. Ask it to generate extra test cases from a requirement and it will suggest edge cases you would have reached eventually, sooner. Paste an error message and it will usually explain what the terminal was too terse to. Ask it to draft a boilerplate Cypress spec, translate a requirement into a checklist, or rephrase a bug report more clearly, and it will give you a solid first draft to correct. Correcting a draft is faster than writing from nothing, and you learn from the corrections.

What it is bad at, and will not warn you about

Being right. It invents API methods that do not exist, guesses at selectors it has never seen, and states all of it with the same steady confidence it uses for the true parts. It does not know your app, and its knowledge of any tool has a cutoff date, so its Cypress advice may quietly describe last year's Cypress. None of this is a reason to avoid it. It is the reason to verify everything it hands you.

Warning

Never paste secrets into an assistant: passwords, API keys, private company code, anything you would not put on a postcard. The practice targets in this course are public on purpose, so you can share their details freely. Real work is not.

The tools

A few worth knowing. Claude (opens in a new tab) and ChatGPT (opens in a new tab) are general assistants you talk to in a browser, good for explanations, test ideas, and reviewing a snippet you paste in. GitHub Copilot (opens in a new tab) and Cursor (opens in a new tab) live inside an editor and suggest code as you type, which is handy once you can tell a good suggestion from a plausible one. Start with a browser assistant. The in-editor tools are more useful after you have enough judgement to reject their worse ideas.

The desktop, or the REPL

You reach these tools in two broad ways, and it is worth knowing both. The first is a desktop app or a browser window: you type into a chat box, paste code in, and read the reply. This is the gentle end, ideal for explanations, test ideas, and reviewing a snippet, and it is where you should start. The second is the REPL, the command line: agentic tools that run in your terminal, or inside an editor, and can read and change the files in your project directly instead of waiting for you to copy and paste. Claude Code (opens in a new tab) is one you drive from the terminal, and an agentic IDE like Antigravity (opens in a new tab) brings the same idea inside the editor.

The command-line end is more powerful and more dangerous in equal measure, because an agent that can edit your files can also edit them wrongly, quickly, and across several files at once. Start in the chat window. Move to the REPL once you can tell a good change from a plausible one, and keep everything in version control, so a bad edit is one `git` command away from undone. The agent gets bolder access as you get better at reviewing it, not before.

How to ask, so the answer is worth having

The quality of the reply tracks the quality of the prompt. Four habits do most of the work. Give it context, including which tool and version you are using. Show an example of what good looks like, even a rough one. Ask it to explain its reasoning, so you can catch a wrong assumption. And ask for a specific format, so the output is usable rather than an essay. Anthropic has a fuller guide to this at the prompting documentation (opens in a new tab), and the same principles carry across tools.

A weak prompt and a stronger one, for the same goal:

Weak prompt
write cypress tests for a login page
Stronger prompt
I am testing the SauceDemo login page with Cypress, latest version, in
JavaScript. The username field has a data-test attribute of "username",
the password field "password", and the button "login-button". A successful
login shows an element with the class "inventory_list".

Write three end-to-end tests: a successful login, a login with a wrong
password, and a login with an empty username. For each, explain in one line
what it proves. Use data-test selectors, not class or id selectors.

The second prompt gets you tests you can almost use as written, because you told it what you already know. The first gets you a guess.

Write to a spec, not a vibe

There is a name for taking that stronger prompt seriously: spec-driven development. Instead of nudging an agent with half a sentence and hoping, you write a short, clear specification of what you want first, then let the agent build against it. The spec is the source of truth; the agent is the literal- minded pair who follows it.

You already know this discipline, because it is what a good requirement or a clear acceptance criterion is in QA. A spec for an agent answers the same questions a test case does: what should happen, under what conditions, and how you will know it worked. Keep it plain. A few sentences of "here is what I want, here are the constraints, here is what done looks like" beats a paragraph of vibes every time. If you want to see the idea formalised, GitHub's Spec Kit (opens in a new tab) is a free, readable example of the workflow, and its introduction (opens in a new tab) explains the thinking without demanding you adopt the whole tool.

Tip

Do not over-engineer this. For most of what you will do in this course, the "spec" is three or four honest sentences at the top of your prompt. The point is to decide what you want before you ask, not to fill in a template.

Getting better at prompts

Prompting is a skill you improve by reading a little and practising a lot. The official guides are short and worth the time, and they mostly agree with each other: be clear, give context, show examples, ask for a format.

The QA workflow, and why it doubles as an interview answer

There is a specific loop that shows judgement rather than just typing speed. Take a requirement, ask an assistant to generate test cases and to suggest scenarios you did not think of, then do the part that matters: review its output, keep what holds up, fix what does not, and write a short note on what it got right and what you had to correct.

Why

That note is a ready-made interview answer. "I used AI to widen my coverage, then reviewed and corrected its output" describes exactly the judgement a team wants from a tester. Using AI well is listed in the job. Using it without checking is the only version that goes wrong, and it goes wrong publicly.

This is the same loop as step four of week six, where you make it a permanent part of your portfolio. Practising it now, on the earlier weeks, means it is a habit by then rather than a task.

A short honesty note

Use these tools to learn faster, not to skip the learning. An assistant that writes a test you do not understand has left you with a test you cannot maintain and cannot explain in an interview. Read what it gives you until it makes sense. The goal is a tester who can work with AI, which is a different, more valuable thing than a tester who is replaced by it.