Wstęp

Kim jesteśmy?

Krzysiek Kijas
Senior Software Quality Engineer, Tech Lead, Mentor
Zwycięzca ogólnopolskiego plebiscytu
Ludzie Testowania 2024 (testerzy.pl)
Microsoft Most Valuable Professional (MVP)
profil na LinkedIn
Microsoft Most Valuable Professional (MVP)
O doświadczeniu...
  • Jako Tech Lead odpowiada za architekturę automatów z Playwright.
  • Z testowaniem i dbaniem o jakość oprogramowania jestem profesjonalnie związany od 2011.
  • Nabywałem doświadczenie w wielu projektach IT z różnych domen biznesowych (transport, finanse, administracja, zarządzanie systemami).
  • Posiadam doświadczenie praktyczne w pracy z różnymi narzędziami CI/CD (Jenkins, GitLab CI, Azure DevOps).
  • W codziennej pracy dbam o szeroko pojętą jakość w projekcie – poczynając od projektowania testów i strategii testowania, definiowanie i usprawnianie procesów, konsultacje rozwiązań, aż po tworzenie i projektowanie architektury frameworków do testów automatycznych.
  • Od 2014 zdobywam doświadczenie jako trener poprzez prowadzenie warsztatów dotyczących jakości, pisania testów i narzędzi wspomagających testowanie.
  • Współtworzę inicjatywę jaktestowac.pl, gdzie od początku przygotowuje kursy i materiały dla Nowoczesnych Testerów.
Przemek Barański
Senior Software Quality Engineer, Principal Engineer
Zwycięzca ogólnopolskiego plebiscytu
Ludzie Testowania 2024 (testerzy.pl)
Microsoft Most Valuable Professional (MVP)
profil na LinkedIn
Microsoft Most Valuable Professional (MVP)
O doświadczeniu...
  • Rozwija frameworki w Playwright do testów GUI oraz API zintegrowane z procesami CI/CD
  • Komercyjnym testowaniem oprogramowania zajmuje się od ponad 10 lat!
  • Specjalizuje się w tematach performance i automation, które praktycznie wykorzystuje przy zapewnieniu jakości dla globalnych systemów informatycznych.
  • Trenuje testerów od 2015, nie tylko online, ale też bezpośrednio na warsztacie, meetupie, konferencji czy uczelni.
  • Twórca bezpłatnych treści wspomagających testerów w całej Polsce ze stawianiem swoich pierwszych kroków w różnych obszarach testowania (vlog, Git dla Testerów, Podstawy Automatyzacji).
  • Zafascynowany technicznym rozwojem oraz upraszczaniem poznanych konceptów do łatwych i przyjemnych treści 😀
  • Tester nie tylko aplikacji ale i praktyk związanych z życiem, rozwojem i szeroko rozumianą jakością.

Jak wspieramy i dzielimy się wiedzą o Playwright?

Prelekcja: Złam zasady, zyskaj przewagę: sekrety podejść do testów automatycznych z Playwright

Czy w automatyzacji naprawdę musimy zawsze “grać według podręcznika”?
Oraz trzymać się sztywno “złotych zasad” automatyzacji testów?
Podczas tej prelekcji pokażemy Ci, że świadome łamanie utartych schematów nie musi oznaczać chaosu. A nawet – może otworzyć drogę do skuteczniejszych, elastycznych i szybszych testów.

Zaprezentujemy niestandardowe, czasem kontrowersyjne rozwiązania z wykorzystaniem Playwright pozwalajacymi zyskać przewagę nad typowymi strategiami.

Dowiesz się między innymi:

  • Jak celowo omijać powszechne reguły (np. kazdy test musi być niezależny czy asercje na poziomie testów), by uprościć kod i zwiększyć produktywność.
  • W jaki sposób niestandardowe hooki i dynamiczne konfiguracje pomagają testować złożone scenariusze szybciej i pewniej.
  • Kiedy i dlaczego warto “złamać” najlepsze praktyki, by dostosować automatyzację do swojego projektu – bez zbędnych kompromisów.

Jeśli chcesz uwolnić potencjał Playwrighta, wykorzystując go w nieszablonowy sposób, ta prezentacja jest dla Ciebie. Przygotuj się na świeże spojrzenie, garść niekonwencjonalnych trików i solidną dawkę inspiracji.

