QualityLabs

AI made development faster.
Testing didn’t keep up.

We bring your testing up to that pace: automation, load and performance, and a team trained to own it.

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

What we get called in for

Five problems, and they rarely arrive alone.

  • AI wrote the tests, and they can never fail.

    Ask AI to test your checkout and you get tests that pass the first time and every time after. They click a button only if it happens to be there, wait a fixed three seconds, and check nothing that matters. The coverage number goes up. The risk does not go down.

    We read what was generated, keep the tests that would catch a problem worth waking someone up for, fix the ones that nearly would, and delete the rest. Then we set a review standard so the next thousand do not arrive the same way.

    Generated, never reviewed 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);
});

  • AI multiplied the changes. The time to check them stayed the same.

    When a team starts writing code with AI, the number of changes waiting to be checked goes up long before anyone thinks to change how the checking works. The two or three people who could review every change last year cannot now, so checking turns into spot checks, without anyone deciding it should.

    Hiring does not close a gap like this, and neither does asking people to go faster. What closes it is deciding what really needs testing, making the rest fast and automatic, and giving the people who check the work the same AI tools the developers already have.

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

  • It works in testing and breaks on your busiest day.

    Heavy traffic exposes problems that ordinary testing never reaches: a database sized for last year, a page that was fast with a thousand customers and crawls with fifty thousand, a supplier that cuts you off in the middle of a campaign.

    We simulate the traffic you actually expect, on a setup close enough to the real one to mean something, and find the first thing that gives way. You get the point where it breaks, with a number on it, and the part responsible, not a chart nobody can act on.

    What we run
    A normal day, your busiest hour, and a run long enough for slow leaks to show themselves.
    What we look for
    The first part of the system to max out, and then the one behind it that was the real limit all along.
    What you keep
    The breaking point, what causes it, and the change we would make to raise it.

  • The old tests nobody wants to touch.

    Six years of tests in an older tool such as Selenium, servers somebody has to keep alive to run them, and results people have learned to second-guess rather than trust. They still hold real knowledge about the product, which is why deleting them all is as wrong as rewriting them all.

    Where the old tests are worth keeping as they are, we look after them there instead. Cypress, Selenium and WebdriverIO included.

    Step one
    An inventory. A good share of most old tests is not worth moving at all, and we say which part is the valuable bit.
    Step two
    A trial run on roughly 10 to 15% of the tests, working for real, so the cost of the rest is known rather than guessed.
    Step three
    The rest, with a named person on your side involved from the first day rather than at the handover.

  • Every test passes. The app still feels slow.

    Every test can pass and the product can still feel bad. Taps that take a moment to register, a page that jumps while it loads, a first screen that arrives in pieces. None of it shows up in test results, and all of it shows up in how your customers behave.

    We measure it on your real users’ devices rather than in a lab, trace each problem back to its cause, and propose the change that fixes it rather than a 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.

Most teams we talk to have tried a tool for this, often several. The tools do what they promise. None of them can tell you which twelve of your four hundred behaviours the business is built on, and deciding that is most of the job. Four generations of tooling have been sold as a replacement for the person who makes that call. There is no such replacement.

This is not an argument against AI. Much of our own delivery runs on it. The best independent measurement put its saving on this work at 24.9%, against a category that advertises minutes. A quarter of the effort handed back is a real gain. It is still not the job.

The platform
Owned your tests. Fixing one meant a support ticket.
The self-healing test
Repairs a moved button and a changed business rule the same way. Only one of them should pass.
The AI-written tests
Breadth with no priority, where the risk is anything but evenly spread.
The AI reviewer
Sees the code change, not the past incident that explains why the code was there.

The long version, generation by generation

What we do

Testing is not the whole of quality.

From the first test to the load that breaks the system, and the team that owns it afterwards.

Your website, tested automatically

Automated tests for the journeys your business runs on, such as sign-up and checkout, checking what matters and running on every change. Built in Playwright.

The systems behind your app

Tests for the services and data your app depends on, including what happens when something goes wrong. Fast, because no screen is involved.

Your iOS and Android apps

Automated tests for your mobile apps in Appium, or in Apple’s and Google’s own tools where they fit better.

Moving or maintaining old tests

Tests in older tools such as Selenium or Cypress moved to Playwright: an inventory, a trial run, then the rest. Or we keep them where they are and look after them.

