Testowanie i jakość

Jak wyglądał świat testowania oprogramowania 20 lat temu? Co zmieniło się przez dwie dekady, jakie przełomy ukształtowały branżę i co w tym czasie udało się osiągnąć testerzy.pl?
W tej prelekcji spojrzymy na historię testowania z perspektywy doświadczeń firmy, ale także zmian technologicznych, organizacyjnych i biznesowych, które wpłynęły na całą branżę.

Zastanowimy się również, gdzie znajduje się testowanie dzisiaj oraz spróbujemy odpowiedzieć na pytanie, dokąd zmierza.

Jak będzie wyglądało za 20 minut, 20 godzin, 20 dni, 20 miesięcy i 20 lat? To podróż przez przeszłość, teraźniejszość i przyszłość testowania, pokazująca, jak wiele może zmienić się w ciągu dwóch dekad – i jak wiele jeszcze przed nami.

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.

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).