TGC'26

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.

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

Jednodniowy, intensywny warsztat pokazujący, jak skutecznie wykorzystać sztuczną inteligencję w automatyzacji testów z użyciem Cypress. Uczestnicy poznają praktyczne zastosowania AI w tworzeniu, analizie i utrzymaniu testów E2E, organizacji projektu testowego oraz integracji z procesami CI/CD. Szkolenie skupia się na realnych scenariuszach projektowych, dobrych praktykach oraz świadomym wykorzystaniu AI jako wsparcia pracy QA.

• AI w pracy QA — narzędzia i realne zastosowania
• Budowa projektu Cypress i POM z pomocą AI
• Generowanie, analiza i debugowanie testów E2E
• Pluginy i rozszerzenia w ekosystemie Cypress
• Integracja z CI/CD i równoległe uruchamianie testów
• Ograniczenia AI i przyszłość automatyzacji testów QA
• Q&A i dyskusja praktyczna

From Logs to Insights: KQL for Test Engineers

Warsztat będzie prowadzony w języku angielskim, jednak Prowadząca komunikuje się w języku polskim i w razie wystąpienia jakichkolwiek barier językowych będzie mogła rozmawiać z uczestnikami w języku polskim. Opis warsztatu: As testers, we often feel that something is wrong in the system but don’t have enough evidence to prove it. Logs, HTTP requests, status codes and response times contain valuable information — if we know how to explore them. In this hands-on workshop, you will learn how to use Kusto Query Language (KQL) to analyze data in Azure environment, investigate failures, and understand application behavior. You will practice writing simple queries to filter data, find errors, calculate failure rates, performance metrics and visualize results with charts. No deep Azure knowledge is required. This session is designed for engineers who want to make data-driven decisions and better investigate issues using real system data. Main takeaways: - Intro: telemetry vs. monitoring vs. observability, and how it supports QA activities. - Use Kusto Query Language (KQL) to query and analyze logs. - Investigate failures and errors by analyzing HTTP status codes, failed requests and source IP activity, etc. - Analyze performance trends using time-based queries and metrics such as average, P90, and P95 response times. - Visualize and interpret log data with charts to support test analysis and reporting. - Leave with set of KQL queries that can be reused/adapted for your projects. Level: Middle QA/Dev/Ops

AI w pracy testera: od frameworków promptowych do workflowów multi-agentowych

Uczestnicy poznają i natychmiast przećwiczą kilka (ilość zależna od grupy, w momencie zgłoszenia nie ma co określać dokładnie ile, w pół roku może się mocno zmienić) frameworków promptowych (CRISPE, Chain of Thought, Tree of Thought, RAG, Few-Shot, CO-STAR, SCQA i inne), z których każdy jest zmapowany na konkretne zadania QA: generowanie test case’ów, analizę edge case’ów, pisanie opisów bugów, budowanie business case’ów dla automatyzacji oraz tworzenie kodu testowego z dokumentacji API. Warsztaty wykraczają poza promptowanie pojedynczego modelu. Uczestnicy poznają możliwości multimodalne — wykorzystanie obrazów, nagrań audio i wideo jako danych wejściowych do raportowania bugów i analizy UI — oraz dowiedzą się, jak Model Context Protocol (MCP) umożliwia agentom AI orkiestrowanie prawdziwych narzędzi: Jiry, Confluence, GitHuba i Slacka w zunifikowanych workflow’ach. Na zakończenie omówimy scenariusze multi-agentowe, w których różne narzędzia AI współpracują nad złożonymi zadaniami QA: od incident response po migrację frameworków. Każde pojęcie jest utrwalane ćwiczeniami na żywo. Uczestnicy wychodzą z osobistą biblioteką promptów, gotowymi szablonami i jasnym zrozumieniem, które narzędzie AI użyć do którego zadania QA.

Testowanie data pipelines w praktyce - warsztat dla QA

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ć!

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

