TestWarez 2025 – recenzja: co naprawdę wyniósł z konferencji doświadczony QA engineer

TestWarez 2025 to trzydniowa konferencja poświęcona testowaniu oprogramowania, która odbyła się w listopadzie 2025 roku w Polsce. Składała się z jednego dnia warsztatowego i dwóch dni prelekcji. Wszystko kręciło się niemal wyłącznie wokół Playwright’a i automatyzacji testów. Dla doświadczonych inżynierów QA konferencja przyniosła mieszane efekty: warsztaty nastawione wyłącznie na początkujących, ale dwie lub trzy prelekcje, które realnie zmieniają sposób myślenia o współpracy między developerami, a QA.

Oto co konferencja rzeczywiście dostarczyła.

Czym jest TestWarez i dla kogo jest przeznaczony?

TestWarez to jedna z największych konferencji testerskich w Polsce, organizowana co roku od ponad dekady. Edycja 2025 zgromadziła kilkaset uczestników przez trzy dni i zdominowana była przez jeden temat: Playwright – framework do automatyzacji przeglądarek rozwijany przez Microsoft.

Publiczność to przede wszystkim testerzy manualni chcący wejść w automatyzację. Ten kontekst jest kluczowy przy ocenie poszczególnych sesji.

Warsztat z Playwrighta: 8 godzin, poziom podstawowy, zero niespodzianek

Pierwszy dzień to całodniowy warsztat: Techniczne testowanie w Playwright z TypeScriptem. Osiem godzin. Dwadzieścia-trzydzieści osób. Hotelowe krzesła.

Na początku każdy uczestnik przedstawił się i opisał swoje doświadczenie. Sala składała się niemal wyłącznie z testerów manualnych stawiających pierwsze kroki w automatyzacji, co nadało ton całej reszcie dnia. Dla kogoś pracującego z Playwright’em na co dzień warsztat nie przyniósł żadnej nowej wiedzy.

Logistyka była w porządku. Wi-Fi – nie (uratował hotspot). I nie było możliwości zmiany warsztatu w trakcie, gdy już wiadomo było, że poziom nie odpowiada oczekiwaniom.

Większy problem to kwestia strukturalna, którą potwierdzili niezależnie kilkoro kolegów: polskie konferencje testerskie nadal nie oznaczają poziomów zaawansowania sesji. Gdy 99% warsztatów celuje w uczestników z zerowym lub minimalnym doświadczeniem, inżynieżyna średnim i seniorskim poziomie albo uczestniczą w tematach, które już znają, albo omijają ten dzień w całości. To luka, którą warto adresować w kolejnych edycjach.

3 prelekcje warte uwagi

Dni wykładowe były mocniejsze. Spośród ośmiu sesji trzy wyróżniają się wyraźnie.

Vitest + Playwright: ta sama składnia, różne warstwy

Prelekcja, która najbardziej wpłynęła na nasze podejście do architektury testów w fireup.pro, to Playwright + Vitest Arkadiusza Jelonka – prelegenta, którego znałem z poprzedniej edycji TestWarez i który konsekwentnie dostarcza konkretną wartość inżynierską.

Główna teza: jeśli automatyzujesz całą piramidę testów narzędziami o niemal identycznej składni, eliminujesz ukryty punkt tarcia, który istnieje w większości zespołów QA. Vitest obsługuje testy jednostkowe. Playwright – integracyjne i end-to-end. Oba mają podobne API, podobny model mentalny i zbliżoną konfigurację.

Praktyczna konsekwencja jest istotna. Gdy developer pisze testy jednostkowe w Vitest, a QA engineer pisze testy E2E w Playwright, oboje mogą czytać swój kod bez dużej krzywej uczenia się. To naturalny most. Developerzy mogą współtworzyć testy wyższego poziomu, QA inżynierzy i testerzy rozumieją, co jest już pokryte na poziomie jednostkowym i decyzje o pokryciu stają się rozmową zespołu, a nie przekazaniem pałeczki.

Jeśli Twój zespół już korzysta z Playwright’a do E2E, dodanie Vitest do testów jednostkowych to najniżej wiszący owoc na drodze do spójnej, pełnowarstwowej automatyzacji.

