Antigravity exploratory testing QA is a useful workflow when your session notes are messy but the product issues are real. Many testers finish an exploratory run with partial reproduction steps, screenshots, browser details, and a few guesses about what failed. The hard part is turning that raw material into a bug report another engineer can act on.

Google’s Antigravity docs describe a workflow built around creating a project, starting an agent, navigation, and slash commands. Google’s managed agents announcement from May 19, 2026 also says the Antigravity agent can run in a secure cloud sandbox and use custom instructions, skills, and data defined with AGENTS.md and SKILL.md. Those documented capabilities are enough for a practical QA tutorial: feed the agent structured notes, ask it to draft a defect report, and review the output before you trust it.

Why Antigravity fits exploratory note cleanup

Exploratory testing generates uneven information. Some notes are precise. Others are fragments like “failed after refresh,” “maybe session issue,” or “cart count wrong on second tab.” An agent can help reorganize those fragments into something a QA engineer can review faster, but only if you give it boundaries.

Use the agent for tasks like these:

  • Group raw notes by symptom, environment, and suspected feature area.
  • Draft cleaner reproduction steps from timestamped observations.
  • Separate confirmed behavior from tester assumptions.
  • Suggest follow-up regression or automation candidates after the manual session.

Do not use it as the final authority on severity, root cause, or whether the issue is truly a defect. That still needs human QA judgment.

What the official sources support

This tutorial stays close to documented vendor capabilities. The official sources support these practical points:

  • Antigravity docs provide the basic workflow for creating a project and starting an agent.
  • The docs include navigation and slash command concepts, which makes step-by-step interactive work realistic.
  • The skills docs describe reusable skills with SKILL.md instructions, which is useful for repeated QA note-triage rules.
  • Google’s managed agents announcement says the Antigravity agent can use your instructions, skills, and data, and that these can be defined with AGENTS.md and SKILL.md.

That is enough to design a note-to-bug-report process without inventing product-specific shortcuts that are not documented.

Before you start

  1. Collect your exploratory notes in one place. A markdown file works well because timestamps, bullets, and screenshots are easy to preserve.
  2. Separate facts from guesses. If you are not sure whether a behavior is expected, mark it clearly.
  3. Save any supporting artifacts you already have, such as console errors, request payloads, screenshots, or short screen recordings.
  4. Decide what output you want first: bug report, reproduction steps, test ideas, or all three in separate sections.

Step 1: Start with a project-level instruction file

If you do this often, give the agent a stable review frame. A lightweight AGENTS.md file can keep the outputs consistent across sessions.

Starter Snippet

# AGENTS.md

When converting exploratory testing notes:
- Preserve uncertainty instead of inventing missing facts.
- Separate observed behavior from assumptions.
- Draft numbered reproduction steps only when the notes support them.
- Always include environment clues if present.
- Suggest automation follow-ups only for repeatable scenarios.

This is the QA equivalent of a review checklist. It prevents the agent from over-polishing incomplete evidence into a fake certainty.

Step 2: Paste or attach raw notes with explicit structure

Antigravity exploratory testing QA works better when the input is structured, even if the content is rough. A simple note file like this is enough:

Copy Example

Session: Checkout exploratory run
Browser: Chrome 137 on Windows 11
Environment: staging
Build: 2026.06.17-rc2

11:03 - Added item to cart, cart badge showed 1.
11:05 - Opened checkout in second tab, badge showed 0 there.
11:06 - Refreshed first tab, badge changed to 0.
11:07 - Proceeded to checkout, item still visible in order summary.
11:09 - Removed postal code and clicked Place order.
11:09 - Spinner ran, no inline validation message appeared.
11:10 - DevTools showed 400 response from /api/checkout/submit.

You do not need perfect notes. You need enough evidence for the agent to organize the facts without guessing beyond them.

Step 3: Ask for a bounded transformation, not a broad analysis

Give the agent a narrow request. Ask it to convert the notes into sections instead of “analyzing everything.” That keeps the output reviewable.