Review of AI-generated tests

We keep the tests that check something real, fix the ones that nearly do, and set a review standard for the next batch.

Load testing

How much traffic your system takes before it breaks, and which part breaks first. Built in k6, and included with a migration.

Performance and user experience

How fast your product feels to real users, measured on their devices and traced to the cause, with the fix proposed rather than a dashboard.

Tests on every change

Your tests running automatically every time the code changes, in the tools you already use, and quick enough that nobody skips them.

Training

Playwright, automated pipelines, and using AI on quality work without trusting it blindly. Side by side during the project, workshops at handover.

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 your tests, a plan for what to do with them, and a blunt view of what is worth keeping. It is yours whether or not you hire us.

  2. Trial run

    A real part of your tests, not a demo, moved and passing on every change your team makes. 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 stages, with your engineers working alongside us. The training is not only a workshop at the end. It is how the work gets done.

  4. Handover

    Documentation about the project, knowledge-transfer workshops, and a team that can extend the tests on its own. Support afterwards, if you want it.

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 tests that repaired themselves, then AI that writes the tests, and now AI that reviews every change. 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 cases where deleting the tests beats moving 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 unreliable 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 tests are worth running at all. Here are four ways to measure it.

Read the note

Case studies

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 sets of tests running side by side. The number vendors never lead with.

Read the case study

Two weeks, 200 tests, and the part everyone skips

A fortnight for 200 tests, GPT-4 inventing checks that do not exist, and why 71% passing on a laptop became 44% on the build server.

Read the case study

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 case study

Zalando load tests in production. Here is why.

At 7,200 orders a minute, a test copy of the site stops telling you anything worth knowing.

Read the case study

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 case study

Start with the audit.

Tell us what your product runs on and how you test it today. We come back with what your tests really check, the risks nothing covers, and where the gap is judgement rather than tooling. Sometimes the answer is less than you think. You keep the document either way.

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.

Questions

What people ask before the audit.

Anything missing here, ask it in the email. The answer costs nothing either.

What do we actually get from the free audit?

A written inventory of your tests, what each part really checks, the parts of the product that carry risk nothing covers, and a plan for moving the tests where that makes sense. It takes about a week of our time and very little of yours.

The document is yours whether or not you hire us. Sometimes the answer is that you need less than you think, and we will say so.

How does an engagement run?

Four steps: the audit, a trial run passing on every change, the bulk of the work with your engineers alongside us, and a handover. Each one ends with something you can use on its own, so you can stop after any of them.

The trial run exists so the estimate for the rest is measured on your code rather than guessed from ours. The steps in more detail.

Do you do the work, or does our team?

Both, from the first day. We do the heavy lifting, and a named owner on your side works alongside us rather than being introduced to the tests at the end. How much each side carries is agreed up front and can shift as your team gets comfortable.

The people who scope the work are the people who do it. There is no handoff to a delivery team you have not met.

We have very little automation today. Is it too early to call you?

It is a good time. Starting from little means nothing to unpick. We set up coverage where you have none, sort your manual checks into what is worth automating and what is not, and set it all running in the tools you already use. Your team learns the habits while the tests are few, which is when they are cheapest to learn.

Our tests use an older tool such as Selenium or Cypress. Do we have to switch?

No. Where your tests are worth keeping as they are, we maintain and improve them there: Cypress, Selenium and WebdriverIO included. Where moving to Playwright pays for itself, we move them in stages, never all at once, and some tests are better deleted than moved. The audit says which is which, test by test.

Is there work you won’t take on?

Yes. A migration with nobody on your side to own it afterwards. A brief to move every test by a deadline with no trial run first. And automating work that needs a person’s judgement, such as exploratory testing and accessibility walkthroughs. If the tests are unreliable because the app cannot be reset to the same starting point before each one, we say so before migrating anything, because moving the tests would only move the problem. The full list, and why.

How long does it take?

The audit takes about a week. Everything after it depends on the size and state of your tests, which is exactly why the trial run comes next: it turns the estimate for the bulk into a number measured on your code. Be wary of anyone who quotes a full migration before they have seen a slice of it running. What a real timeline looks like.

What happens once you leave?

Your team is ready to carry on without us. The handover is documentation about the project and knowledge-transfer workshops.

We still offer support once the project is finished. It comes in different levels, depending on how much of us you want around, and it can be extended depending on the conditions we agree.