Testy dostępności to problem frontendowy, który QA musi brać na siebie

Łukasz Nowak, frontend developer, poprowadził sesję o automatyzacji testów dostępności i wskazał coś, co w rozmowach QA często umyka: zgodność z WCAG jest technicznie złożona, a QA to ostatni punkt kontrolny przed użytkownikiem.

Pokazany podział odpowiedzialności był wymowny. To, za co odpowiada UX, jest stosunkowo wąskie — kontrasty, hierarchia wizualna, stany fokusa. To, co muszą zaimplementować developerzy, jest znacznie bardziej złożone semantyczny HTML, atrybuty ARIA, nawigacja klawiaturą, kompatybilność z czytnikami ekranu. I jest to rutynowo pomijane w testch aplikacji. 

Dwa demonstrowane narzędzia:

Google Lighthouse działa bezpośrednio z Chrome DevTools i generuje natychmiastowy, natychmiastowy audit dostępności z konkretnymi wskazówkami. Niski próg wejścia – nie ma powodu, żeby nie uruchamiać go przy wypuszczaniu nowej wersji aplikacji.  

Axe, zintegrowany przez oficjalną bibliotekę @axe-core/playwright, pozwala wbudować sprawdzanie WCAG bezpośrednio w istniejący zestaw testów Playwright. Jedno wywołanie, automatyczne pokrycie najczęstszych błędów dostępności.

Przy obowiązującym już European Accessibility Act to nie jest kwestia opcjonalna. Dla zespołów budujących produkty cyfrowe w sektorze healthcare czy fintech dla klientów z regionu DACH dostępność to wymóg zgodności, a narzędzia są dostępne od ręki.

W dobie AI nadal potrzebujemy inżynierów, którzy myślą

Mateusz Jabłonowski poprowadził najbardziej dyskutowaną prelekcję konferencji: W dobie AI ciągle potrzebujemy dobrych inżynierów. Argument był prosty i w dużej mierze trafny.

AI przejmie powtarzalne, oparte na regułach zadania w tym części pracy QA, które da się niezawodnie zautomatyzować. Ale warstwa weryfikacji pozostaje ludzka. Ktoś musi ocenić, czy AI-generowane przypadki testowe są sensowne, czy pokrycie jest znaczące, czy wynik jest akceptowalny dla klienta w regulowanej branży.

Głębszy wniosek: logiczne myślenie, rozpoznawanie wzorców i analiza domeny nie znikają. Zmienia się to, że inżynierowie, którzy opierali się wyłącznie na powtarzalnych elementach pracy, będą najbardziej narażeni.

Końcowe przesłanie było dosadne: mieć plan B. Wiedzieć, co zrobisz, jeśli Twoja rola ulegnie drastycznej zmianie. To nie pesymizm, lecz zawodowa higiena, ta sama logika, która stoi za przemyślanymi decyzjami o certyfikatach i doszkalaniu.

Prelekcja, która uratowała drugi dzień

Sesja Michała Wilkowskiego Tester z ADHD: złoczyńca czy bohater? była najbardziej niespodziewanie wartościową prelekcją całej konferencji. Omówiła, jak cechy ADHD (hiperfokus, wykrywanie wzorców, nietolerancja niespójności) przekładają się na pracę QA z korzyścią, gdy są dobrze ukierunkowane, i destrukcyjnie, gdy nie.

Sesja jest teraz dostępna po polsku – obejrzyj na YouTube. Warto, nawet jeśli ADHD Cię nie dotyczy: rzuca nowe światło na to, co tak naprawdę oznacza dobra praca w QA.

Ogólna ocena

Uczciwa rekomendacja: TestWarez to doskonała konferencja dla testerów manualnych wchodzących w automatyzację. Dla zespołów prowadzących już dojrzałe pipeline’y Playwright ROI jest trudniejszy do uzasadnienia – budżet lepiej przeznaczyć na ukierunkowane szkolenie lub certyfikat, w zależności od tego, czy optymalizujesz proces, czy prowadzisz projekt.