Atarim for QA Engineers: Tracking and Managing Feedback

Most of a QA engineer’s wasted time goes on the same two things: writing down context a tool could have captured, and re-testing something that was closed without anyone telling you. Atarim removes the first by recording repro conditions when the task is created, and the second by giving you a status that means “ready for you to verify”.

Everything a developer would otherwise ask for, captured at the moment the bug was found.

This guide is about testing and verification specifically, rather than general task use.

Filing a Defect

The click is what carries the context — element, screen size and browser are captured with it, so the developer does not have to ask.

Instructions:

1. Open the page under test and switch to Comment mode in the bottom bar.
2. Click the element that is behaving incorrectly. A marker is placed and a comment box opens, prompting What are you thinking?
3. Describe what you did and what happened.
4. Select Comment to post. A task is created, and Atarim captures a screenshot of the page as it was — described as a snapshot of what was seen when the task was made.

You do not have to write down the URL, the browser, the viewport, or where on the page it happened. That is recorded for you.

What Gets Captured for You

Expand Technical Details on any task to see the repro context.

Every defect also carries a screenshot. For one that matches exactly what you saw, use the Atarim Chrome extension, or in Chrome or Edge select Most accurate when Atarim asks to Share exactly what you see. Without either, Atarim takes the screenshot from the page’s address, so content behind a sign-in or a click can look different. How the screenshot is taken

Annotating the Evidence

When the defect is visual, mark it up. The comment box has an annotation control, described as annotating a screenshot and attaching it as a comment, which opens a window headed Annotate screenshot.

Undo, Redo, and Fit to Screen are available while you work. Save attaches the annotated image to your comment; Cancel discards it.

Testing Across Breakpoints

The bottom bar carries a device menu for previewing at Desktop, Tablet, and Mobile. A defect filed while a view is active is recorded against that view, so a mobile-only bug arrives already saying so.

Automated Checks the AI Can Run

Atarim’s AI team includes Glitch, which reviews functionality — broken links, missing assets and forms that aren’t built properly. In a page review Glitch reads the page as it was captured, so faults that only show when someone clicks or submits need a browser check in chat. Alongside the review, the agents can run real diagnostics when you ask for them in an AI chat. These are run on request, not automatically. Each AI chat reply uses credits, based on how much work it takes.

Findings from a page review come back in the Review tab in the sidebar, grouped by the section of the page they were found in. Selecting one takes you to it on the page.

Glitch has its own guide worth reading if functionality is your focus. Read Catch Bugs Before Users Do With Glitch

Verifying Fixes

Statuses are what turn a defect list into a verification queue.

Priorities run Low, Medium, High, and Critical, set on the same control as status.

On AI suggestions that propose a change, a Show me control appears, with the tooltip describing it as showing the update in place. It previews the suggested change on the page without applying it, and carries controls to hide the preview again or regenerate it. That preview is a quick sanity check — not a substitute for retesting once a change is genuinely applied.

Tracking completion honestly is what makes the numbers meaningful later. See Tracking Task Progress And Completion

When the Element Has Moved

A defect pinned to an element that no longer exists reports Element not found on this page, and offers Remap to element so you can point it at the current markup.

This happens constantly in an active codebase. A refactor orphans every task attached to the renamed component, and remapping is what stops your defect list quietly rotting.

Organising a Test Run

The filters in the Feedback tab are what make a defect list workable.

Instructions:

1. Open the Feedback tab in the sidebar. Filter and sort controls appear alongside the list.
2. Filter to Assigned To Me, or sort by Status to pull Pending Review items together.
3. Switch scope between the current page and the whole project.
4. Turn on Complete Tasks when auditing a release rather than working the live queue.
5. Use search to find defects and comments as you type.

Tags are useful for cutting across projects — a regression suite, a release, a browser-specific set. They are added under Add Tags, where the field prompts you to type and press enter to create a new tag.

Keeping Test Discussion Internal

Tasks and comments can be marked internal, which hides them from guests and clients. Defect triage, severity arguments, and known-issue discussion belong there rather than in a thread a client is reading.

Benefits for a QA Engineer

Example Use Cases

Known Limitations

• AI diagnostics need a public URL. Lighthouse and accessibility scans exclude authenticated and internal addresses.
• Diagnostics run on request in an AI chat, not automatically as part of a review.
• Screenshots capture the moment of reporting and do not update as the page changes.
• Element paths reflect the page as it was, so tasks need remapping after markup changes.
• Internal tasks and attachments depend on your plan.
• Nothing enforces who closes a defect — QA-verifies-and-closes is a team agreement, not a product rule.
• Statuses and priorities are fixed and cannot be renamed to match another defect taxonomy.

FAQs

Common issues

• “Element not found on this page” — the markup changed. Use Remap to element to reattach the defect.
• Clicking a link leaves a comment instead of navigating — you are in Comment mode. Switch to Browse, navigate, then switch back.
• An accessibility or Lighthouse check returns nothing useful — the URL is not publicly reachable. Run it against a public environment.
• Defects are being closed without verification — agree that fixes go to Pending Review and QA closes them.
• Filters are missing from the sidebar — open the Feedback tab; the controls appear with it. If still absent, filtering is not enabled for your role.
• No Show me control on a comment — it appears only on AI suggestions that propose a change, and not while a change is queued.
• The screenshot does not match the page — it is a snapshot from when the defect was filed. The page has changed since.
• Internal tasks are locked — not included on your plan. Do not assume a comment is hidden.
• You cannot find a defect you filed — the list may be scoped to the current page. Widen the scope, or turn on Complete Tasks.
• Technical Details is missing fields — your role does not carry full visibility. Ask an administrator.

Conclusion

File from the breakpoint the defect occurs at, spend your words on the steps rather than the environment, annotate when it is visual, and hold the line that QA closes defects rather than developers. The context comes free — the discipline around verification is what actually stops regressions shipping.

It helps to understand how the developers receiving your reports work. Explore Atarim For Frontend Developers