Bo czasem warto odejść od podręcznikowych wzorców, by wypracować realną przewagę w testach! 😉

Prezentacja

Prezentacje możesz pobrać klikając poniższy obrazek:

Lub za pomocą linka: Prezentacja

Poruszone tematy

🔒 Zasada: Jeden test – jedna asercja?

  • Stara dobra zasada… ale czy zawsze ma sens?
  • W rzeczywistości wiele przypadków testowych naturalnie wymaga kilku niezależnych weryfikacji.
  • W Playwright możemy skorzystać z soft asercji: 
    expect.soft(form.name).toBe('Harry');
expect.soft(form.age).toBe(55);
expect.soft(form.surname).toBe('Potter');
expect(form.submit).not.toBeNull();
  • Soft asercje to specjalny mechanizm – pozwalają wykonać kilka weryfikacji i nie zatrzymują testu przy niepowodzeniu. Dopiero na końcu testu sprawdzane są błędy zebrane z soft asercji – jeśli były jakieś błędy, test zostaje oznaczony jako zakończony niepowodzeniem.
  • ✅ Można łamać zasadę jeden test-jedna asercja: przy jednorodnych kontekstach (np. formularz) lub sprawdzaniu niezależnych elementów (kilka elementów na tej samej stronie).
  • ⚠️Uważaj: Powinniśmy unikać w testach, gdzie chcemy szybki feedback.
  • ⚠️Uważaj: Asercje w Playwright mają mechanizm auto-czekania, a tym samym czekają na elementy na stronach. Przy wielu soft asercjach, które kończą sie niepowodzeniem, może się okazać że nasze testy trwają bardzo długo.
TIP: Poszerz swoją wiedzę z darmowymi materiałami o Playwright:

📁 Asercje tylko w testach?

  • Dlaczego nie w metodach Page Object?
  • Kod testu staje się czystszy i wykorzystujemy wbudowany mechanizm auto-wait w Playwright.
  • Przykład: 
    async assertCreatedComment() {
  await expect.soft(this.publishButton).toBeDisabled();
  await expect.soft(this.successMessage).toBeVisible();
}
  • Soft asercje pozwalają zebrać wszystkie błędy zamiast zatrzymać się na pierwszym.
  • ✅ Można łamać: Przy często powtarzanych walidacjach w wielu testach — wspólna metoda skraca kod i upraszcza czytanie.
  • ⚠️Uważaj: Może zaburzyć przejrzystość, gdy asercje znikają z testu i trzeba ich szukać w obiektach stron.
  • ⚠️Uważaj: Konfiguracja ESLinta (lub innych linterów) ma reguły, wykrywające brak asercji w testach.
  • ⚠️Uważaj: Rozważ różne opcje i ich plusy i minuse. Nastepnie spisz decyzje w decision log i coding standards.
TIP: Poszerz swoją wiedzę z materiałami:

🔗 Testy niezależne?

  • “Zawsze niezależne” to mit. Czasem zależność to świadomy wybór: np. testy e2e.
  • Przykład: 
    test.describe.serial('User journey', () => {
  test('adds to cart', ...);
  test('goes to checkout', ...);
  test('places order', ...);
});

    Dzięki takiemu podziałowi test.describe staje się testem, a test staje się krokiem całego testu. Pozwala to na otrzymywanie czytelnych wyników testów.

  • ✅ Można łamać: Przy testowaniu całych ścieżek biznesowych (np. journey test, e2e), gdzie poszczególne kroki zależą od poprzednich (np. aby wykonać zakup potrzebujemy konta użytkownika).
  • ⚠️Uważaj: Trudniejsze debugowanie, bo błąd w jednym kroku unieruchamia kolejne kroki.
  • ⚠️Uważaj: Powinniśmy utrzymuj minimalne zależności i brak współdzielenia danych – testów zależnych nie zrównoleglisz!
TIP: Poszerz swoją wiedzę z darmowymi materiałami o Playwright:

🎥 Nagrywanie testów to amatorszczyzna?

  • Nagrywanie testów może być świetnym sposobem, aby wystartować z projektem, przygotować POC, do eksploracji czy nauki.
  • W Playwright do nagrywania testów służy narzędzie codegen.
  • Generuje bazowy kod: 
    await page.locator('#firstName').fill('John');
