# Co automatizované testy přístupnosti skutečně pokrývají — a co jim uniká

V projektech s dobrou CI coverage se opakuje jeden vzorec: všechny Playwright testy prochází, axe nenachází žádná porušení, Lighthouse dává skóre přístupnosti přes devadesát. Pak přijde skutečný uživatel se čtečkou obrazovky a nezvládne dokončit základní úkol.

Tohle není selhání nástrojů. Je to nepochopení toho, k čemu byly navrženy.

## Na co je automatizovaný sken skutečně spolehlivý

Axe-core a Lighthouse zachytí strukturální porušení dobře. Chybějící atributy `alt`, formuláře bez popisků, neplatné ARIA role, nedostatečný kontrast barev u statického textu — to vše je detekovatelné čtením DOMu a porovnáváním s pravidly. Má smysl spouštět je při každém CI buildu a brát výsledky vážně.

Skutečná hodnota spočívá v prevenci regresí. Atribut `aria-label` tiše odstraněný při refaktoringu, pořadí nadpisů rozbité po aktualizaci komponenty, orientační bod, který zmizí po změně layoutu — automatizovaný sken zachytí tyto tiché regrese dřív, než se dostanou na produkci. To není malá věc.

Výzkumy ale konzistentně ukazují, že detekční strop je někde mezi třiceti a sedmapadesáti procenty skutečných WCAG porušení. Deque, firma stojící za axe, odhaduje, že jejich nástroj zachytí na reálných stránkách přibližně 57 %. W3C řadí jako plně automatizovatelná jen 20–30 % WCAG kritérií úspěchu. To není pesimismus — je to přesný popis toho, co analýza na úrovni DOMu může a co strukturálně nemůže vyhodnotit.

## Mezery, které v praxi nejvíce vadí

Mezery nejsou náhodné. Seskupují se do tří oblastí: kontextově závislý smysl, dynamický stav a správa fokusu.

**Kontext a smysl.** Odkaz s textem „Číst více" projde každou strukturální kontrolou. Uživatel čtečky obrazovky, který naviguje podle odkazů, slyší „Číst více" bez jakéhokoli okolního kontextu. Axe ověřuje přítomnost a formát — ne to, jestli je text smysluplný čtený izolovaně. Totéž platí pro alternativní texty. `alt="obrázek"` je detekovatelné jako generické. `alt="usměvavý člověk"` projde bez problémů, i když to nic užitečného o roli obrázku na stránce neříká.

**Dynamický stav.** Přepínač motivu označený „Přepnout na tmavý režim" projde kontrolami. Ale pokud je stránka již v tmavém režimu, popisek je fakticky chybný. Automatizovaný sken vyhodnocuje snímek DOMu v jednom okamžiku. Nemůže ověřit, jestli ARIA popisky zůstávají přesné při změnách stavu.

**Správa fokusu.** Modální okna jsou klasickým problematickým místem. Statická analýza DOMu potvrdí, že `role="dialog"` je přítomné. Nemůže ale testovat, jestli se fokus při otevření přesune do modálního okna, jestli Tab zůstane uvnitř, nebo jestli se fokus po zavření vrátí na spouštěcí prvek. Ze strukturálního pohledu vše vypadá v pořádku. Z pohledu uživatele klávesnice může být modální okno zcela nedostupné.

## Co Playwright dokáže testovat tam, kde axe nestačí

Hranice mezi axe a Playwright není jen o omezeních axe — je to o tom, co Playwright umožňuje a co axe nikdy poskytnout nemůže: interakci. Spuštění axe po vyvolání konkrétních stavů výrazně zmenšuje mezeru.

Kontrast v hover a focus stavu:

```ts
await page.getByRole('button', {name: 'Odebírat'}).hover()
const results = await new AxeBuilder({page}).analyze()
expect(results.violations).toEqual([])
```

Sken tmavého režimu, který je zcela jiným barevným kontextem než výchozí sken:

```ts
await page.emulateMedia({colorScheme: 'dark'})
await page.goto('/')
const results = await new AxeBuilder({page}).analyze()
expect(results.violations).toEqual([])
```

Dynamické ARIA popisky měnící se se stavem:

```ts
const toggle = page.getByRole('button', {name: /přepnout/i})
await expect(toggle).toHaveAttribute('aria-label', 'Přepnout na tmavý režim')
await toggle.click()
await expect(toggle).toHaveAttribute('aria-label', 'Přepnout na světlý režim')
```

Uzamčení fokusu v modálním okně a chování klávesy Escape:

```ts
await page.getByRole('button', {name: 'Otevřít dialog'}).click()
for (let i = 0; i < 10; i++) {
	await page.keyboard.press('Tab')
	const isInsideDialog = await page.evaluate(
		() => document.activeElement?.closest('[role="dialog"]') !== null
	)
	expect(isInsideDialog).toBe(true)
}
await page.keyboard.press('Escape')
await expect(page.getByRole('dialog')).not.toBeVisible()
```

Skip link — jestli se zobrazí jako první fokusovatelný prvek a jestli skutečně funguje:

```ts
await page.keyboard.press('Tab')
const focused = page.locator(':focus')
await expect(focused).toHaveAttribute('href', '#main-content')
await page.keyboard.press('Enter')
await expect(page).toHaveURL(/#main-content$/)
```

Tohle nejsou okrajové případy. Přepínače motivu, modální okna, skip linky a barevná schémata jsou standardní součástí většiny produkčních aplikací. Pokud testy tyto interakční stavy nepokrývají, má přístupnostní coverage reálné mezery bez ohledu na to, co axe skóre ukazuje.

## Co automatizace nemůže nahradit

Některé kategorie nemají automatizované řešení. Chybové hlášky formulářů, které říkají „Neplatný vstup" bez upřesnění, co je špatně. Povinná pole označená pouze hvězdičkou bez textového popisku. Dlouhé formuláře, kde se chybová oznámení zobrazí nahoře, ale fokus se tam nepřesune — a uživatel klávesnice musí hledat.

Nic z toho neselže při strukturálních kontrolách. Vše z toho vytváří skutečné bariéry pro reálné uživatele.

Praktický přístup je považovat automatizovaný sken za podlahu, ne za strop. Poskytuje pokrytí pro regrese a vyhodnocuje každou stránku při každém CI runu — to jsou dvě věci, které manuální testování v takovém rozsahu nedokáže. Ale průchod čtečkou obrazovky, navigační session pouze s klávesnicí, ověření, jestli jsou chybové hlášky skutečně užitečné — to vše zůstává potřebné bez ohledu na to, co automatizovaná zpráva říká.

## Shrnutí

- Automatizovaný sken spouštěj při každém CI buildu — spolehlivě zachytí strukturální regrese
- Jdi za výchozí sken — vyvolej hover, focus, tmavý režim a interaktivní stavy před spuštěním axe
- Testuj dynamické ARIA popisky, uzamčení fokusu v modálním okně a chování skip linku přímo v Playwright
- Kontextově závislý smysl, použitelnost formulářů a zkušenost se čtečkou obrazovky vyžadují lidský úsudek

Projít axe skenem je začátek. Jestli je produkt skutečně přístupný pro reálné uživatele, je jiná otázka — a taková, na kterou analýza DOMu sama o sobě nedokáže odpovědět.

Axe a Lighthouse zachytí přibližně 30–57 % skutečných WCAG porušení. Co jim uniká a jak rozšířit Playwright testy za výchozí sken.

Co Playwright testy přístupnosti skutečně pokrývají | sw-tester.cz

Co automatizované testy přístupnosti skutečně pokrývají — a co jim uniká

# Was automatisierte Barrierefreiheitstests wirklich abdecken — und was ihnen entgeht

In Projekten mit solider CI-Coverage wiederholt sich ein Muster: Alle Playwright-Tests bestehen, axe findet keine Verstöße, Lighthouse vergibt eine Barrierefreiheitspunktzahl über neunzig. Dann öffnet ein echter Nutzer mit einem Screenreader die Seite und kann eine grundlegende Aufgabe nicht erledigen.

Das ist kein Versagen der Tools. Es ist ein Missverständnis darüber, wozu sie gebaut wurden.

## Wo automatisiertes Scannen wirklich zuverlässig ist

Axe-core und Lighthouse erkennen strukturelle Verstöße gut. Fehlende `alt`-Attribute, Formulare ohne Labels, ungültige ARIA-Rollen, unzureichender Farbkontrast bei statischem Text — das alles lässt sich durch DOM-Analyse und Regelvergleich erkennen. Es lohnt sich, diese Prüfungen bei jedem CI-Build auszuführen und Ergebnisse ernst zu nehmen.

Der eigentliche Wert liegt in der Regressionsprävention. Ein `aria-label`, das beim Refactoring stillschweigend entfernt wird, eine durch ein Komponentenupdate unterbrochene Überschriftenreihenfolge, ein Orientierungspunkt, der nach einer Layout-Änderung verschwindet — automatisiertes Scannen erkennt diese stillen Regressionen, bevor sie die Produktion erreichen.

Doch Studien setzen die Erkennungsrate konsistent bei dreißig bis siebenundfünfzig Prozent echter WCAG-Verstöße an. Deque, das Unternehmen hinter axe, schätzt, dass ihr Tool auf real auditierten Seiten etwa 57 % erkennt. Das W3C stuft nur 20–30 % der WCAG-Erfolgskriterien als vollständig automatisierbar ein. Das ist kein Pessimismus — es ist eine präzise Beschreibung dessen, was DOM-Analyse leisten kann und was sie strukturell nicht kann.

## Die Lücken, die in der Praxis am meisten zählen

Die Lücken sind nicht zufällig. Sie konzentrieren sich auf drei Bereiche: kontextabhängige Bedeutung, dynamische Zustände und Fokusmanagement.

**Kontext und Bedeutung.** Ein Link mit dem Text „Mehr lesen" besteht jede strukturelle Prüfung. Ein Screenreader-Nutzer, der per Link navigiert, hört „Mehr lesen" ohne jeglichen umgebenden Kontext. Axe prüft Vorhandensein und Format — nicht ob der Text isoliert gelesen sinnvoll ist. Das gilt ebenso für Alt-Texte. `alt="Bild"` ist als generisch erkennbar. `alt="lächelnde Person"` besteht ohne Beanstandung, auch wenn es nichts Nützliches über die Rolle des Bildes auf der Seite aussagt.

**Dynamischer Zustand.** Ein Theme-Schalter mit der Bezeichnung „Zum Dunkelmodus wechseln" besteht Prüfungen. Aber wenn die Seite bereits im Dunkelmodus ist, ist das Label faktisch falsch. Automatisiertes Scannen wertet einen DOM-Snapshot zu einem einzelnen Zeitpunkt aus. Es kann nicht prüfen, ob ARIA-Labels bei Zustandsänderungen korrekt bleiben.

**Fokusmanagement.** Modale sind ein klassischer Problemfall. Statische DOM-Analyse bestätigt, dass `role="dialog"` vorhanden ist. Sie kann aber nicht testen, ob der Fokus beim Öffnen ins Modal wandert, ob Tab darin gefangen bleibt oder ob der Fokus beim Schließen zum auslösenden Element zurückkehrt. Strukturell sieht alles korrekt aus. Für Tastaturnutzer kann das Modal jedoch völlig unerreichbar sein.

## Was Playwright testen kann, wo axe versagt

Die Grenze zwischen axe und Playwright geht nicht nur um axe's Einschränkungen — es geht darum, was Playwright ermöglicht, was axe nie bieten kann: Interaktion. Axe nach dem Auslösen bestimmter Zustände auszuführen schließt einen erheblichen Teil der Lücke.

Kontrast im Hover- und Fokuszustand:

```ts
await page.getByRole('button', {name: 'Abonnieren'}).hover()
const results = await new AxeBuilder({page}).analyze()
expect(results.violations).toEqual([])
```

Dunkelmodus-Scan, der ein völlig anderer Farbkontext als der Standard-Scan ist:

```ts
await page.emulateMedia({colorScheme: 'dark'})
await page.goto('/')
const results = await new AxeBuilder({page}).analyze()
expect(results.violations).toEqual([])
```

Dynamische ARIA-Labels, die sich mit dem Zustand ändern:

```ts
const toggle = page.getByRole('button', {name: /wechseln/i})
await expect(toggle).toHaveAttribute('aria-label', 'Zum Dunkelmodus wechseln')
await toggle.click()
await expect(toggle).toHaveAttribute('aria-label', 'Zum Hellmodus wechseln')
```

Fokus-Eingrenzung im Modal und Escape-Verhalten:

```ts
await page.getByRole('button', {name: 'Dialog öffnen'}).click()
for (let i = 0; i < 10; i++) {
	await page.keyboard.press('Tab')
	const isInsideDialog = await page.evaluate(
		() => document.activeElement?.closest('[role="dialog"]') !== null
	)
	expect(isInsideDialog).toBe(true)
}
await page.keyboard.press('Escape')
await expect(page.getByRole('dialog')).not.toBeVisible()
```

Skip-Link — ob er als erstes fokussierbares Element erscheint und ob er tatsächlich funktioniert:

```ts
await page.keyboard.press('Tab')
const focused = page.locator(':focus')
await expect(focused).toHaveAttribute('href', '#main-content')
await page.keyboard.press('Enter')
await expect(page).toHaveURL(/#main-content$/)
```

Das sind keine Randfälle. Theme-Schalter, Modale, Skip-Links und Farbschemata sind Standardbestandteile der meisten Produktionsanwendungen. Wenn Tests diese Interaktionszustände nicht abdecken, hat die Barrierefreiheits-Coverage echte Lücken — unabhängig davon, was der axe-Score zeigt.

## Was Automatisierung nicht ersetzen kann

Manche Kategorien haben keine automatisierte Lösung. Formularfehlermeldungen, die „Ungültige Eingabe" sagen, ohne zu erklären, was falsch ist. Pflichtfelder, die nur durch ein rotes Sternchen ohne Textlabel gekennzeichnet sind. Lange Formulare, bei denen Fehlermeldungen oben erscheinen, der Fokus aber nicht dorthin wandert.

Nichts davon scheitert an strukturellen Prüfungen. Alles davon schafft echte Barrieren für reale Nutzer.

