TGC'26

Poniedziałek 5 października

Testy Playwright napędzane AI - od agentów E2E po inteligentne testy API

•  Generowanie i modyfikowanie testów e2e i API z pomocą AI (framework testowy: Playwright).
• Praca z agentami testowymi i narzędziami MCP / Stagehand.
• Wykorzystanie AI do testów dostępności, danych testowych i walidacji logiki.
• Łączenie AI z CI/CD oraz utrzymanie generowanych testów.

Poniedziałek 5 października

Holistyczne Bezpieczeństwo Aplikacji narzędzia metody standardy i AI

Holistyczne Bezpieczeństwo Aplikacji to praktyczny warsztat dla osób, które chcą wejść w świat security testingu i nauczyć się patrzeć na aplikację z perspektywy ryzyk, podatności oraz realnych zagrożeń.

Podczas szkolenia poznasz podstawy bezpieczeństwa aplikacji, standardy OWASP, pracę z narzędziami takimi jak Kali Linux, Burp Suite, OWASP ZAP i Postman, a także wykorzystanie AI w testach security, analizie podatności i raportowaniu.

Szkolenie jest prowadzone od podstaw, ale obejmuje szeroki zakres tematów: aplikacje Web, API, Mobile, LLM, rekonesans, skany bezpieczeństwa, narzędzia security i praktyczne podejście do raportowania podatności.

Poniedziałek 5 października

Wkrótce ogłosimy

Poniedziałek 5 października

Cursor + Playwright = zrobiło się poważnie

Długo broniłem się przed używaniem AI w pracy. Dziś nie wyobrażam sobie powrotu do ręcznego pisania testów automatycznych. Pół roku temu godzinami i z wielkim trudem generowałem „takie sobie” testy. Dziś robię to błyskawicznie i z dużą przyjemnością. Nie dlatego, że sztuczna inteligencja to magiczny lek na wszystko, ale dlatego, że nauczyłem się mądrze z nią współpracować.

Nie uważam, że AI odbierze ci pracę. Ale jeśli zostaniesz w tyle – z pewnością zrobią to ludzie, którzy potrafią się nią sprawnie posługiwać. Czy Cursor + Playwright to przyszłość testowania? Dlaczego AI jest jak smok? I czy uda nam się nad nim zapanować? Wpadnij, żeby się dowiedzieć!

Poniedziałek 5 października

S.M.U.R.F. w praktyce: Warsztat budowania i optymalizacji testów Playwright. Wyciśnij maksimum z Speed, Reliability i Fidelity

Masz dość testów, które są niestabilne, trudne w utrzymaniu i wydłużają pipeline? Ten praktyczny warsztat pokaże Ci, jak przejść „od flaky do reliable” i budować produkcyjne testy w Playwright i TypeScript.

Skupimy się na AAA (Arrange–Act–Assert) oraz SMURF (Small, Maintainable, Understandable, Repeatable, Fast), czyli podejściu, które pomaga tworzyć małe, czytelne, przewidywalne i szybkie testy oraz usprawnia code review.

W praktyce zajmiemy się m.in. typowanymi fixtures Playwright, bezpiecznym teardownem i strategiami dla kosztownych setupów. Dużo uwagi poświęcimy również testom API i scenariuszom API+UI – wykorzystaniu APIRequestContext, seedowaniu i cleanupowi danych oraz selective mocking.

Nauczysz się diagnozować i refaktoryzować flakujące testy, wdrażać paralelizację i sharding w CI oraz wykorzystywać trace, screenshoty, video i metryki do szybszego znajdowania problemów.

To warsztat nastawiony na praktykę, piszesz kod, uruchamiasz testy i od razu mierzysz efekty zmian. Wyjdziesz z gotowymi wzorcami, checklistą SMURF do code review oraz rozwiązaniami, które pomogą skrócić czas wykonania i zwiększyć stabilność testów.

Poniedziałek 5 października

