ChiefOSby ConversintStart free
Menu
← Back to the library
Coding

Browser QA

Verify a deployed or runnable web experience with browser evidence: critical journeys, errors, responsive behavior, accessibility checks, and an explicit verdict. Use for exploratory browser QA and post-change interaction checks; use e2e-testing to create or maintain a persistent automated test suite.

Works with the context you provideVersion 2.0.1

Browser QA

Use browser evidence to determine whether a runnable web experience behaves as intended. The host chooses the available browser tool; this method defines what to inspect and how to report it.

Boundary

Use for exploratory QA, reproduction, critical-flow verification, responsive checks, and post-change browser evidence. Use `e2e-testing` when the deliverable is a durable automated test suite. Use a dedicated accessibility method for a formal conformance audit. When the requested deliverable is a durable suite, explicitly route the work to `e2e-testing` before offering suite details. When broad or recurring coverage is requested, split repeatable journeys into `e2e-testing` and formal accessibility claims into the dedicated accessibility method.

Do not claim live, authenticated, or visual verification without a successful browser capability. Do not bypass login, anti-bot, rate-limit, payment, or permission controls. External writes such as purchases, submissions, sends, or production changes require their own authorization.

Establish scope

Identify:

  • target URL or local run command;
  • environment and build or commit under test;
  • critical user journeys and expected outcomes;
  • approved test accounts and whether actions are reversible;
  • viewport, theme, browser, and accessibility coverage that matter;
  • prohibited or destructive actions.

Prefer the smallest representative matrix that covers the change and its main risks.

Execute

  1. Confirm the target loads and record the actual URL, title, build marker when available, and timestamp.
  2. Check relevant console and network failures, distinguishing product defects from known third-party noise.
  3. Exercise each critical journey with valid, invalid, empty, loading, error, and recovery states as relevant.
  4. Inspect responsive behavior at the narrowest supported viewport plus representative wider layouts. Check overflow, clipping, unreachable controls, focus visibility, and content reflow.
  5. Check keyboard operation and accessible names for the exercised flow. Use an automated accessibility scanner when available, while labeling what still needs human judgment.
  6. Capture only the evidence needed to support findings: screenshots, snapshots, traces, request details, and exact reproduction steps.
  7. Re-run repaired failures and update the verdict from fresh evidence.

Avoid clicking every link or generating a huge screenshot set by default. Test the changed surface, shared navigation it could affect, and the smallest set of high-value journeys.

Evidence and verdict

For each finding, report:

  • severity and user impact;
  • environment, viewport, and exact steps;
  • expected versus observed behavior;
  • supporting artifact or browser observation;
  • whether reproduced after a fresh reload;
  • suggested next check, not an invented root cause.

End with one verdict:

  • **PASS:** exercised scope met the stated expectations.
  • **PASS WITH RISKS:** no blocker found, but named coverage or evidence is missing.
  • **FAIL:** one or more blocking defects reproduced.
  • **NOT RUN:** browser capability, environment, access, authorization, or a required fresh rerun was unavailable.

Use **PASS WITH RISKS** only after the stated checks actually ran and passed while some named, non-blocking coverage remains missing. A known defect that has not been rerun after repair remains **NOT RUN** or pending; it is never PASS WITH RISKS.

A plan, script, static code inspection, or browser launch without completed checks is not a PASS.

In a read-only simulation, an asserted browser capability is not execution evidence; do not report responsive, interaction, console, network, screenshot, trace, or defect findings unless an actual browser operation produced them.

Capability and fallback

Treat a browser tool named in a request as usable only after the host actually exposes an operable browser session and a reachable target. When both are available, execute the scoped checks in this method and collect evidence; when either is absent, do not simulate the checks from a plan. State exactly which prerequisite is missing, return a bounded QA plan, and end with **NOT RUN**.

For public page content that does not require rendering or interaction, prefer a simple fetch. Escalate to browser automation only when rendering or interaction is required. Use an authenticated live-browser session only when the task genuinely requires the user's session and the host exposes it.