Automatyzacja testów: co się naprawdę opłaca automatyzować, a co nie

Automatyzacja testów ma jedną ogromną zaletę i jedną ogromną pułapkę. Zaleta jest oczywista: szybciej dostajecie feedback i szybciej dowozicie. Pułapka jest mniej oczywista: możecie zautomatyzować bardzo dużo i nadal nie mieć jakości. Wtedy automatyzacja staje się kosztownym hobby, a nie dźwignią biznesu.

Jeśli chcecie podejść do tego dojrzale, musicie przestać myśleć kategorią zautomatyzujemy jak najwięcej, a zacząć myśleć kategorią zautomatyzujemy to, co daje największy zwrot, a resztę zostawimy w manualu albo przeniesiemy niżej w piramidzie testów. W praktyce nie wygrywa organizacja, która ma najwięcej testów. Wygrywa organizacja, która ma najlepsze testy w najlepszych miejscach.

Dlaczego większość automatyzacji nie dowozi ROI

Najczęściej dlatego, że automatyzacja startuje od niewłaściwego pytania. Zamiast pytać, które ryzyka są najdroższe i które scenariusze muszą być chronione codziennie, pytacie, które testy manualne macie i jak je przepisać na automaty. To jest prosta droga do dużej liczby testów UI, długich pipeline, flakiness i frustracji.

Drugi powód to automatyzacja rzeczy, które ciągle się zmieniają. Jeśli produkt jest w fazie intensywnych zmian interfejsu, to automaty UI będą się łamały szybciej, niż zdążycie je naprawiać. Wtedy automatyzacja nie przyspiesza. Ona przenosi czas z testowania na utrzymanie.

Trzeci powód to brak definicji, po co dany test istnieje. Test bez powiązania z ryzykiem jest tylko kodem, który czasem świeci na czerwono.

Zasada, która upraszcza decyzje

Najbardziej opłaca się automatyzować to, co jest jednocześnie krytyczne dla biznesu, często wykonywane i stabilne w czasie. Najmniej opłaca się automatyzować to, co jest niestabilne, rzadko używane i wymaga ludzkiej oceny.

Brzmi banalnie, ale gdy zaczniecie tym filtrem przechodzić przez backlog testów, nagle wiele decyzji robi się oczywistych.

Co się opłaca automatyzować, prawie zawsze

1. Smoke i krytyczne ścieżki, czyli testy, które chronią pieniądze

Jeśli mielibyśmy wskazać jeden obszar automatyzacji, który prawie zawsze ma sens, to jest to ochrona krytycznych ścieżek. Nie dlatego, że brzmi profesjonalnie, tylko dlatego, że to są miejsca, w których błąd natychmiast zamienia się w stratę. Jeśli macie produkt sprzedażowy, krytyczne flow to zwykle logowanie, rejestracja, wyszukiwanie, koszyk, checkout, płatność, reset hasła. Jeśli macie SaaS, to logowanie, uprawnienia, billing, aktywacja kluczowej funkcji, upgrade planu. To nie są testy na pokaz. To są testy, które odpowiadają na jedno pytanie: czy biznes działa jutro rano.

Warto zauważyć jeszcze jeden mechanizm. Krytyczne ścieżki wcale nie muszą psuć się często, żeby ich automatyzacja miała sens. Wystarczy, że psują się rzadko, ale boleśnie. Wtedy ROI wynika nie z liczby znalezionych błędów, tylko z tego, że jeden błąd, który przeszedł, kosztuje więcej niż miesiące utrzymania testu. I to jest powód, dla którego dobrze zaprojektowany smoke suite jest jak pas bezpieczeństwa. Zakładacie go nie dlatego, że co tydzień macie wypadek, tylko dlatego, że wypadek jest drogi.

Jak powinien wyglądać sensowny smoke na start. Krótko i bez przesady. Kilka testów end to end, ale tylko na absolutnie kluczowych flow i tylko w wersji minimalnej. Logowanie działa. Wyszukiwanie zwraca wynik. Produkt da się dodać do koszyka. Checkout przechodzi do kroku płatności. Płatność dochodzi przynajmniej do potwierdzenia po stronie systemu, nawet jeśli finalny krok jest stubowany. Każdy taki test ma mieć jedno zadanie: wykryć regresję, która blokuje biznes. To nie jest miejsce na testowanie wszystkich kombinacji. To jest miejsce na szybki sygnał, czy release jest w ogóle bezpieczny.