Der praktische Ansatz ist, automatisiertes Scannen als Boden zu behandeln, nicht als Decke. Es bietet Regressions-Coverage und prüft jede Seite bei jedem CI-Run — zwei Dinge, die manuelles Testen in diesem Umfang nicht leisten kann. Aber der Screenreader-Durchgang, die reine Tastaturnavigation, die Bewertung ob Fehlermeldungen wirklich hilfreich sind — diese bleiben notwendig, unabhängig davon, was der automatisierte Bericht zeigt.

## Zusammenfassung

- Automatisiertes Scannen bei jedem CI-Build ausführen — es erkennt strukturelle Regressionen zuverlässig
- Über den Standard-Scan hinausgehen — Hover-, Fokus-, Dunkelmodus- und interaktive Zustände vor axe auslösen
- Dynamische ARIA-Labels, modale Fokus-Eingrenzung und Skip-Link-Verhalten direkt in Playwright testen
- Kontextabhängige Bedeutung, Formularnutzbarkeit und Screenreader-Erfahrung erfordern menschliches Urteil

Ein bestandener axe-Scan ist ein Ausgangspunkt. Ob das Produkt für echte Nutzer tatsächlich barrierefrei ist, ist eine andere Frage — und eine, die sich durch DOM-Analyse allein nicht beantworten lässt.

Axe und Lighthouse erkennen etwa 30–57 % echter WCAG-Verstöße. Was sie übersehen und wie Playwright-Tests mehr als nur den Standard-Scan abdecken können.

Was Playwright-Barrierefreiheitstests wirklich abdecken | sw-tester.cz

Was automatisierte Barrierefreiheitstests wirklich abdecken — und was ihnen entgeht

# What automated accessibility tests actually cover — and what they miss

There is a pattern that appears in projects with solid CI coverage: all Playwright tests pass, axe finds no violations, Lighthouse gives an accessibility score above ninety. Then a real user with a screen reader opens the page and cannot complete a basic task.

This is not a failure of the tools. It is a misunderstanding of what they were built to do.

## What automated scanning is reliably good at

Axe-core and Lighthouse catch structural violations well. Missing `alt` attributes, forms without labels, invalid ARIA roles, colour contrast failures on static text — these are detectable by reading the DOM and comparing it against known rules. Worth running on every CI build, and worth taking seriously when they fire.

The real value is regression prevention. An `aria-label` quietly removed during a refactor, a heading order broken by a component update, a landmark that disappears after a layout change — automated scanning catches these silent regressions before they reach production. That is not a small thing.

But research consistently puts the detection ceiling somewhere between thirty and fifty-seven percent of real WCAG violations. Deque, the company that builds axe, estimates their tool catches around 57% on real-world audited pages. W3C places only 20–30% of WCAG success criteria as fully automatable. This is not pessimism — it is a precise description of what DOM-level scanning can evaluate and what it structurally cannot.

## The gaps that matter most in practice

The gaps are not random. They cluster around three areas: context-dependent meaning, dynamic state, and focus management.

**Context and meaning.** A link that reads "Read more" passes every structural check. A screen reader user navigating by links hears "Read more" with no surrounding context. Axe validates presence and format — not whether the text is meaningful when read in isolation. The same applies to alt text. `alt="image"` is detectable as generic. `alt="person smiling"` passes without question, even if it describes nothing useful about what the image contributes to the page.

**Dynamic state.** A theme toggle labeled "Switch to dark mode" passes checks. But if the page is already in dark mode, the label is factually wrong. Automated scanning evaluates a snapshot of the DOM at a single moment. It cannot verify that ARIA labels stay accurate as state changes.

**Focus management.** Modals are a classic failure point. Static DOM scanning confirms that `role="dialog"` is present. It cannot test whether focus moves into the modal when it opens, whether Tab is trapped inside, or whether focus returns to the trigger when the modal closes. From a structural perspective, everything looks fine. From a keyboard user's perspective, the modal may be completely unreachable.

## What Playwright can test that axe can't

The boundary between axe and Playwright is not just about axe's limits — it is about what Playwright enables that axe can never provide: interaction. Running axe after triggering specific states closes a significant part of the gap.

Hover and focus state contrast:

```ts
await page.getByRole('button', {name: 'Subscribe'}).hover()
const results = await new AxeBuilder({page}).analyze()
expect(results.violations).toEqual([])
```

Dark mode scanning, which is a completely separate colour context from the default scan:

```ts
await page.emulateMedia({colorScheme: 'dark'})
await page.goto('/')
const results = await new AxeBuilder({page}).analyze()
expect(results.violations).toEqual([])
```

Dynamic ARIA labels that change with state:

```ts
const toggle = page.getByRole('button', {name: /switch to/i})
await expect(toggle).toHaveAttribute('aria-label', 'Switch to dark mode')
await toggle.click()
await expect(toggle).toHaveAttribute('aria-label', 'Switch to light mode')
```

Modal focus trapping and Escape key behaviour:

```ts
await page.getByRole('button', {name: 'Open dialog'}).click()
for (let i = 0; i < 10; i++) {
	await page.keyboard.press('Tab')
	const isInsideDialog = await page.evaluate(
		() => document.activeElement?.closest('[role="dialog"]') !== null
	)
	expect(isInsideDialog).toBe(true)
}
await page.keyboard.press('Escape')
await expect(page.getByRole('dialog')).not.toBeVisible()
```

Skip link — whether it appears as the first focusable element and whether it actually works:

```ts
await page.keyboard.press('Tab')
const focused = page.locator(':focus')
await expect(focused).toHaveAttribute('href', '#main-content')
await page.keyboard.press('Enter')
await expect(page).toHaveURL(/#main-content$/)
```

None of these are edge cases. Theme toggles, modals, skip links, and colour schemes are standard parts of most production applications. If tests do not cover these interaction states, the accessibility coverage has real gaps regardless of what the axe score shows.

## What automation cannot replace

Some categories have no automated solution. Form error messages that say "Invalid input" without specifying what is wrong. Required fields indicated only by a red asterisk with no text label. Long forms where error announcements appear at the top but focus does not move there, leaving keyboard users to search.

None of these fail structural checks. All of them create genuine barriers for real users.

The practical approach is to treat automated scanning as a floor, not a ceiling. It provides regression coverage and evaluates every page on every CI run — two things that manual testing cannot do at that scale. But the screen reader walk-through, the keyboard-only navigation session, the evaluation of whether error messages are actually helpful — these remain necessary regardless of what the automated report shows.

## Summary

- Run automated scanning on every CI build: it reliably catches structural regressions
- Extend beyond the default scan — trigger hover, focus, dark mode, and interactive states before running axe
- Test dynamic ARIA labels, modal focus trapping, and skip link behaviour directly in Playwright
- Context-dependent meaning, form usability, and screen reader experience require human judgement

A passing axe score is a starting point. Whether the product is actually accessible to real users is a different question, and one that requires more than DOM analysis to answer.

Axe and Lighthouse catch roughly 30–57% of real WCAG violations. Here is what they miss, and how Playwright tests can cover more than just the default scan.

What Playwright accessibility tests actually cover | sw-tester.cz

What automated accessibility tests actually cover — and what they miss

# Qué cubren realmente las pruebas automatizadas de accesibilidad — y qué se les escapa

En proyectos con buena cobertura de CI se repite un patrón: todos los tests de Playwright pasan, axe no encuentra violaciones, Lighthouse otorga una puntuación de accesibilidad por encima de noventa. Luego llega un usuario real con un lector de pantalla, abre la página y no puede completar una tarea básica.

Esto no es un fallo de las herramientas. Es una incomprensión de para qué fueron diseñadas.

## En qué es realmente fiable el análisis automatizado

Axe-core y Lighthouse detectan bien las violaciones estructurales. Atributos `alt` faltantes, formularios sin etiquetas, roles ARIA inválidos, contraste de color insuficiente en texto estático — todo esto es detectable leyendo el DOM y comparándolo con reglas conocidas. Vale la pena ejecutarlos en cada build de CI y tomar los resultados en serio.

El valor real está en la prevención de regresiones. Un `aria-label` eliminado silenciosamente durante un refactoring, un orden de encabezados roto tras la actualización de un componente, un punto de referencia que desaparece después de un cambio de layout — el análisis automatizado detecta estas regresiones silenciosas antes de que lleguen a producción. Eso no es poca cosa.

Sin embargo, la investigación sitúa consistentemente el techo de detección entre el treinta y el cincuenta y siete por ciento de las violaciones WCAG reales. Deque, la empresa detrás de axe, estima que su herramienta detecta alrededor del 57 % en páginas auditadas en el mundo real. El W3C clasifica solo el 20–30 % de los criterios de éxito de las WCAG como completamente automatizables. Esto no es pesimismo — es una descripción precisa de lo que el análisis a nivel de DOM puede evaluar y lo que estructuralmente no puede.

## Las brechas que más importan en la práctica

Las brechas no son aleatorias. Se agrupan en tres áreas: significado dependiente del contexto, estado dinámico y gestión del foco.

**Contexto y significado.** Un enlace que dice "Leer más" supera todas las comprobaciones estructurales. Un usuario de lector de pantalla que navega por enlaces escucha "Leer más" sin ningún contexto circundante. Axe valida presencia y formato — no si el texto es significativo leído de forma aislada. Lo mismo aplica al texto alternativo. `alt="imagen"` es detectable como genérico. `alt="persona sonriendo"` pasa sin problemas, aunque no diga nada útil sobre el papel de la imagen en la página.

**Estado dinámico.** Un botón de cambio de tema etiquetado "Cambiar al modo oscuro" supera las comprobaciones. Pero si la página ya está en modo oscuro, la etiqueta es factualmente incorrecta. El análisis automatizado evalúa un snapshot del DOM en un único momento. No puede verificar que las etiquetas ARIA sigan siendo precisas a medida que cambia el estado.

**Gestión del foco.** Los modales son un punto de fallo clásico. El análisis estático del DOM confirma que `role="dialog"` está presente. No puede probar si el foco se mueve al modal cuando se abre, si Tab queda atrapado dentro, o si el foco regresa al elemento desencadenante cuando el modal se cierra. Desde una perspectiva estructural, todo parece correcto. Desde la perspectiva de un usuario de teclado, el modal puede ser completamente inalcanzable.

## Lo que Playwright puede probar donde axe no llega

La frontera entre axe y Playwright no es solo sobre las limitaciones de axe — es sobre lo que Playwright permite y que axe nunca puede proporcionar: interacción. Ejecutar axe después de activar estados específicos cierra una parte significativa de la brecha.

Contraste en estado hover y focus:

```ts
await page.getByRole('button', {name: 'Suscribirse'}).hover()
const results = await new AxeBuilder({page}).analyze()
expect(results.violations).toEqual([])
```

Análisis del modo oscuro, que es un contexto de color completamente diferente al análisis predeterminado:

```ts
await page.emulateMedia({colorScheme: 'dark'})
await page.goto('/')
const results = await new AxeBuilder({page}).analyze()
expect(results.violations).toEqual([])
```

Etiquetas ARIA dinámicas que cambian con el estado:

```ts
const toggle = page.getByRole('button', {name: /cambiar/i})
await expect(toggle).toHaveAttribute('aria-label', 'Cambiar al modo oscuro')
await toggle.click()
await expect(toggle).toHaveAttribute('aria-label', 'Cambiar al modo claro')
```

Trampa de foco en modal y comportamiento de la tecla Escape:

```ts
await page.getByRole('button', {name: 'Abrir diálogo'}).click()
for (let i = 0; i < 10; i++) {
	await page.keyboard.press('Tab')
	const isInsideDialog = await page.evaluate(
		() => document.activeElement?.closest('[role="dialog"]') !== null
	)
	expect(isInsideDialog).toBe(true)
}
await page.keyboard.press('Escape')
await expect(page.getByRole('dialog')).not.toBeVisible()
```

Skip link — si aparece como el primer elemento enfocable y si realmente funciona:

```ts
await page.keyboard.press('Tab')
const focused = page.locator(':focus')
await expect(focused).toHaveAttribute('href', '#main-content')
await page.keyboard.press('Enter')
await expect(page).toHaveURL(/#main-content$/)
```

Estos no son casos extremos. Los botones de cambio de tema, los modales, los skip links y los esquemas de color son partes estándar de la mayoría de las aplicaciones en producción. Si las pruebas no cubren estos estados de interacción, la cobertura de accesibilidad tiene brechas reales independientemente de lo que muestre la puntuación de axe.

## Lo que la automatización no puede reemplazar

Algunas categorías no tienen solución automatizada. Mensajes de error de formularios que dicen "Entrada no válida" sin especificar qué está mal. Campos obligatorios indicados solo por un asterisco rojo sin etiqueta de texto. Formularios largos donde los anuncios de error aparecen en la parte superior pero el foco no se mueve allí, dejando a los usuarios de teclado buscando.

Nada de esto falla en las comprobaciones estructurales. Todo ello crea barreras genuinas para usuarios reales.

El enfoque práctico es tratar el análisis automatizado como un suelo, no como un techo. Proporciona cobertura de regresiones y evalúa cada página en cada ejecución de CI — dos cosas que las pruebas manuales no pueden hacer a esa escala. Pero el recorrido con lector de pantalla, la sesión de navegación solo con teclado, la evaluación de si los mensajes de error son realmente útiles — estos siguen siendo necesarios independientemente de lo que muestre el informe automatizado.

## Resumen

- Ejecutar el análisis automatizado en cada build de CI: detecta regresiones estructurales de forma fiable
- Ir más allá del análisis predeterminado — activar estados hover, focus, modo oscuro e interactivos antes de ejecutar axe
- Probar etiquetas ARIA dinámicas, trampa de foco en modales y comportamiento del skip link directamente en Playwright
- El significado dependiente del contexto, la usabilidad de formularios y la experiencia con lector de pantalla requieren juicio humano

Superar un análisis de axe es un punto de partida. Si el producto es realmente accesible para usuarios reales es una pregunta diferente — y una que no puede responderse solo con análisis del DOM.

Axe y Lighthouse detectan entre el 30 y el 57 % de las violaciones WCAG reales. Qué se pierden y cómo ampliar las pruebas de Playwright más allá del análisis predeterminado.

Qué cubren realmente las pruebas de accesibilidad en Playwright | sw-tester.cz

