Cursor Side Chats for QA give testers a useful way to investigate a failing test without turning the main repair conversation into a long trail of competing theories. Cursor documented Side Chats in its July 10, 2026 changelog: they run alongside the main chat, inherit its context, and default to reading, searching, and answering. That makes them well suited to a focused diagnostic question while the main task remains anchored to the agreed fix.

This tutorial shows a practical SDET workflow: reproduce a flaky Playwright failure, keep the main Cursor conversation focused on the repair, use a Side Chat to examine logs and compare hypotheses, then bring only the strongest evidence back. The same pattern works for Selenium, API automation, mobile test suites, and CI failures.

Why separate diagnosis from the main repair task?

A test failure often produces several plausible explanations: a weak selector, an API delay, shared state, a missing network wait, bad test data, or an actual application defect. Asking the main agent to explore all of them can expand the task before the team has agreed which explanation is supported.

A Side Chat creates a separate reasoning lane. Cursor says you can open one with /side, /btw, or the plus button in the chat panel. Each Side Chat is durable, can be revisited, and can be referenced from the main thread. The goal is not to let two agents make overlapping edits. The safer QA pattern is to keep the Side Chat diagnostic and read-only until it produces a testable recommendation.

Example failure to investigate

Assume a checkout test fails intermittently in CI because the confirmation heading is not visible before the assertion timeout. The main conversation already contains the failing test, the relevant page object, and the CI log. Your working hypotheses are:

  • The test clicks Submit before the form is ready.
  • The confirmation depends on a network response that the test does not observe.
  • The selector matches a temporary loading element instead of the final heading.
  • Shared test data causes an application-level rejection.

The main task should retain the acceptance criteria: reproduce the problem, make the smallest defensible change, run the targeted test repeatedly, and show the evidence. The Side Chat should only rank the hypotheses and identify what evidence would confirm or reject each one.

Step 1: Establish a reproducible baseline

Before opening a Side Chat, capture one failing run and one passing run if possible. Record the exact command, environment, browser, test data, error message, trace or screenshot path, and relevant timestamps. Do not ask AI to infer a race condition from a single cropped error.

In the main Cursor chat, summarize the baseline:

Goal: fix the intermittent checkout confirmation failure.
Constraints: do not change production code yet; avoid fixed delays; keep selectors user-facing.
Evidence: CI failure log, Playwright trace, test file, checkout page object.
Validation: targeted spec passes repeatedly, then the affected regression group passes.

This keeps implementation criteria explicit even if the diagnostic branch explores several possibilities.

Step 2: Open a diagnostic Side Chat

Use /side or /btw from the main conversation. Cursor says the Side Chat receives context from the main chat, but you should still state a narrow assignment. A good diagnostic prompt is:

Read only. Investigate the checkout confirmation failure using the attached test, page object, CI log, and trace notes.
1. List each plausible root cause.
2. Cite the exact evidence for and against it.
3. Name the smallest observation or targeted run that would discriminate between the top two causes.
4. Do not edit files or recommend a fixed delay.
Return a table with hypothesis, evidence, confidence, and next check.

The words read only and do not edit files matter because the purpose of this branch is investigation. Cursor’s tools can read files, search the codebase, and use terminal capabilities; your prompt should make the permitted scope clear.

Step 3: Ask for evidence, not a confident story

Review the Side Chat output like a bug triage note. Reject conclusions that are not tied to an observable artifact. For example, “probably a timing issue” is weak. “The click occurs at 10:14:32.214, the checkout response completes at 10:14:34.881, and the assertion begins before the final heading is rendered” is a testable claim.

Use follow-up questions to challenge the leading explanation:

  • Which log or trace event contradicts this hypothesis?
  • Could the same evidence be explained by invalid test data?
  • What would we observe if the selector were wrong rather than the response being slow?
  • Can the issue be reproduced with a targeted command and no code change?
  • Which suggested check is deterministic and safe in CI?

This turns the Side Chat into a structured peer review instead of a second source of unverified code.

