Jak zacząć automatyzację regresji w Playwright

Dlaczego regresja trwa za długo

Ręczna regresja rośnie razem z produktem. Każda nowa funkcja to kolejne scenariusze do sprawdzenia przed releasem, a liczba osób, które je klikają, zwykle się nie zmienia. W jednym z moich projektów automatyzacja regresji skróciła czas jej wykonania o 80%, ale nie dlatego, że zautomatyzowaliśmy wszystko. Zautomatyzowaliśmy właściwe rzeczy, w dobrej kolejności.

Automatyzacja ma sens, gdy:

• te same scenariusze sprawdzacie przed każdym wydaniem,
• funkcja jest stabilna i nie zmienia się co sprint,
• błąd w danym miejscu kosztuje dużo (logowanie, płatność, zamówienie).

Pierwszy test w Playwright

Zacznij od scenariusza, który zespół i tak sprawdza ręcznie przed każdym releasem, np. logowania. Test powinien mieć jedną odpowiedzialność i korzystać z lokatorów opartych na roli i etykiecie, a nie na klasach CSS. Polecenie npx playwright test uruchomi go lokalnie.

import { test, expect } from '@playwright/test';

test('loguje użytkownika poprawnymi danymi', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('E-mail').fill('[email protected]');
  await page.getByLabel('Hasło').fill(process.env.QA_PASSWORD!);
  await page.getByRole('button', { name: 'Zaloguj' }).click();
  // oczekiwany wynik: panel użytkownika
  await expect(page.getByRole('heading', { level: 1 })).toHaveText('Panel');
});

Lokatory getByRole i getByLabel działają tak, jak użytkownik widzi stronę. Zmiana klasy CSS czy struktury div ich nie zepsuje, a przy okazji wyłapią problemy z dostępnością, np. pole bez etykiety.

Struktura projektu

Kilka zasad, które oszczędzają godziny utrzymania:

• Jeden plik, jeden obszar funkcjonalny. login.spec.ts, checkout.spec.ts, a nie tests1.spec.ts.
• Dane testowe poza testami. Konta, produkty i adresy trzymaj w fixture’ach albo twórz przez API przed testem.
• Logowanie raz. Playwright pozwala zapisać stan zalogowanej sesji (storageState) i użyć go w kolejnych testach. Nie loguj się przez UI w każdym teście.
• Niezależne testy. Każdy test musi działać sam, w dowolnej kolejności. Inaczej równoległe uruchamianie zamieni się w loterię.

Nie automatyzuj scenariusza, który zmienia się co sprint. Poczekaj, aż funkcja się ustabilizuje.

Co automatyzować najpierw

Ułóż listę scenariuszy z regresji i oceń każdy w dwóch wymiarach: jak często go sprawdzacie i ile kosztuje błąd. Zacznij od tych, które są wysoko w obu.

Dane w tabeli są przykładowe, ale proporcje zgadzają się z tym, co widuję w projektach.

Kiedy podpiąć testy pod CI

Od pierwszego dnia. Test, który działa tylko na laptopie autora, nie chroni przed regresją. Zacznij od uruchamiania testów przy każdym pull requeście do głównej gałęzi, z raportem HTML jako artefaktem. Playwright generuje go jednym poleceniem i pokazuje zrzuty ekranu oraz nagranie przebiegu dla testów, które nie przeszły.

Gdy zestaw urośnie, podziel go na szybki smoke (kilka minut, przy każdym PR) i pełną regresję (nocą albo przed releasem). Szczegóły opisałem w poradniku Regresja w CI.

Podsumowanie

Automatyzacja regresji to nie projekt “napiszmy testy do wszystkiego”. To seria małych kroków: jeden stabilny scenariusz, uruchamiany w CI, potem kolejny. Jeśli chcesz, żebym pomógł Ci zacząć albo uporządkować istniejące testy, opisz swój projekt.