Qué cubren realmente las pruebas automatizadas de accesibilidad — y qué se les escapa

# Jak kombinovat AI a lidské QA (a proč samotná automatizace nestačí)

AI v testování je dnes skoro všude. Generuje testy, analyzuje výsledky a pomáhá ve chvíli, kdy je potřeba rychle zpracovat velké množství běhů v CI pipeline. Na první pohled to může působit, že jsme velmi blízko stavu, kdy bude možné QA téměř plně automatizovat.

Jenže právě týmy, které AI nasadily nejdřív, poměrně rychle narazily na stejný limit. Testy běží, reporty existují, dashboardy vypadají dobře, ale důvěra ve výsledek chybí. A bez důvěry není automatizace oporou pro release rozhodnutí, jen další vrstvou technického provozu.

## Když test projde, ale produkt je rozbitý

Typický problém není v tom, že by test nic neověřoval. Problém je v tom, že často ověřuje jen to, co je snadno měřitelné. Tlačítko jde kliknout, stránka se otevře, potvrzovací krok se zobrazí. Z pohledu automatizace všechno vypadá správně.

Ve skutečnosti ale může být výsledek byznysově špatně. Částka je špatně zaokrouhlená, backend poslal chybnou hodnotu, data se propsala do nesprávného účtu nebo se porušila pravidla, která nejsou vidět na první pohled v UI. Test prošel, ale kvalita produktu ne.

Právě tady se ukazuje rozdíl mezi kontrolou povrchu a skutečným ověřením kvality. AI i automatizace obecně velmi dobře zvládají opakovat známé kroky. Mnohem hůř ale rozpoznávají, jestli systém ve skutečnosti dělá správnou věc.

## Kde AI funguje výborně

AI má v QA reálné a praktické místo. Ne proto, že by rozuměla produktu lépe než člověk, ale protože výrazně zrychluje práci v oblastech, kde je potřeba škála, opakovatelnost a rychlé třídění dat.

- spouštění testů ve velkém objemu
- opakování flaky běhů a porovnávání výsledků
- seskupování podobných chyb
- hledání patternů, anomálií a podezřelých odchylek
- rychlejší orientace v trace, logách a opakujících se selháních

V těchto situacích AI skutečně šetří čas. Pomáhá týmu rychleji dojít k místu, kde má smysl začít problém řešit.

## Kde AI nestačí

Stejně důležité je ale vědět, kde AI nestačí. Nejslabší není v rychlosti, ale v interpretaci.

AI sama nerozhodne, jestli je chyba kritická pro release. Nechápe obchodní dopad změny v konkrétním produktu tak, jako ho chápe QA, vývoj nebo produktový tým. Neumí spolehlivě posoudit, jestli je problém skutečný bug, accepted risk, flaky test nebo jen vedlejší symptom jiné chyby.

Ještě výrazněji se to ukazuje u kreativního testování. Tam, kde je potřeba změnit perspektivu, zkusit nečekanou kombinaci kroků nebo si položit otázku, co se stane v nestandardní situaci, zůstává lidský přístup zásadní.

## Human-in-the-loop jako praktický model

Proto dává v moderním QA největší smysl model human-in-the-loop. Ne jako kompromis mezi starým a novým světem, ale jako realistické rozdělení práce podle toho, co která strana umí nejlépe.

AI zajišťuje škálu. Spouští testy, třídí výsledky, zvýrazňuje podezřelé stavy a pomáhá týmu dostat se rychleji k podstatě. Člověk naopak přináší kontext. Chápe produkt, interpretuje dopad a rozhoduje, co má následovat dál.

Jinými slovy: AI umí říct, že se něco stalo. Člověk rozhoduje, co to znamená.

## Proč samotná plná automatizace selhává

Myšlenka, že AI jednou otestuje všechno, zní lákavě. V praxi ale naráží na to, že velká část automatizovaných kontrol je příliš mělká. Assertions často ověřují jen viditelné změny, ne skutečný záměr produktu. Pipeline pak může běžet rychle, generovat čisté reporty a přesto neposkytovat jistotu, že release je opravdu bezpečný.

To je důvod, proč se i ve velmi automatizovaných týmech nakonec stejně vrací ruční ověřování. Ne proto, že by automatizace byla zbytečná, ale proto, že bez lidské validace není kompletní.

## Exploratory testing zůstává lidská disciplína

Nejcennější bugy často nevznikají v předem připraveném scénáři. Vznikají ve chvíli, kdy někdo klikne ve špatný okamžik, vrátí se uprostřed flow zpět, zkombinuje dva kroky, které spolu běžně nikdo nekombinuje, nebo si všimne detailu, který se do předem napsaného testu vůbec nedostal.

Tohle není jen otázka techniky. Je to způsob myšlení. Exploratory testing stojí na intuici, zkušenosti a schopnosti pochopit, kde je produkt zranitelný. A právě proto je to oblast, kde AI zatím zůstává spíš pomocníkem než náhradou.

## Jak to vypadá v reálném workflow

Dobře nastavený QA systém dnes obvykle nevypadá jako nahrazení člověka, ale jako spolupráce. V praxi to může znamenat třeba to, že automatizovaná vrstva v Playwright stacku běží testy napříč regiony a browsery, AI seskupí podobná selhání a upozorní na podezřelé patterny, zatímco člověk otevře trace, podívá se na requesty a rozhodne, jestli jde o bug, flaky chování nebo infrastrukturní problém.

Takové workflow dává smysl právě proto, že obě strany řeší jiný typ práce. AI zkracuje čas k nálezu. Člověk dává výsledku význam.

## Největší chyba je slepá důvěra

Jedna z nejnebezpečnějších vět v moderním QA zní: „AI to otestovala, tak je to v pohodě.“ Ve chvíli, kdy se automatizovaný výstup začne brát jako zdroj pravdy bez další interpretace, vzniká iluze kvality. A ta bývá nebezpečnější než přiznaná nejistota.

AI není náhrada za úsudek. Je to nástroj, který dokáže výrazně pomoci, pokud je zasazený do správného systému rozhodování.

## Co z toho plyne pro QA dnes

Budoucnost QA nestojí na tom, že AI nahradí testery. Stojí na tom, že převezme rutinu, zrychlí analýzu a umožní týmu věnovat víc energie tomu, co je skutečně důležité: kontextu, prioritám a rozhodování o kvalitě produktu.

To je důvod, proč kombinace AI a lidského QA není přechodná fáze. Je to praktický model, který odpovídá realitě dnešních produktových týmů.

## Shrnutí

- AI zrychluje testovací operace a práci s daty
- člověk přináší kontext, interpretaci a odpovědnost
- samotná automatizace bez lidské validace nevytváří důvěru
- human-in-the-loop je dnes nejpraktičtější cesta k udržitelnému QA

Pokud má QA fungovat i za pár let, nebude rozhodovat to, kolik automatizace tým má. Rozhodovat bude to, jestli je správně rozdělená práce mezi systém a člověka.

Jak kombinovat AI a lidské QA v praxi: co AI zvládá dobře, kde selhává a proč human-in-the-loop dává v moderním testování největší smysl.

AI a lidské QA | Proč samotná automatizace nestačí

Jak kombinovat AI a lidské QA (a proč samotná automatizace nestačí)

# Wie sich KI und menschliches QA kombinieren lassen (und warum reine Automatisierung nicht reicht)

KI ist im Testing heute fast überall. Sie generiert Tests, analysiert Ergebnisse und hilft dabei, große Mengen an Läufen in CI-Pipelines schneller auszuwerten. Auf den ersten Blick wirkt es so, als sei vollständig automatisiertes QA endlich in greifbarer Nähe.

Die Realität sieht jedoch anders aus. Teams, die KI früh eingeführt haben, sind schnell auf dieselbe Grenze gestoßen. Tests laufen, Reports existieren, Dashboards sehen gut aus, aber das Vertrauen in das Ergebnis fehlt. Und ohne Vertrauen ist Automatisierung keine verlässliche Grundlage für Release-Entscheidungen.

## Wenn der Test grün ist, aber das Produkt trotzdem fehlerhaft

Das Kernproblem ist meist nicht, dass der Test gar nichts prüft. Das Problem ist, dass er oft nur überprüft, was sich leicht messen lässt. Ein Button lässt sich klicken, eine Seite öffnet sich, der Bestätigungsschritt erscheint. Aus Sicht der Automatisierung wirkt alles korrekt.

Im Business-Kontext kann das Ergebnis trotzdem falsch sein. Ein Betrag wird falsch gerundet, das Backend liefert einen falschen Wert, Daten landen im falschen Konto oder eine Produktregel wird verletzt, ohne dass es im UI sofort sichtbar wird. Der Test ist grün, die Produktqualität aber nicht.

Hier zeigt sich der Unterschied zwischen Oberflächenkontrolle und echter Qualitätsvalidierung. KI und Automatisierung sind hervorragend darin, bekannte Schritte zu wiederholen. Viel schwächer sind sie darin zu erkennen, ob das System tatsächlich das Richtige tut.

## Wo KI wirklich stark ist

KI hat im QA einen klaren praktischen Nutzen. Nicht weil sie das Produkt besser versteht als Menschen, sondern weil sie skalierbare, wiederholbare Arbeit deutlich beschleunigt.

- Tests in großem Umfang ausführen
- flaky Läufe erneut starten und Ergebnisse vergleichen
- ähnliche Fehler gruppieren
- Muster, Anomalien und auffällige Abweichungen erkennen
- Teams schneller durch Traces, Logs und wiederkehrende Fehler führen

Genau in diesen Bereichen spart KI echte Zeit. Sie bringt das Team schneller an den Punkt, an dem eine sinnvolle Untersuchung beginnen kann.

## Wo KI an Grenzen stößt

Genauso wichtig ist es zu verstehen, wo KI nicht ausreicht. Ihre größte Schwäche ist nicht Geschwindigkeit, sondern Interpretation.

KI entscheidet nicht zuverlässig, ob ein Defekt release-kritisch ist. Sie versteht die fachliche Auswirkung in einem konkreten Produkt nicht so wie QA, Entwicklung oder Produktverantwortliche. Sie kann nicht verlässlich unterscheiden, ob es sich um einen echten Bug, ein akzeptiertes Risiko, einen flaky Test oder nur um ein Symptom eines anderen Problems handelt.

Noch deutlicher wird das im kreativen Testen. Überall dort, wo Perspektivwechsel, unerwartete Kombinationen oder ungewöhnliche Abläufe notwendig sind, bleibt menschliche Arbeit zentral.

## Human-in-the-loop als praktikables Modell

Genau deshalb ist Human-in-the-loop im modernen QA der sinnvollste Ansatz. Nicht als Kompromiss zwischen alt und neu, sondern als bewusste Arbeitsteilung nach Stärken.

KI übernimmt die Skalierung. Sie führt Tests aus, verarbeitet Ergebnisse, markiert verdächtige Zustände und verkürzt den Weg durch große Datenmengen. Menschen bringen Kontext ein. Sie verstehen das Produkt, interpretieren Auswirkungen und entscheiden, was als Nächstes passieren muss.

Kurz gesagt: KI kann melden, dass etwas passiert ist. Menschen entscheiden, was es bedeutet.

## Warum vollständige Automatisierung scheitert

Die Vorstellung, dass KI irgendwann alles testet, klingt attraktiv. In der Praxis scheitert sie daran, dass viele automatisierte Checks zu oberflächlich bleiben. Assertions prüfen häufig sichtbare Änderungen, aber nicht die eigentliche Produktabsicht. Pipelines können schnell laufen, saubere Reports erzeugen und trotzdem keine echte Release-Sicherheit schaffen.

Deshalb kehren selbst stark automatisierte Teams am Ende wieder zur manuellen Validierung zurück. Nicht weil Automatisierung nutzlos wäre, sondern weil sie ohne menschliche Bewertung unvollständig bleibt.

## Exploratory Testing bleibt menschlich

Die wertvollsten Bugs entstehen selten in vollständig vorbereiteten Szenarien. Sie entstehen, wenn jemand im falschen Moment klickt, mitten im Flow zurückgeht, unerwartete Schritte kombiniert oder ein Detail bemerkt, das nie in einen vorgeplanten Test aufgenommen wurde.

Das ist nicht nur Technik, sondern Denkweise. Exploratory Testing lebt von Intuition, Erfahrung und dem Blick für Schwachstellen. Genau deshalb bleibt diese Disziplin auch mit KI stark menschlich geprägt.

## Wie das in einem realen Workflow aussieht

Ein gut aufgebautes QA-System sieht heute meist eher nach Zusammenarbeit als nach Ersatz aus. Praktisch kann das bedeuten, dass ein automatisierter Playwright-Stack Tests über Browser und Regionen hinweg ausführt, KI ähnliche Fehler gruppiert und auffällige Muster markiert, während ein Mensch den Trace öffnet, Requests prüft und entscheidet, ob es sich um einen Bug, flaky Verhalten oder ein Infrastrukturproblem handelt.

Dieses Modell funktioniert, weil beide Seiten unterschiedliche Arten von Arbeit übernehmen. KI verkürzt die Zeit bis zur Erkenntnis. Menschen geben dem Ergebnis Bedeutung und Richtung.

## Der größte Fehler ist blindes Vertrauen

Eine der gefährlichsten Aussagen im modernen QA lautet: „Die KI hat es getestet, also ist alles in Ordnung.“ In dem Moment, in dem automatisierter Output ohne Interpretation zur Wahrheit erklärt wird, entsteht eine Illusion von Qualität. Und diese Illusion ist oft gefährlicher als offen eingestandene Unsicherheit.

KI ersetzt kein Urteilsvermögen. Sie ist ein Werkzeug, das nur dann wirklich nützlich wird, wenn es in ein gutes Entscheidungssystem eingebettet ist.

## Was das heute für QA bedeutet

Die Zukunft von QA besteht nicht darin, dass KI Tester ersetzt. Sie besteht darin, dass KI Routinearbeit übernimmt, Analysen beschleunigt und Teams mehr Zeit für das gibt, was wirklich zählt: Kontext, Priorisierung und Entscheidungen über Produktqualität.

Darum ist die Kombination aus KI und menschlichem QA keine Übergangsphase. Sie ist ein realistisches Modell für die Art, wie moderne Produktteams arbeiten.