Try This Prompt

Read these exploratory testing notes.
Create three sections only:
1. Confirmed observations
2. Draft bug report with numbered reproduction steps
3. Automation follow-up ideas
Do not invent missing data.
If a step is uncertain, label it as uncertain.

This prompt is strong because it limits the format and explicitly tells the agent not to fill gaps with fiction.

Step 4: Review the draft bug report line by line

Once the agent produces a draft, review it like a QA lead reviewing a junior tester’s first report. Look for these failure patterns:

  • The agent turned a guess into a fact.
  • The reproduction steps assume hidden setup that your notes never captured.
  • The expected result is too generic, such as “should work properly.”
  • The title describes a cause instead of the observable problem.
  • The automation idea is not stable enough to become a repeatable test.

Here is a stronger output shape to aim for:

Title: Checkout submit shows no inline validation when postal code is empty

Environment:
- Staging
- Chrome 137 on Windows 11
- Build 2026.06.17-rc2

Reproduction steps:
1. Add one item to cart.
2. Open checkout.
3. Clear the postal code field.
4. Click Place order.
5. Observe the page behavior and network response.

Actual result:
The page shows a spinner and the submit request returns 400, but no inline validation message was visible in the UI during the session.

Expected result:
The UI should block submission clearly and show an inline validation message for the required postal code field.

Step 5: Use a skill for repeated bug-report formatting

The skills docs matter when your team repeats this workflow. A small skill can standardize how the agent formats observations, defects, and automation ideas. For example, you can require every output to contain environment details, confidence labels, and a “missing evidence” section.

This is especially useful when multiple testers contribute notes. The agent becomes more consistent, but your review standard stays explicit and human-owned.

Step 6: Turn strong defects into automation candidates

After the report is cleaned up, ask the agent for automation ideas only for the scenarios that are repeatable and product-relevant. That usually means:

  • Required-field validation gaps.
  • State-sync issues between tabs or refreshes.
  • Error handling that depends on clear UI feedback.
  • Regression-prone checkout or auth flows.

A good follow-up prompt is short:

From the confirmed observations only, suggest 3 automation candidates.
Rank them by repeatability and business risk.
Do not suggest tests for unconfirmed assumptions.

Screenshot checklist

  • The Antigravity project opened for the exploratory session notes.
  • The raw note file before cleanup.
  • The prompt asking for confirmed observations, bug report, and automation ideas.
  • The first drafted bug report from the agent.
  • The final edited bug report after human QA review.
  • The list of approved automation follow-up ideas.

Common mistakes to avoid

  • Uploading notes with no timestamps or environment details: this weakens reproduction quality.
  • Letting the agent infer missing expected results: that often creates vague or incorrect bug language.
  • Mixing confirmed findings with hypotheses: always label uncertainty clearly.
  • Automating every exploratory finding: only repeatable, meaningful scenarios should become tests.
  • Skipping manual review because the report looks polished: polished wording can still hide factual errors.

Conclusion

Antigravity exploratory testing QA is most useful when you treat the agent as a structured writing and triage assistant, not as a defect oracle. Feed it real notes, tell it to preserve uncertainty, review the reproduction steps, and only then promote the strongest findings into bug reports or automation ideas. That approach fits the official Antigravity documentation and gives QA teams a practical way to reduce note-cleanup time without lowering evidence quality.

FAQ

Can Antigravity replace exploratory testing judgment?

No. It can help organize notes and draft reports, but QA engineers still decide what is a real defect and what evidence is strong enough.

What kind of notes work best with this workflow?

Short timestamped notes with browser, environment, build, and observed behavior are enough. Screenshots and request details make the draft more reliable.

Should every exploratory finding become an automation test?

No. Focus on repeatable, high-value scenarios with clear expected behavior and stable assertions.

Why use AGENTS.md or a skill for this process?

They help the agent keep a consistent defect format and reduce the chance of turning uncertain notes into overconfident output.

References