Dzięki automatyzacji testów zespół może pracować szybciej i pewniej. Trzeba jednak pamiętać, że testy również są kodem: wraz ze wzrostem ich liczby rośnie koszt utrzymania, debugowania i dostosowywania ich do zmian w aplikacji.

Dlatego przy automatyzacji testów warto patrzeć nie tylko na to, co da się zautomatyzować, ale też na jakość feedbacku i koszt późniejszego utrzymania.

Najpierw oceń ryzyko regresji i koszt błędu

Najlepszym kandydatem do automatyzacji nie jest funkcja, którą najłatwiej pokryć testem. Jest nim obszar, którego awaria najbardziej zaboli urzytkowników.

Płatności, autoryzacja, uprawnienia, billing czy kontrakty API zwykle spełniają ten warunek. Regresja w takim miejscu szybko przekłada się na problemy użytkowników albo blokuje cały proces biznesowy.

Przy wyborze warto ocenić cztery rzeczy:

• Wpływ regresji. Co stanie się, jeśli ten fragment przestanie działać?
• Prawdopodobieństwo błędu. Jak często zmieniamy ten kod i ile ma zależności?
• Częstotliwość testowania. Czy scenariusz sprawdzamy przy każdym release?
• Koszt utrzymania. Ile pracy będzie wymagało utrzymanie testu w kolejnych miesiącach?

Dzięki temu łatwiej odróżnić test, który rzeczywiście zmniejsza ryzyko, od takiego, który tylko podbija metrykę coverage.

Jeśli chcesz przełożyć ten wybór również na koszty zespołu, warto osobno policzyć ROI automatyzacji testów. Szczególnie tam, gdzie manualna regresja powtarza się przy każdym wdrożeniu.

Dobierz poziom testu do problemu

Krytyczna ścieżka nie zawsze wymaga rozbudowanego testu E2E. Sporą część ryzyka można ograniczyć testami jednostkowymi i integracyjnymi, które są szybsze, stabilniejsze i łatwiejsze w utrzymaniu.

Weźmy jako przykład proces płatności.

Reguły naliczania kwoty możesz sprawdzić testami jednostkowymi. Komunikację z gatewayem warto pokryć testami integracyjnymi. Testy E2E wystarczą dla kilku najważniejszych scenariuszy obejmujących cały proces.

Takie podejście ogranicza koszt utrzymania i skraca pętlę zwrotną. Nie musisz tutaj odpalać przeglądarki, bazy, kilku usług i zewnętrznego sandboxa po to, żeby sprawdzić prostą regułę domenową.

Ma to znaczenie także w CI/CD. Według DORA jednym z fundamentów Continuous Delivery jest szybka informacja zwrotna o jakości oprogramowania i jego gotowości do wdrożenia.

Jeśli sekwencja testów trwa czterdzieści minut, feedback przychodzi za późno. Jeszcze gorzej, gdy testy regularnie blokują pipeline mimo braku błędu w kodzie.

Niestabilne testy szybko podkopują zaufanie do automatyzacji

Niestabilny test nie daje Ci poczucia bezpieczeństwa. Za każdym razem, gdy nie przechodzi, musisz ustalić, czy problem leży w kodzie, czy w samym teście.

Na początku sprawdzasz logi, szukasz przyczyny błędu i próbujesz odtworzyć problem. Po kilku fałszywych alarmach zaczynasz podchodzić do wyniku z rezerwą. Później pojawia się ponowne uruchamianie testu „na wszelki wypadek”. Jeśli taki stan trwa dłużej, przestajesz ufać całemu zestawowi testów.

Wtedy każdy błąd wymaga interpretacji, zamiast od razu wskazywać realny problem.

Dobrym przykładem jest test E2E zależny od niestabilnej usługi zewnętrznej. Jeśli regularnie nie przechodzi z powodów niezwiązanych z Twoim kodem, lepszym rozwiązaniem może być test integracyjny z kontrolowanym mockiem. Dostaniesz bardziej wiarygodny sygnał przy niższym koszcie utrzymania.

Kiedy nie warto automatyzować testu?

Nie każdy scenariusz zasługuje na automatyzację, nawet jeśli technicznie da się ją zrobić.

Słaby ROI mają zwykle funkcje, które szybko się zmieniają, krótkotrwałe eksperymenty, jednorazowe migracje albo obszary wymagające subiektywnej oceny.

Jeśli test E2E jest mocno związany ze szczegółami interfejsu, każda większa zmiana w UI może wymagać jego aktualizacji. Jeśli scenariusz wykonujesz rzadko, a ręczne sprawdzenie zajmuje chwilę, koszt utrzymania automatyzacji może być wyższy niż korzyść.

Oceniaj zestaw testów po jakości informacji zwrotnej

Procent pokrycia testami może być przydatnym wskaźnikiem. Nie mówi jednak, czy chronisz właściwe rzeczy.

Możesz mieć 90% pokrycia i nadal nie zabezpieczać najważniejszej ścieżki użytkownika. Możesz też mieć znacznie mniej i jednocześnie dostawać szybki, stabilny sygnał o tym, czy zmiana nadaje się do wdrożenia.

Najlepszym sprawdzianem jest prostsze pytanie:

Czy kiedy wszystkie testy przechodzą, naprawdę ufasz, że możesz bezpiecznie wdrożyć zmianę?

Jeśli wszystkie testy przechodzą, a przed wdrożeniem i tak trzeba ręcznie przeklikać pół aplikacji, problem leży w doborze testów albo w lukach w ich pokryciu.

W Pragmatic Coders patrzymy na automatyzację właśnie przez pryzmat ryzyka, feedbacku i kosztu utrzymania.

Nie potrzebujesz testu dla każdego możliwego przypadku. Potrzebujesz takich testów, które szybko wykrywają regresje tam, gdzie ich koszt jest najwyższy, a przy tym pozostają wystarczająco stabilne, żeby zespół mógł im zaufać.

Artykuł sponsorowany