Skip to content

Portfolio

Four case studies, end to end

Not twenty projects - four that go all the way down. Each one is traced through the same seven stages: the problem, the approach, the architecture, how it was tested, what was automated, the numbers, and what it changed for the business.

Case Study 01

AI Agent Testing

Incub8 Engineering · Omni Quality Platform

An autonomous quality platform that takes a requirement from JIRA intake through governed execution, root-cause analysis and locator self-healing - without a human writing the tests.

  1. Problem

    Testing was fragmented across manual teams and multiple tools. Regression cycles ran long, locators drifted constantly, automation was flaky, and nobody had a single view of release risk. Agents running on third-party platforms could not be instrumented from the inside.

  2. Approach

    Treat quality itself as an agentic workflow. Six specialised agents each own one step - analysis, design, generation, execution, failure analysis and self-healing - with a human quality gate holding the release. Test from the outside, the way a customer experiences the system.

  3. Architecture

    JIRA / OpenAPI / live URL feeds the Analyst Agent, then Test Designer, Test Generator, Executor, Failure Analyst and Self-Heal Agent, ending at a Quality Gate wired into GitLab CI/CD, Slack and Grafana.

  4. Testing

    Six test types from one pipeline: functional, end-to-end, REST API, performance, security via OWASP ZAP, and cross-browser. Scenarios are generated from acceptance criteria rather than written by hand, including negative and edge cases.

  5. Automation

    An async job queue drives isolated runners executing Playwright and Selenium workflows in parallel. The Self-Heal Agent recovers from UI drift using deterministic locator strategies and DOM heuristics first, with LLM proposals only as a fallback.

  6. Metrics

    Testing effort per release indexed to the pre-Omni baseline

    Before
    100
    With Omni
    60-70
    30-40% less effort
    Regression automation coverage80%+
    Release validation speed-up25%
    Impact metrics
    Testing effort vs baseline60-70% (30-40% reduction)
    Regression automation coverage80%+
    Release validation speed-up25% faster
  7. Business outcome

    Releases validate in a fraction of the time with an auditable trail behind every gate. Engineers stopped maintaining brittle locators and moved to risk and coverage decisions instead.

Case Study 02

LLM Evaluation Framework

Incub8 Engineering · Agentic Quality Platform

A two-layer evaluation harness that pairs AI judgment with deterministic proof, so a prompt or model change can only ship with evidence behind it.

  1. Problem

    LLM output is non-deterministic, so a pass/fail assertion is the wrong instrument. The same prompt returns different words every run, hallucinations surface only on the paths nobody tested, and a model upgrade can silently regress tone, policy compliance or accuracy.

  2. Approach

    Split the judgement in two. An LLM judge scores the subjective dimensions against explicit rubrics; deterministic checks handle everything that can be proved - schema, PII, policy, required disclosures. Anything that can be checked deterministically never goes to a model.

  3. Architecture

    Golden datasets feed a scenario generator producing adversarial and functional cases. Each response passes through the judge layer and the deterministic layer in parallel, with results written to a versioned baseline for candidate-vs-baseline diffing.

  4. Testing

    Adversarial suites built for the failure modes that matter: hallucination traps, multi-turn context drift, prompt injection, policy violations and edge cases that hand-written suites routinely miss.

  5. Automation

    Evaluations run as a CI gate. Every candidate is scored against the current baseline, regressions are attributed to the dimension that moved, and fail-closed guardrails block a release rather than logging a warning.

  6. Metrics

    Candidate v3.2 vs baseline per evaluated dimension

    Accuracy · refunds
    -4.2%
    Tone · escalations
    -1.1%
    Factuality
    +0.8%
    Policy · PII check FAILED - deterministic, fails closed
    Hallucination traps PASSED - 0 on guarded paths

    Defect detection before and after the eval harness

    Before
    100
    With evals
    140
    up to +40% detection
    Evaluation results
    Accuracy on refunds-4.2% vs baseline
    Tone on escalations-1.1% vs baseline
    Factuality+0.8% vs baseline
    Policy PII checkFailed - blocks release
    Hallucination trapsPassed - zero on guarded paths
    Defect detectionUp to 40% improvement
  7. Business outcome

    Model and prompt changes became routine rather than risky. Each release carries a scorecard showing exactly which quality dimensions moved and by how much.

