TESTOWANIE ANALIZY WPŁYWU NA RZECZ SZYBSZEJ ŚCIEŻKI PROCESOWEJ

TESTOWANIE ANALIZY WPŁYWU NA RZECZ SZYBSZEJ ŚCIEŻKI PROCESOWEJ

Czy widziałeś moją poprzednią prezentację na temat pokrycia testowego? Ta jest kontynuacją mojej historii. Tym razem zamiast dzielić się moimi badaniami i teoretycznymi wynikami, omówię praktyczny przypadek zastosowania analizy pokrycia testów – analizy wpływu testów.
Czy zmagasz się z dużym zestawem testów automatycznych? Być może, tak jak w moim przypadku, przeprowadzasz wszystkie testy po każdej zmianie. Nie ma znaczenia, czy wrzucasz bezpośrednio na mastera, czy też stosujesz rozgałęzienie funkcji. Twoi programiści spędzają dużo czasu czekając na wyniki testów. Aby zmniejszyć ten problem, przeprowadzamy testy równolegle, przesuwamy testy w dół do piramidy, skupiając się bardziej na izolowanych testach komponentów lub jednostek.
Parallelizacja ma swoje granice i nie jest tak, że oszczędzał pieniądze, jedynie czas. Spychanie testów w dół piramidy brzmi ładnie, ale wymaga czasu i dużego zaangażowania, które może być trudne do osiągnięcia. Co by było, gdyby istniał łatwy sposób na skrócenie czasu wykonania testu i zachowania pokrycia? Co by było, gdyby istniał sposób na analizę wpływu testu na kod produkcyjny? Na szczęście jest i omówię jak to wygląda w praktyce. Jak przy użyciu narzędzi open source i odrobinie inwestycji można przeprowadzić tylko te testy, które mają sens dla konkretnej zmiany.

Bart Szulc

Bart Szulc

Tester od serca. Można powiedzieć, że urodziłem się, aby testować. Od początku swojej kariery zawodowej, mam ręce brudne od automatyzacji testów i pisania skryptów. Projektowania strategii, dostarczania platform i środowisk do testowania aplikacji internetowych i mobilnych. Aktywnie zaangażowany w lokalne społeczności testerskie. Prezenter na najpopularniejszych konferencjach testerskich w Polsce. Od kiedy dołączył do Spartez, pomaga programistom stać się lepszymi testerami. Zakochany w analizie statycznej big data. Dąży do kwantyfikacji jakości w rozwoju oprogramowania.