05 października 2026 (warsztaty 9:00-17:00)
Radosław Wasik
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.
Grzegorz Holak
Konrad Gomulski
AI w pracy testera: od frameworków promptowych do workflowów multi-agentowych
Podczas warsztatu przekażemy uczestnikom praktyczną wiedzę o tym, jak testerzy mogą wykorzystywać AI w codziennej pracy — nie tylko do pojedynczych zapytań, ale jako realne wsparcie całego procesu testowego. Zaczniemy od krótkiego self-checku, który pomoże uczestnikom określić swój obecny poziom pracy z narzędziami AI. Następnie przejdziemy przez skalę adopcji AI: od poznania i stosowania frameworków promptowych, przez świadomą pracę z kontekstem, aż po projektowanie bardziej zaawansowanych workflowów z użyciem agentów i podejścia multi-agentowego. Warsztat będzie nastawiony na rozwijanie praktycznych umiejętności, które pomagają testerom lepiej analizować wymagania, projektować testy, generować dane, wspierać automatyzację i usprawniać codzienne zadania. Ze względu na dynamiczny rozwój narzędzi AI, finalny zakres oraz przykłady używane podczas szkolenia zostaną dopracowane około miesiąc przed warsztatem, aby zapewnić uczestnikom możliwie aktualną i praktyczną wiedzę. Po zakończeniu warsztatu uczestnicy otrzymają dodatkowe ćwiczenia oraz propozycje dalszego planu rozwoju w obszarze AI w pracy testera, tak aby każdy mógł samodzielnie utrwalać i rozwijać zdobyte umiejętności również po zajęciach.
Michał Wilkowski
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ć!
Krzysztof Kołodziejczyk
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.
Tomasz Klepacki
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.
Tomasz Jański
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
Kamil Iwanowicz
Krystian Mikła
Agentic QA w dużych projektach
- Jak inicjalizować AI w istniejącym projekcie
- Dlaczego zasada „więcej kontekstu = lepsze wyniki” nie zawsze działa
- Co uwzględnić w dokumentacji dla AI, a czego unikać
- Jak selektywnie wczytywać dokumentację do kontekstu agenta
- Jak projektować orkiestrację - fazy, subagenci i pętla feedbacku
- Jak utrzymywać dokumentację niskim kosztem
- Jak sprawić, żeby agent z każdym zadaniem stawał się coraz lepszy
Katarzyna Basiewicz
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
06 października 2026 (prelekcje) Sala 1
Oficjalne rozpoczęcie konferencji
Otwarcie konferencji
Grzegorz Holak
Filip Barszcz
Polityka i strategia testów jako elementy governance w organizacjach technologicznych
Piotr Zając
Od automatyzacji do autonomii: Agenci AI w Dark Testing Factory
Automatyzacja testów przestaje oznaczać wyłącznie wykonywanie wcześniej przygotowanych skryptów. Dark Testing Factory to koncepcja autonomicznego systemu jakości, w którym agenci AI mogą planować testy, przygotowywać dane i środowiska, uruchamiać scenariusze, analizować wyniki oraz utrzymywać testy wraz ze zmianą aplikacji. Podczas wystąpienia przyjrzymy się, jak zmienia się rola testera, gdzie potrzebny jest ludzki osąd oraz jakie wyzwania przynoszą niedeterminizm, halucynacje, regresje modeli i testowanie decyzji, a nie tylko interfejsu.
Tomasz Stelmach
Zarządzanie jakością w dużej organizacji. Trzy nowe fronty: AI, bezpieczeństwo, dostępność
Sztuczna inteligencja przyspieszyła pisanie kodu, ale nie przyspieszyła jego sprawdzania. Do tego NIS2 i KSC przenoszą odpowiedzialność za bezpieczeństwo na zarząd i na łańcuch dostaw, a Europejski Akt o Dostępności od czerwca 2025 roku zamienił dostępność cyfrową w obowiązek prawny. W dużej organizacji jakość przestała być sprawą samego działu testów.Na przykładach z ponad 150 projektów Quality Island, od strategii jakości w sektorze bankowym po budowę działu automatyzacji testów, pokażę, jak zarządzać tymi trzema frontami jednym systemem, a nie trzema osobnymi projektami. Zobaczycie, dlaczego większość firm utyka na etapie pilota AI, jak przenieść bezpieczeństwo z pentestu do Definition of Done i gdzie w organizacji wpisać dostępność, żeby nie była najdroższą poprawką przed wdrożeniem.Wyjdziecie z listą pięciu pytań, które warto w poniedziałek zadać we własnym zespole QA.
Artur Ziółkowski
Your Spec Can Write Your Code
Przez lata specyfikacje były traktowane głównie jako dokumentacja, a w wielu projektach zastępowały je wiadomości, tickety i ustalenia między zespołami. Kod pozostawał ostatecznym źródłem prawdy.Rozwój AI może jednak zmienić ten model pracy. Coraz większego znaczenia nabiera Specification Driven Development (SDD), czyli podejście, w którym punktem wyjścia do tworzenia oprogramowania jest precyzyjna specyfikacja.Podczas prelekcji na przykładzie projektu REST API zobaczymy, jak specyfikacja może stać się podstawą kolejnych elementów rozwiązania i jak AI wpływa na możliwości wykorzystania SDD. Zastanowimy się również, co upowszechnienie tego podejścia może oznaczać dla ról, procesów i codziennej pracy w IT.
Kinga Witko
Dlaczego testerzy nie testują dostępności (i jak to zmienić w 30 dni)
Większość testerów wie, że dostępność istnieje. Wielu zna podstawy WCAG, a mimo to dostępność nadal nie jest częścią codziennych testów. Dlaczego? Problemem nie jest brak wiedzy – tylko brak podejścia, które da się zastosować w projekcie. W tym wystąpieniu pokażę, jak przejść od teorii do praktyki: jak testować dostępność w sposób powtarzalny, uporządkowany i dopasowany do pracy testera. Key takeways: - Jak zbudować prosty, powtarzalny proces testowania dostępności w projekcie? - Jak wykorzystać dostępność jako przewagę jakościową i biznesową produktu?
Arkadiusz Jelonek
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.
Krzysztof Kijas
Przemysław Barański
Model AI to tylko silnik a Ty potrzebujesz kompletnej maszyny. O efektywnym wykorzystaniu AI w testach automatycznych
Bierzesz najmocniejszy model, wrzucasz zadanie i liczysz, że AI dowiezie? To trochę jak wsadzić silnik z bolidu F1 do przeciętnego auta bez dobrej skrzyni biegów, opon i wprawnego kierowcy. Może będzie szybko. Może będzie drogo. Ale wcale nie musi być skutecznie. W pracy z AI model jest tylko silnikiem. O wyniku jednak decyduje cała maszyna: kontekst, prompt, narzędzia, warstwy walidacji - w tym Twoja decyzja, czy naprawdę potrzebujesz najmocniejszej jednostki do prostego commita, refaktoryzacji albo wygenerowania testów E2E. A ta maszyna właśnie się zmienia. Ekosystem AI do kodowania przechodzi od zachwytu nad modelami do chłodnej kalkulacji: limitów, requestów, tokenów, nowych planów i korekt subskrypcji. To sygnał, że AI przechodzi z fazy eksperymentu w fazę kosztu operacyjnego. Podczas tej prelekcji pokażemy, jak świadomie dobierać modele AI do różnych scenariuszy w testach automatycznych: od prostych zmian w kodzie, przez analizę commitów i refaktoryzację, aż po generowanie testów end-to-end. Zobaczysz, kiedy wystarczy tani i szybki model, kiedy warto sięgnąć po mocniejszy, a kiedy problemem nie jest silnik, tylko źle dobrany kontekst i chaotyczny sposób pracy. Pokażemy też: - jak wygląda aktualny ekosystem narzędzi i modeli AI do pracy z kodem, - jak context window, system prompt, agent prompt i fine-tuning wpływają na jakość odpowiedzi, - gdzie AI najczęściej przepala tokeny, czas i budżet, - jak dobierać model do zadania, zamiast używać jednego „najlepszego” modelu do wszystkiego, - jak liczyć koszt pracy z AI: subskrypcje, requesty, tokeny, limity, iteracje i poprawki. To prelekcja dla testerów automatyzujących, QA engineerów i tech leadów, którzy chcą szybciej dowozić wartość, lepiej dobierać narzędzia i nie przepalać budżetu na pełnym gazie tam, gdzie wystarczyłby dobrze dobrany bieg.
Rafał Krząpa
Late Security = Expensive Security. Dlaczego bezpieczeństwo musi zacząć się przed pentestem
Bezpieczeństwo nie powinno zaczynać się kilka dni przed wdrożeniem, gdy aplikacja trafia do pentestera. Wtedy usunięcie podatności jest najdroższe, wymaga zmian w gotowym rozwiązaniu i może opóźnić publikację produktu. Pentest powinien weryfikować bezpieczeństwo, a nie być momentem, w którym zespół po raz pierwszy zaczyna o nim myśleć.
Podczas prezentacji pokażę, jak włączyć bezpieczeństwo w cały cykl tworzenia oprogramowania: od wymagań i projektowania, przez development i testy, aż po wdrożenie. Opowiem, jak wykorzystać threat modeling do wcześniejszego rozpoznawania zagrożeń oraz jak QA może rozszerzać codzienne testy o niewielkie, ale regularne działania security: sprawdzanie autoryzacji, kontroli dostępu, walidacji danych i nietypowych scenariuszy użycia. Pokażę praktyczne działania, narzędzia i przykłady błędów możliwych do wykrycia przed pentestem. Bezpieczeństwo nie jest osobnym etapem projektu, to wspólna odpowiedzialność analityków, developerów, QA i liderów technicznych.
Pokażę też realne przykłady i koszty dużych zmian po przeprowadzonych pentestach a także co znaleźliśmy i jakie skutki to mogło mieć dla klientów na produkcji.
Zakończenie konferencji i rozstrzygnięcie konkursów
Zakończenie konferencji i rozstrzygnięcie konkursów
06 października 2026 (prelekcje) Sala 2
Łukasz Eich
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.
Agata Rudzka
WCAG 2.2: Nowa „Dziewiątka” w arsenale testera
Dostępność cyfrowa to nie tylko teoretyczne wytyczne i kontrasty – to przede wszystkim realne doświadczenie użytkownika, które w wersji WCAG 2.2 zyskało zupełnie nowe oblicze. Podczas prelekcji odejdziemy od definicji ustawowych na rzecz praktycznego ich zastosowania. Skupimy się na 9 kluczowych kryteriach sukcesu, które wnoszą największą zmianę dla użytkowników mobilnych i osób z ograniczeniami poznawczymi.
Pokażę, jak przy pomocy prostych narzędzi – bez konieczności pisania skryptów automatyzujących – w 30 minut przetestować, czy Wasza aplikacja nie stawia kłód pod nogi użytkownikom. Uczestnicy otrzymają gotową checklistę „na jutro”, dzięki której samodzielnie wykryją błędy takie jak znikający focus, „nieklikalne” miniaturowe przyciski czy blokady wklejania haseł.
Czego dowiesz się podczas wystąpienia?
Praktyki ponad teorię: Jak manualnie zweryfikować kryteria dotyczące widoczności focusa (Focus Not Obscured) oraz rozmiarów celów (Target Size).
Logika ponad kod: Dlaczego zmuszanie użytkownika do przepisywania danych czy rozwiązywania „zagadek” przy logowaniu to błąd dostępności.
Strategia QA: Jak włączyć testowanie dostępności w codzienne testy eksploracyjne i zadania w Jirze bez kosztownych narzędzi.
Gotowy zestaw narzędzi: Otrzymasz checklistę, która pozwoli Ci natychmiast zacząć dbać o inkluzywność Twojego projektu.
Katarzyna Nowakowska
What masters do to become masters?
Masz dość czekania na nagły zryw motywacji, który i tak zawsze mija? Czas bezlitośnie rozprawić się z mitem wrodzonego talentu i odkryć prawdziwą anatomię wybitności.
Dlaczego warto wziąć udział w tej sesji?
- Koniec z czekaniem na wenę: Przestaw swoje myślenie z emocjonalnych zrywów na budowanie niezawodnego, codziennego sposobu stawania sie lepszym.
- Potęga Uporu: Dowiedz się, jak połączyć długodystansową pasję z żelazną wytrwałością, gdy rzeczywistość mówi „sprawdzam”.
- Celowa praktyka: Zobacz, jak mistrzowie namierzają swoje najsłabsze punkty i szlifują je z chirurgiczną precyzją.
- Architektura otoczenia: Przestań polegać na zawodnej silnej woli – zaprojektuj swój dzień tak, by konsekwencja stała się automatycznym nawykiem.
- Potykanie się z klasą: Zaprzyjaźń się z nudą rutyny i zamień każdą porażkę w chłodny, biznesowy feedback.
Zarezerwuj swoje miejsce już teraz. Mistrzostwo to świadoma decyzja, a nie przypadek.
Mateusz Bator
Wojciech Biskowski
Stabilne testy na bramkach w dobie agentów AI
Masz dość czerwonych pipeline'ów i testów, które failują bez żadnej zmiany w kodzie? A może liczysz, że agent dopilnuje stabilności za Ciebie?Czas zderzyć się z rzeczywistością: zły kod zawsze pozostanie złym kodem. W dobie AI powstaje więcej kodu i szybciej ląduje na bramce jakości.W naszej prelekcji opowiemy:- jak procesowo stabilizujemy testy, zanim trafią na bramki jakości,- o fundamentach frameworka i procesie wokół bramki jakości (architektura, standardy, AI harness),- kiedy wdrażamy tymczasowe obejście i czym nasz Repeat różni się od Retry w Playwright,- o agentach do code review, którzy odsiewają flaky testy przed mergem, oraz tych do analizy błędów z raportów i bugfixingu.Wyjdziesz z pomysłami, jak budować testy, którym można ufać, niezależnie od tego, kto je napisał. Bo nadal wygrywa ten, kto wie, o co zapytać i czy odpowiedź jest dobra.
Radosław Wasik
Sztuka projektowania zaufania. Czy czeka nas koniec deterministycznych testów?
Tradycyjna automatyzacja testów coraz częściej zderza się z rzeczywistością dynamicznych interfejsów, systemów AI i rosnących kosztów utrzymania. Flaky testy, walka o “zielone buildy” i niekończące się poprawki selektorów pokazują, że problemem bywa nie tylko technologia, ale też nasze przywiązanie do iluzji pełnej kontroli. W tej prelekcji przyjrzymy się koncepcji Agentic Testing - podejściu, w którym testy zaczynają działać bliżej intencji użytkownika i celu biznesowego, a nie wyłącznie struktury interfejsu. Na praktycznym przykładzie zobaczymy, jak agent AI może wspierać automatyzację, adaptować się do zmian w UI i współpracować z klasycznymi testami tam, gdzie deterministyczne podejście nadal ma największy sens. Porozmawiamy też o tym, jak budować zaufanie do takich rozwiązań: mierzyć stabilność wyników, kontrolować zakres działania agenta, stosować guardrails i rozpoznawać sytuacje, w których potrzebna jest eskalacja do człowieka. To opowieść nie tylko o nowych narzędziach, ale o możliwej zmianie roli QA - od utrzymywania kruchych skryptów do projektowania systemów jakości, ryzyka i zaufania.
Emilia Krzemińska-Komenda
AI w dostępności: niebezpieczny audytor czy genialny asystent? Przegląd możliwości bez lukrowania
Automatyczne narzędzia wykrywają zaledwie 30% błędów dostępności. W tej sytuacji sztuczna inteligencja wydaje się "świętym graalem", który może wypełnić tę lukę. Ale czy powierzenie oceny dostępności modelom AI jest bezpieczne dla jakości produktu? Podczas tej prelekcji zamienimy hurraoptymizm na chłodną analizę faktów. Zamiast live codingu, przejrzymy konkretne scenariusze użycia. Zobaczysz, gdzie AI realnie przyspiesza pracę nad WCAG, a gdzie staje się generatorem ryzyka. Dowiesz się, jak świetnie radzi sobie ono z tłumaczeniem technicznego żargonu i generowaniem opisów alternatywnych. Zrozumiesz też, dlaczego wciąż nie można mu ufać w roli ostatecznego sędziego. To prelekcja o budowaniu bezpiecznej jakości. AI powinno być wsparciem intelektualnym, a nie zastępstwem dla empatii i wiedzy eksperta.
Artur Duziak
Page object model: świadoma decyzja czy dziedziczony nawyk?
Page Object Model to domyślny wzorzec w prawie każdym projekcie testowym - pytanie, ile osób świadomie go wybiera, a dla ilu jest to po prostu przyzwyczajenie?
W prelekcji poruszymy argumenty przeciw POM i skonfrontujemy je z zasadami programistycznymi takimi jak DRY, ale też z tymi mniej popularnymi jak WET oraz AHA. Pokażę, dlaczego POM może utrudniać czytelność testów i pracę nad nimi.
Będzie to lekcja krytycznego myślenia, szczególnie ważna teraz, gdy AI coraz częściej próbuje podejmować decyzje za nas. Wszystko omówimy na przykładach napisanych w Playwright + TypeScript. Po tej prelekcji inaczej spojrzysz na każdą abstrakcję w swoim kodzie.
Halyna Muryniuk
How Microsoft Copilot Transforms QA Workflow: Practical Insights from Daily Use
This talk explores how Microsoft Copilot supports the thinking side of manual QA work rather than just accelerating routine tasks. Based on real experience, it demonstrates how Copilot can help uncover implicit system logic, challenge product assumptions, identify meaningful regression risks, and strengthen exploratory testing. Instead of using AI as a shortcut, we treat it as a thinking partner that improves decision‑making and collaboration across QA, development, and product teams. The session is aimed at experienced testers who want to evolve their approach and focus on what matters most: judgment in complex systems.
Zakończenie konferencji i rozstrzygnięcie konkursów
Zakończenie konferencji i rozstrzygnięcie konkursów
Masz pytania lub wątpliwości? Kontakt z organizatorami
E-mail: kontakt@testingground.pl
Dominika Gospodarczyk, Event Manager
- tel: +48 531 119 616
Aleksandra Herman, Event Manager Assistant
- tel: +48 570 330 516
Wydarzenie wspiera również kilku ambasadorów z całej Polski, którzy aktywnie włączają się rozwój i organizację społeczności oraz samego wydarzenia!
