Skip to main content
Start for free

QA AND ENGINEERING

Visual bug reporting for website QA

Website QA turns a suspicious behavior into a report someone else can reproduce. A clipped menu, a failed form, and a broken redirect need different evidence. Sending a screenshot without the starting state can still leave the developer guessing which route, account, or sequence produced it.

Annot8 supports manual QA by collecting visual feedback on the page under test, with screenshots and captured context where available. Paid plans add screen recording for interaction-heavy bugs. It gives the team a place to discuss and verify findings; you still choose the test coverage and run the checks.

Start for freeSee visual feedback

Combine a checklist with exploration

Start with the high-risk flows: navigation, search, forms, account changes, and any journey affected by the release. Give each a known starting state and expected result. Then explore nearby cases such as long text, empty results, repeated clicks, expired sessions, and a narrower viewport. Keep a simple record of the browser, account role, and build reviewed.

A focused exploration question is easier to act on than 'test the website.' For example, ask whether someone can recover from a failed search without losing their filters. Record both failures and the conditions you covered. A feedback inbox records findings; it is not itself a complete test execution log or automated browser suite.

Write reports that survive a handoff

Use one report for one observable defect. Include the page, preconditions, exact actions, expected result, and actual result. Distinguish severity from scheduling priority: a spelling mistake on a launch-critical campaign may be urgent without being a system failure. Avoid vague titles such as 'broken again' that become meaningless when removed from the original conversation.

Captured console or network errors can help an engineer investigate, but they do not establish the cause on their own. Reproduce the problem before concluding a particular request caused it. When the fix is ready, repeat the original sequence and check the neighboring flow; a successful screenshot alone cannot prove that submission, persistence, or authorization works.

The review workflow

  1. Define the test window

    Specify the build, environment, roles, pages, and supported browser set. Use safe test accounts and choose the most important journeys before broad exploratory review.

  2. Capture a useful failure

    Attach the affected element and visible evidence, then write the reproducible steps. For transient or multi-step failures, use a paid-plan recording and keep sensitive information out of view.

  3. Verify the whole fix

    Repeat the reported sequence on the changed build, check the resulting state, and exercise nearby paths. Explain the verification in the thread before resolving the issue.

DEFINE DONE

Acceptance checklist

  • Each blocker has reproducible steps or a documented reason it is intermittent.
  • The agreed critical journeys pass on the browsers and devices in scope.
  • Keyboard, zoom, and form-error checks have been performed where relevant.
  • Fixes are retested against the original scenario and adjacent behavior.

ILLUSTRATIVE EXAMPLE

A form that looks submitted but is not

Fictional example: a newsletter form shows a success message after a request fails. The tester initially notices only that the button animation looks unusual.

THE FEEDBACK

Enter a valid test email and submit while the request fails. Expected: an actionable error and the ability to retry. Actual: the page shows success although no subscription was saved.

The team fixes the error handling. QA checks both a successful submission and a failed request, including keyboard operation, before resolving the thread.

Fit and plan limits

Annot8 is a feedback and bug-reporting workflow, not an automated QA runner, security scanner, or accessibility certification. Browser and screenshot restrictions can leave some cross-origin embeds outside the captured evidence.

The Free plan includes screenshot-based feedback within its usage limits; screen recording and external integrations require paid plans. Review captured evidence before sharing it outside the team, especially on authenticated pages.

Check current plans and limits →

Common questions

Can Annot8 run our QA tests automatically?

This workflow helps people report and manage findings from manual testing. Keep automated regression tests and test execution records in the tools your team uses for those purposes.

What if a screenshot misses the issue?

Describe the starting state and exact steps, and use a screen recording on a paid plan when motion or timing matters. Some embedded or browser-restricted content may need separate evidence.

Further reading