speaker-photo

Krzysztof Kijas

jaktestowac.pl

Od 2013 roku aktywnie rozwijam się jako trener, prowadząc warsztaty skoncentrowane na jakości, pisaniu testów i narzędziach wspomagających testowanie. Regularnie dzielę się wiedzą w moich wpisach zarówno na moim profilu LinkedIn oraz playwright.info. Również od wielu lat działam jako mentor, rekruter techniczny, konsultant i test architekt w różnych projektach i firmach, które stawiają na jakość i spełnienie potrzeb klientów.

Jako współtwórca inicjatywy jaktestowac.pl, od samego początku tworzę kursy i materiały edukacyjne dla Nowoczesnych Testerów, wspierając rozwój społeczności testerskiej w Polsce. Mój wkład w rozwój społeczności został doceniony i razem z Przemkiem Barańskim wygrałem plebiscyt Ludzie Testowania 2024 organizowany przez testerzy.pl.

Warsztat 1

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.

Warsztat 2

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.

Warsztat 3

Poniedziałek 5 października

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.</br
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

Warsztat 6

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

Warsztat 7

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.

Warsztat 8

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.

Warsztat 9

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

Warsztat 11

Poniedziałek 5 października

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.

10:20 - 10:50

Wtorek 6 października (Sala 1)

Evolution of OpenAPI Codegen in the Age of AI

 

11:00 - 11:30

Wtorek 6 października (Sala 1)

Zarządzanie jakością w dużej organizacji

 

11:40 - 11:55

Wtorek 6 października (Sala 1)

Przerwa kawowa

 

11:55 - 12:25

Wtorek 6 października (Sala 1)

Wkrótce ogłosimy

Niebawem więcej informacji

12:35 - 13:05

Wtorek 6 października (Sala 1)

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?

13:05 - 14:30

Wtorek 6 października (Sala 1)

Przerwa obiadowa

 

15:10-15:40

Wtorek 6 października (Sala 1)

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.

09:40 - 10:10

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.

10:20 - 10:50

Wtorek 6 października (Sala 2)

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.

11:00 - 11:30

Wtorek 6 października (Sala 2)

What masters do to become masters?

 

11:40 - 11:55

Wtorek 6 października (Sala 2)

Przerwa kawowa

 

11:55 - 12:25

Wtorek 6 października (Sala 2)

Szczegóły już wkrótce

Niebawem więcej informacji

12:35 - 13:05

Wtorek 6 października (Sala 2)

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.

13:05 - 14:30

Wtorek 6 października (Sala 2)

Przerwa obiadowa

 

14:30 - 15:00

Wtorek 6 października (Sala 2)

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.

15:10 - 15:40

Wtorek 6 października (Sala 2)

Page object model: świadoma decyzja czy dziedziczony nawyk?