GitHub Copilot Chat can help QA engineers move faster, but the quality of the answer depends heavily on the quality of the prompt and the context you provide. GitHub’s own Copilot guidance recommends starting with the broad goal, adding specific requirements, giving examples, breaking complex tasks into smaller prompts, avoiding ambiguity, and pointing Copilot at the relevant code. For QA work, that translates into a simple rule: do not ask Copilot to “test this” and accept the first answer. Give it the feature, file, risk, expected behavior, and review criteria.

This article gives QA engineers, SDETs, and automation testers a practical prompt library they can reuse in GitHub Copilot Chat. The prompts are designed for test review, edge-case discovery, failure analysis, stronger assertions, and test data generation. They also include the human review step, because GitHub’s best-practices docs are clear that Copilot can make mistakes and suggested code should be understood, reviewed, and checked with automated tests and tooling.

How to Use These Copilot Prompts

Before using the prompt library, set up the right context. In the IDE, GitHub docs recommend highlighting relevant code, opening relevant files, using file references or chat variables, and using workspace or project context where available. For test generation, GitHub’s docs also describe the /tests slash command for the active file or selected code, while noting that generated tests may not cover every scenario.

A practical QA setup looks like this:

  • Open the implementation file and the closest existing test file.
  • Highlight the code path, assertion, failing test, or log section you want reviewed.
  • Tell Copilot which framework is used, such as Playwright, Selenium, pytest, JUnit, REST Assured, or Postman.
  • Ask for a plan or review first when the task is risky.
  • Run the generated or changed tests before accepting the output.

Prompt 1: Review an Existing Test for Weak Assertions

Review this test as a QA automation reviewer.
Focus on assertion strength, false positives, test data dependency, and whether the test would fail for the real regression.
Return a table with: issue, risk, suggested improvement, and whether the test must change before merge.

Use this when a test only checks that a request succeeded, a page loaded, or an element is visible. A good test should validate the outcome that matters to the user or business rule.

Prompt 2: Find Missing Edge Cases

Given this feature and the current tests, suggest missing edge cases.
Separate them into positive, negative, boundary, permission, data-state, and regression cases.
Limit the list to the 10 highest-value cases and explain what defect each case would catch.

This prompt follows GitHub’s recommendation to give specific requirements and break complex work into focused tasks. It also forces Copilot to explain value, not just generate a long checklist.

Prompt 3: Generate Tests for Selected Code

/tests using the existing project test style.
Prioritize boundary conditions, invalid input, and business-rule assertions.
After generating tests, list any scenarios that are still missing and should be reviewed manually.

The /tests command is useful for active files or selected code. QA engineers should still review the generated output, especially when the feature has hidden rules, external dependencies, or state transitions.

Prompt 4: Explain a Failed Test Log

Analyze this failing test log.
Separate symptoms from likely root causes.
Rank the top 3 causes by likelihood.
For each cause, suggest one focused validation step before changing code.

This is useful for CI failures where logs include noise. Ask Copilot to rank causes, but do not let it jump straight to a fix. First confirm whether the failure is product code, automation code, test data, environment, or timing.

Prompt 5: Improve a Playwright or Selenium Selector

Review this UI test selector strategy.
Suggest a more stable locator only if the current one is fragile.
Prefer user-facing or accessibility-based signals when available.
Explain why the new locator is less likely to break.

This keeps the prompt grounded in maintainability. Avoid prompts that ask Copilot to rewrite all locators at once unless you are deliberately doing a scoped refactor.

Prompt 6: Turn a Bug Report into Regression Tests

Convert this bug report into regression test ideas.
Return: reproduction path, expected result, observed result, affected area, automation layer, and the smallest useful automated test.
Flag any missing information I should ask the reporter for.

This prompt works well when bug notes are vague. It also protects against automating the wrong thing before reproduction steps are clear.

Prompt 7: Generate API Assertion Ideas

Review this API response and current test.
Suggest stronger assertions beyond status code.
Include schema, required fields, business rules, error handling, authorization, and data consistency checks.
Mark which assertions are high-value for regression coverage.

For API tests, status-only checks are rarely enough. Ask for schema and business rules separately so Copilot does not stop at basic response validation.

Prompt 8: Create Test Data Variations

Create test data variations for this validation rule.
Include valid, invalid, boundary, empty, duplicate, permission-related, and locale-sensitive examples.
For each item, explain the expected outcome and why it matters.

GitHub’s prompt-engineering docs recommend giving examples. If you already know a few valid and invalid examples, paste them into the prompt so Copilot can match your domain instead of guessing.

Prompt 9: Review AI-Generated Tests Before Commit

Act as a strict QA reviewer for these AI-generated tests.
Find duplicate coverage, weak assertions, overuse of mocks, hidden timing assumptions, and missing negative cases.
Do not rewrite the tests yet. Return prioritized review findings with file and line references where possible.

This prompt is useful after Copilot or another AI tool generates a large first draft. Review before editing so you can decide what is worth keeping.

Prompt 10: Write a Pull Request Test Summary

Summarize the QA impact of this change for a pull request.
Include: what changed, what was tested, new or updated automated tests, manual checks still recommended, and known risk.
Keep it concise and factual.

A clean PR summary helps reviewers understand coverage without reading every test file first. It should not exaggerate confidence or claim testing that was not actually performed.

Screenshot Checklist

  • Capture the selected file or highlighted code used as Copilot context.
  • Capture the Copilot Chat prompt with the specific QA task.
  • Capture Copilot’s response table or test suggestions.
  • Capture the generated test diff if code was created.
  • Capture the QA review findings before accepting the change.
  • Capture the terminal or IDE test result after running the focused check.
  • Capture the final PR test summary or evidence note.

Common Mistakes

  • Asking vague questions: Replace “write tests” with the exact behavior, risk, and framework.
  • Leaving context out: Open the implementation and nearby tests so Copilot can match the project style.
  • Accepting every generated case: Remove low-value tests that do not catch meaningful regressions.
  • Skipping verification: Run the focused test and related checks before merging.
  • Ignoring maintainability: Review readability, fixture use, selectors, data setup, and CI stability.

FAQ

Can GitHub Copilot Chat create complete QA coverage?

No. Copilot can suggest useful tests and missing cases, but QA engineers still need to review coverage, remove weak tests, and validate behavior with real checks.

Should QA engineers use the /tests command?

Yes, when the active file or selected code is the right scope. The generated tests should still be reviewed and expanded because they may not cover every scenario.

What context should I give Copilot for test prompts?

Provide the implementation file, nearby test files, selected code, framework details, expected behavior, and examples of valid or invalid data when available.

How do I know whether a Copilot-generated test is valuable?

Ask what regression the test would catch. If the test would still pass when the real defect returns, the assertion or test scope is too weak.

Conclusion

The best Copilot prompts for QA engineers are specific, contextual, and reviewable. Use Copilot Chat to speed up test thinking, but keep ownership of risk, coverage, assertions, and final validation. A saved prompt library gives your team faster starts without turning test quality into guesswork.