The Testing Academy · Field Guide · GitHub Copilot
Ten things every QA should know about GitHub Copilot.
A daily-driver reference for automation engineers and SDETs. Copilot isn't autocomplete anymore — it's a test-writing, failure-fixing, PR-reviewing agent that lives across your editor, terminal, and repo. Here's what actually earns its keep, in the order worth learning it.
Foundation · custom instructions
Teach it your house rules — once.
A single copilot-instructions.md is the highest-leverage thing you can do.
Drop .github/copilot-instructions.md in your repo and it loads on every Copilot request — chat, agent mode, the cloud agent, review. Encode your stack, locator policy, and no-sleep rule once and every suggestion obeys instead of guessing. Scope stricter rules to just your test files with a path-based *.instructions.md and an applyTo glob.
# QA conventions — loaded on every Copilot request ## Stack Playwright + TypeScript · @playwright/test · pnpm ## Locators — strict - Prefer getByRole / getByLabel / getByTestId. - Never raw XPath or brittle CSS (add a "// why" if unavoidable). ## Waits - No page.waitForTimeout(). Use auto-wait + expect.poll(). ## Test data - Build with @faker-js/faker. Never hard-code emails or PII. ## Assertions - Assert user-visible outcomes, not implementation details.
--- applyTo: "**/*.spec.ts,**/tests/**" --- Every test follows the Page Object Model in tests/pom/. One behaviour per test · no shared mutable state between tests.
Why it mattersIt kills brittle-selector and hard-wait suggestions at the source — so you stop re-correcting the same mistakes on every generation.
Context · # variables
Feed it the right context with #.
Output quality tracks context precision. Pin exactly what matters.
Typing # in chat lets you attach precise context instead of hoping Copilot finds it. The ones a tester reaches for daily: #file, #selection, #codebase (semantic search), #changes (the PR diff), #problems, #testFailure, and #terminalLastCommand. Scope the question to the one method, file, or diff you actually mean.
#file:LoginPage.ts generate POM-based tests for every method #selection write a unit test for just this function #changes add tests only for the code changed in this PR #testFailure why is this failing, and the smallest fix? #terminalLastCommand explain this pytest error and fix the test #codebase where do we mock the payment gateway?
Why it mattersVague prompts make Copilot invent context. Precise # scoping is the single biggest lever on whether the generated test is usable.
Workflow · slash commands
Run the whole test loop with slash commands.
Three commands cover the red-to-green loop without leaving the editor.
/setupTests recommends and wires up a framework in a bare repo. /tests generates a suite for the active file — always add the framework and the cases you want. /fixTestFailure diagnoses a red test and proposes the fix (it's also the sparkle button in the Test Explorer gutter).
/setupTests → recommends + configures a test framework /tests Generate tests for this function. Cover the happy path, failure paths, and boundary cases. Use pytest fixtures. /fixTestFailure → diagnoses the red test, proposes a fix
Why it mattersIt turns the daily unit-test loop into three keystrokes — scaffold, generate, repair — instead of context-switching to docs and back.
Agents · agent mode
Let Agent Mode build and refactor across files.
Give an outcome, not steps. It picks the files, runs your tests, and self-corrects.
Switch the Chat mode dropdown to Agent and describe the goal. Copilot determines the files, edits across them, runs terminal commands and your test suite, reads the output, and loops until it's green — showing every tool call for approval. This is the mode for cross-cutting work: scaffolding a whole framework, a big refactor, or "add this and its tests."
Scaffold a Playwright + Cucumber framework in this repo: - features/, step-definitions/, pom/, fixtures/, config - a login.feature with 3 scenarios + step definitions - getByRole locators only · no fixed waits - an npm script "test:e2e" and a GitHub Actions workflow Then run the suite and fix anything red before you stop.
Why it mattersIt executes and verifies, not just suggests — so a whole framework or migration can go from prompt to passing suite while you review.
MCP · Playwright server
Generate real-DOM tests with the Playwright MCP.
Give Copilot a real browser and the accessibility tree — no more guessed selectors.
Wire up the Playwright MCP server and Copilot drives an actual browser, reads the a11y snapshot, and writes getByRole locators against the live DOM — then runs them and heals failures. Playwright's planner → generator → healer agents ride on this: explore the app, produce a plan, generate specs, and auto-repair the red ones.
{
"servers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"]
}
}
}
Using the Playwright MCP: open the checkout flow, add an item, apply promo "SAVE10", then generate a spec from what you did. Use role-based locators from the a11y tree. Run it.
Why it mattersLocators come from the real DOM, so they don't rot — and the healer re-runs and repairs selector breaks when the UI shifts.
Context · chat participants
Ask the right expert with @.
Point the question at the domain that owns the answer.
@workspace reasons over your whole indexed project, @terminal knows your shell and the last runner error, @github searches issues, PRs, and other repos, and @vscode handles editor and debug config. Aim the participant and the retrieval comes pre-scoped.
@workspace where is the login flow tested, and what's missing? @terminal why did my last `npx playwright test` run fail? @github how does the auth-service repo mock JWT in its tests? @vscode set up a debug config for the failing spec
Why it mattersEach participant pulls the exact context its domain owns — you stop pasting logs and file trees into the prompt by hand.
Agents · cloud coding agent
Delegate long jobs to the coding agent.
Hand off the boring 80% — it works async and hands you a draft PR.
Assign a GitHub issue to Copilot (or delegate from chat/CLI) and it runs in an isolated Actions-powered sandbox: researches the repo, commits to a draft PR, runs tests, and iterates on your review comments. Prep its environment — browsers, test deps — with a copilot-setup-steps.yml. Playwright and GitHub MCP are on by default, so it can generate and validate E2E tests.
Migrate the Cypress specs in cypress/e2e to Playwright under
tests/e2e. Keep coverage identical. Open a draft PR.
# or delegate from the CLI and keep working:
> delegate: backfill API tests for the /orders endpoints &
Why it mattersMigrations and coverage backfill run without you babysitting them — you review one PR instead of typing the whole thing.
Terminal · Copilot CLI
Triage CI failures from the terminal.
The CLI ships with the GitHub MCP — it can read your Actions logs and fix the code.
The Copilot CLI is a terminal-native agent with direct access to your workflow runs and job logs. Point it at a red pipeline and it pulls the latest logs, correlates them to code, proposes a fix, and you verify with a shell escape. It's scriptable with copilot -p "…" for CI itself.
# install once (Node 22+) npm install -g @github/copilot # start it, then ask: > My CI is failing on this branch. Pull the latest workflow run logs, find what's broken, and fix it. Relevant files: @order.py and @test_order_service.py # review the diff, then verify > /diff > !pytest tests/test_order_service.py -q
Why it mattersA red pipeline becomes a diagnosed fix without opening the browser — logs, root cause, and patch in one loop.
Customization · prompt files & skills
Save repeatable work as prompt files & skills.
Turn your recurring tasks into /commands the whole team shares via git.
A *.prompt.md file becomes a reusable command you invoke with /name — /generate-api-tests, /generate-pom, /security-review — with inputs, a pinned mode, even a model. For patterns Copilot doesn't know (self-healing locators, your POM base), package them as a SKILL.md it loads on demand. Commit them and onboarding a new SDET becomes a README line.
--- mode: agent description: Generate API tests from an endpoint --- Generate REST tests for ${input:endpoint} using our APIRequestContext fixture. Cover 2xx, 4xx, schema, and auth. Group with describe(). Log only on failure. # then just run: /api-tests
Why it mattersOutput stays consistent across people and across models — your team's testing conventions become executable, not tribal knowledge.
Review · code review + model choice
Ship a first-pass review — and pick the model.
Get an instant first look at every PR, and match the model to the job.
Add Copilot as a reviewer, or auto-review protected branches via a repository ruleset — it leaves inline, severity-tagged comments and reads the same instructions file you already wrote. Treat it as a fast filter, not a merge gate. And switch models per task: reasoning and agentic scaffolds lean Claude, bulk generation leans GPT-Codex, huge context leans a million-token model — or let Auto pick (and take the credit discount).
# Add Copilot as a reviewer, or enable auto-review on # protected branches via a repository ruleset. Pick the model to the task: - Agentic scaffolds / deep debugging → Claude Opus / Sonnet - High-volume generation / 2nd opinion → GPT-5.x-Codex - Whole-suite refactor / huge logs → Gemini (1M context) - Not sure? → Auto (Copilot picks)
Why it mattersIssues get caught before a human looks — and using the model that fits the task changes both quality and cost on heavy agent runs.