Step 4: Search earlier conversations when the failure looks familiar

Cursor’s official changelog says the Agents Window can search agent transcripts with Cmd+K, while Cmd+F searches within the current conversation. Its history documentation also describes referencing earlier conversations with @Past Chats. Use these features to find an earlier failure signature, selector decision, or test-data constraint.

Search for stable identifiers such as the spec name, error text, endpoint, page-object method, or CI job name. Do not copy an old fix merely because the wording matches. Bring the earlier context into the Side Chat and ask whether the current trace shows the same causal evidence.

Step 5: Bring a concise finding back to the main chat

Cursor says a Side Chat can be at-mentioned to pull its context into the main thread. Before doing that, ask the Side Chat to produce a compact handoff:

Summarize for the main repair task in no more than eight bullets. Include: reproduced behavior, strongest root-cause hypothesis, evidence, rejected alternatives, smallest proposed change, and exact validation commands. Mark uncertainty explicitly.

Return that summary to the main task, not the entire exploratory transcript. The main task should then decide whether the evidence is sufficient to edit code. This preserves a clean decision trail for reviewers.

Step 6: Make the smallest supported change

Suppose the evidence shows that the assertion starts before a specific checkout response completes and the user-visible confirmation renders afterward. The main task might replace an indirect readiness assumption with an observable application condition or an appropriate framework wait tied to the response and final UI state. It should not add an arbitrary pause.

Keep the patch narrow. Review the diff for accidental selector changes, weakened assertions, hidden retries, expanded timeouts, and swallowed errors. If the investigation instead points to invalid shared data, fix data isolation rather than masking the failure with waiting logic.

Step 7: Validate the result deterministically

Run the exact failing spec first. Then repeat it enough times to make the original intermittent symptom meaningful, followed by the affected regression group. Capture command output, pass counts, duration, and any trace or screenshot produced by the repaired test. Finally, let CI run in the environment where the failure originally appeared.

A practical evidence bundle contains:

  • The original failing log or trace.
  • The Side Chat hypothesis table and concise handoff.
  • The code diff with a short explanation of why it addresses the observed cause.
  • Targeted repeat-run results.
  • Affected regression results and CI status.
  • Any remaining uncertainty or follow-up monitoring.

Guardrails for QA teams

  • One writer at a time: keep the Side Chat read-only while the main task owns edits.
  • No secrets in prompts: redact tokens, customer data, cookies, and private payloads before sharing logs.
  • No fixed-delay shortcuts: wait on observable state or framework-supported conditions.
  • No proof by explanation: an AI rationale is not a passing test, trace, screenshot, or CI result.
  • No blind reuse: earlier chats provide context, not confirmation that two failures share a cause.
  • Human approval remains mandatory: reviewers decide whether the diagnosis and patch satisfy the test risk.

Screenshot checklist

  1. The main Cursor chat showing the failure goal, constraints, evidence, and validation plan.
  2. The Side Chat opened with /side or /btw and the read-only diagnostic prompt.
  3. The hypothesis table with evidence for and against each root cause.
  4. Conversation search results for the stable failure signature or spec name.
  5. The compact Side Chat handoff referenced from the main conversation.
  6. The final diff beside the targeted repeat-run results.
  7. The CI result and trace or screenshot confirming the repaired behavior.

When this workflow is most useful

Cursor Side Chats for QA are most useful when a repair task is already well defined but one diagnostic branch could consume significant context: flaky UI tests, conflicting CI evidence, selector debates, intermittent API failures, or a possible product defect hiding behind an automation symptom. For a simple syntax error, a separate branch may add overhead. Use it when isolating the investigation improves the quality of the final decision.

Final takeaway

Side Chats are a context-management tool, not a test oracle. Their value comes from separating exploratory diagnosis from the main implementation thread, demanding evidence for each hypothesis, and returning only the strongest findings. The finished repair still needs a minimal diff, deterministic test runs, CI evidence, and human review.

Sources