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.
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.
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.
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.
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.
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).
Ostatnie lata pokazały, jak dynamicznie zmienia się branża IT. Nowe frameworki, rozwój AI a co za tym idzie presja na zwiększanie efektywność sprawiają, że rola testera zmienia szybciej niż kiedykolwiek.
Choć narzędzia i technologie nieustannie się zmieniają, potrzeba dostarczania wysokiej jakości oprogramowania pozostaje niezmienna.
W oparciu o przykłady z projektów, opowiem jak świadomie budować swoją wartość w zespole i rozwijać kompetencje, które pozostają istotne niezależnie od zmieniających się technologii. Moim celem nie jest odpowiedź na pytanie, czy testowanie ma przyszłość, ale pokazanie, jak rozwijać się, aby pozostać specjalistą, którego wiedza, umiejętności i sposób myślenia będą wartościowe niezależnie od zmian na rynku IT.