To jest automatyzacja, która ma sens nawet wtedy, gdy nie macie idealnej architektury. Bo nawet proste testy typu czy da się przejść od A do B potrafią zatrzymać regresję, która kosztowałaby dużo więcej niż utrzymanie tych testów. A jeśli pipeline ma być narzędziem decyzji, to właśnie smoke ma być pierwszą informacją zwrotną, nie trzygodzinna regresja.

2. Testy kontraktowe i integracyjne na API, bo dają największy zwrot przy najmniejszym bólu

Jeśli mielibyśmy wskazać jeden typ automatyzacji, który najczęściej daje świetny zwrot i jednocześnie najmniej boli w utrzymaniu, to są to testy API i kontraktowe. Są szybsze niż UI, stabilniejsze, łatwiej je uruchamiać równolegle, łatwiej je debugować, a przede wszystkim dają Wam kontrolę nad tym, co tak naprawdę psuje biznes, czyli nad integracjami i zależnościami. Większość drogich problemów jakościowych nie rodzi się w ładnym przycisku. Rodzi się na styku systemów, danych, uprawnień, konfiguracji i zewnętrznych usług.

Testy kontraktowe mają tu szczególną wartość, bo łapią zmiany w API zanim zamienią się w produkcyjne niespodzianki. Jeśli jeden zespół zmienia pole, typ danych albo wymagane atrybuty, kontrakt powinien krzyknąć. I to jest feedback, który oszczędza tygodnie frustracji. Dodatkowo testy API łatwiej utrzymać w ryzach, bo mniej zależą od wizualnych zmian i od refaktorów UI, które w każdym produkcie są nieuniknione.

W praktyce wiele zespołów ma za dużo UI i za mało API. A potem dziwi się, że pipeline trwa wieki, że testy są flaky i że każdy bug jest trudny do odtworzenia. Jeżeli macie wybór, automatyzujcie jak najwięcej na poziomie API i integracji, a UI zostawcie na cienką warstwę smoke i kilka kluczowych scenariuszy. To jest najprostszy sposób, żeby skrócić czas feedbacku bez utraty realnej ochrony.

3. Testy regresji dla rzeczy, które zmieniają się rzadko, ale psują się boleśnie

Są obszary, które nie są sexy i nie są codziennie klikane, ale gdy padną, robi się gorąco. Uprawnienia i role. Podatki. Rabaty. Faktury. Eksporty. Integracje z zewnętrznymi systemami. Raporty finansowe. Procesy, które dzieją się raz na miesiąc, ale muszą zadziałać w dniu rozliczenia. To są miejsca, gdzie manual często zawodzi nie dlatego, że ludzie są słabi, tylko dlatego, że rzadko się to dotyka i łatwo o fałszywe poczucie bezpieczeństwa.

W takich obszarach automatyzacja działa jak polisa. Raz budujecie zestaw testów, potem tylko utrzymujecie. I to utrzymanie bywa minimalne, bo logika tych obszarów zwykle zmienia się wolniej niż interfejs. Największy błąd, jaki firmy popełniają, to zostawianie takich rzeczy jako nie mamy czasu, bo nie palą się codziennie. One palą się rzadko. Ale jak już się zapalą, to potrafią spalić miesiąc.

Praktyczna wskazówka: te testy powinny być projektowane tak, żeby były deterministyczne, oparte na kontrolowanych danych i uruchamiane cyklicznie, nie tylko przy merge. Wiele regresji w obszarach rozliczeń wychodzi nie przy codziennym rozwoju, tylko przy zmianie konfiguracji, danych lub integracji. Automatyzacja ma to wyłapać, zanim zrobi to klient albo księgowość.

4. Walidacje i logika biznesowa, jeśli da się ją testować nisko

Wiele firm próbuje testować logikę biznesową przez UI, a potem cierpi. Wchodzą w formularz, wpisują dane, klikają dalej, sprawdzają komunikaty. To jest powolne, kruche i kosztowne w utrzymaniu. Dużo lepiej jest testować reguły tam, gdzie są zaimplementowane, czyli na poziomie serwisów, funkcji, komponentów, a nie na poziomie przeklikiwania ekranów. Im niżej testujecie, tym szybciej i taniej.

Logika biznesowa to idealny kandydat do automatyzacji, bo jest przewidywalna i da się ją opisać jako zestaw reguł. Rabat powinien naliczyć się w określonych warunkach. Limit powinien zadziałać w określonych warunkach. Walidacja powinna przepuścić określone formaty. I tu automaty są świetne, bo mogą przebiec setki kombinacji danych w sekundach, czego manual nie zrobi bez ogromnego nakładu.