await page.locator('#email').fill('john@example.com');
  • ✅ Można łamać: Podczas szybkiej eksploracji, prototypowania, warsztatów lub onboardingu testerów.
  • ⚠️Uważaj: Nigdy nie zostawiaj nagranego kodu bez refaktoru i weryfikacji – to jedynie baza pod dalszy refactor i wprowadzenie kolejnych wzorców.
TIP: Poszerz swoją wiedzę z darmowymi materiałami o Playwright:

♿ Dostępność? A11y testy automatyczne to za mało!

  • Automaty sprawdzające accesibility pozwalają wykryć wstępnie wiele różnych problemów.
  • Przykład testu: 
    const results = await new AxeBuilder({ page }).analyze();
expect(results.violations).toEqual([]);
  • ✅ Można łamać: Dla uzyskania szybkiej informacji zwrotnej i integracji z CI/CD.
  • ⚠️ Uważaj: Testy automatyczne nie zastąpią eksperta ds. WCAG.
TIP: Poszerz swoją wiedzę z darmowymi materiałami o Playwright:

👀 Visual Testing = nieefektywny?

  • Jeśli nie zaplanujesz co chcesz testować – to utrzymanie takich testów może być bardzo kosztowne.
  • Jeśli dobrze zaplanujesz: fantastyczne uzupełnienie testów regresji!
  • Mockowanie API i ignorowanie obszarów poprawia stabilność.
  • ✅ Można łamać: Gdy testujesz wygląd komponentów, branding, style.
  • ✅ Można łamać: Gdy chcesz przetestować prezentacje danych (wykresy), jednocześnie stabilizując dynamiczne dane (mockowanei API).
  • ⚠️ Uważaj: Nie nadaje się do całych stron dynamicznych. Potrzebna dobra strategia i narzędzia.
TIP: Poszerz swoją wiedzę z darmowymi materiałami o Playwright:

🤜 Piszemy tylko w tym co znamy?

  • Nie zamykaj się na nowe technologie!
  • Spróbuj Playwrighta, Vitest, Copilota.
  • Często to nie tylko nowe narzędzia – to nowe paradygmaty, które mogą pokazać Ci nowe podejścia i możliwości.
  • ✅ Można łamać: Przy testowaniu czegoś nowego, budowie frameworka, nauce.
  • ⚠️ Uważaj: W produkcji bez wsparcia i wiedzy technicznej może to generować problemy i frustrację zespołu.

🤖 AI = chaos?

  • Nie, jeśli masz wiedzę i umiejętność krytycznej oceny wyników.
  • Copilot i inne narzędzia to szansa, ale wymagają dojrzałości w użyciu.
  • ✅ Można łamać: Kiedy AI przyspieszą Twoją pracę, np. przy generowaniu kodu testów, refaktorach, szukaniu błędów.
  • ⚠️ Uważaj: AI nie zna Twojej domeny, nie wie co oznacza “dobry test”. Weryfikuj, analizuj, podchodzi krytycznie do rozwiązań zaproponowanych przez AI – nie kopiuj bezrefleksyjnie!
  • ⚠️ Uważaj: Wiele firm lub projektów ma specyficzne wymagania dotyczące prywatności! Również uważaj jakie informacje przesyłasz do AI (ChatGPT, DeepSeek etc) – przesłane informacje mogą zostać wykorzystane podczas uczenia modeli AI.
TIP: Poszerz swoją wiedzę z darmowymi materiałami o Playwright:

🔄 Podsumowując

  • Złam zasady tam, gdzie masz kompetencje i świadomość zagrożeń
  • Nowoczesne narzędzia dają ogromne możliwości – korzystajmy z nich mądrze!
  • Komunikacja w zespole i przejrzystość decyzji to klucz. Pamiętaj o wypisywaniu wad i zalet danych decyzji.
  • POC może pomóc Ci zrozumieć dane narzędzie w Twoim kontekście.
  • ⚡ Odwaga eksperymentowania daje przewagę!

Linki

Poniżej znajdziesz rozszerzenie różnych materiałów: