QualityLabs

Development moved to AI speed. Quality did not.

AI does the mechanical work. The judgement stays human.

Start with a free audit or write to hello@qualitylabs.eu

What we get called in for

Five problems, and they rarely arrive alone.

  • The model wrote the tests, and they can never fail.

    Ask a model to cover checkout and you get something that runs green on the first attempt and on every attempt after it. An optional click, a fixed sleep, an assertion that checks a page is a page. The coverage number moves. The risk does not.

    We read what was generated, keep the tests that assert something somebody would be woken up for, rewrite the ones that nearly do, and delete the rest. Then we put a review standard in front of the next thousand so they do not land the same way.

    Generated, merged unread typical 
    test('checkout works', async ({ page }) => {
  await page.goto('/checkout');
  await page.waitForTimeout(3000);

  const btn = page.locator('.btn-primary').first();
  if (await btn.isVisible()) await btn.click();

  expect(true).toBeTruthy(); // green forever
});
    What survives the review kept 
    test('charged exactly once', async ({ page }) => {
  const cart = await seedCart({ sku: 'SKU-118' });

  await page
    .getByRole('button', { name: 'Place order' })
    .click();

  await expect(page).toHaveURL(/\/confirmation\//);
  expect(await chargesFor(cart)).toHaveLength(1);
});

  • Delivery tripled. The quality team did not.

    When a team starts writing with a model at its elbow, the volume of change arriving at the quality gate goes up long before anyone thinks to change how that gate works. The two or three people who could read every pull request last year cannot now, and the work quietly becomes sampling that nobody has written down.

    Hiring does not close a gap of this shape and neither does asking people to go faster. What closes it is deciding what genuinely needs a test, pushing everything else down to a layer that runs in seconds, and putting the same tooling in the quality team’s hands that the developers already have.

    Change arriving, against capacity to review it The shape of the gap. Not a measurement of your team. Change merged per week Capacity to review and test it then now

  • It holds in staging and folds at scale.

    Volume exposes what correctness testing never touches: a connection pool sized for last year, a query that was fine at ten thousand rows, a queue with no backpressure, a third party whose rate limit you find out about during a campaign.

    We model the load you actually expect, run it against something close enough to production to mean anything, and find the first thing that gives way. What you get is a breaking point with a number on it and the component responsible, not a graph of requests per second.

    What we run
    Steady state, peak, and a soak long enough for the leaks to show themselves.
    What we look for
    The first component to saturate, and then the one sitting behind it that was the real limit all along.
    What you keep
    The breaking point, the bottleneck, and the architectural change we would make to move it.

  • The Selenium suite nobody wants to open.

    Six years of tests, a Grid somebody has to babysit, and a pass rate that everyone has learned to interpret rather than trust. It still encodes real knowledge about the product, which is why deleting it wholesale is as wrong as converting it wholesale.

    Where a suite is worth keeping where it is, we maintain it there instead. Cypress, Selenium and WebdriverIO included.

    Step one
    Inventory and triage. A sizeable share of most suites should not be converted at all, and saying which part is the valuable bit.
    Step two
    A pilot batch of roughly 10 to 15%, taken through CI, so the real cost of the bulk is known rather than estimated.
    Step three
    The bulk, with a named owner on your side from the first day rather than at the handover.

  • Green in CI, slow in the hand.

    A suite can be entirely green and the product can still feel bad. Interaction latency, layout that moves under the thumb, a first view that arrives in pieces. None of it shows up in a pass rate, and all of it shows up in the numbers your users generate.

    We measure these in the field rather than in a lab tab, trace each one back to the thing causing it, and propose the change that fixes it rather than the dashboard that reports it.

    LCP
    How long before the thing the page is actually for is on screen.
    INP
    How long the interface takes to answer a tap. The one most teams have never looked at, and the one users describe as the site feeling heavy.
    CLS
    How much the page moves after somebody has started reading it.

Our team has built and shipped quality at

Regulated and unregulated markets: financial services and high-frequency trading, crypto and digital assets, real-estate marketplaces, browsers at consumer scale, and a fair number of niches in between.

The argument

The missing part has never been a tool.

Nearly everyone we talk to has already bought something to fix this, and most have bought several. The tools work, in the narrow sense that they do what is written on the box. What none of them can do is tell you which twelve of your four hundred behaviours the business is actually built on, and sorting that out turns out to be most of the job.

For about a decade the same promise has arrived in four forms, each better engineered than the last, and each sold as a replacement for the person who would make that call. There is no such replacement. The reason the tool got bought is usually that nobody was making that call to begin with, which leaves it supplying the judgement as well as the labour. It can do the labour.

So this is not an argument against AI, and we would be poor company for that argument given how much of our own delivery runs on it. It is an argument about who is holding it. The best independent measurement of a model doing this work with a light touch on the wheel put the saving at 24.9%, against a category that advertises minutes. A quarter of the effort handed back is a real gain. It is also not the job.

The platform
Your tests lived in somebody else’s format, on their servers. Healing meant a support ticket.
The healing locator
Repairs a moved button and a changed business rule identically. One of those is now a green test describing a product that no longer exists.
The generated suite
Breadth with no priority, across a product where risk is nothing like evenly spread.
The agent on the diff
It has the change. Not the incident three years ago that explains the guard clause it just tidied away.

The long version, generation by generation

What we do

Testing is not the whole of quality.

Most of what we get asked for is test automation. Most of what actually moves the number is deciding which tests are worth having, and then looking at everything tests do not cover: how fast the application feels, where it slows down under real conditions, and what gives way first when the traffic arrives.

Migration, and maintenance of what stays

Inventory first, then a pilot batch, then the bulk. You get a test-by-test map of what was converted, what was fixed and what we dropped. No big-bang cutover. Where a suite is worth keeping as it is, we maintain it there instead: Cypress, Selenium and WebdriverIO included.

Test automation

Frontend, backend and mobile, in Playwright, Appium and the native tooling where that is the right answer. New coverage where you have none, and a manual backlog sorted into what is worth automating and what is not.

Load testing and breaking points

Included in the migration rather than sold back to you later. We look for where the system stops coping and why, not just whether it survived one rehearsal at the traffic you already expected.

Performance and user experience

Latency, interaction patterns and the field metrics users actually feel: LCP, INP, CLS. We trace them back to the bottleneck causing them and propose the architectural change that fixes it, rather than the dashboard that reports it.

Training

Playwright, CI, and how to use AI on quality work: where it earns its keep, where it produces confident nonsense, and how to tell the difference. Human-driven, and the reason the work sticks after we leave.

Tools we work in

  • Playwright
  • TypeScript
  • Python
  • k6
  • Lighthouse
  • Web Vitals
  • Selenium
  • Cypress
  • WebdriverIO
  • Appium
  • XCUITest
  • Espresso
  • GitHub Actions
  • GitLab CI
  • Azure DevOps
  • Jenkins

How it works

Four steps, and you can stop after any of them.

  1. Audit

    About a week, free. You get a written inventory of the suite, a migration map, and a blunt view of what is worth moving. It is yours to keep whether or not you hire us.

  2. Pilot batch

    A real slice of the suite, not a demo, migrated and running green in your CI. This is where you find out if the estimate holds, while it is still cheap to change course.

  3. Migration and training

    The bulk of the work, in tranches, with your engineers pairing along the way. The training is not a workshop at the end. It is how the migration gets done.

  4. Handover

    A runbook, the decisions written down, and a team that can extend the suite without calling us. If you need us afterwards, something went wrong.

Notes

What we think, with the working shown.

No client logos on this page pretending to be endorsements. Read the arguments instead and decide whether we know what we are doing.

Start here

Four generations of self-healing tests, and the same missing person

A platform that owned your tests, then a locator that repaired itself, then a model that writes the suite, and now an agent on the diff. Each one is better engineering than the last, and each one was sold as a way to do without the person who understands the product. That person was the only load-bearing part.

Read the note

What we won’t take on

The migrations we turn down, and the suites where deleting the tests beats converting them.

Read the note

Where AI actually fails at test migration

One controlled study put the saving at 24.9%, not “minutes”. Here are the six places it reliably breaks, and why.

Read the note

Flaky tests come in clusters

Three quarters of flaky tests share a cause with about a dozen others. Fixing them one at a time is why the queue never empties.

Read the note

Your suite isn’t slow. It’s lying to you.

Duration is the easy metric. Trust is the one that decides whether the suite is worth running at all. Here are four ways to measure it.

Read the note

Teardowns

Other people’s migrations, read properly.

We have no client case studies to show you, so we will not invent any. Instead we take the best publicly documented accounts in this field and read them closely, including the parts that argue against hiring anyone at all. Every number below traces to a published source you can check.

What a real Selenium migration timeline looks like

One hundred tests, eight months, two suites running at once. The number vendors never lead with.

Read the teardown

Two weeks, 200 tests, and the part everyone skips

A fortnight for 200 tests, GPT-4 inventing assertions that do not exist, and why 71% local became 44% in CI.

Read the teardown

The automation project that found eight bugs in three years

A quality director published her own three-year failure. Going back to manual testing may have been right.

Read the teardown

Zalando load tests in production. Here is why.

At 7,200 orders a minute, staging stops telling you anything worth knowing.

Read the teardown

Nobody is coming to test it for you

Amazon went from ten engineers per tester to a hundred. The testing work did not go anywhere.

Read the teardown

Start with the audit. It costs you a week and nothing else.

Tell us what your team ships with and what the suite looks like today. We come back with a read on what it is actually asserting, which parts of the product carry risk that nothing covers, and where the gap is judgement rather than tooling. That includes the times the answer is “less than you think, and here is what to do instead”. You keep the document either way. There is nothing to sign.

Request the audit or write to hello@qualitylabs.eu

Who we are

A small team, with more than 30 years of this work behind us.

We are a boutique, not an agency. The people who scope the work are the people who do it, and we take on a small number of engagements at a time because that is what it takes to do them properly.

We are based in the EU and work across European and US time zones. We use AI heavily in our own delivery and are straightforward about where it helps and where it does not. That is the same judgement we teach your team to make.