## Zusammenfassung

- KI beschleunigt Testbetrieb und datenintensive Arbeit
- Menschen liefern Kontext, Interpretation und Verantwortung
- Automatisierung allein schafft keine belastbare Sicherheit
- Human-in-the-loop ist heute das nachhaltigste QA-Modell

Wenn QA in den kommenden Jahren gut funktionieren soll, ist nicht entscheidend, wie viel Automatisierung ein Team besitzt. Entscheidend ist, wie gut die Arbeit zwischen System und menschlichem Urteil aufgeteilt ist.

Wie sich KI und menschliches QA sinnvoll kombinieren lassen: wo KI stark ist, wo sie an Grenzen stößt und warum Human-in-the-loop für modernes Testing am praktikabelsten ist.

KI und menschliches QA | Warum Automatisierung allein nicht reicht

Wie sich KI und menschliches QA kombinieren lassen (und warum reine Automatisierung nicht reicht)

# How to combine AI and human QA (and why automation alone is not enough)

AI is now everywhere in testing. It generates tests, analyses results and helps process large numbers of runs in CI pipelines. At first glance, it can feel like fully automated QA is finally within reach.

But teams that adopted AI early ran into the same limit very quickly. Tests run, reports exist, dashboards look convincing, yet trust in the outcome is still missing. And without trust, automation is not a release decision tool. It is just another operational layer.

## When the test passes but the product is still broken

The usual problem is not that the test checks nothing. It is that it often checks only what is easy to measure. A button can be clicked, a page opens, a confirmation step appears. From the automation point of view, everything looks correct.

In reality, the business outcome can still be wrong. The amount is rounded incorrectly, the backend sends the wrong value, data is applied to the wrong account, or a product rule is violated in a way that is not visible in the UI. The test passed, but the product quality did not.

That is where the difference between checking the surface and validating actual quality becomes obvious. AI and automation are excellent at repeating known steps. They are far weaker at recognising whether the system is doing the right thing.

## Where AI works really well

AI has a real place in QA, not because it understands the product better than humans, but because it makes large-scale, repetitive work much faster.

- running tests at scale
- rerunning flaky checks and comparing outcomes
- grouping similar failures
- spotting patterns, anomalies and suspicious deviations
- helping teams navigate traces, logs and repeated failures faster

In those areas, AI genuinely saves time. It helps teams get to the point where real investigation begins.

## Where AI still falls short

It is just as important to understand where AI does not help enough. Its biggest weakness is not speed, but interpretation.

AI does not reliably decide whether a defect is critical for release. It does not understand business impact in a specific product the way QA, engineering or product people do. It cannot consistently tell whether something is a real bug, an accepted risk, a flaky test or a side effect of another issue.

The limit is even clearer in creative testing. Wherever it is necessary to shift perspective, try unexpected combinations or ask what happens in edge situations, the human role is still fundamental.

## Human-in-the-loop is the practical model

That is why human-in-the-loop is the most useful model in modern QA. Not as a compromise between old and new, but as a practical split of work based on what each side does best.

AI handles scale. It runs tests, processes outputs, highlights suspicious states and shortens the path to the right place in the data. Humans bring context. They understand the product, interpret impact and decide what should happen next.

In simple terms: AI can tell you that something happened. A human decides what it means.

## Why fully automated QA keeps failing

The idea that AI will eventually test everything sounds attractive. In practice, it runs into the fact that many automated checks are too shallow. Assertions often validate visible changes, not actual product intent. Pipelines can run fast, produce clean reports and still fail to create confidence that a release is safe.

That is why even highly automated teams still return to manual validation. Not because automation is useless, but because without human validation it remains incomplete.

## Exploratory testing is still deeply human

The most valuable bugs rarely appear in fully scripted scenarios. They appear when someone clicks at the wrong moment, goes back in the middle of a flow, combines steps no one expected to combine, or notices a detail that never made it into a predefined test.

That is not just technique. It is a way of thinking. Exploratory testing depends on intuition, experience and the ability to see where the product is vulnerable. That is why AI still acts more as an assistant here than a replacement.

## What this looks like in a real workflow

A well-designed QA system today usually looks more like collaboration than replacement. In practice, that can mean an automated Playwright stack running checks across browsers and regions, AI grouping similar failures and highlighting suspicious patterns, while a human opens the trace, inspects requests and decides whether the issue is a bug, flaky behaviour or an infrastructure problem.

That workflow works because each side solves a different kind of problem. AI reduces the time to insight. Humans provide meaning and decision-making.

## The biggest mistake is blind trust

One of the most dangerous sentences in modern QA is: “AI tested it, so it must be fine.” The moment automated output is treated as a source of truth without interpretation, testing turns into an illusion of quality. And that illusion is often more dangerous than admitted uncertainty.

AI is not a substitute for judgement. It is a tool that becomes powerful only when it is part of the right decision-making system.

## What this means for QA now

The future of QA is not about AI replacing testers. It is about AI taking over routine work, accelerating analysis and allowing teams to spend more time on what matters most: context, priorities and release decisions.

That is why combining AI with human QA is not a temporary transition. It is a practical operating model that fits how product teams actually work.

## Summary

- AI speeds up testing operations and data-heavy work
- humans provide context, interpretation and responsibility
- automation alone does not create trust
- human-in-the-loop is the most sustainable QA model today

If QA is supposed to stay effective in the coming years, the key question will not be how much automation a team has. It will be how well work is divided between system and human judgement.

How to combine AI and human QA in practice: where AI works well, where it fails and why human-in-the-loop is the most useful model for modern testing.

AI and human QA | Why automation alone is not enough

How to combine AI and human QA (and why automation alone is not enough)

# Cómo combinar IA y QA humano (y por qué la automatización sola no basta)

La IA está hoy en casi todas partes dentro del testing. Genera tests, analiza resultados y ayuda a procesar grandes volúmenes de ejecuciones en pipelines de CI. A primera vista parece que el QA totalmente automatizado está por fin al alcance.

Sin embargo, los equipos que adoptaron IA antes se encontraron muy rápido con el mismo límite. Los tests corren, los reportes existen, los dashboards parecen convincentes, pero sigue faltando confianza en el resultado. Y sin confianza, la automatización no sirve como base real para decidir sobre un release.

## Cuando el test pasa pero el producto sigue roto

El problema habitual no es que el test no valide nada. El problema es que a menudo solo valida lo que resulta fácil medir. Se puede hacer clic en un botón, se abre una página, aparece el paso de confirmación. Desde el punto de vista de la automatización, todo parece correcto.

En realidad, el resultado de negocio puede seguir siendo incorrecto. Una cantidad se redondea mal, el backend envía un valor erróneo, los datos se aplican a la cuenta equivocada o se rompe una regla del producto sin que el fallo sea visible en la interfaz. El test pasó, pero la calidad del producto no.

Ahí es donde se ve la diferencia entre comprobar la superficie y validar de verdad la calidad. La IA y la automatización son excelentes repitiendo pasos conocidos. Son mucho más débiles cuando se trata de detectar si el sistema está haciendo lo correcto.

## Dónde la IA funciona muy bien

La IA tiene un lugar real dentro de QA. No porque entienda el producto mejor que las personas, sino porque acelera mucho el trabajo repetitivo y a gran escala.

- ejecutar tests a gran escala
- relanzar checks flaky y comparar resultados
- agrupar fallos similares
- detectar patrones, anomalías y desviaciones sospechosas
- ayudar a navegar más rápido por traces, logs y errores repetidos

En esas áreas, la IA ahorra tiempo de verdad. Lleva al equipo antes al punto donde empieza la investigación útil.

## Dónde la IA se queda corta

Es igual de importante entender dónde la IA no basta. Su mayor debilidad no es la velocidad, sino la interpretación.

La IA no decide de forma fiable si un defecto es crítico para el release. No entiende el impacto de negocio en un producto concreto como lo entienden QA, desarrollo o producto. Tampoco distingue de forma consistente entre un bug real, un riesgo aceptado, un test flaky o un síntoma de otro problema.

El límite se ve todavía más claro en el testing creativo. Allí donde hace falta cambiar de perspectiva, probar combinaciones inesperadas o preguntarse qué pasa en situaciones límite, el papel humano sigue siendo esencial.

## Human-in-the-loop como modelo práctico

Por eso human-in-the-loop es hoy el modelo más útil en QA moderno. No como compromiso entre lo antiguo y lo nuevo, sino como reparto consciente del trabajo según fortalezas reales.

La IA se encarga de la escala. Ejecuta tests, procesa resultados, marca estados sospechosos y acorta el camino dentro de grandes volúmenes de datos. Las personas aportan contexto. Entienden el producto, interpretan el impacto y deciden qué hacer después.

En otras palabras: la IA puede decir que algo ocurrió. La persona decide qué significa.

## Por qué la automatización total falla

La idea de que la IA podrá testearlo todo suena atractiva. En la práctica choca con un problema: muchos checks automatizados son demasiado superficiales. Las assertions suelen validar cambios visibles, no la intención real del producto. Una pipeline puede correr rápido, producir reportes limpios y aun así no generar confianza real en el release.

Por eso incluso los equipos muy automatizados vuelven al final a la validación manual. No porque la automatización no sirva, sino porque sin validación humana queda incompleta.

## El exploratory testing sigue siendo humano

Los bugs más valiosos rara vez aparecen en escenarios completamente preparados. Aparecen cuando alguien hace clic en el momento incorrecto, vuelve atrás a mitad de un flujo, combina pasos que nadie esperaba combinar o detecta un detalle que nunca llegó a un test predefinido.

Eso no es solo técnica. Es una forma de pensar. El exploratory testing depende de intuición, experiencia y de la capacidad de ver dónde el producto es vulnerable. Por eso sigue siendo una disciplina fuertemente humana.

## Cómo se ve esto en un workflow real

Un sistema QA bien planteado hoy se parece más a una colaboración que a una sustitución. En la práctica puede significar que una capa automatizada en Playwright ejecuta tests en distintos browsers y regiones, la IA agrupa fallos parecidos y marca patrones sospechosos, mientras una persona abre el trace, revisa requests y decide si se trata de un bug, un comportamiento flaky o un problema de infraestructura.

Ese modelo funciona porque cada parte resuelve un tipo distinto de trabajo. La IA reduce el tiempo hasta el hallazgo. La persona aporta significado y decisión.

## El mayor error es la confianza ciega

Una de las frases más peligrosas en QA moderno es: “La IA ya lo probó, así que está bien”. En el momento en que el resultado automatizado se toma como fuente de verdad sin interpretación, el testing se convierte en una ilusión de calidad. Y esa ilusión suele ser más peligrosa que una incertidumbre reconocida.

La IA no sustituye el criterio. Es una herramienta que solo se vuelve realmente útil cuando forma parte de un sistema de decisión bien diseñado.

## Qué significa esto para QA hoy

El futuro de QA no consiste en que la IA reemplace a los testers. Consiste en que la IA asuma la rutina, acelere el análisis y deje al equipo más tiempo para lo importante: contexto, prioridades y decisiones sobre calidad de producto.

Por eso la combinación entre IA y QA humano no es una fase temporal. Es un modelo práctico que encaja con la realidad de los equipos de producto actuales.

## Resumen

- la IA acelera la operación de testing y el trabajo con datos
- las personas aportan contexto, interpretación y responsabilidad
- la automatización por sí sola no genera confianza real
- human-in-the-loop es hoy el modelo de QA más sostenible

Si QA quiere seguir funcionando bien en los próximos años, la cuestión no será cuánta automatización tiene un equipo. La cuestión será cómo reparte el trabajo entre sistema y criterio humano.

Cómo combinar IA y QA humano en la práctica: dónde la IA aporta valor, dónde falla y por qué human-in-the-loop es el modelo más útil para el testing moderno.

IA y QA humano | Por qué la automatización sola no basta

Cómo combinar IA y QA humano (y por qué la automatización sola no basta)

# Testování autentizace v Playwrightu (bez bolesti a flaky testů)

Autentizace patří k nejčastěji podceňovaným částem E2E testování. Na začátku vypadá jednoduše: přihlásíte se a pokračujete dál. Jakmile ale testovací sada začne růst, login se velmi rychle stane jedním z hlavních zdrojů nestability.

To je důvod, proč dává smysl brát autentizaci ne jako jeden technický krok navíc, ale jako součást celé testovací architektury. Pokud je navržená špatně, testy se zpomalují, padají v CI a navzájem se ovlivňují. Pokud je navržená dobře, naopak výrazně zvyšuje stabilitu celé sady.

## Proč bývá autentizace problém

Typické symptomy bývají podobné napříč projekty. Testy fungují lokálně, ale padají v CI. Session expiruje uprostřed běhu. Login se zbytečně opakuje v každém scénáři a celá sada je pomalá. Nebo si testy navzájem přepisují stav a chyba se objevuje jen občas.

To obvykle není izolovaný bug. Je to signál, že přihlášení bylo do testů přidané jen jako nutný krok, ale nebylo navržené jako samostatná vrstva.

## Nejpomalejší anti-pattern je login v každém testu

Nejčastější začátek vypadá zhruba takto:

```ts
test('user can open dashboard', async ({page}) => {
	await page.goto('/login')
	await page.fill('#email', 'test@test.com')
	await page.fill('#password', 'password')
	await page.click('button[type=submit]')
})
```

Pro několik prvních testů to funguje. Pro větší sadu ale takový přístup škáluje velmi špatně. Login je pomalý, opakuje se pořád dokola a každé zpomalení nebo drobná nestabilita v auth flow se okamžitě násobí přes celou regresní vrstvu.

## Praktický základ: storageState

Playwright naštěstí umožňuje uložit přihlášený stav a znovu ho použít:

```ts
await page.context().storageState({path: 'auth.json'})
```

Potom stačí stav připojit do testů:

```ts
test.use({storageState: 'auth.json'})
```

Tohle je ve většině projektů první rozumný krok. Testy jsou rychlejší, login se nespouští pořád dokola a výrazně ubude flaky chování navázané čistě na autentizační flow.

## Kdy samotné storageState přestává stačit

