How automated QA works
When QA is in a ticket's execution scope, Trundle:
You can follow all of this live in the ticket's Thought process tab, under the QA view. It streams the agent's setup attempts, commands, per-objective results, and any screenshots it captured.
Objective-based results
Rather than a single pass/fail, each objective gets its own status and evidence, so you get granular, line-item feedback on exactly what worked and what didn't. Acceptance criteria you define on a ticket are also fed into the Trundle Review Agent, so review is judged against the ticket's intended behaviour.
See what the Trundle QA Agent saw
For web tickets, the Trundle QA Agent captures a screenshot at the most informative moment of each objective (a handful per run) and displays them inline in the Thought process tab, right next to its written findings. That gives you visual proof of what the page looked like when it tested each objective, not just a description. Screenshots are only produced for browser-based (web) testing; API, CLI and library checks verify behaviour in other ways and don't generate images.
The "Blocked" safeguard
If a QA run can't complete because of an environment problem rather than your code (for example, the app won't build or start), Trundle won't penalise the ticket:
- the run is marked Blocked,
- the ticket returns to Pending QA, and
- a Trundle bot comment and a human Action Item are created so someone can look into the environment.
Other behaviours
- Duplicate prevention: Trundle won't start a second QA run for a ticket that already has one in progress.
- Where the detail lives: The ticket's Activity tab records high-level outcomes (QA passed, QA failed with counts, or QA blocked); the moment-by-moment detail (setup attempts, commands, per-objective results and screenshots) streams into the Thought process tab.
- Manage sprints inline: You can add, remove, or move a ticket between sprints directly from the ticket dialog, and the change saves immediately.