1. SMURF jako model oceny testów Speed, Maintainability, Utilization, Reliability, Fidelity jako praktyczne kryteria architektury testów. Analiza kompromisów między szybkością, stabilnością i realizmem testów. Identyfikacja antywzorców w istniejącym suite. 2. Reliability w Playwright Auto-waiting i actionability checks jako fundament stabilnych testów. Lokatory odporne na zmiany: getByRole, getByLabel, getByTestId. Eliminacja flaky tests: race conditions, złe selektory, nadmiar wait. 3. Speed i optymalizacja wykonania Redukcja długości scenariuszy E2E i przenoszenie walidacji na niższe poziomy. Równoległość: workers, projekty, fullyParallel, organizacja suite pod CI. Optymalizacja setupu, danych i izolacji testów. 4. Fidelity i kontrola środowiska Kiedy testować pełne E2E, a kiedy używać mocków. Mockowanie sieci przez page.route() / browserContext.route(). Budowa kontrolowanych scenariuszy błędów i przypadków brzegowych. 5. Refaktoryzacja i diagnostyka Trace Viewer jako narzędzie analizy błędów i flakiness. Przebudowa niestabilnych testów na bardziej deterministyczne. Review architektury testów pod kątem SMURF. 6. Capstone Optymalizacja istniejącego flow biznesowego w Playwright. Skracanie testów, poprawa stabilności i zwiększanie diagnostyczności. Finalny zestaw dobrych praktyk do wdrożenia w projekcie.

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

RiskStorming - Odkrywanie strategii testów

Warsztat całodniowy, na bazie https://www.youtube.com/watch?v=oZCQJrkHyw4 Język: Polski Grupa docelowa: Wszyscy testerzy – od juniorów po seniorów i liderów QA Opis warsztatu: Warsztat wprowadza uczestników w metodę RiskStorming – praktyczne podejście do testowania opartego na ryzyku z wykorzystaniem talii kart TestSphere. Uczestnicy w grupach pracują nad realnymi scenariuszami, identyfikując obszary ryzyka w aplikacjach i priorytetyzując działania testowe. Warsztat łączy teorię z intensywną praktyką – każdy uczestnik wychodzi z gotową techniką, którą może zastosować następnego dnia w swojej pracy. Czego uczestnicy się nauczą: - Czym jest risk-based testing i dlaczego warto go stosować – Jak używać kart TestSphere do identyfikacji ryzyk – Jak priorytetyzować testowanie w oparciu o ryzyko biznesowe i techniczne – Jak przeprowadzić sesję RiskStorming w swoim zespole

Don’t be flaky! Stabilizacja drogą do niezawodnych automatów w praktyce (Selenium + Java)

Flaky tests są jedną z większych bolączek w automatyzacji testów. Warsztat oparty o prelekcje wygłoszoną na 3 konferencjach pokaże praktyczne zastosowanie omawianych tam technik. Wykorzystamy framework na bazie Selenium oraz prostą aplikację webową. Celem warsztatu jest przekazanie sprawdzonych praktyk wykrywania, zapobiegania i naprawiania flaky tests. Dzięki kilkunastu latom doświadczenia zeszliśmy z flaky tests do poziomu < 0,5% na Quality Gates. Warsztat zrealizowany i wysoko oceniony na ConSelenium 2024 (ocena 4.9/5) i TestWarez 2025 (ocena 4.625/5). Agenda warsztatu: 1. Wprowadzenie i setup projektu - Analiza przyczyn i skutków flaky tests. - Dyskusja nad problemami uczestników. 2. Metoda stabilizacji i separacja kodu - Autorska metoda stabilizacji testów - jak, kiedy, ile razy? - Ćwiczenie: Jak odseparować niestabilny kod oraz testy od stabilnego. - Ćwiczenie: Implementacja skryptu do stabilizacji testów i analiza wyników. 3. Logowanie i raportowanie - Ćwiczenie: Jak usprawnić raport o niezbędne logi i załączniki - Ćwiczenie: Pokazanie w praktyce trendów i historii test case’ów. - Ćwiczenie: Budowa czytelnego timeline’u w Allure. - Ćwiczenie: Automatyczne logowanie metod (AspectJ). 4. Case study wybranych flaky tests Najdłuższa część warsztatu wraz z demo analizy flaky tests przez agenta AI - Ćwiczenie: Właściwe oczekiwania na dynamicznie zmieniające się elementy na GUI. - Ćwiczenie: Sposób na ponawianie nieudanych clicków. - Ćwiczenie: Problemy „nierozwiązywalne” - mechanizm „Repeat”. 5. Bonus - Pozytywne efekty uboczne stabilizacji testów. - Złoty środek pomiędzy kosztami automatyzacji a zaufaniem do wyników na QG. Testy Selenium wciąż są obecne w wielu projektach. Często brakuje im stabilności. Uczestnicy wrócą zatem z wieloma usprawnieniami, które będą mogli wdrożyć w swoich projektach.

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