Sdílený přihlášený stav ale není univerzální řešení. Limity se objeví ve chvíli, kdy testy mění data, běží paralelně nebo pracují s více rolemi. V ten moment sdílený účet přestává být bezpečný a testy si začnou překážet.

Typický příklad je sada, kde potřebujete oddělit admina, běžného uživatele a guest scénář. Tam už dává smysl mít samostatné `storageState` pro každý typ uživatele, případně uživatele dynamicky vytvářet podle potřeby.

## OAuth, MFA a další realita produkčních systémů

V řadě aplikací není autentizace jen kombinace emailu a hesla. Reálně do ní vstupuje Google login, magic link, MFA nebo další externí identity flow. A právě tady se ukazuje rozdíl mezi teoretickým a praktickým testováním auth vrstvy.

Takové scénáře je často výrazně těžší udržet stabilní. Ne kvůli Playwrightu samotnému, ale kvůli tomu, že do testu vstupují externí systémy, časování a prostředí, které není plně pod kontrolou testovací sady.

## Dvě cesty: mockovaný nebo reálný login

V praxi se většinou pracuje se dvěma přístupy.

### Mockování

Mockovaný login přeskočí reálný auth flow a simuluje token nebo session. Je rychlý a stabilnější, ale netestuje skutečný scénář tak, jak ho zažije uživatel.

### Reálný login

Reálný login ověřuje skutečný flow a přináší vyšší důvěru. Zároveň ale znamená náročnější setup, vyšší citlivost na prostředí a větší nároky na správu testovacích účtů.

Nejde o to vybrat jedinou správnou variantu. Smysl dává rozhodnout, které scénáře opravdu musí validovat reálné přihlášení a kde naopak stačí rychlejší a stabilnější mockovaná vrstva.

## Proč auth testy padají nejčastěji

Většina problémů se opakuje. Expirované cookies, špatně nastavená doména, rozdíl mezi CI a lokálním prostředím nebo session stav, který se mezi testy nečekaně mění.

Proto se vyplatí auth vrstvu víc logovat než běžné scénáře. Pomáhá sledovat cookies, aktuální URL, čas běhu nebo další metadata, která ukážou, jestli jde o problém aplikace, testu nebo samotného prostředí.

## Co si z toho vzít do praxe

Autentizace není detail. Je to základní stavební kámen testovací architektury. Pokud je navržená dobře, přináší stabilitu celé sadě. Pokud je navržená špatně, stává se z ní jeden z největších zdrojů flaky testů i zbytečných prodlev.

Prakticky dává smysl držet několik základních pravidel:

- nepřihlašovat se znovu v každém testu
- používat `storageState` tam, kde to dává smysl
- oddělovat uživatele podle rolí a účelu
- logovat auth problémy systematicky
- počítat s tím, že CI a local prostředí se chovají jinak

## Shrnutí

Na začátku bývá login jen technický krok. Na konci z něj ale může být buď zdroj flaky testů a bottleneck celé sady, nebo stabilní základ, na kterém stojí zbytek testovací strategie.

Rozdíl není v tom, jestli autentizaci v Playwrightu řešíte. Rozdíl je v tom, jak ji navrhnete.

Jak řešit autentizaci v Playwrightu: storageState, více uživatelů, OAuth, MFA a nejčastější důvody, proč auth testy padají v CI.

Testování autentizace v Playwrightu | Bez flaky testů

Testování autentizace v Playwrightu (bez bolesti a flaky testů)

# Authentifizierung in Playwright testen (ohne Schmerzen und flaky Tests)

Authentifizierung gehört zu den am meisten unterschätzten Teilen von End-to-End-Testing. Am Anfang wirkt alles einfach: einloggen und dann den restlichen Flow testen. Sobald die Suite wächst, wird der Login jedoch sehr schnell zu einer der Hauptquellen für Instabilität.

Deshalb lohnt es sich, Authentifizierung nicht als bloßen Zusatzschritt zu behandeln, sondern als Teil der gesamten Testarchitektur. Wenn sie schlecht entworfen ist, werden Tests langsamer, scheitern in CI und beeinflussen sich gegenseitig. Wenn sie gut entworfen ist, verbessert sie die Stabilität der gesamten Suite deutlich.

## Warum Authentifizierung zum Problem wird

Die typischen Symptome ähneln sich in vielen Projekten. Tests funktionieren lokal, scheitern aber in CI. Sessions laufen mitten im Lauf ab. Der Login wird in jedem Szenario unnötig wiederholt und die ganze Suite wird langsam. Oder Tests überschreiben gegenseitig ihren Zustand und Fehler tauchen nur gelegentlich auf.

Das ist meist kein isolierter Bug. Es ist ein Zeichen dafür, dass der Login nur als notwendiger Schritt eingebaut wurde, aber nicht als eigene Schicht durchdacht wurde.

## Der langsamste Anti-Pattern ist Login in jedem Test

Der häufigste Startpunkt sieht ungefähr so aus:

```ts
test('user can open dashboard', async ({page}) => {
	await page.goto('/login')
	await page.fill('#email', 'test@test.com')
	await page.fill('#password', 'password')
	await page.click('button[type=submit]')
})
```

Für die ersten Tests funktioniert das. Für eine größere Suite skaliert dieser Ansatz jedoch schlecht. Der Login ist langsam, wiederholt sich ständig und jede kleine Verzögerung oder Instabilität im Auth-Flow vervielfacht sich über die gesamte Regressionsschicht.

## Praktische Grundlage: storageState

Playwright erlaubt es, den angemeldeten Zustand zu speichern und wiederzuverwenden:

```ts
await page.context().storageState({path: 'auth.json'})
```

Danach kann dieser Zustand in Tests verwendet werden:

```ts
test.use({storageState: 'auth.json'})
```

Für die meisten Projekte ist das der erste sinnvolle Schritt. Die Tests laufen schneller, der Login wiederholt sich nicht dauernd und ein erheblicher Teil auth-bezogener Flakiness verschwindet.

## Wann storageState allein nicht mehr reicht

Ein geteilter eingeloggter Zustand ist keine universelle Lösung. Grenzen zeigen sich, sobald Tests Daten verändern, parallel laufen oder mit mehreren Rollen arbeiten. Dann ist ein gemeinsamer Account nicht mehr sicher und Tests beginnen, sich gegenseitig zu stören.

Ein typisches Beispiel ist eine Suite mit Admin-, Normalnutzer- und Guest-Szenarien. In solchen Fällen ist es sinnvoll, getrennte `storageState`-Dateien pro Rolle zu verwenden oder Benutzer bei Bedarf dynamisch zu erzeugen.

## OAuth, MFA und die Realität produktiver Systeme

In vielen Anwendungen besteht Authentifizierung nicht nur aus E-Mail und Passwort. Reale Systeme enthalten häufig Google-Login, Magic Links, MFA oder andere externe Identity-Flows. Genau dort zeigt sich der Unterschied zwischen theoretischem und praktischem Auth-Testing.

Solche Szenarien stabil zu halten, ist oft deutlich schwieriger. Nicht wegen Playwright selbst, sondern weil Tests plötzlich von externen Systemen, Timing und Umgebungen abhängen, die die Suite nicht vollständig kontrolliert.

## Zwei Wege: gemockter oder realer Login

In der Praxis arbeiten Teams meist mit zwei Strategien.

### Mocking

Ein gemockter Login überspringt den realen Auth-Flow und simuliert Token oder Session. Das ist schnell und stabiler, testet aber nicht den echten Ablauf, den Nutzer erleben.

### Realer Login

Ein realer Login validiert den tatsächlichen Flow und schafft mehr Vertrauen. Gleichzeitig bedeutet er mehr Setup-Aufwand, höhere Empfindlichkeit gegenüber Umgebungsproblemen und anspruchsvollere Verwaltung von Testaccounts.

Es geht nicht darum, eine einzige richtige Option zu wählen. Entscheidend ist, welche Szenarien wirklich echten Login brauchen und wo eine schnellere, stabilere Mock-Schicht ausreicht.

## Warum Auth-Tests am häufigsten scheitern

Die meisten Probleme wiederholen sich. Abgelaufene Cookies, falsch konfigurierte Domains, Unterschiede zwischen CI und lokaler Umgebung oder Session-Zustände, die sich zwischen Tests unerwartet verändern.

Deshalb lohnt es sich, die Auth-Schicht stärker zu loggen als normale Szenarien. Cookies, aktuelle URL, Laufzeit und ähnliche Metadaten helfen oft sehr dabei zu verstehen, ob das Problem aus der Anwendung, dem Test oder der Umgebung kommt.

## Was sich daraus praktisch ableiten lässt

Authentifizierung ist kein Detail. Sie ist ein grundlegender Baustein der Testarchitektur. Gut entworfen stabilisiert sie die gesamte Suite. Schlecht entworfen wird sie zu einer der größten Quellen für flaky Tests und unnötige Verzögerungen.

Praktisch helfen ein paar Grundregeln:

- nicht in jedem Test neu einloggen
- `storageState` dort einsetzen, wo es Sinn ergibt
- Benutzer nach Rolle und Zweck trennen
- Auth-Probleme systematisch loggen
- Unterschiede zwischen CI und lokaler Umgebung einplanen

## Zusammenfassung

Am Anfang wirkt Login wie nur ein technischer Schritt. Mit der Zeit kann daraus aber entweder eine Quelle für flaky Tests und ein Bottleneck werden oder ein stabiler Unterbau für die gesamte Teststrategie.

Der Unterschied liegt nicht darin, ob Authentifizierung in Playwright gelöst wird. Der Unterschied liegt darin, wie sie entworfen wird.

Wie sich Authentifizierung in Playwright sauber lösen lässt: storageState, mehrere Benutzer, OAuth, MFA und die häufigsten Gründe für fehlschlagende Auth-Tests in CI.

Authentifizierung in Playwright testen | Ohne flaky Tests

Authentifizierung in Playwright testen (ohne Schmerzen und flaky Tests)

# Testing authentication in Playwright (without pain and flaky tests)

Authentication is one of the most underestimated parts of end-to-end testing. At first it looks simple: log in and continue with the rest of the test. Once the suite grows, though, login quickly becomes one of the main sources of instability.

That is why it makes sense to treat authentication not as just one extra technical step, but as part of the whole testing architecture. If it is designed badly, tests slow down, fail in CI and influence each other. If it is designed well, it significantly improves the stability of the entire suite.

## Why authentication becomes a problem

The symptoms are usually similar across projects. Tests work locally but fail in CI. Sessions expire in the middle of a run. Login repeats unnecessarily in every scenario and the whole suite becomes slow. Or tests overwrite each other’s state and failures appear only sometimes.

That is usually not an isolated bug. It is a signal that authentication was added only as a necessary step, not designed as a separate layer.

## The slowest anti-pattern is logging in inside every test

The most common starting point looks like this:

```ts
test('user can open dashboard', async ({page}) => {
	await page.goto('/login')
	await page.fill('#email', 'test@test.com')
	await page.fill('#password', 'password')
	await page.click('button[type=submit]')
})
```

This works for the first few tests. For a larger suite, however, it scales very poorly. Login is slow, repeats over and over, and every small delay or instability in the auth flow gets multiplied across the whole regression layer.

## A practical foundation: storageState

Playwright allows you to save the authenticated state and reuse it:

```ts
await page.context().storageState({path: 'auth.json'})
```

Then you can attach that state to tests:

```ts
test.use({storageState: 'auth.json'})
```

For most projects, this is the first sensible step. Tests run faster, login no longer repeats all the time and a significant amount of auth-related flakiness disappears.

## When storageState alone stops being enough

A shared authenticated state is not a universal solution. Its limits appear as soon as tests modify data, run in parallel or work with multiple user roles. At that point, a shared account stops being safe and tests begin to interfere with each other.

A common example is a suite where you need to separate admin, regular user and guest scenarios. In that case, it makes sense to have separate `storageState` files per role, or to create users dynamically when needed.

## OAuth, MFA and real-world systems

In many applications, authentication is not just email and password. Real systems often include Google login, magic links, MFA or other external identity flows. That is where the difference between theoretical and practical auth testing becomes obvious.

Such scenarios are often much harder to keep stable. Not because of Playwright itself, but because tests now depend on external systems, timing and environments that are not fully controlled by the test suite.

## Two paths: mocked login or real login

In practice, teams usually work with two strategies.

### Mocking

Mocked login skips the real auth flow and simulates a token or session. It is fast and more stable, but it does not validate the real scenario the user experiences.

### Real login

Real login validates the actual flow and gives more confidence. At the same time, it means more setup complexity, more sensitivity to environment issues and more demanding test account management.

The goal is not to choose one universal option. The practical decision is to define which scenarios truly need real authentication and where a faster, more stable mocked layer is sufficient.

## Why auth tests fail most often

Most problems repeat. Expired cookies, wrong domain configuration, differences between CI and local environments, or a session state that changes unexpectedly between tests.

That is why it makes sense to log the authentication layer more carefully than regular scenarios. Tracking cookies, the current URL, runtime and similar metadata often makes it much easier to understand whether the issue comes from the application, the test or the environment itself.

## What to take into practice

Authentication is not a detail. It is a basic building block of testing architecture. If designed well, it stabilises the whole suite. If designed badly, it becomes one of the biggest sources of flaky tests and wasted time.

In practice, a few basic rules help:

- do not log in again inside every test
- use `storageState` where it makes sense
- separate users by role and purpose
- log auth problems systematically
- expect CI and local environments to behave differently

## Summary

At the beginning, login looks like just one technical step. In the long run, it can become either a source of flaky tests and a bottleneck, or a stable foundation for the whole testing strategy.

The difference is not whether you solve authentication in Playwright. The difference is how you design it.

How to handle authentication in Playwright: storageState, multiple users, OAuth, MFA and the most common reasons auth tests fail in CI.

Authentication testing in Playwright | Without flaky tests

Testing authentication in Playwright (without pain and flaky tests)

# Cómo testear autenticación en Playwright (sin dolor ni flaky tests)

La autenticación es una de las partes más subestimadas del testing end-to-end. Al principio parece sencilla: iniciar sesión y seguir con el resto del flujo. En cuanto la suite crece, el login se convierte muy rápido en una de las principales fuentes de inestabilidad.

