Dzień 2 - wykłady

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.

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.