Built quality engineering at Thomann Music from the first hire

Context

Thomann Music has sold musical instruments online since 1996, when it became the first music retailer in Germany with its own website. In September 2022 it hired its first quality engineer. That was me.

A shop of that age and reach ships changes every day, from several product teams, each with its own services. Until then there had been no quality engineering function. Developers tested their own work and releases went out on judgment. The judgment was often right. It was not written down, it did not run in a pipeline, and it could not be handed to the next person.

The constraint

One person cannot test a shop of that size and should not try. Anything I did by hand would be gone on the first day I was busy with something else. So the function had to be built as a system from the first week: practices the product teams run themselves, checks that run in the pipeline without me, and a hiring plan that turns one engineer into a team.

The other constraint was the one that matters. The customer does not care how many tests exist. They care that the shop works when they want to buy something, on the device they happen to hold. Every practice below had to trace back to that, or it was not worth introducing.

My role and decision scope

I joined as Test Quality Architect and the only quality engineer, led the function as Engineering Manager from 2024, and have been Head of Quality Engineering since 2026. What I could decide: what to introduce, in what order, which automation stack to build on, and where quality engineers would sit once there were more of them. What I could not decide: the product teams’ priorities. Everything durable was agreed with the teams rather than imposed on them, which is a theme that runs through the other case studies here.

What changed in the system

Automated testing became part of the CI/CD pipeline. End-to-end browser suites run on every change, so a release candidate carries its own evidence instead of waiting for someone to produce it. How I keep those suites trustworthy is its own entry: Browser automation a team can trust on the first read.

Accessibility and visual testing joined the pipeline. Accessibility checks against WCAG on every published page, and visual regression on the pages where a broken layout costs a sale. Both catch the class of defect a functional test passes straight through.

Manual testing became exploratory testing. Time-boxed sessions with a charter, aimed at the risky change, instead of walking a script that only confirms what everyone already expected.

Three-amigos sessions moved quality to before the code. Product, development and quality engineering agree what a change should do and how it will be checked, before anyone builds it. The cheapest defect to fix is the one that never gets written.

Defect triage became a routine. A regular session where open defects are looked at, ranked and given an owner, so nothing sits in a backlog because nobody decided.

Quality engineers embedded in the product teams. As the team grew, each engineer joined a product team rather than a central pool. Six product teams now ship with an embedded quality engineer. What that changed about release decisions, and the testing standard that came with it, is in Wrote the testing standard and moved release decisions into the teams that ship.

Quality engineers as quality ambassadors. The job description I hold my team to is wider than testing. An embedded quality engineer sits in every ceremony of their product team, brings the system-level view of risk, asks for acceptance criteria that can be checked before anything is built, and teaches developers to test their own work well. The measure of the role is whether the team’s habits change, not how many defects the engineer found. Quality is built into how a product team works, or it is not there at all.

AI-assisted engineering, with the audit trail intact. The quality engineering team now runs agents that review pull requests, keep dependencies current, report on coverage and prepare refinement. Each one produces evidence. A person reads it and decides. AI changes the speed of the work, not the bar it has to meet, and the organisation-wide guidelines that grew out of this practice are their own entry: Wrote the AI-assisted engineering guidelines the organisation adopted.

Evidence and outcome

The evidence is structural. A quality engineering function exists where there was none. Automated, accessibility and visual testing run in the pipeline. Six product teams ship with an embedded quality engineer. A company-wide testing standard and a set of AI-assisted engineering guidelines exist and were adopted.

I have not published defect, flake or release figures, for the reason given in the release-confidence entry: they depend on a baseline a reader here cannot see. I am glad to talk through them in a conversation where I can also say what they exclude.

What I would change

The two things I would do differently are written up where they happened. I under-invested in failure legibility before handing ownership to the product teams, and I framed the testing standard as a standard rather than as defaults a team may deviate from with a reason. Both are in the release-confidence entry, and I would rather point there than repeat them here with less context.