Por eso conviene tratar la autenticación no como un paso técnico más, sino como parte de toda la arquitectura de testing. Si está mal diseñada, los tests se vuelven más lentos, fallan en CI y se afectan entre sí. Si está bien diseñada, mejora de forma importante la estabilidad de toda la suite.

## Por qué la autenticación se vuelve un problema

Los síntomas suelen repetirse entre proyectos. Los tests funcionan en local pero fallan en CI. La sesión expira en mitad de la ejecución. El login se repite innecesariamente en cada escenario y la suite se vuelve lenta. O los tests se pisan el estado y los fallos aparecen solo algunas veces.

Eso normalmente no es un bug aislado. Es la señal de que el login se añadió solo como un paso necesario, pero no se diseñó como una capa propia.

## El anti-pattern más lento es hacer login en cada test

El punto de partida más común suele verse así:

```ts
test('user can open dashboard', async ({page}) => {
	await page.goto('/login')
	await page.fill('#email', 'test@test.com')
	await page.fill('#password', 'password')
	await page.click('button[type=submit]')
})
```

Esto funciona para los primeros tests. Para una suite más grande escala muy mal. El login es lento, se repite una y otra vez y cualquier pequeño retraso o inestabilidad en el auth flow se multiplica en toda la capa de regresión.

## Base práctica: storageState

Playwright permite guardar el estado autenticado y reutilizarlo:

```ts
await page.context().storageState({path: 'auth.json'})
```

Después basta con usar ese estado en los tests:

```ts
test.use({storageState: 'auth.json'})
```

En la mayoría de proyectos, este es el primer paso sensato. Los tests son más rápidos, el login deja de repetirse y desaparece una parte importante del comportamiento flaky ligado solo al flujo de autenticación.

## Cuándo storageState deja de ser suficiente

Un estado autenticado compartido no es una solución universal. Sus límites aparecen cuando los tests modifican datos, corren en paralelo o trabajan con varias funciones de usuario. En ese momento, una sola cuenta compartida deja de ser segura y los tests empiezan a interferirse.

Un ejemplo típico es una suite donde se necesita separar escenarios de admin, usuario normal y guest. En ese caso tiene sentido usar `storageState` separado por rol o crear usuarios dinámicamente según necesidad.

## OAuth, MFA y la realidad de los sistemas productivos

En muchas aplicaciones, la autenticación no es solo email y password. Los sistemas reales suelen incluir Google login, magic links, MFA u otros flujos externos de identidad. Ahí es donde se ve claramente la diferencia entre testing teórico y testing práctico de la capa auth.

Mantener estables esos escenarios suele ser mucho más difícil. No por Playwright en sí, sino porque el test depende de sistemas externos, timing y entornos que la suite no controla por completo.

## Dos caminos: login mockeado o login real

En la práctica, los equipos suelen trabajar con dos estrategias.

### Mocking

El login mockeado salta el flujo real y simula token o sesión. Es rápido y más estable, pero no valida el escenario real que vive el usuario.

### Login real

El login real valida el flujo auténtico y aporta más confianza. Al mismo tiempo, implica un setup más complejo, mayor sensibilidad al entorno y más exigencia en la gestión de cuentas de test.

La idea no es elegir una única opción correcta. Lo útil es decidir qué escenarios necesitan de verdad autenticación real y dónde basta una capa mockeada más rápida y estable.

## Por qué fallan más a menudo los auth tests

La mayoría de los problemas se repiten. Cookies expiradas, dominio mal configurado, diferencias entre CI y entorno local o estados de sesión que cambian de forma inesperada entre tests.

Por eso conviene loguear la capa auth con más detalle que los escenarios normales. Revisar cookies, URL actual, tiempo de ejecución y otros metadatos ayuda mucho a entender si el problema viene de la aplicación, del test o del entorno.

## Qué conviene llevar a la práctica

La autenticación no es un detalle. Es una pieza básica de la arquitectura de testing. Si está bien diseñada, estabiliza toda la suite. Si está mal diseñada, se convierte en una de las mayores fuentes de flaky tests y pérdida de tiempo.

A nivel práctico ayudan varias reglas simples:

- no hacer login de nuevo en cada test
- usar `storageState` donde tenga sentido
- separar usuarios por rol y propósito
- loguear los problemas de autenticación de forma sistemática
- asumir que CI y local no se comportan igual

## Resumen

Al principio, el login parece solo un paso técnico. Con el tiempo puede convertirse en una fuente de flaky tests y un bottleneck, o en una base estable para toda la estrategia de testing.

La diferencia no está en si resuelve autenticación en Playwright. La diferencia está en cómo la diseña.

Cómo resolver autenticación en Playwright: storageState, varios usuarios, OAuth, MFA y las razones más comunes por las que fallan los auth tests en CI.

Testear autenticación en Playwright | Sin flaky tests

Cómo testear autenticación en Playwright (sin dolor ni flaky tests)

# Jak navrhnout Playwright regresní sadu, která pomáhá releasu místo toho, aby ho blokovala

## Nejdřív rozhodnutí, až potom počet testů

Nejdůležitější otázka není kolik testů v Playwrightu máte, ale jaké rozhodnutí z nich plyne. Má suite zastavit deploy? Má jen signalizovat riziko? Má pokrývat smoke, nebo i hlubší regresi?

Bez tohoto vyjasnění vznikají velké balíky testů, které běží dlouho, padají kvůli flakiness a ve výsledku ztrácí důvěru týmu. Automatizace pak není součást release flow, ale překážka vedle něj.

## Jak sadu rozdělit v praxi

Ve většině projektů fungují tři vrstvy. Každá má jinou rychlost, jinou stabilitu a jiný vztah k releasu.

- Smoke suite: 5 až 15 minut, jen kritické flows, běží na každém deployi.
- Core regression: hlavní byznys scénáře, běží před releasem nebo podle harmonogramu.
- Extended coverage: méně kritické scénáře, edge cases a širší matrix zařízení nebo rolí.
- Každý test musí mít vlastníka, jasný důvod existence a známou hodnotu pro release rozhodnutí.

## Co nejčastěji rozbíjí důvěru v automatizaci

Typický problém není Playwright samotný, ale architektura kolem něj: nestabilní testovací data, sdílené závislosti mezi testy, nejasné prostředí a chybějící pravidla pro údržbu.

Když má automatizace fungovat dlouhodobě, musí mít stejné standardy jako produkční kód. Review, refaktoring, observabilitu a rozumné priority. Teprve potom se z ní stane nástroj, kterému tým věří při releasu.

Praktické principy pro Playwright regresní sadu: vrstvy testů, stabilita, priority a napojení na CI/CD.

Playwright regresní sada | Jak ji navrhnout pro release proces

Jak navrhnout Playwright regresní sadu, která pomáhá releasu místo toho, aby ho blokovala

# Wie Sie eine Playwright-Regression-Suite aufbauen, die Releases unterstützt statt blockiert

## Erst die Release-Entscheidung, dann die Anzahl der Tests

Die wichtigste Frage ist nicht, wie viele Playwright-Tests Sie haben, sondern welche Entscheidung sie unterstützen. Soll die Suite das Deployment blockieren? Nur auf erhöhtes Risiko hinweisen? Ein Smoke-Gate oder eine tiefere Regressionsschicht sein?

Ohne diese Klarheit entstehen große Testpakete, die zu lange laufen, wegen Flakiness scheitern und am Ende das Vertrauen des Teams verlieren. Automatisierung wird dann nicht Teil des Release-Flows, sondern ein Hindernis daneben.

## Wie Sie die Suite praktisch aufteilen

In den meisten Projekten funktionieren drei Ebenen gut. Jede hat eine andere Geschwindigkeit, Stabilität und Rolle im Release-Prozess.

- Smoke-Suite: 5 bis 15 Minuten, nur kritische Flows, läuft bei jedem Deployment.
- Core-Regression: zentrale Business-Szenarien, läuft vor dem Release oder nach Zeitplan.
- Extended Coverage: weniger kritische Szenarien, Edge Cases und breitere Geräte- oder Rollenmatrix.
- Jeder Test sollte einen Owner, einen klaren Existenzgrund und einen bekannten Nutzen für Release-Entscheidungen haben.

## Was Vertrauen in Automatisierung am häufigsten zerstört

Das übliche Problem ist nicht Playwright selbst, sondern die Architektur darum herum: instabile Testdaten, geteilte Abhängigkeiten zwischen Tests, unklare Umgebungen und fehlende Wartungsregeln.

Wenn Automatisierung langfristig funktionieren soll, braucht sie die gleichen Standards wie Produktionscode: Review, Refactoring, Observability und sinnvolle Prioritäten. Erst dann wird sie zu einem Release-Werkzeug, dem das Team vertraut.

Praktische Prinzipien für eine Playwright-Regression-Suite: Testebenen, Stabilität, Prioritäten und CI/CD-Integration.

Playwright-Regression-Suite | Aufbau für den Release-Prozess

Wie Sie eine Playwright-Regression-Suite aufbauen, die Releases unterstützt statt blockiert

# How to design a Playwright regression suite that supports releases instead of blocking them

## Start with release decisions, not with test count

The key question is not how many Playwright tests you have, but what decision they support. Should the suite block deployment? Should it only signal elevated risk? Is it a smoke gate or a deeper regression layer?

Without that clarity, teams build large packs of tests that run too long, fail because of flakiness and eventually lose trust. Automation stops being part of the release flow and becomes a side obstacle.

## How to split the suite in practice

In most projects, three layers work well. Each has different speed, stability and a different role in the release process.

- Smoke suite: 5 to 15 minutes, only critical flows, runs on every deploy.
- Core regression: primary business scenarios, runs before release or on a schedule.
- Extended coverage: less critical scenarios, edge cases and broader device or role matrix.
- Every test should have an owner, a clear reason to exist and a known value for release decisions.

## What most often destroys trust in automation

The usual problem is not Playwright itself but the architecture around it: unstable test data, shared dependencies between tests, unclear environments and missing maintenance rules.

If automation should work long term, it needs the same standards as production code: review, refactoring, observability and sensible priorities. That is when it becomes a release tool the team actually trusts.

Practical principles for a Playwright regression suite: test layers, stability, priorities and CI/CD integration.

Playwright regression suite | How to design it for release workflow

How to design a Playwright regression suite that supports releases instead of blocking them

# Cómo diseñar una suite de regresión en Playwright que ayude al release en lugar de bloquearlo

## Empiece por la decisión de release, no por el número de tests

La pregunta clave no es cuántos tests de Playwright tiene, sino qué decisión sustentan. ¿La suite debe bloquear el despliegue? ¿Solo señalar riesgo? ¿Es una puerta smoke o una capa de regresión más profunda?

Sin esa claridad, los equipos construyen paquetes grandes de tests que tardan demasiado, fallan por flakiness y terminan perdiendo la confianza del equipo. La automatización deja de ser parte del release flow y pasa a ser un obstáculo paralelo.

## Cómo dividir la suite en la práctica

En la mayoría de proyectos funcionan bien tres capas. Cada una tiene distinta velocidad, estabilidad y papel dentro del proceso de release.

- Suite smoke: 5 a 15 minutos, solo flujos críticos, se ejecuta en cada deploy.
- Regresión core: escenarios principales de negocio, se ejecuta antes del release o según programación.
- Cobertura extendida: escenarios menos críticos, edge cases y una matriz más amplia de dispositivos o roles.
- Cada test debe tener responsable, motivo claro de existencia y valor conocido para la decisión de release.

## Qué es lo que más suele destruir la confianza en la automatización

El problema habitual no es Playwright en sí, sino la arquitectura que lo rodea: datos de prueba inestables, dependencias compartidas entre tests, entornos poco claros y ausencia de reglas de mantenimiento.

Si la automatización debe funcionar a largo plazo, necesita los mismos estándares que el código de producción: review, refactorización, observabilidad y prioridades sensatas. Solo entonces se convierte en una herramienta de release en la que el equipo confía.

Principios prácticos para una suite de regresión en Playwright: capas de test, estabilidad, prioridades e integración con CI/CD.

Suite de regresión en Playwright | Cómo diseñarla para el release

Cómo diseñar una suite de regresión en Playwright que ayude al release en lugar de bloquearlo

# QA audit před releasem: co zkontrolovat, než pustíte produkt ven

## Proč dělat QA audit těsně před releasem

Poslední dny před releasem bývají nejrizikovější. Feature je hotová, tým už přepíná pozornost jinam a do produkce se často dostane změna, která na stagingu prošla jen částečně.

Krátký QA audit není o tom brzdit release. Je to kontrola, že fungují scénáře s největším dopadem na byznys a že případné známé problémy mají vlastníka i rozhodnutí.

## Minimum viable release checklist

Rozsah checklistu se liší podle typu produktu, ale několik oblastí by mělo být součástí skoro vždy.

- Kritické user flows: přihlášení, registrace, checkout, odeslání formuláře, hlavní CTA.
- Regrese nejrizikovějších míst: části aplikace dotčené změnou, integrace, role a oprávnění.
- Základní technická kontrola: JavaScript chyby, broken links, chybové stavy, responzivita.
- Performance a accessibility sanity check: Core Web Vitals, keyboard navigation, kontrast, formulářové chyby.
- Release decision log: co je blocker, co je accepted risk a kdo to schválil.

## Kdy má audit největší přínos

Největší efekt má před větším releasem, redesignem, změnou checkoutu, onboarding flow nebo před spuštěním kampaně. Právě tam je chyba nejdražší a zároveň nejviditelnější.

Pokud potřebujete rychlou nezávislou kontrolu před nasazením, dává smysl QA audit jako samostatná služba. Pokud releasy běží často, je lepší audit převést do pravidelného release procesu a opřít ho o automatizaci.

Co zkontrolovat před releasem webu nebo aplikace: kritické flows, regresi, performance, accessibility a reporting.

QA audit před releasem | Checklist před nasazením

QA audit před releasem: co zkontrolovat, než pustíte produkt ven

# QA-Audit vor dem Release: Was Sie vor dem Go-live prüfen sollten

## Warum kurz vor dem Release ein QA-Audit sinnvoll ist

Die letzten Tage vor dem Release sind meist am riskantesten. Das Feature gilt als fertig, das Team richtet den Fokus bereits auf andere Themen, und Änderungen landen oft nur teilweise validiert in Produktion.

