HOW RECUS WORKS
Results & human review
The report is a record of what Recus tried and what it observed. Use it to make an informed decision—not as an automatic release approval.
Read the verdict in context
- Pass
- The observed behavior matched the test’s expectation. This applies to that test and the evidence available, not every possible user journey.
- Fail
- Evidence suggests the tested behavior did not meet its expectation. Check that the expectation matches your product requirements before filing a defect.
- Warning
- The outcome needs review. This can include usability concerns, uncertainty, blocked verification, or a missing capability—not just a flow that succeeded with a cosmetic issue.
Review a finding, step by step
Read the goal and starting context
Confirm the page, intended behavior, and relevant account or session state. Ask whether the generated expectation is correct for your product.
Follow the actions
Check the browser journey and any skill actions. For a discovered control, include the steps that revealed it; for a new page, include the navigation that reached it.
Inspect the available evidence
Review screenshots, recordings, traces, and action details where available. A missing artifact or interrupted execution reduces the evidence you can rely on.
Check what remains unverified
Look for missing skills, input requests, skipped follow-ups, and routes that were seen but not tested. A partial browser journey is not a verified end-to-end result.
Choose the next action
Confirm and triage a defect, correct a mistaken expectation, rerun with suitable test data, or manually cover the part that Recus could not verify.
When a person needs to help
Some journeys need information or access the agent does not have. Recus can identify a need for human input, such as credentials or a verification value, rather than treating the blocked journey as complete.
When an input request is available in the run, provide only authorized test information through that workflow and review the affected test’s rerun. A CAPTCHA, SSO barrier, or unavailable service may still require manual testing; asking for input does not guarantee that every blocker can be resolved.
Check coverage before sharing
Separate completed tests from discoveries and skipped candidates. A long list of discovered URLs is not evidence that every listed page was tested. Likewise, full skill coverage is about the capabilities needed for one test, not the breadth of the scan.
Review the evidence for personal data, test credentials, and application content before sharing a report. Keep sensitive production information out of test journeys wherever possible.
Your team makes the release decision