Szybki feedback w CI/CD: jak zaprojektować pipeline, który buduje, testuje i wdraża bez utraty jakości

Szybki feedback w CI/CD: jak krok po kroku zbudować pipeline, który testuje i raportuje bez utraty jakości
Pipeline CI/CD, którego wykonanie trwa zbyt długo, potrafi skutecznie spowolnić pracę całego zespołu: pull requesty czekają na wyniki, feedback pojawia się zbyt późno, a testy UI często stają się najbardziej kosztownym i najmniej przewidywalnym etapem procesu. W tym warsztacie pokażemy, jak zbudować pipeline, który szybko dostarcza zespołowi informację zwrotną i nie uruchamia najbardziej kosztownych testów wtedy, gdy wcześniejsze kontrole już wykryły problem.

 Uczestnicy otrzymają gotową aplikację demonstracyjną wraz z wyjściowym workflowem CI/CD, który uruchamia wszystkie kroki sekwencyjnie. Warsztat będzie bazował na GitHub Actions jako narzędziu do budowy i optymalizacji pipeline'u. Krok po kroku przebudujemy workflow w bardziej użyteczny pipeline: dodamy build aplikacji, linting, typecheck, podstawowy skan bezpieczeństwa, testy jednostkowe, testy API oraz testy UI. Następnie uporządkujemy poszczególne etapy tak, aby szybkie kontrole wykonywały się jako pierwsze, a bardziej kosztowne testy UI były uruchamiane selektywnie i z czytelnym raportowaniem.

 Podczas warsztatu skupimy się na technikach skracania feedback loop: rozdzielaniu jobów, definiowaniu zależności między etapami, uruchamianiu smoke testów dla pull requestów, ograniczaniu pełnej regresji UI do wybranych scenariuszy, stosowaniu mechanizmu fail-fast, publikowaniu raportów oraz zbieraniu artefaktów. Pokażemy także, jak wykorzystać równoległość i shardowanie testów UI bez potrzeby stawiania dodatkowej infrastruktury w chmurze.

Celem warsztatu nie jest nauka pisania testów od zera, ale zbudowanie pipeline'u, który dostarcza czytelny feedback, pomaga szybko zidentyfikować źródło problemu i podjąć decyzję o kolejnych krokach. Uczestnicy wyjdą z gotowym przykładem struktury CI/CD w GitHub Actions, którą będzie można łatwo zaadaptować do własnych projektów.

Poniedziałek 5 października

RiskStorming - Odkrywanie strategii testów

Ile razy zdarzyło Ci się przetestować coś dokładnie, a i tak najważniejszy błąd wyszedł tam, gdzie nikt nie patrzył? Risk Storming to sposób, żeby to zmienić. Zamiast testować "wszystko po trochu", uczysz się świadomie wybierać, co naprawdę wymaga uwagi.
Podczas warsztatu poznasz metodykę Risk Storming i talię kart TestSphere - narzędzie, które pomaga zespołom wspólnie zidentyfikować ryzyka w aplikacji, zanim staną się problemem na produkcji. Pracując w grupach nad realnym scenariuszem, przećwiczysz proces: określania atrybutów jakościowych, definiowania ryzyk, określenia działań testowych i przełożenia tego na strategię testów.

Co wyniesiesz z tego dnia:
• metodę na to, jak wspólnie z zespołem (developerami, PO, biznesem) zdecydować, co i jak testować,
• umiejętność prowadzenia własnej sesji Risk Storming - od pierwszego atrybutu jakościowego do konkretnego planu działania,
• skuteczną komunikację o ryzykach i priorytetach w zespole,
• konkretne, przećwiczone na realnych case study podejście, a nie tylko teorię.

Dla kogo: dla każdego testera - od juniora, który chce zrozumieć, jak myśleć o ryzyku, po seniora i lidera QA, który chce nauczyć tego swój zespół.