Ein kurzes QA-Audit soll den Release nicht ausbremsen. Es ist eine gezielte Kontrolle, dass die wichtigsten Business-Szenarien funktionieren und bekannte Probleme einen Owner und eine bewusste Entscheidung haben.

## Minimum viable Release-Checkliste

Der genaue Umfang hängt vom Produkt ab, aber einige Bereiche sollten fast immer Teil des Releases sein.

- Kritische User-Flows: Registrierung, Login, Checkout, Formularversand, primäre CTA-Pfade.
- Regression der riskantesten Bereiche: von der Änderung betroffene Teile, Integrationen, Rollen und Berechtigungen.
- Grundlegende technische Kontrolle: JavaScript-Fehler, defekte Links, Fehlerzustände, Responsiveness.
- Performance- und Accessibility-Sanity-Check: Core Web Vitals, Tastaturnavigation, Kontrast, Formularfehler.
- Release-Entscheidungslog: Was ist ein Blocker, welches Risiko wird akzeptiert und wer hat es freigegeben.

## Wann dieses Audit den größten Nutzen bringt

Den größten Nutzen bringt es vor größeren Releases, Redesigns, Checkout-Änderungen, Onboarding-Anpassungen oder Kampagnenstarts. Genau dort sind Fehler am teuersten und am sichtbarsten.

Wenn Sie vor dem Deployment eine unabhängige Kontrolle brauchen, ist ein eigenständiges QA-Audit sinnvoll. Bei häufigen Releases sollte daraus besser ein wiederholbarer Release-Prozess mit Automatisierung werden.

Was Sie vor dem Release einer Website oder App prüfen sollten: kritische Flows, Regression, Performance, Barrierefreiheit und Reporting.

QA-Audit vor dem Release | Checkliste vor dem Launch

QA-Audit vor dem Release: Was Sie vor dem Go-live prüfen sollten

# QA audit before release: what to check before you ship

## Why run a QA audit right before release

The final days before release are usually the riskiest. The feature is done, the team is already shifting focus, and changes often reach production after only partial validation on staging.

A short QA audit is not about blocking the release. It is a focused check that the highest-impact business scenarios work and that known issues have an owner and an explicit decision.

## Minimum viable release checklist

The exact checklist depends on the product, but a few areas should be part of almost every release.

- Critical user flows: sign-up, login, checkout, form submission, primary CTA paths.
- Regression of the riskiest areas: parts touched by the change, integrations, roles and permissions.
- Basic technical checks: JavaScript errors, broken links, error states, responsiveness.
- Performance and accessibility sanity checks: Core Web Vitals, keyboard navigation, contrast, form errors.
- Release decision log: what is a blocker, what is accepted risk and who approved it.

## When this audit brings the highest value

It delivers the most value before a larger release, redesign, checkout change, onboarding update or campaign launch. That is where bugs are both the most expensive and the most visible.

If you need an independent check before deployment, a standalone QA audit makes sense. If releases happen often, the better move is to turn that audit into a repeatable release process supported by automation.

What to check before releasing a website or app: critical flows, regression, performance, accessibility and reporting.

QA audit before release | Pre-launch checklist

QA audit before release: what to check before you ship

# Auditoría QA antes del release: qué revisar antes de lanzar

## Por qué hacer una auditoría QA justo antes del release

Los últimos días antes del release suelen ser los más arriesgados. La funcionalidad ya se considera terminada, el equipo cambia el foco y a producción llegan cambios validados solo parcialmente en staging.

Una auditoría QA corta no busca bloquear el lanzamiento. Sirve para comprobar que funcionan los escenarios con mayor impacto de negocio y que los problemas conocidos tienen responsable y decisión clara.

## Checklist mínima viable para release

El checklist exacto depende del producto, pero hay varias áreas que deberían formar parte de casi cualquier release.

- Flujos de usuario críticos: registro, login, checkout, envío de formularios, rutas CTA principales.
- Regresión de las zonas más arriesgadas: partes afectadas por el cambio, integraciones, roles y permisos.
- Comprobación técnica básica: errores JavaScript, enlaces rotos, estados de error, responsive.
- Sanity check de rendimiento y accesibilidad: Core Web Vitals, navegación por teclado, contraste, errores de formularios.
- Registro de decisión del release: qué bloquea, qué riesgo se acepta y quién lo aprueba.

## Cuándo aporta más valor esta auditoría

Aporta más valor antes de un release grande, un rediseño, un cambio de checkout, una actualización del onboarding o el lanzamiento de una campaña. Ahí es donde los errores son más caros y más visibles.

Si necesita una revisión independiente antes del despliegue, tiene sentido una auditoría QA como servicio puntual. Si publica con frecuencia, lo correcto es convertir esa auditoría en un proceso repetible apoyado por automatización.

Qué revisar antes de publicar una web o app: flujos críticos, regresión, rendimiento, accesibilidad y reporting.

Auditoría QA antes del release | Checklist previa al lanzamiento

Auditoría QA antes del release: qué revisar antes de lanzar

# Test strategie, která škáluje: co nastavit dřív, než začnete přidávat další testy

## Proč týmy selhávají, když jen přidávají další testy

Na začátku to vypadá logicky: objevila se chyba, přidá se test. Jenže bez jasné strategie roste počet testů rychleji než schopnost týmu je udržovat. Výsledkem bývá pomalý pipeline, flaky testy a nejistota, čemu ještě věřit.

Fungující test strategie nezačíná nástrojem, ale rozhodnutím, jaká rizika má QA pokrýt a jaké otázky má zodpovědět před releasem. Teprve potom dává smysl volit konkrétní testy a úroveň automatizace.

## Rámec pro test strategii v praxi

Ve většině produktových týmů funguje jednoduchý model: mapovat kritické user flow, vyhodnotit obchodní dopad chyby a podle toho určit, co má být manuální kontrola, co automatizace a co stačí monitorovat až po releasu.

- Riziková mapa: kde chyba nejvíc bolí uživatele i byznys.
- Vrstevnaté testování: smoke, core regression, rozšířená coverage.
- Jasná release kritéria: co blokuje release a co je akceptované riziko.
- Odpovědnosti: kdo vlastní testy, data a stabilitu prostředí.

## Jak poznat, že strategie funguje

Dobrá test strategie je vidět na výsledcích: méně překvapení v produkci, rychlejší rozhodnutí před releasem a jasnější komunikace mezi QA, vývojem a produktem. Není to dokument do šuplíku, ale živý rámec, který se upravuje s každou větší změnou produktu.

Pokud produkt roste, strategie musí růst s ním. To znamená pravidelně vyhodnocovat, které testy stále přinášejí hodnotu a které už jen spotřebovávají čas. Cílem není více testovat, ale lépe rozhodovat.

Jak navrhnout test strategii, která drží krok s růstem produktu: prioritizace rizik, role automatizace a měření kvality.

Test strategie pro růst produktu | Jak škálovat QA bez chaosu

Test strategie, která škáluje: co nastavit dřív, než začnete přidávat další testy

# Eine skalierbare Teststrategie: Was Sie festlegen sollten, bevor weitere Tests hinzukommen

## Warum Teams scheitern, wenn sie nur weitere Tests hinzufügen

Zunächst wirkt es logisch: Ein Bug taucht auf, also kommt ein weiterer Test dazu. Ohne Strategie wächst die Anzahl der Tests jedoch schneller als die Fähigkeit des Teams, sie zu warten. Das Ergebnis sind oft langsame Pipelines, flaky Tests und Unsicherheit, worauf man sich noch verlassen kann.

Eine belastbare Teststrategie beginnt nicht mit einem Tool. Sie beginnt mit der Definition, welche Risiken QA abdecken soll und welche Fragen vor dem Release beantwortet werden müssen. Erst dann ist die Auswahl konkreter Tests und der passende Automatisierungsgrad sinnvoll.

## Ein praktischer Rahmen für die Teststrategie

In den meisten Produktteams funktioniert ein einfaches Modell am besten: kritische User-Flows erfassen, den Business-Impact von Fehlern bewerten und danach entscheiden, was manuell geprüft, was automatisiert und was erst nach dem Release überwacht wird.

- Risikomap: Wo Fehler Nutzer und Business am stärksten treffen.
- Geschichtetes Testen: Smoke, Core-Regression, erweiterte Coverage.
- Klare Release-Kriterien: Was den Release blockiert und welches Risiko akzeptiert wird.
- Verantwortlichkeiten: Wer Tests, Daten und Umgebungsstabilität besitzt.

## Woran Sie erkennen, dass die Strategie funktioniert

Eine gute Teststrategie zeigt sich in Ergebnissen: weniger Überraschungen in Produktion, schnellere Entscheidungen vor dem Release und klarere Kommunikation zwischen QA, Entwicklung und Produkt. Sie ist kein Dokument für die Schublade, sondern ein lebender Rahmen, der sich mit größeren Produktänderungen weiterentwickelt.

Wenn das Produkt wächst, muss die Strategie mitwachsen. Das bedeutet, regelmäßig zu prüfen, welche Tests weiterhin Wert liefern und welche nur Zeit verbrauchen. Ziel ist nicht mehr zu testen, sondern besser zu entscheiden.

Wie Sie eine Teststrategie entwickeln, die mit dem Produktwachstum Schritt hält: Risikopriorisierung, Rolle der Automatisierung und Qualitätsmetriken.

Teststrategie für wachsende Produkte | QA ohne Chaos skalieren

Eine skalierbare Teststrategie: Was Sie festlegen sollten, bevor weitere Tests hinzukommen

# A test strategy that scales: what to set up before adding more tests

## Why teams fail when they only keep adding tests

At first it looks logical: a bug appears, so a new test is added. Without strategy, though, test count grows faster than the team can maintain it. The result is usually slow pipelines, flaky checks and uncertainty about what can still be trusted.

A reliable test strategy does not start with a tool. It starts with defining which risks QA must cover and which release questions must be answered. Only then does choosing specific tests and automation depth make sense.

## A practical framework for test strategy

In most product teams, a simple model works best: map critical user flows, estimate business impact of failure, then decide what should be manual checks, what should be automated and what can be monitored post-release.

- Risk map: where failure hurts users and business the most.
- Layered testing: smoke, core regression, extended coverage.
- Clear release criteria: what blocks release and what is accepted risk.
- Ownership: who owns tests, data and environment stability.

## How to tell the strategy is working

A good test strategy shows up in outcomes: fewer production surprises, faster pre-release decisions and clearer communication between QA, engineering and product. It is not a document for a drawer but a living framework updated with major product changes.

As the product grows, strategy must grow with it. That means regularly reviewing which tests still deliver value and which only consume time. The goal is not to test more, but to decide better.

How to design a test strategy that keeps up with product growth: risk prioritisation, automation role and quality metrics.

Test strategy for growing products | Scale QA without chaos

A test strategy that scales: what to set up before adding more tests

# Una estrategia de testing que escala: qué definir antes de añadir más tests

## Por qué los equipos fallan cuando solo añaden más tests

Al principio parece lógico: aparece un bug y se añade un test. Sin estrategia, el número de tests crece más rápido que la capacidad del equipo para mantenerlos. El resultado suele ser un pipeline lento, checks inestables y poca confianza en lo que realmente valida.

Una estrategia de testing sólida no empieza por la herramienta. Empieza por definir qué riesgos debe cubrir QA y qué preguntas deben quedar resueltas antes del release. Solo entonces tiene sentido decidir qué tests automatizar y con qué profundidad.

## Un marco práctico para la estrategia de testing

En la mayoría de equipos de producto funciona mejor un modelo simple: mapear flujos críticos de usuario, estimar el impacto de negocio del fallo y decidir qué va en validación manual, qué en automatización y qué se monitoriza tras el release.

- Mapa de riesgo: dónde un fallo impacta más a usuarios y negocio.
- Testing por capas: smoke, regresión core y cobertura extendida.
- Criterios de release claros: qué bloquea y qué riesgo se acepta.
- Responsabilidades: quién es dueño de tests, datos y estabilidad del entorno.

## Cómo saber que la estrategia está funcionando

Una buena estrategia de testing se nota en los resultados: menos sorpresas en producción, decisiones más rápidas antes del release y comunicación más clara entre QA, desarrollo y producto. No es un documento para guardar, sino un marco vivo que evoluciona con los cambios del producto.

Si el producto crece, la estrategia debe crecer con él. Eso implica revisar de forma regular qué tests siguen aportando valor y cuáles solo consumen tiempo. El objetivo no es testear más, sino decidir mejor.

Cómo diseñar una estrategia de testing que acompañe el crecimiento del producto: priorización de riesgos, rol de la automatización y métricas de calidad.

Estrategia de testing para productos en crecimiento | Escalar QA sin caos

Una estrategia de testing que escala: qué definir antes de añadir más tests

Webová SaaS aplikace pro administrativní a finanční agendu, ve které uživatelé denně vystavují doklady, spravují kontakty, nastavují účty a pořizují předplatné. Produkt fungoval ve více jazykových i tržních variantách a každá změna se dotýkala scénářů s přímým dopadem na zákazníka.

Ruční kontrola nejdůležitějších flow byla pomalá, drahá a při každém releasu čím dál méně udržitelná.

Situaci komplikovaly rozdílné texty, URL adresy a pravidla napříč jednotlivými trhy. Pokrýt všechny kombinace ručně znamenalo vysoké náklady i vysoké riziko, že kritická chyba projde do produkce.

Vznikla automatizovaná E2E vrstva zaměřená na nejrizikovější části produktu a navržená tak, aby přidávala jistotu bez zbytečné byrokracie.

Release přestal být ruční přehlídkou rizik a stal se kontrolovaným krokem s předvídatelným výsledkem. Regresní chyby se zachytí dřív, než se projeví u zákazníků, a tým má spolehlivý kontrolní bod před nasazením.

Cypress · Percy · Cypress Cloud · CircleCI · Page Object Pattern · Rails + Vue

Jistota při každém releasu díky automatizaci kritických scénářů

Eine webbasierte SaaS-Anwendung für administrative und finanzielle Abläufe, in der Nutzer täglich Belege erstellen, Kontakte verwalten, Konten konfigurieren und Abonnements bestellen. Das Produkt lief in mehreren Sprach- und Marktvarianten, sodass selbst kleine Änderungen direkt kundenrelevante Abläufe beeinflussen konnten.

