Aegis-QA — the tooling I built

The work was spread across a dozen tools. Postman here, a Playwright repo there, SQL in a client, Datadog in a browser tab, test cases in a spreadsheet. Every investigation meant stitching them back together by hand.

• One place to trigger and watch runs across UI, API, flow and security layers.
• A recorder that turns a real session into a reviewable script instead of hand-written selectors.
• API tests, SQL queries and Datadog lookups available next to the run that needs them.
• Test-case management tied to the automation that covers it.
• Self-healing locators. Proposed and sandbox-verified, never applied without a human saying yes.

QA is my profession. AI is my curiosity. Aegis-QA is what happened when the two met: I did not wait for a vendor to sell me a tool, I learned enough AI to build my own.

That is the short version of how a QA engineer ends up maintaining a platform. The QA judgement is mine. AI is how one person shipped something that would normally need a team, and learning enough of it to do that is the part I would do again.

Open the full portal walkthrough ↗

page.get_by_role("button", name="Add to basket").click()
page.get_by_label("Email").fill(email)
page.get_by_role("button", name="Pay now").click()
expect(page.get_by_text(f"Order {order_id} confirmed")).to_be_visible()

Before this, the job was five windows. The comparison worth making is not against a product with a pricing page. It is against the stack a QA team actually runs when nobody has built them one.

1. 01

   Write a test

   Before

   Hand-written selectors, rewritten every time the UI moved.

   With Aegis

   Record the real session. The spec is generated, and regenerable from the recording.

2. 02

   Run it

   Before

   A framework repo driven from a terminal, results scrolling past in the console.

   With Aegis

   One place, with the run history and its artefacts kept together.

3. 03

   Check the API

   Before

   Postman in another window, with its own environment files to keep in sync.

   With Aegis

   Collections run beside the UI suite, against the same run record.

4. 04

   Confirm the data really changed

   Before

   A SQL client, queried by hand, when someone remembered to.

   With Aegis

   Saved queries against the state the run just produced. This is where the UI-says-success-but-the-ledger-disagrees bug gets caught.

5. 05

   A locator stops matching

   Before

   Find it, guess a new one, hope it holds until next week.

   With Aegis

   A proposed replacement, verified in a sandbox, waiting for a human to approve it.

6. 06

   A run fails at 2am

   Before

   Read the log, then the trace, then the diff, then ask the developer.

   With Aegis

   Classified and diagnosed on arrival, with the trace for the failed request pulled in beside it.

7. 07

   Know what is covered

   Before

   A spreadsheet, out of date the day after it was written.

   With Aegis

   Cases tied to the automation that covers them, so a gap is visible rather than assumed.

8. 08

   Test the Android app

   Before

   A separate project, on a separate framework, that nobody maintained.

   With Aegis

   The same record-and-compile path, over Appium.

Five, and they are a frozen contract. Every module has to keep working in all five, because the cost of a runner mode quietly breaking is a suite that looks green while running almost nothing.

single

One test, on its own. The loop you use while writing it.

suite

One layer or a grouped set, for a targeted regression.

flow

Lifecycle and flow tests, where the output of one step feeds the next.

full

Every primary layer. The pre-release pass.

all

Every module, everything. The nightly.

• A generated fix is a proposal until a person approves it. Nothing self-applies.

• Deterministic checks run before AI, always. AI is the last resort, not the first.

• The recording is immutable. Everything else is derived and can be rebuilt from it.

• A sandbox pass proves a fix compiles and runs. It does not prove the bug is gone.

• Secrets never enter a recording, a report or a repository.

A product page without this section is a brochure.

• —

  It is internal tooling for one team, not a commercial product. There is no pricing page and no support line.

• —

  It assumes a web or Android application it can drive directly. It is not a unit-test runner.

• —

  A sandbox-verified fix proves the change compiles and runs. It does not prove the bug is gone, which is why a human still approves it.

1. 1

   Record

   A real session on the real app becomes a structured recording.

2. 2

   Compile

   The recording compiles to readable Gherkin and a runnable Playwright spec.

3. 3

   Run

   UI, API, flow and security layers execute together across five runner modes.

4. 4

   Heal

   When a locator rots, the run proposes a fix and verifies it in a sandbox.

5. 5

   Learn

   Only verified fixes are kept. Everything else stays advisory until a human approves it.

• ✓Investigating a failed run happens in one tool instead of five.
• ✓Recorded sessions become maintained scripts, so coverage grows without hand-writing every selector.
• ✓It is internal tooling rather than a product. I built it because the off-the-shelf options did not fit how the team works.

• Python 3.12
• Playwright
• asyncio
• FastAPI
• Next.js
• Docker