Every QA tool can find a bug. The hard part is what happens next. Does the bug get triaged? Does someone verify the fix? Does the same bug come back two sprints later? Most testing workflows stop at detection. Aiqaramba closes the full loop through three feedback mechanisms that operate at different speeds and with different amounts of automation.
Loop 1: Fix what is broken
The health board shows every journey in your project as a card. Green means passing, red means failing. When a card turns red, you click it.
The agent report tells you what happened in plain language: which page it visited, what it tried to do, and why it failed. You get the failure reason, the steps taken, and a recording of the browser session.
Example
Your "Signup flow" card turns red. The report says: "Email validation rejected user+test@example.com. The form's client-side validation rejects the + character." You fix the regex, click Re-run on the card, and it turns green.
This loop takes minutes. The health board surfaces the problem, the report explains it, and a single click verifies the fix. There is no separate test suite to maintain and no "works on my machine" guessing. The same agent that found the bug confirms whether the fix worked.
The manual loop is where most teams start. It is also the fallback when the automated loops surface something unexpected.
Loop 2: Catch regressions before users do
The regression trigger connects Aiqaramba to your CI/CD pipeline. After every deploy, your pipeline sends commit messages, changed files, and the PR description. An LLM analyses those changes against your project's journey catalogue and app map, then runs only the journeys that could be affected.
This goes further than keyword matching. The LLM understands that a change to auth.ts could affect the login flow, the signup flow and the checkout flow, because they all share an auth module. Journeys are matched on what the change means for the product, and results come back in about five minutes with no manual steps in between.
When a regression agent fails and the project is linked to a GitHub repository, Aiqaramba creates a GitHub issue automatically. The issue contains the failure details, reproduction steps extracted from the agent trace, and expected versus actual behaviour. The developer who pushed the breaking change sees the issue in their repo within minutes of the deploy.
Nobody needs to decide which tests to run, and nobody needs to review results unless something actually broke. The loop runs from push to issue without a human in it.
Loop 3: Discover what to test
The first two loops assume you already have journeys. When you first connect an app, you start from zero. Discovery fills that gap.
You provide a URL and, optionally, login credentials. Aiqaramba sends agents to explore the application in phases. The first agent catalogues pages, forms and navigation links from the entry URL. Follow-up agents chase leads from earlier phases: settings pages, nested forms, areas behind login. After two or three phases, an LLM synthesises everything into a structured app map and generates three to five journey templates for the key user flows it found, ranked by importance.
The whole process takes about ten minutes. At the end, the health board shows journey cards ready to run. Run them, and the first loop begins.
Discovery is typically a one-time step per project. The journeys it creates persist and become part of your ongoing coverage. You can edit them, add checkpoints for finer progress tracking, and set success criteria. As your app evolves, you run discovery again to pick up new pages and flows.
The full cycle
The three loops feed into each other. Discovery creates journeys. Running journeys produces health data. Health data drives manual investigation. CI/CD triggers regression runs. Regressions create GitHub issues. Fixes get verified by re-runs.
The product moves through a natural lifecycle:
- Unknown. No project, no journeys, no data. Discovery moves you past this in minutes.
- Discovered. The app map exists and journeys are ready to run. The first run produces a health snapshot.
- Broken. Agents found failures. Reports explain exactly what went wrong.
- Recovering. Some journeys pass, some still fail. Checkpoint progress shows how close each flow is to working.
- Healthy. All critical journeys pass. The regression loop keeps it that way.
When a developer pushes code that breaks a healthy flow, the regression loop catches it. The health board turns red. The manual loop kicks in. The product recovers. This is the steady state: healthy, with automatic guardrails against regression.
Coverage tiers
Journeys are organised into five tiers that form a dependency pyramid:
- Access (can users get in?) and Reachability (can users navigate?) are critical. They drive the project-level health verdict.
- Functionality (can users do things?) and Workflows (can users complete tasks?) are important, and do not affect the top-level status.
- Resilience (what happens under stress?) is informational.
A healthy project means the product works for typical users. It does not mean the product is perfect. If login works, navigation works and the core features work, the project is healthy, even while an edge case in the settings page is broken.
For implementation details on each loop, including the regression trigger, discovery phases and health computation, see the documentation.