Warto też pamiętać o jednym. Automatyzując logikę nisko, zwiększacie testowalność produktu. To jest inwestycja, która procentuje później, bo każda kolejna zmiana w logice jest tańsza do zweryfikowania.

5. Monitoring syntetyczny w produkcji dla krytycznych flow

To nie jest klasyczna automatyzacja testów w CI, ale w praktyce daje ogromną wartość, czasem większą niż kolejna paczka testów w pipeline. Syntetyczne checki typu czy można się zalogować, czy można dodać do koszyka, czy checkout dochodzi do kroku płatności, potrafią wykryć incydent zanim zrobi to klient. A to jest różnica między problemem, który widzicie w monitoringu, a problemem, o którym dowiadujecie się z komentarzy w mediach społecznościowych.

Syntetyki działają szczególnie dobrze, gdy macie zależności zewnętrzne, operatorów płatności, integracje logistyczne, zewnętrzne API, bo one potrafią psuć się punktowo i w czasie. Pipeline może być zielony, a produkcja może już cierpieć, bo zmieniły się warunki, ruch, konfiguracja albo zachowanie dostawcy. Monitoring syntetyczny jest w tym sensie testem realności. Nie mówi Wam, że kod przeszedł. Mówi Wam, że klient nadal może zrobić to, co musi zrobić.

Praktyczna zasada: syntetyki mają być krótkie, deterministyczne i mierzyć czas, a nie tylko prawdę lub fałsz. Bo dla biznesu różnica między działa a działa wolno bywa taka sama jak między działa a nie działa.

Co automatyzować ostrożnie, bo łatwo spalić czas

1. Testy UI end to end na szeroką skalę

Testy E2E są potrzebne, ale mają być jak złoto, a nie jak piasek. W idealnym świecie E2E to cienka warstwa, która potwierdza, że krytyczne flow działa od początku do końca, a reszta jakości jest łapana niżej, szybciej i taniej. Problem polega na tym, że wiele zespołów robi dokładnie odwrotnie. Zaczyna automatyzację od UI, bo to jest najbardziej widoczne i najłatwiejsze do wytłumaczenia biznesowi. Klikamy jak użytkownik, więc to musi być najlepsze. A potem pojawia się rachunek, którego nikt nie planował.

Zbyt duża liczba E2E robi trzy rzeczy naraz i każda z nich boli. Po pierwsze wydłuża pipeline. Nawet jeśli jeden test trwa minutę, sto testów to już godziny, a godziny w CI to nie tylko czas maszyn, ale przede wszystkim czas ludzi, którzy czekają na feedback albo zaczynają go omijać. Po drugie podnosi flakiness, bo testy UI są z natury bardziej wrażliwe na wszystko: czas ładowania, animacje, drobne zmiany w selektorach, stabilność środowiska, dane testowe, a nawet kolejność uruchomienia. Po trzecie daje fałszywe poczucie bezpieczeństwa, bo testy przechodzą, ale często testują jedynie scenariusz idealny. A realne bugi siedzą w wyjątkach, w danych, w integracjach, w edge case, czyli w miejscach, do których E2E rzadko dociera w sposób systemowy.

Najbardziej bolesny paradoks jest taki, że gdy E2E robi się dużo, zespół zaczyna traktować je jak cel sam w sobie. Dopisuje kolejne, bo tak rośnie coverage. Tylko że coverage w E2E rośnie wolno, kosztuje dużo i zwykle przykrywa to, że brakuje testów niższego poziomu. I wtedy zaczyna się normalizacja obejść. Wyłączacie część suite. Uruchamiacie tylko w nocy. Ignorujecie czerwone, bo pewnie flake. W tym momencie E2E przestaje chronić jakość, a zaczyna ją symulować.

Ten moment, w którym rosnąca suita E2E zamienia się właśnie w to, co nazywamy testowym spaghetti, opisaliśmy dokładniej razem z konkretnymi objawami i sposobami naprawy w osobnym tekście o tym, jak unikać testowego spaghetti.

Jak podejść do tego mądrze. Opłaca się mieć małą liczbę E2E na krytycznych flow, naprawdę małą, i trzymać je w stanie świętym: szybkie, stabilne, deterministyczne. Resztę przenosicie na API, kontrakty, integracje i testy komponentów. Kombinacje testujecie niżej.

2. Testy wizualne i pixel perfect

