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.
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.
Testy automatyczne coraz częściej muszą radzić sobie z zależnościami, nad którymi nie mamy pełnej kontroli: fizycznymi urządzeniami, mechanizmami MFA czy zewnętrznymi dostawcami logowania.
W rezultacie testy stają się wolne, niestabilne a często nakład pracy potrzebny do automatyzacji przewyższa zyski.
Podczas prezentacji pokażę, jak w praktyce mockować takie zależności, na podstawie trzech rzeczywistych case study z projektu, w którym pracuję.
Pierwszy dotyczy testowania aplikacji współpracującej z glukometrem – gdzie dane testowe z fizycznego urządzenia zastąpiłem symulacją REST API przy pomocy WireMock, uwalniając testy od sprzętu i konieczności automatyzacji aplikacji desktopowej.
Drugi przypadek to logowanie do aplikacji wewnętrznych zabezpieczonych przez Microsoft Entra i MFA oparte na TOTP – omówię, jak działa algorytm HMAC-SHA1 w tle i jak wygenerować kod jednorazowy bezpośrednio w kodzie testu za pomocą biblioteki OTP.Net, eliminując zależność od telefonu i aplikacji uwierzytelniającej.
Trzeci, najbardziej rozbudowany case study, to rejestracja konta z integracją Google Drive. Prześledzimy ewolucję podejść: od próby obsługi pełnego logowania, przez rolling cache profilu przeglądarki Chrome w Azure Pipelines, aż po docelowe rozwiązanie – przechwytywanie i mockowanie odpowiedzi Google za pomocą Playwright RouteAsync, bez jakiegokolwiek kontaktu z prawdziwym serwerem OAuth.
Prezentacja pokaże konkretny kod i konfigurację, ale przede wszystkim sposób myślenia stojący za decyzją „co i jak mockować”. Uczestnicy zobaczą, że test automatyczny nie zawsze musi dokładnie odwzorowywać ścieżkę testu manualnego – a świadome mockowanie zależności zewnętrznych potrafi zapewnić stabilność, szybkość, izolację i kontrolę, które w innym wypadku byłyby trudne do osiągnięcia.
Testowanie zmieniło się wyraźnie w ostatnich latach.
Wielu z nas pamięta manualne regresje wykonywane na podstawie rozbudowanych checklist, bugtrackery jako centrum codziennej pracy, szukanie odpowiedzi na forach i pierwsze frameworki Selenium wymagające własnych mechanizmów synchronizacji, raportowania oraz utrzymania.
Dziś ten sam problem potrafimy analizować przez API, trace, logi pipeline’u, nowoczesne frameworki i asystentów AI.
Prelekcja nie będzie próbą udowodnienia, że kiedyś było lepiej. To zaproszenie do wysłuchania historii, jak zmieniał się warsztat Testera / QA i jakie konsekwencje miały kolejne technologiczne skróty.
Przyjrzymy się drodze od manualnej regresji i narzędzi działających obok procesu wytwarzania do testowania zintegrowanego z repozytorium i procesem dostarczania oprogramowania.
Porównamy sposób zdobywania wiedzy, projektowania testów, diagnozowania awarii i komunikowania ryzyka. Zobaczymy, co zyskaliśmy dzięki szybszemu feedbackowi, śladom wykonania, scenariuszom API + UI i automatycznym raportom, ale również gdzie pojawiają się nowe pułapki: powierzchowna znajomość narzędzi, szum w pipeline’ach, nadmiar automatyzacji i bezkrytyczne zaufanie do odpowiedzi AI.
Pokażę, że zmiana narzędzi nie usuwa odpowiedzialności testera. Doświadczenie nadal ujawnia się w umiejętności zadawania właściwych pytań, oceny ryzyka, łączenia sygnałów i wpływania na decyzje zespołu. Narzędzia coraz szybciej dostarczają odpowiedzi, ale to człowiek nadal musi ocenić, czy prowadzą one do właściwej decyzji.