GitHub Copilot Vision for QA can make a failed UI screenshot easier to investigate, but it should not become an automated verdict. A screenshot shows rendered pixels at one moment. It does not prove which DOM state, network response, feature flag, browser setting, or test-data condition produced them.
This tutorial shows a safe, practical workflow for asking Copilot to analyze a UI failure image, converting its observations into testable hypotheses, and verifying each hypothesis with deterministic browser evidence before filing a defect.
What Copilot Vision supports
GitHub’s official announcement says Copilot Vision accepts JPEG, PNG, GIF, WebP, and PDF attachments. It is available in VS Code Copilot Chat in ask, plan, and agent modes, in Copilot Chat on github.com, and through image paths in Copilot CLI. GitHub also says the capability is available across Copilot plans.
For Business and Enterprise users, GitHub says image and PDF attachments are retained for approximately 24 hours to provide the service. Treat that as a real data-handling consideration. Use a staging account, remove customer information, blur tokens and email addresses, and follow your organization’s AI and evidence-retention policy.
Test objective and boundaries
Assume a Playwright or Selenium test failed because a checkout confirmation panel looked wrong. Your objective is not to ask Copilot whether the product is broken. Your objective is to create a short list of observable differences and likely causes that you can verify.
Prepare these artifacts:
- the original failure screenshot and an optional expected baseline;
- test name, commit, browser, viewport, locale, and timestamp;
- Playwright trace or Selenium logs;
- console and failed-network-request evidence;
- relevant DOM or accessibility snapshot; and
- the exact test-data and feature-flag state.
Preserve the unedited original in your test report. Create a redacted copy for AI analysis so evidence integrity and privacy are both maintained.
Step 1: Check image quality before prompting
Confirm that the screenshot contains the whole component, enough surrounding context, and a readable scale. GitHub’s image-input documentation notes that large images may be resized or quality-reduced. Tiny error text can therefore disappear or become ambiguous.
Prefer PNG or JPEG for a static UI failure. If the defect is temporal, attach a small sequence of numbered screenshots or use the trace viewer; a single final frame cannot show the preceding action. Do not convert SVG evidence into a claim that the original vector rendered correctly merely because a rasterized copy looks acceptable.
Step 2: Start with observation, not diagnosis
Attach the redacted screenshot in Copilot Chat and use a bounded prompt:
You are assisting with QA triage. Describe only observable UI facts in this screenshot. Separate observations from hypotheses. List up to five differences that could affect the user. Do not infer root cause yet. For every item, identify the exact region and state what additional browser evidence would confirm or reject it.This structure reduces premature certainty. A useful response might observe that the confirmation button overlaps a price label, then request viewport, computed-style, and DOM-box evidence. An unsafe response would declare a CSS regression without those checks.
Step 3: Compare expected and actual carefully
If you have an approved baseline, attach both images and label them clearly as expected and actual. Include the viewport, device scale factor, browser, theme, locale, font-loading state, and animation policy for each capture.
Ask Copilot to produce a comparison table with four columns: visible difference, user impact, possible non-product explanation, and evidence needed. Non-product explanations matter. Responsive breakpoints, late web fonts, consent banners, stale test data, clock-dependent content, and animation timing can all create visual differences without a product-code defect.
Step 4: Turn hypotheses into deterministic checks
For each candidate issue, add or run a direct check:
- Overlap: compare bounding boxes and verify the affected text remains visible and clickable.
- Missing content: inspect the DOM, accessibility tree, API response, and feature flag.
- Wrong style: capture computed properties and confirm the correct stylesheet loaded.
- Truncation: test the same component with boundary-length text and relevant locales.
- Wrong data: compare rendered values with the API payload and seeded fixture.
Keep pass/fail logic in explicit assertions. Copilot may help draft a locator or diagnostic command, but review it and run it against the exact failing build. A green assertion on the wrong element is worse than a clear failure.
Step 5: Reproduce outside the original test
- Open the same staging build with the recorded account and test data.
- Set the same viewport, locale, browser version, theme, and feature flags.
- Repeat the user journey manually or with a focused deterministic script.
- Capture a new screenshot, trace, console log, network evidence, and DOM state.
- Repeat once with a clean browser context to exclude cached state.
If the result cannot be reproduced, record it as an unconfirmed failure and continue investigating. Do not turn Copilot’s plausible explanation into a defect title.
Step 6: Create a defensible defect report
Ask Copilot to draft the report only after verification. Supply the confirmed facts and require these fields: environment, preconditions, exact steps, expected result, actual result, reproducibility, user impact, attached evidence, and excluded hypotheses.
Remove unsupported root-cause language. For example, write “the button overlaps the total at 320 CSS pixels” when that is proven. Do not write “the flexbox refactor broke checkout” unless code history and reproduction support it.
Screenshot checklist
- Original unedited failure screenshot in the test report
- Redacted copy attached to Copilot Chat
- Prompt requesting observations separately from hypotheses
- Expected-versus-actual comparison with labels
- Trace viewer at the failing action
- DOM or accessibility evidence for the affected element
- Console and failed-network-request panel
- Clean-context reproduction screenshot
- Final defect report with verified evidence
Common mistakes
- Uploading sensitive screenshots: redact customer data, tokens, internal URLs, and unrelated conversations.
- Cropping too tightly: missing surrounding layout can lead to false spatial conclusions.
- Asking for root cause first: request observable facts before hypotheses.
- Ignoring image degradation: large attachments may be resized or quality-reduced.
- Skipping environment metadata: viewport, locale, fonts, browser, and flags often explain visual differences.
- Letting AI write the verdict: defect status and release decisions require reproducible evidence and human review.
What this workflow does not replace
Copilot Vision does not replace pixel-diff tooling, accessibility testing, DOM assertions, API validation, network inspection, cross-browser coverage, performance checks, security review, exploratory testing, or human release approval. It is a triage accelerator that helps organize evidence and questions.
References
FAQ
Can Copilot Vision confirm a visual regression?
No. It can identify possible differences and hypotheses, but QA should reproduce the issue and verify it with deterministic evidence.
Which files can Copilot Vision accept?
GitHub lists JPEG, PNG, GIF, WebP, and PDF attachments for Copilot Vision.
Should QA upload production screenshots?
Use redacted staging evidence whenever possible and follow organizational privacy and retention rules.
What evidence should accompany the screenshot?
Include environment metadata, a trace or logs, console and network evidence, DOM or accessibility state, and exact test data.
Conclusion
GitHub Copilot Vision for QA is most useful when it changes a screenshot from a vague failure into a small set of testable questions. Preserve the original, redact the shared copy, separate observations from hypotheses, and verify every conclusion against the browser and a clean reproduction. That produces faster triage without lowering the evidence standard.