Testy wizualne potrafią uratować UI, zwłaszcza w produktach, gdzie layout i prezentacja są częścią wartości, na przykład w e commerce, w aplikacjach konsumenckich, w marketingowych landingach, w produktach, gdzie błąd wizualny od razu obniża zaufanie. Ale to jest automatyzacja, która ma dwie miny. Pierwsza to fałszywe alarmy. Druga to utrzymanie baseline w świecie, w którym UI zmienia się ciągle.

Pixel diff bywa bezlitosny. Dla narzędzia różnica o jeden piksel to różnica. Dla użytkownika to czasem nic, a czasem katastrofa. Jeśli wrzucicie testy wizualne masowo, bardzo łatwo zalać zespół czerwonymi alertami, które nie mają znaczenia. Wtedy zaczyna się ignorowanie, a ignorowanie w automatyzacji jest zawsze początkiem końca zaufania.

Kiedy to ma sens. Tam, gdzie layout jest krytyczny i zmiany są kontrolowane. Kluczowe ekrany sprzedażowe, checkout, koszyk, płatność, strony z formularzami, gdzie układ wpływa na konwersję. Tam test wizualny jest jak alarm przeciwpożarowy. Kiedy nie ma sensu. Gdy UI jest w ciągłej przebudowie, gdy macie dużo eksperymentów A B, gdy komponenty są dynamiczne, gdy treści są zmienne, bo wtedy baseline żyje szybciej niż testy.

Jak to ustawić, żeby nie spalić czasu. Najpierw ograniczcie zakres do kilku ekranów, potem ustalcie reguły, co jest akceptowalną zmianą, a co jest defektem, i miejcie rytuał aktualizacji baseline. Testy wizualne mają wzmacniać pewność, a nie produkować hałas.

3. Automatyzacja mobile, jeśli nie macie stabilnego środowiska i danych

Automaty na mobile są bardzo wartościowe, bo mobile to dziś często większość ruchu i często większość bólu użytkownika. Tylko że automatyzacja mobile wymaga większej dyscypliny niż web. Macie więcej wariantów systemów, urządzeń, wersji, integracji, uprawnień, powiadomień, a do tego dochodzi sieć, która w realnym świecie jest kapryśna. Jeśli nie macie stabilnego środowiska i danych testowych, mobilne automaty szybko zamienią się w generator losowych czerwonych buildów.

Najczęstsze problemy są powtarzalne. Testy padają, bo dane nie są deterministyczne. Testy padają, bo środowisko jest wspólne i ktoś zmienił stan. Testy padają, bo nie ma izolacji kont i sesji. Testy padają, bo buildy są niezsynchronizowane z backendem. Testy padają, bo urządzenia w farmie są obciążone. I nagle zespół ma wrażenie, że automatyzacja mobile jest z natury flaky. A prawda jest taka, że to nie mobile jest problemem. Problemem jest brak fundamentów.

Jak robić to bez bólu. Po pierwsze zaczynacie od minimalnego smoke na kluczowych flow, nie od pełnej regresji. Po drugie budujecie deterministyczne dane testowe i izolację kont. Po trzecie ustalacie, na jakich urządzeniach testujecie przy każdej zmianie, a jaką macierz puszczacie nocą lub cyklicznie. Po czwarte dopiero potem rozszerzacie zakres. Mobilna automatyzacja działa świetnie, gdy jest selektywna i dobrze osadzona w procesie. Działa źle, gdy próbujecie nią zastąpić całe QA.

Czego nie opłaca się automatyzować, prawie nigdy

1. Rzeczy, które wymagają oceny człowieka

UX, czytelność, zrozumiałość komunikatów, wrażenia z procesu, mikrocopy, dostępność w sensie doświadczenia, to są obszary, gdzie automat może pomóc jako filtr, ale nie zastąpi człowieka. Automat sprawdzi, czy przycisk istnieje i czy da się go kliknąć. Nie sprawdzi, czy użytkownik rozumie, że ma go kliknąć, czy czuje się bezpiecznie, czy komunikat błędu jest sensowny, czy proces jest logiczny. Jeśli próbujecie to automatyzować na siłę, dostajecie testy, które formalnie przechodzą, a produkt nadal frustruje.

2. Funkcje, które żyją w ciągłej przebudowie

Jeśli obszar UI zmienia się co sprint, automatyzacja UI będzie kosztować dużo utrzymania i będzie stale goniła produkt. To jest klasyczny moment, w którym lepiej oprzeć się na testach niższego poziomu, czyli API, komponenty, logika, a UI zostawić na krótki smoke i manualne exploratory do czasu ustabilizowania. Automatyzacja ma bronić stabilności. Jeśli obszar nie jest stabilny, automatyzacja stanie się podatkiem od zmian.