Die manuelle Prüfung der wichtigsten User Flows war langsam, teuer und mit jedem Release schwerer skalierbar.

Jeder Markt brachte eigene Texte, URLs und Regeln mit. Alle Varianten manuell abzudecken bedeutete hohe Kosten und ein hohes Risiko, dass kritische Regressionen in Produktion gelangen.

Für die risikoreichsten Produktbereiche wurde eine automatisierte End-to-End-Schicht aufgebaut, die Release-Sicherheit schafft, ohne unnötige Prozesslast zu erzeugen.

Die Release-Prüfung wurde von einer manuellen Belastung zu einem kontrollierten Qualitätsschritt. Regressionen werden erkannt, bevor Kunden sie bemerken, und das Team erhält einen verlässlichen Freigabepunkt vor dem Deployment.

Release-Sicherheit durch automatisierte kritische Szenarien

A web-based SaaS product for administrative and financial workflows where users issue documents, manage contacts, configure accounts and purchase subscriptions every day. The platform served multiple languages and markets, so even a small change could affect customer-critical flows.

Manual verification of the most important journeys was slow, expensive and increasingly difficult to scale with every release.

Each market introduced different texts, URLs and business rules. Covering every combination manually meant high cost and a high chance that a critical regression would reach production.

An automated end-to-end layer was introduced for the riskiest parts of the product, designed to improve release confidence without adding unnecessary process overhead.

Release validation became a controlled step instead of a manual stress point. Regression defects are caught before customers feel them, and the team has a reliable quality checkpoint before deployment.

Release confidence through automation of critical scenarios

Una aplicación SaaS web para procesos administrativos y financieros, donde los usuarios emiten documentos, gestionan contactos, configuran cuentas y contratan suscripciones cada día. El producto operaba en varios idiomas y mercados, por lo que cualquier cambio podía afectar flujos clave para el cliente.

La validación manual de los recorridos más importantes era lenta, costosa y cada vez menos escalable con cada release.

Cada mercado tenía textos, URLs y reglas distintas. Cubrir todas las combinaciones manualmente implicaba un coste alto y un riesgo real de que una regresión crítica llegara a producción.

Se construyó una capa E2E automatizada para las partes más sensibles del producto, diseñada para aumentar la confianza en el release sin añadir burocracia innecesaria.

La validación del release dejó de ser una revisión manual tensa y pasó a ser un paso controlado y predecible. Las regresiones se detectan antes de que afecten a los clientes y el equipo cuenta con un punto de control fiable antes del despliegue.

Confianza en cada release gracias a la automatización de escenarios críticos

Hlasový bot napojený na backendové API, u kterého nestačí vědět, že jeden hovor projde. Důležité je vědět, jak se systém chová při desítkách paralelních hovorů a jak zátěž ovlivňuje stabilitu, paměť i procesor.

Před releasem nebo větší změnou bylo potřeba ověřit výkon na základě dat, ne odhadů.

Bez těchto informací se release rozhodnutí opírala spíš o dojem než o měřitelný obraz reality.

Byl připraven opakovatelný performance test, který generuje zátěž přes reálné backendové API a současně sbírá systémová data pro interpretovatelný výstup.

Tým získal konkrétní data o chování systému pod zátěží a mohl dělat release rozhodnutí na základě měřitelných výsledků. Výkonové problémy se dají zachytit dřív, než se projeví v produkci.

Python · requests · OAuth2 · pandas · matplotlib · CSV · Bash

Výkon callbotu pod zátěží s daty pro release rozhodnutí

Ein Voice-Bot mit Anbindung an ein Backend-API, bei dem es nicht reicht, dass ein einzelner Anruf funktioniert. Entscheidend ist, wie sich das System bei dutzenden parallelen Anrufen verhält und welche Auswirkungen die Last auf Stabilität, Speicher und CPU hat.

Vor einem Release oder einer größeren Änderung musste die Performance datenbasiert statt anhand von Annahmen überprüft werden.

Ohne diese Antworten basierten Release-Entscheidungen eher auf Gefühl als auf einem messbaren Bild der Realität.

Es wurde ein wiederholbarer Performance-Test aufgebaut, der Last über das echte Backend-API erzeugt und gleichzeitig Systemmetriken sammelt, damit die Ergebnisse interpretierbar bleiben.

Das Team erhielt belastbare Daten über das Verhalten des Systems unter Last und konnte Release-Entscheidungen auf Basis messbarer Ergebnisse treffen. Performance-Probleme lassen sich erkennen, bevor sie in Produktion sichtbar werden.

Callbot-Performance unter Last mit belastbaren Daten für Release-Entscheidungen

A voice bot connected to a backend API, where it is not enough to know that one call succeeds. What matters is how the system behaves under dozens of parallel calls and what that load does to stability, memory usage and CPU consumption.

Before a release or a larger change, performance had to be verified using data rather than assumptions.

Without these answers, release decisions depended more on guesswork than on a measurable view of real system behaviour.

A repeatable performance test setup was created to generate load through the real backend API while collecting system metrics for an output that can actually be interpreted.

The team gained concrete data about how the system behaves under load and could make release decisions based on evidence. Performance issues can now be identified before they become customer-facing incidents.

Callbot performance under load with data for release decisions

Un bot de voz conectado a una API backend, donde no basta con comprobar que una sola llamada funciona. Lo importante es entender cómo se comporta el sistema con decenas de llamadas paralelas y qué efecto tiene la carga sobre la estabilidad, la memoria y la CPU.

Antes de un release o de un cambio importante, era necesario validar el rendimiento con datos reales y no con suposiciones.

Sin estas respuestas, las decisiones de release dependían más de intuiciones que de una visión medible del comportamiento real del sistema.

Se preparó un entorno de performance testing repetible que genera carga a través de la API backend real y al mismo tiempo recopila métricas del sistema para obtener resultados interpretables.

El equipo obtuvo datos concretos sobre el comportamiento del sistema bajo carga y pudo tomar decisiones de release basadas en evidencia. Los problemas de rendimiento se detectan antes de convertirse en incidentes visibles para el cliente.

Rendimiento de un callbot bajo carga con datos para decidir un release

Rozsáhlá React a Next.js aplikace s přihlášením, katalogem obsahu, video playerem, upload flow a lokalizacemi. Produkt, kde se stejná funkce musí chovat správně na desktopu i mobilu, v různých prohlížečích a v různých jazykových verzích.

S rostoucím počtem funkcí a variant rozhraní roste i riziko, že změna v jedné části tiše rozbije jinou. Manuálně ověřit všechny kombinace zařízení, browserů a jazyků není realistické.

Bez automatizované vrstvy by cross-device a cross-browser problémy zůstávaly překvapením až v produkci.

Byla vytvořena a průběžně rozvíjena E2E testovací vrstva zaměřená na klíčové uživatelské scénáře s pokrytím napříč zařízeními, browsery a jazykovými mutacemi.

Tým získal pevný základ pro ověření kvality před každým releasem bez závislosti na ručním procházení všech kombinací. Cross-device problémy přestaly být nepříjemným překvapením po nasazení.

Playwright · TypeScript · Next.js / React · axe · cross-browser konfigurace

Release confidence pro frontendovou aplikaci napříč zařízeními a browsery

Eine umfangreiche React- und Next.js-Anwendung mit Anmeldung, Content-Katalog, Video-Player, Upload-Flows und Lokalisierung. Dieselbe Funktion musste auf Desktop und Mobile, in verschiedenen Browsern und in mehreren Sprachversionen zuverlässig funktionieren.

Mit jeder neuen Funktion und jeder zusätzlichen UI-Variante steigt das Risiko, dass eine Änderung an einer Stelle stillschweigend eine andere beschädigt. Alle Kombinationen aus Geräten, Browsern und Sprachen manuell zu prüfen, ist nicht realistisch.

Ohne eine automatisierte Schicht würden Cross-Device- und Cross-Browser-Fehler weiterhin erst nach dem Release sichtbar werden.

Es wurde eine End-to-End-Testschicht aufgebaut und laufend erweitert, die sich auf zentrale User Journeys konzentriert und Geräte-, Browser- und Sprachvarianten abdeckt.

Das Team erhielt eine verlässliche Qualitätsbasis vor jedem Release, ohne alle Kombinationen manuell durchklicken zu müssen. Cross-Device-Probleme wurden nicht länger erst in Produktion entdeckt.

Playwright · TypeScript · Next.js / React · axe · Cross-Browser-Konfiguration

Release-Sicherheit für Frontend-Produkte über Geräte und Browser hinweg

A large React and Next.js application with authentication, a content catalogue, a video player, upload journeys and localisation. The same feature had to work correctly on desktop and mobile, across browsers and across language versions.

As the number of features and interface variants grows, so does the risk that a change in one area silently breaks another. Manually checking every combination of devices, browsers and languages is not realistic.

Without an automated layer, cross-device and cross-browser defects would continue to surface only after release.

An end-to-end test layer was created and iteratively expanded around the product's key user journeys, with coverage across devices, browsers and language variations.

The team gained a reliable quality baseline before each release without relying on manual walkthroughs of every combination. Cross-device issues stopped being production surprises.

Playwright · TypeScript · Next.js / React · axe · cross-browser configuration

Release confidence for a frontend product across devices and browsers

Una aplicación amplia en React y Next.js con autenticación, catálogo de contenido, reproductor de vídeo, flujos de carga y localización. La misma funcionalidad debía comportarse correctamente en escritorio y móvil, en distintos navegadores y en varios idiomas.

Cuantas más funciones y variantes de interfaz existen, mayor es el riesgo de que un cambio en una parte rompa otra sin que se note de inmediato. Validar manualmente todas las combinaciones de dispositivos, navegadores e idiomas no es realista.

Sin una capa automatizada, los problemas cross-device y cross-browser seguirían apareciendo solo después del release.

Se creó y fue ampliando una capa E2E centrada en los recorridos clave del producto, con cobertura sobre dispositivos, navegadores y variantes de idioma.

El equipo obtuvo una base fiable para validar la calidad antes de cada release sin depender de recorridos manuales por todas las combinaciones. Los problemas cross-device dejaron de ser sorpresas en producción.

Playwright · TypeScript · Next.js / React · axe · configuración cross-browser

Confianza en el release de una aplicación frontend en distintos dispositivos y navegadores

Objednávkový formulář pro nákup voucherů ve více brand variantách s odlišným UI a různými platebními metodami. Typ e-commerce flow, kde chyba v checkoutu přímo ovlivňuje konverze a tržby.

Každá varianta produktu vypadala trochu jinak a nabízela jiné platební metody. Změna v jednom formuláři mohla tiše rozbít jinou variantu a údržba testů pro všechny kombinace hrozila rychlou ztrátou přehlednosti.

Vznikla Playwright smoke sada, která pokrývá happy path i validační scénáře napříč variantami produktu z jedné sdílené sady testů.

Vznikl čistý a rozšiřitelný základ pro automatizaci checkoutu, který je použitelný i pro další varianty nebo platební scénáře. Nové kombinace se dají přidávat bez přepisování existující logiky.

Playwright · TypeScript · Page Object Model · Parameterized projects · ESLint / Prettier

Smoke testy pro objednávkový formulář ve více variantách bez duplikace

Ein Bestellformular für Gutscheinkäufe in mehreren Brand-Varianten mit unterschiedlichem UI und verschiedenen Zahlungsmethoden. Ein typischer E-Commerce-Flow, bei dem ein Fehler im Checkout direkt Conversion und Umsatz beeinflusst.

Jede Produktvariante sah etwas anders aus und bot andere Zahlungsmethoden. Eine Änderung in einem Formular konnte unbemerkt eine andere Variante beschädigen, und separate Tests für jede Kombination wären schnell unübersichtlich geworden.

Es wurde eine Playwright-Smoke-Suite aufgebaut, die Happy Path und Validierungsszenarien über alle Produktvarianten hinweg mit einer gemeinsamen Testsuite abdeckt.

Es entstand eine saubere und erweiterbare Grundlage für die Checkout-Automatisierung, die auch bei neuen Varianten und Zahlungsarten weiterverwendet werden kann. Neue Kombinationen lassen sich hinzufügen, ohne bestehende Logik umzuschreiben.

Smoke-Tests für ein mehrvariantiges Checkout-Formular ohne doppelte Testlogik

An order form for voucher purchases available in multiple brand variants, each with a different UI and different payment methods. This is the kind of e-commerce flow where a checkout defect directly impacts conversion and revenue.

Each product variant looked slightly different and supported different payment methods. A change in one form could silently break another, and maintaining separate tests for every combination would quickly become unmanageable.

A Playwright smoke suite was created to cover the happy path and validation scenarios across product variants from one shared set of tests.

The result is a clean and extensible automation baseline for checkout validation that can grow with new variants and payment scenarios. New combinations can be added without rewriting existing logic.

Smoke tests for a multi-variant checkout form without duplicated logic

Un formulario de pedido para la compra de vouchers disponible en varias variantes de marca, cada una con una interfaz distinta y con métodos de pago diferentes. Es un flujo e-commerce donde un error en checkout impacta directamente en la conversión y en los ingresos.

Cada variante del producto se veía distinta y ofrecía métodos de pago diferentes. Un cambio en un formulario podía romper otra variante sin que se detectara de inmediato, y mantener tests separados para cada combinación habría sido difícil de sostener.

Se creó una suite smoke en Playwright que cubre el happy path y los escenarios de validación en todas las variantes del producto desde una única base compartida de tests.

El resultado es una base limpia y ampliable para automatizar el checkout, útil también para nuevas variantes o métodos de pago. Las nuevas combinaciones se incorporan sin reescribir la lógica existente.

Software testing you can rely on

What I can test

E-commerce testing

SaaS application testing

Web application testing

Mobile app testing

AI & LLM Product Testing

Accessibility Testing

Case studies from real QA work

Release confidence through automation of critical scenarios

Why address QA early

Cost reduction

Release confidence

Better decisions

How we work

Fast project understanding

Recommended approach

Testing execution

Output and next step

Expert blog on QA and testing

How to design a Playwright regression suite that supports releases instead of blocking them

QA audit before release: what to check before you ship

Contact