• Connect to Us

PON-PT: 08:00 - 16:00 +48 533 389 220

Schedule Tabs

This is sample of page tagline and you can set it up using page option
Expand All +

  • Dzień 1 - warsztaty


  • Dzień 2 - wykłady


  • Projekt testów automatycznych to pełnoprawny projekt, który - tak jak aplikacja, którą testujemy - bez przerwy się zmienia.
    Dodajemy nowe testy lub poprawiamy istniejące, niezależnie od tego, czy mówimy o testach API, aplikacji webowej, desktopowej czy mobilnej.

    Na co dzień skupiamy się na jakości aplikacji, którą testujemy, często nie poświęcając wystarczającej uwagi jakości kodu samych testów. Powód jest zwykle prozaiczny: brak czasu, brak wiedzy lub zwykła pokusa, żeby „jakoś to działało”, a głębsze porządki odłożyć na później.

    Na początku wszystko wygląda dobrze. Z czasem jednak, gdy projekt rośnie, coraz trudniej dopisywać nowe testy, wprowadzać zmiany i analizować testy, które znowu świecą się na czerwono po nocnym runie.

    Jakość kodu testów automatycznych bywa równie trudna do utrzymania jak jakość aplikacji, którą dostarczamy klientom.

    Podczas warsztatu zaadresujemy część tych problemów, korzystając ze znanych od ponad 20 lat wzorców projektowych: Fabryka, Fluent Builder, Fasada, Strategia, czyli rozwiązań, które sprawdzają się nie tylko w kodzie produkcyjnym, ale równie dobrze w kodzie testów automatycznych.

    Na początku warsztatu otrzymacie działającą solucję testową C#/.NET 10, wykorzystującą RestSharp (testy API) i Playwright (testy web).

    Wspólnie przeprowadzimy refaktoryzację krok po kroku, wprowadzając kolejne wzorce jako odpowiedź na konkretny problem - nie jako sztukę dla sztuki.

    Po warsztatach wyjdziesz z działającym szkieletem frameworka do testów API i UI oraz wiedzą o wzorcach projektowych i umiejętnością ich wdrożenia w Twoim projekcie.

    Wymagania wstępne:
    Nie musisz być ekspertem w C#, ale przydatna będzie podstawowa znajomość: klas i ich składowych, interfejsów, tworzenia obiektów, wywoływania metod, metod asynchronicznych (async/await).
    Bez tego przyswojenie materiału może być trudniejsze.
    Automatyzacja
    Języki programowania
    Testowanie i jakość

  • 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.
    Testowanie i jakość

  • Przez ostatnie 20 lat zmieniły się narzędzia, języki i podejścia do automatyzacji. Jedno wyzwanie pozostało jednak aktualne: jak zbudować testy, które nie rozsypią się przy pierwszej większej zmianie aplikacji?

    Na początku zwykle wszystko wygląda dobrze. Powstaje pierwszy test, później kilka kolejnych, pojawia się Page Object, wspólny helper i konfiguracja środowiska. Z czasem projekt rośnie, testy zaczynają współdzielić dane i zależności, setup staje się coraz bardziej rozbudowany, a niewielka zmiana w aplikacji wymaga poprawek w kilkunastu miejscach. Framework, który miał przyspieszać pracę zespołu, sam zaczyna wymagać ciągłego ratowania.

    Podczas warsztatu przejdziemy drogę od pojedynczych testów do uporządkowanego i rozwijalnego frameworka automatyzacji opartego na TypeScript i Playwright. Nie będziemy jednak budować architektury dla samej architektury. Każdy element pojawi się jako odpowiedź na konkretny problem: duplikację kodu, trudne przygotowanie danych, niestabilne środowisko, rozbudowany setup, wolne testy lub nieczytelne raporty.

    W praktyce wykorzystamy:
    • typowane fixtures o zakresie testowym i workerowym,
    • Page Object stosowany tam, gdzie rzeczywiście upraszcza testy,
    • helpery i czytelny podział odpowiedzialności,
    • fabryki oraz zestawy danych testowych,
    • konfigurację wielu środowisk z wykorzystaniem dotenv,
    • raporty, ślady wykonania, zrzuty ekranu i inne artefakty diagnostyczne,
    • testy API oraz scenariusze łączące warstwę API + UI.
    Warsztat ma formę hands-on. Zaczniemy od projektu, który działa, ale szybko ujawnia typowe problemy utrzymaniowe. Następnie będziemy go krok po kroku porządkować, refaktoryzować i rozszerzać. Uczestnicy nie otrzymają wyłącznie gotowego szablonu - zobaczą, dlaczego podejmujemy poszczególne decyzje i jakie konsekwencje mają one dla całego zespołu.

    Po warsztacie uczestnik wyjdzie z działającym szkieletem frameworka w TypeScript i Playwright, obejmującym testy UI, API oraz scenariusze hybrydowe, typowane fixtures, dane testowe, konfigurację środowisk i raportowanie.
    Przede wszystkim otrzyma jednak zestaw zasad pomagających budować automatyzację, która rozwija się razem z aplikacją, zamiast po każdej zmianie wymagać kolejnego przepisywania.
    Automatyzacja

  • Agent AI potrafi dziś zrobić znacznie więcej niż podpowiedzieć fragment kodu. Może poznać aplikację, przygotować plan testów, napisać kod w Playwright, uruchomić testy i pomóc znaleźć przyczynę błędu.
    Sam dostęp do takich możliwości nie gwarantuje jednak dobrych testów. Nadal liczą się właściwy kontekst, jasne zasady i ocena testera.

    Podczas warsztatu przejdziemy przez ten proces na praktycznym przykładzie. Uczestnicy wykorzystają agenta AI do zbadania aplikacji, wyboru scenariuszy oraz przygotowania i poprawienia testów UI w Playwright.

    Pokażę również możliwości agentów odpowiedzialnych za planowanie, generowanie i naprawianie testów.

    Sprawdzimy, jak przekazywać agentowi informacje o projekcie, jak oceniać przygotowany przez niego kod oraz jak reagować, gdy wybierze zły selektor, napisze słabą asercję albo zaproponuje poprawkę, która tylko ukrywa problem.

    Uczestnicy zobaczą, które zadania warto przekazać agentowi, a które nadal wymagają decyzji i doświadczenia testera.

    Warsztat będzie miał praktyczną formę. Zależy mi, aby uczestnicy nie tylko zobaczyli możliwości agentów AI, ale też samodzielnie przygotowali testy i poznali sposób pracy, który będą mogli później wykorzystać we własnych projektach.

    Po warsztacie uczestnik będzie potrafił:
    • wykorzystać agenta AI do poznania aplikacji i zaplanowania testów;
    • przygotować testy UI w Playwright z pomocą agenta;
    • przekazać agentowi potrzebne informacje o projekcie i zasady pracy;
    • uruchamiać wygenerowane testy oraz analizować ich wyniki;
    • oceniać selektory, asercje i strukturę przygotowanego kodu;
    • rozpoznawać błędne założenia i poprawki proponowane przez agenta;
    • decydować, które zadania można przekazać agentowi, a które wymagają kontroli człowieka.

    Dla kogo:
    Warsztat jest przeznaczony dla testerów i inżynierów QA znających podstawy programowania w JavaScript lub TypeScript.
    Podstawowa znajomość Playwrighta będzie pomocna.
    AI
    Automatyzacja

  • Ile razy w tygodniu klikasz dokładnie to samo?
    Sprawdzasz, czy pojawił się nowy pull request, przepisujesz to samo zgłoszenie w kilka miejsc, wklejasz linki na Slacka. n8n - wizualne narzędzie low-code, w którym automatyzacje składa się z gotowych klocków zamiast pisać kod od zera - pozwala tę drobnicę oddać workflowom.

    Ten mini-warsztat jest o pierwszym kroku: w jedno popołudnie przechodzimy od pustego workflowu do pierwszej działającej integracji - bez umiejętności programowania.
    To półdniowy warsztat w formule hands-on follow-along: krok po kroku, wszyscy jednocześnie budujemy w n8n uruchomionym lokalnie (albo w chmurze, jeśli u kogoś łatwiej wystartuje). Składamy realne workflowy z gotowych węzłów i spinamy ze sobą narzędzia, których używasz na co dzień, w jeden działający przepływ - kończysz z czymś namacalnym, co realnie odciąża testera.
    Po drodze złapiesz fundamenty: jak dane płyną między węzłami (koncept Item), jak działają triggery i credentials, jak jednym workflow zbudować od zera testowy „projekt" w Trello i jak spiąć trzy narzędzia - GitHub, Trello i Slack - w jeden sensowny przepływ.
    Nie wyjdziesz z gotową integracją 1:1 do wdrożenia u siebie - wyjdziesz z wyczuciem, jak taką automatyzację pomyśleć, złożyć i uruchomić samodzielnie.

    Wymagania wstępne:
    Znajomość n8n nie jest wymagana - każdy startuje z pustego workflowu. Wystarczą bazowe podstawy: obsługa terminala (do uruchomienia środowiska), pojęcie REST/HTTP oraz korzystanie ze Slacka i GitHuba na poziomie użytkownika. Tydzień wcześniej dostajesz PDF z instrukcjami setupu, żeby pierwsze minuty nie poszły na przygotowywanie środowiska. Na koniec zabierasz ze sobą działające środowisko n8n, komplet zbudowanych podczas warsztatu workflowów, paczkę eksportów JSON oraz jednostronicowy cheatsheet (kluczowe węzły, pułapki, linki).
    Testowanie i jakość

  • Gdzie byliśmy 20 lat temu i odrobinę wcześniej? Na marginesie IT. Lekceważeni i poniewierani.
    Juniorzy i midzi dziś mają ciężko? 20 lat temu prawie nikt nie wiedział czym jest testowanie, a ci którzy wiedzieli, nie chcieli zapłacić za nie więcej niż 10zł. Nie było nas uczelniach, nie było nas na ważnych korporacyjnych meetingach i nie przyznawano nam nagród za sukces projektu.

    Przez 20 lat budowaliśmy szacunek dla naszej pracy i kiedy już zostaliśmy docenieni, przyszło AI i znów obniżyło postrzeganie naszej pracy. To gdzie jesteśmy dzisiaj z testowaniem? Nie jesteśmy w gorszym miejscu. Jesteśmy na rynku, który próbując obniżyć koszty będzie próbował zastąpić nas maszynami. I to jest OK jeśli się to rozumie.
    Testowanie dla części będzie pasją, a dla części po prostu zajęciem do zarobkowania. Nie będzie testowania to będzie inna robota. Ci z nas, którzy mają odrobinę więcej przywiązania do zawodu, wcale nie mają większych szans na pozostanie w nim. Jeśli liczby nie będą się zgadzać, nikt na siłę nie będzie trzymał testerów.
    Ta prezentacja opowie o tym gdzie byliśmy 20 minut, 20 godzin, 20 dni, 20 miesięcy i 20 lat przed jej rozpoczęciem.
    Spróbuje odpowiedzieć na pytanie gdzie będziemy za 20 minut, 20 godzin, 20 dni, 20 miesięcy i 20 lat po jej zakończeniu.

    Choć moja przygoda z testowaniem zaczęła się ćwierć wieku temu, dopiero wejście w rolę senioralną i rozpoczęcie dzielenia się wiedzą nauczyło mnie prawdziwie testować. Nie zrozumiesz testowania jeśli nie jesteś w stanie go wyjaśnić. Dla mnie momentem kiedy musiałem wytłumaczyć testowanie każdemu było początek testerzy.pl – 20 lat temu.
    Testowanie i jakość

  • AI i narzędzia takie jak Claude Code, Gemini czy Cursor nie zastępują wiedzy - są wzmacniaczem tego, jak dobrze potrafisz z nich korzystać. Podczas prezentacji pokażę, co naprawdę wpływa na jakość pracy z AI: budowanie kontekstu, świadome promptowanie, tworzenie własnych sposobów pracy i kontrolowanie efektów. Zobaczycie, jak wykorzystać AI jako stały element codziennego workflow, a nie tylko jednorazowe narzędzie do generowania treści.
    AI
    Testowanie i jakość

  • Testy UI często są postrzegane jako najwolniejszy i najmniej przewidywalny element pipeline’u CI/CD. W efekcie wiele zespołów przenosi je do nightly builds, godząc się na opóźniony feedback i późne wykrywanie regresji.

    Podczas prezentacji pokażę, jak projektować i optymalizować testy UI tak, aby dostarczały szybki i wiarygodny feedback już na etapie pull requestów. Omówię najczęstsze problemy związane z testami UI w CI/CD: długi czas wykonania, flaky testy, niestabilne środowiska, współdzielone dane testowe oraz trudności wynikające z równoległego uruchamiania testów.

    Przedstawię praktyczne techniki skracania czasu wykonania testów, takie jak równoległe uruchamianie, shardowanie między agentami, strategie fail-fast, podział na smoke testy i pełną regresję czy selektywne uruchamianie testów zależnie od zakresu zmian. Pokażę również, dlaczego samo zwiększanie liczby workerów często nie rozwiązuje problemu.

    Porozmawiamy także o aspektach architektonicznych: przygotowaniu danych testowych, izolacji testów, zarządzaniu artefaktami, środowiskach efemerycznych oraz kosztach infrastruktury.

    Prezentacja będzie oparta na rzeczywistych doświadczeniach projektowych i problemach spotykanych przy utrzymaniu testów UI w CI/CD. Uczestnicy otrzymają praktyczny model decyzyjny, który pomoże określić, które testy warto uruchamiać w pull requestach, które pozostawić do pełnej regresji, co równoleglić, kiedy skalować infrastrukturę, a kiedy najpierw poprawić strategię testowania zamiast dokładać kolejne workery.
    Testowanie i jakość