3. Rzadkie edge case, które nie są ryzykiem, tylko ciekawostką

Automatyzacja każdego pojedynczego przypadku, który zdarzył się raz, to prosta droga do rozrostu suity bez wartości. Taki test potrafi żyć latami, psuć się co jakiś czas, wymagać utrzymania, a realnie broni scenariusza, który nie wraca. Lepiej zapisać obserwację, dodać monitoring lub alerty, a test automatyczny tworzyć tylko wtedy, gdy problem ma realny koszt albo realne prawdopodobieństwo powrotu. Automatyzacja nie jest muzeum bugów. Automatyzacja jest ochroną ryzyka.

Prosta matryca decyzyjna, która działa w 15 minut

Jeśli chcecie szybko zdecydować, czy coś automatyzować, odpowiedzcie na cztery pytania.

Jeśli macie trzy razy tak, automatyzujcie. Jeśli macie dwa razy tak, automatyzujcie ostrożnie, najlepiej niżej. Jeśli macie jedno tak, zostawcie w manualu lub monitoringu. Jeśli macie zero, nie dotykajcie.

Jak policzyć ROI automatyzacji, żeby to przestało być dyskusją na wiarę

Najprostszy model jest praktyczny i konserwatywny. Liczycie, ile godzin miesięcznie idzie na ręczną regresję danego obszaru oraz ile kosztuje Was jedna godzina pracy. To jest oszczędność operacyjna. Potem dodajecie koszt ryzyka, czyli ile incydentów lub krytycznych defektów w tym obszarze mieliście w ostatnich miesiącach i jaki był ich koszt. To jest oszczędność ryzyka. Jeśli automatyzacja ma pokryć krytyczny flow, często sama oszczędność ryzyka bije oszczędność godzin.

I tu ważna rzecz. Automatyzacja zawsze kosztuje utrzymanie. Jeśli nie uwzględnicie czasu na utrzymanie, ROI będzie wyglądało pięknie na papierze i słabo w życiu. Jeśli wolicie, żeby ktoś policzył to razem z Wami na podstawie realnych danych z Waszego pipeline, tak wygląda nasz przegląd automatyzacji testów.

Jak zacząć, żeby nie zbudować wielkiego, wolnego potwora

Najlepszy start to nie jest napisanie stu testów. Najlepszy start to zrobienie małego zestawu smoke na krytyczne ścieżki i spięcie go z CI tak, żeby feedback był szybki. Potem dokładanie testów API i integracyjnych tam, gdzie najczęściej uciekają regresje. Dopiero na końcu rozbudowa E2E, ale tylko dla kluczowych flow i tylko wtedy, gdy macie stabilne środowiska i dane.

Jeśli zrobicie to w tej kolejności, automatyzacja zaczyna pomagać szybko. Jeśli zrobicie to odwrotnie, zaczyna przeszkadzać szybko.

Nasza perspektywa

W projektach automatyzacji najczęściej widzimy jeden powtarzalny błąd: zespół inwestuje miesiące w rozbudowę E2E, zanim zbuduje fundament na poziomie API i logiki biznesowej. Efekt jest zawsze ten sam. Duża liczba testów, długi pipeline i niepewność, czy czerwony build to realny problem, czy kolejny flake. W projekcie dla Argos w e-commerce uporządkowanie automatyzacji i przeniesienie części pokrycia z UI na niższe poziomy skróciło regresję przed releasem z pięciu dni do dziesięciu godzin, a liczba błędów krytycznych na produkcji spadła o 46 procent.

Pierwszy wniosek: automatyzacja nie skaluje się przez dokładanie testów, tylko przez dobór miejsc, w których testy w ogóle powinny powstać. Drugi wniosek: firmy, które boją się usuwać albo przenosić testy niżej, kończą z wolniejszym pipeline, nie z lepszą jakością. Trzeci wniosek: matryca decyzyjna z tego artykułu działa najlepiej wtedy, gdy stosujecie ją regularnie, nie tylko przy starcie projektu automatyzacji, bo produkt i ryzyka zmieniają się z czasem, a suita testów powinna nadążać za tą zmianą, nie zostawać w tyle.

Powiązane na Strefie QA

• Testy end to end: jak unikać testowego spaghetti
• 10 oznak braku kontroli przez Twojego dostawcę software’u

Źródła:

• Case study klienta Quality Island: Argos, e-commerce, zakres pracy i wyniki potwierdzone przez klienta
• Automatyzacja testów, Quality Island
• Metodyka i praktyka własna Quality Island z projektów automatyzacji