Format: całodniowy, intensywna praca w grupach, po polsku. Karty Test Sphere są opisane po angielsku - wymagana samodzielność czytania. Materiał bazowy: metodyka odwołuje się m.in. do tego materiału: How To Do Risk Based Software Testing Using TestSphere

Poniedziałek 5 października

n8n w służbie testera — od przeklikiwania do workflowów

Ile razy w tygodniu klikasz dokładnie to samo? Sprawdzasz statusy w Jirze, wklejasz linki na Slacka, pilnujesz, czy build nie czerwienieje. n8n — narzędzie low-code, w którym automatyzacje składasz z gotowych klocków — pozwala tę drobnicę oddać workflowom. Spędzimy cały dzień hands-on: budujemy razem, od pustego workflow, w rytmie demo → zadanie solo → rozwiązanie.
Zaczynamy od konceptu Item („n8n nie robi pętli, on iteruje”), przez credentiale i pierwsze wiadomości na Slacku, po monitoring PR-ów z GitHuba: powiadomienie o nowym PR i przypominajka o wiszących, wzbogacana o stan CI i recenzji. Potem Jira: JQL i workflow łapiący awarie. Na koniec AI — zbudujemy agenta nad Jirą, a przede wszystkim własne MCP, które podepniesz pod Claude'a albo Copilota u siebie lokalnie. Domykamy pułapkami produkcyjnymi i wyborem self-hosted vs chmura. Znajomość n8n nie jest wymagana — wystarczą podstawy terminala, pojęcie REST/HTTP i codzienna praca ze Slackiem. Tydzień wcześniej dostajesz PDF z setupem. Wychodzisz z działającym n8n, kompletem workflowów, eksportami JSON i cheatsheetem.

Wtorek 6 października (Sala 1)

Testować, czy nie testować - oto jest pytanie (do agenta). Jak Claude Code, Playwright i AI zmieniają dziś codzienność pracy testera

Hamlet przynajmniej miał prosty wybór. Być albo nie być. Tester ma obecnie gorzej. Co automatyzować, co zostawić, czy ten flaky test naprawiać czy udawać że go nie widać? I tak po kilka razy dziennie. Codziennie.
Claude Code, Playwright i agenty nie odpowiedzą za Ciebie na te pytania. Ale zmieniają ekonomię na tyle, że trzeba je zadać od nowa. Bo jeśli test E2E czy API pisze się trzy minuty zamiast godziny, to nagle automatyzujesz rzeczy o których wcześniej nawet nie myślałeś, że można.
Pokażę jak to wszystko wygląda w praktyce. Pisanie testów Playwright z Claude Code, własne skills pod swój projekt, agenty wykonujący zadania za Ciebie. Plus uczciwa część czyli gdzie AI ściemnia, gdzie się zapętla i czego dalej musisz pilnować sam. Gdzie się sparzyłem, co kosztowało mnie pół dnia debugowania i kiedy lepiej AI nie ufać.
Wyjdziesz z konkretną listą rzeczy do wypróbowania. I z trochę innym myśleniem o tym co dziś znaczy być dobrym testerem.

Wtorek 6 października (Sala 2)

Historia o tym, że testy E2E nie zawsze muszą wyglądać tak samo

Gdyby testy E2E zawsze wyglądały tak samo, nasza praca byłaby nudna. Albo idealna. Niestety, rzadko bywa idealna. Częściej bywa tak: nieustanne zmiany w wymaganiach, goniące terminy, wieczny brak czasu na cokolwiek i presja, że wszystko ma być zrobione „na wczoraj”. Brzmi znajomo? A co jeśli dodamy do tego nagłą transformację zespołu, gdzie testerzy manualni muszą z dnia na dzień zacząć automatyzować, mając drastycznie limitowany czas na mentoring?

Zamiast narzekać na warunki, postanowiliśmy nagiąć zasady. Zapraszam na prezentację, która pokaże, że w testowaniu E2E cel uświęca środki, a kreatywność bywa ważniejsza od sztywnych wzorców projektowych.