Warsztat wprowadzający do n8n dla testerów — automatyzacja procesów wokół testów (powiadomienia, monitorowanie, raportowanie) bez pisania kodu. Znajomość n8n NIE jest wymagana. Plan 6 bloków: 1. Hello World i koncept Item — fundament dla wszystkich kolejnych workflowów („n8n nie robi pętli, on iteruje"). 2. Triggery + credentials + bootstrap workflow tworzący testowy projekt w Jirze/Trello (~30s zamiast 15 min klikania) → pierwszy własny workflow „Slack pinger". 3. Logika i transformacja + workflow „PR Notifier z kontekstem z Jiry/Trello" (Schedule + GitHub API + IF + Slack). 4. Data Tables, sub-workflowy, error workflow → workflow „Mini monitor statusów Jiry/Trello". 5. AI w n8n: AI Agent, prompt design, limity tokenów. Agent jako „doradca" vs „pracownik" → workflow „AI sumaryzator". 6. Pułapki produkcyjne (code review workflowów, multi-user, backupy w self-hosted) + self-hosted vs cloud. Co uczestnik wynosi: działającego n8n na własnej maszynie, zestaw workflowów spiętych ze Slackiem, GitHubem i Jirą/Trello, ZIP z eksportami JSON + bootstrap workflow + cheatsheet (1 strona A4). Format: hands-on follow-along, n8n lokalnie w Dockerze (cloud free jako backup), architektura outbound + polling. Grupa 12–18 osób. Pre-workshop (PDF przez organizatora ~tydzień przed): instalacja Dockera + n8n self-hosted lub konto n8n.cloud, podstawy terminala, pojęcie REST/HTTP, korzystanie ze Slacka i GitHuba.

Audyt jakości oprogramowania - jak ocenić i poprawić jakość w organizacji

Agentic QA in large codebases, fixed

Testowanie dostępności w 2026: co zrobi za Ciebie AI (i jak to sprawdzić w praktyce)

1.Wprowadzenie: czym jest „testowanie dostępności w 2026” i gdzie w tym miejscu znajduje się AI 2.Szybkie przypomnienie podejścia klasycznego: narzędzia automatyczne (axe), testy manualne, screen reader 3.Praca na wspólnym case study (ta sama aplikacja / komponent dla wszystkich uczestników) 4.Testowanie klasyczne w praktyce: analiza wyników z narzędzi automatycznych identyfikacja problemów niewykrywalnych automatycznie testy z użyciem screen readera 5.Testowanie z wykorzystaniem AI / agentów: generowanie scenariuszy testowych analiza dostępności przez AI interpretacja wyników i potencjalne błędy / halucynacje 6.Porównanie wyników: AI vs narzędzia vs tester 7.Najczęstsze pułapki i ograniczenia AI w testowaniu dostępności 8.Jak sensownie włączyć AI do procesu QA (praktyczne wskazówki) 9.Podsumowanie + checklist: co warto zabrać do codziennej pracy