Case Study 03

Playwright Enterprise Automation

Cross-platform execution layer

The execution layer underneath the agents: parallel, cross-browser, self-healing, and fast enough to gate every deploy rather than run overnight.

  1. Problem

    Enterprise suites were serial, slow and brittle. A single DOM change broke dozens of tests, flaky failures trained the team to ignore red builds, and runs were too slow to sit inside a deployment pipeline.

  2. Approach

    Make the suite fast enough to be a gate and stable enough to be trusted. Parallel execution across isolated runners, a layered locator strategy that survives DOM change, and honest quarantine for genuinely flaky tests instead of blanket retries.

  3. Architecture

    An async job queue distributes work to isolated Playwright and Selenium runners, sharded for parallel execution across browsers, with results aggregated into a single report and pushed to CI/CD, Slack and Grafana.

  4. Testing

    Functional, end-to-end and cross-browser coverage alongside REST API and performance suites, exercised against the same scenario set so a regression is caught wherever it surfaces.

  5. Automation

    Self-healing locators with deterministic strategies and DOM heuristics, drift alerts on retry, and CI/CD webhook integration so every merge triggers the relevant slice rather than the whole suite.

  6. Metrics

    Regression automation coverage80%+

    Six suites, one pipeline executed in parallel on isolated runners

    • Functional
    • End-to-end
    • REST API
    • Performance
    • Security (ZAP)
    • Cross-browser
    Execution coverage
    Regression automation coverage80%+
    Suites in one pipeline6: functional, end-to-end, REST API, performance, security (OWASP ZAP), cross-browser
    Execution modelParallel across isolated runners
  7. Business outcome

    The suite moved from an overnight job to a deploy gate. Maintenance effort dropped sharply because locator drift stopped producing failures that needed a human.

Case Study 04

FinTech & Banking QA Transformation

GoTo Group (Gojek) · GoFin · 2019-2023

Quality engineering rebuilt across Lending, Payments, Insurance and Collections, with a distributed team of 30 engineers across three countries.

  1. Problem

    Financial products spanning Lending, Payments, Insurance and Collections were validated largely by hand. Full cycle testing took 54 hours, releases waited on manual regression, and quality standards varied between country teams.

  2. Approach

    Transform the platform and the organisation together. Automate the regression backbone, virtualise unstable downstream services, put observability behind the pipeline, and establish shared engineering standards and delivery governance across all three sites.

  3. Architecture

    API-first automation with Selenium UI coverage on top, WireMock service virtualisation to decouple from unstable dependencies, and Grafana observability across CI/CD pipelines feeding automated quality gates.

  4. Testing

    Risk-based regression across all four financial product lines, plus performance and customer experience testing, prioritised by exposure rather than by module.

  5. Automation

    Parallel execution against optimised regression suites with automated quality gates, replacing the manual sign-off that had been sitting on the critical path of every release.

  6. Metrics

    Full cycle testing hours per release

    Before
    54h
    After
    9h
    83% faster
    Regression automation coverage80%+
    Deployment validation effort removed40%+
    Production availability99.9%+
    Transformation metrics
    Full cycle testing54 hours to 9 hours (83% reduction)
    Regression automation coverage80%+
    Deployment validation effort removed40%+
    Production availability99.9%+
  7. Business outcome

    Releases moved from a multi-day event to a same-day one across four regulated product lines, with production availability held above 99.9% through resilience engineering.

Try it

Walk through a run

Pick a case study and follow one concrete request through it - the steps taken, what came back, and where the pipeline stops and hands the decision to a person.

Pipeline run Demo · scripted responses

Want the full write-up?

Each of these has a deeper technical breakdown - architecture diagrams, agent workflows and the decisions behind them.

Get in touch Architecture deep dives