Zautomatyzuj te testy, które i tak zamierzasz przeprowadzić ponownie, te, które kończą się cichą porażką, oraz te, których niepowodzenie wiąże się z kosztami, których nie da się cofnąć. Ta kolejność — powtarzalność, brak sygnału o niepowodzeniu, nieodwracalność — stanowi większość decyzji i właśnie dlatego zespół zamawiający usługi automatyzacji testów powinien zazwyczaj zacząć od ścieżki płatności lub rejestracji, a nie od funkcji, która najbardziej ekscytuje zespół produktowy. Wszystko, co zmienia się szybciej niż test może stać się nieaktualny, należy pozostawić w trybie ręcznym. Poniżej: jak wybieramy pierwsze dziesięć testów automatycznych, co celowo pomijamy oraz ile kosztuje utrzymanie zestawu testów po zakończeniu współpracy.
W jakich obszarach usługi automatyzacji testów pozwalają zaoszczędzić pieniądze, a w jakich powodują jedynie wzrost kosztów utrzymania
Jeśli wydajesz aktualizacje co tydzień lub co dwa tygodnie, koszt ręcznej kontroli jakości nie wynika z poszukiwania błędów. Chodzi o testy regresyjne: te same czterdzieści lub sześćdziesiąt kroków, które osoba wykonuje przed każdym wydaniem, prawie za każdym razem nic nie znajdując, a od czasu do czasu odkrywając tę jedną rzecz, której naprawa byłaby kosztowna. Ten etap to czysta powtarzalność, a powtarzalność to jedyna rzecz, w której automatyzacja naprawdę się sprawdza.
To nowe spojrzenie ma znaczenie, gdy trzeba uzasadnić wydatki przed dyrektorem finansowym. Automatyzacja nie zmniejsza ilości testów, jakich wymaga produkt. Przenosi ona koszt z wydatku naliczanego na każdą wersję – który rośnie wraz z częstotliwością wydawania nowych wersji – na koszt początkowy związany z wdrożeniem oraz stałą roczną opłatę za utrzymanie. Jeśli wydajesz nowe wersje co miesiąc, ta zamiana nie jest zbyt atrakcyjna. Jeśli wydajesz aktualizacje co tydzień i planujesz w przyszłym roku wydawać je dwa razy w tygodniu, to właśnie koszt związany z każdą aktualizacją będzie najbardziej dotkliwy – i to właśnie ten koszt automatyzacja spłaszcza.
Warto znać następującą zasadę obowiązującą w branży: zautomatyzowany zestaw testów regresyjnych zazwyczaj obejmuje 20–40% przypadków testowych produktu, a właśnie ten wycinek zapewnia większość oszczędności. Nie dlatego, że reszta jest nieistotna, ale dlatego, że reszta jest albo rzadko powtarzana, albo jej ocena przez człowieka jest tańsza. Użytecznym celem nie jest maksymalny zasięg testów — chodzi o pokrycie odpowiedniej części, od jednej piątej do dwóch piątych.
Tak więc prawdziwą pracą przy określaniu zakresu usług testowania oprogramowania jest selekcja, a nie dobór narzędzi. Wybór jednej platformy do automatyzacji testów w przeglądarce zamiast innej to sprawa jednego popołudnia. Wybór czterdziestu testów, które na stałe znajdą się w środowisku CI, decyduje o tym, czy zestaw testów będzie atutem, czy uciążliwością.
Jak wybrać pierwsze dziesięć testów automatycznych
Każdego kandydata należy poddać ocenie według trzech kryteriów, w podanej kolejności.
Czy to się powtarza w każdym sprincie? Jeśli odpowiedź brzmi „nie”, to automatyzacja tej czynności jest tylko hobby. Test jednorazowej migracji danych uruchamia się tylko raz; napisz skrypt, wyrzuć go, nie umieszczaj go w CI.
Czy awaria przebiega bez żadnych oznak? Rażące błędy — biały ekran, kod 500 na stronie głównej — zauważa pierwsza osoba, która otworzy aplikację, zazwyczaj bezpłatnie. Ciche błędy są tymi kosztownymi: waluta zaokrąglona w niewłaściwym kierunku, webhook zwracający kod 200 i pomijający dane, pamięć podręczna dostarczająca wiarygodną, ale nieaktualną odpowiedź. Przez tydzień nikt tego nie zauważa. Właśnie w takich sytuacjach automatyczne testy sprawdzające swoją wartość, ponieważ maszyna weryfikuje wartość, którą ludzkie oko pomija.
Czy skutki porażki można odwrócić? Uszkodzony układ strony marketingowej to tylko godzina wstydu. Nieudana transakcja, w wyniku której obciążono konto klienta, a nikomu nie zaksięgowano środków, oznacza zgłoszenie do pomocy technicznej, zwrot pieniędzy, problem z zgodnością z przepisami i utratę użytkownika. Należy przywiązywać dużą wagę do nieodwracalnych scenariuszy, nawet jeśli zdarzają się rzadko.
Trzy „tak” oznaczają: zautomatyzuj to teraz. Dwa oznaczają: umieść to w kolejce. Jedno oznacza: pozostaw to w trybie ręcznym i przestań mieć z tego powodu wyrzuty sumienia.
| Kandydat | Werdykt | Dlaczego |
|---|---|---|
| Proces płatności / ścieżka realizacji transakcji od początku do końca | Najpierw zautomatyzuj | Powtarza się przy każdym uruchomieniu, kończy się niepowodzeniem bez komunikatu, a w przypadku niepowodzenia jest nieodwracalne |
| Uwierzytelnianie, sesje, ograniczenia uprawnień | Najpierw zautomatyzuj | Powtórzenia, a wyciek uprawnień jest nieodwracalny |
| Sprawdzanie zgodności z umową API w przypadku kluczowych punktów końcowych | Najpierw zautomatyzuj | Najtańsze w pisaniu, najszybsze w uruchamianiu, wykrywające ukryte usterki |
| Integralność danych podstawowych (tworzenie, edycja, usuwanie, sumy) | Zautomatyzuj na wczesnym etapie | Powtarza się przy każdej premierze; błędne numery nie ogłaszają się same |
| Krytyczne przepływy w najpopularniejszych kombinacjach urządzeń i systemów operacyjnych | Zautomatyzuj, zawęź zakres | Warto to zrobić w przypadku krótkiej listy urządzeń, ale nie w przypadku tabeli zawierającej trzydzieści pozycji |
| Funkcja wprowadzona w tym sprincie, która wciąż jest modyfikowana | Zachowaj instrukcję obsługi | Test zostanie przepisany, zanim zostanie uruchomiony pięć razy |
| Testowanie eksploracyjne, wyszukiwanie skrajnych przypadków, “czy to wydaje się nie tak?” | Zawsze korzystaj z trybu ręcznego | Żaden skrypt nie generuje pytania, które zadaje tester |
| Wygląd graficzny, teksty reklamowe, treści stron | Zachowaj instrukcję obsługi | Ciągle się zmienia, zawodzi z wielkim hukiem, można to cofnąć w ciągu kilku minut |
Wśród tych pierwszych dziesięciu ważna jest kolejność. Zacznij od warstwy API: testy umów i integracji są najtańsze w pisaniu, najszybsze w uruchamianiu i najmniej narażone na awarie z przyczyn niezwiązanych z Twoim produktem. Następnie dodaj jedno kompleksowe przetestowanie „szlaku sukcesu” przepływu środków, a po nim trzy najgorsze scenariusze awarii tego samego przepływu — odrzucona karta, przekroczenie limitu czasu w trakcie transakcji, podwójne przesłanie danych. To właśnie tam kryją się koszty nieodwracalne i właśnie tam testerzy ręczni zaczynają się nudzić i pomijać kroki.
Powstrzymaj się przed dodawaniem od razu dziesięciu testów interfejsu użytkownika. Test przeglądarkowy, który weryfikuje coś, co można by sprawdzić za pomocą wywołania HTTP, wymaga dziesięciokrotnie większego nakładu pracy przy utrzymaniu kodu, by uzyskać tę samą informację.
Przykład z naszej praktyki: TipTip
TipTip to usługa umożliwiająca bezgotówkowe przekazywanie napiwków. Gość skanuje kod QR i dokonuje płatności — nie trzeba instalować żadnej aplikacji, rejestrować się ani zapamiętywać żadnych danych. Usługa obsługuje Apple Pay, Google Pay i BLIK, a naszym celem projektowym było zapewnienie, by cała transakcja trwała mniej niż dziesięć sekund. Zintegrowane systemy płatności posiadają odpowiednie certyfikaty.
Wystarczy przepuścić ten produkt przez trzy filtry, a odpowiedź sama się nasunie. Ścieżka płatności powtarza się przy każdej aktualizacji, ponieważ każda z nich wpływa na coś z nią powiązanego. Błąd przebiega po cichu: płatność, która niepostrzeżenie podąża wolną ścieżką, nadal zwraca ekran potwierdzenia powodzenia, tyle że nie w ciągu dziesięciu sekund, i nikt nie otrzymuje powiadomienia o tym, że “zadziałało, ale za późno”. A ta porażka jest nieodwracalna — gość, który skanuje kod, czeka, a potem rezygnuje, nie wraca, by spróbować ponownie. Ta ścieżka była pierwszą rzeczą, którą zautomatyzowaliśmy, a reszta produktu ustawiła się w kolejce za nią.
Prace nad zapleczem sprawiły, że problem stał się wyraźniejszy. Zoptymalizowaliśmy API i wprowadziliśmy buforowanie, aby zachować warunek dziesięciu sekund — a właśnie buforowanie jest mechanizmem, który generuje wiarygodne błędne odpowiedzi. Pamięć podręczna nie zgłasza błędu, gdy zawarte w niej dane są nieaktualne; pewnie zwraca wartość z zeszłego tygodnia, a test sprawdzający kod 200 i ekran sukcesu bez problemu to akceptuje. Dlatego weryfikacje musiały sięgnąć o warstwę głębiej: nie “czy żądanie zakończyło się sukcesem”, ale “czy ta wartość jest aktualna i czy całość zakończyła się w ramach limitu”. Czas staje się warunkiem weryfikacji, a nie tylko obserwacją.
Certyfikacja stanowi drugą część argumentacji. Gdy integracje płatnicze są certyfikowane, ścieżka płatności nie jest czymś, co weryfikuje się ponownie, kiedy tylko ma się na to ochotę — jest to coś, co trzeba umieć ponownie zweryfikować na żądanie, za każdym razem w ten sam sposób. To zadanie dla maszyny. Więcej o tym, jak działają mechanizmy kontroli wydania i automatyzacja testów regresyjnych w kontekście przepływów płatności, napisaliśmy w nasz artykuł na temat kontroli jakości w branży fintech oraz strategii wprowadzania nowych wersji.
W przypadku TipTip ręczne pozostawało jedynie pierwsze doświadczenie gościa: czy zeskanowanie kodu z paragonu w słabo oświetlonej restauracji wydaje się oczywiste, czy osoba, która nigdy wcześniej nie widziała tego produktu, poradzi sobie z tym bez zastanowienia. Żadne stwierdzenie nie oddaje tego.
Na co zwrócić uwagę
Konserwacja to pozycja budżetowa, a nie kwestia drugorzędna. Utrzymanie pakietu w dobrym stanie zajmuje zespołowi ds. kontroli jakości zazwyczaj 10–20% czasu rocznie — selektory ulegają dryftowi, elementy konfiguracji przestarzeją się, a piaskownica zewnętrznego dostawcy zmienia format odpowiedzi. Należy uwzględnić tę liczbę w ofercie już na samym początku. Dyrektor finansowy, który dowie się o tym w siódmym miesiącu, dojdzie do wniosku, że projekt został niedoszacowany, co jest gorsze niż nieco wyższa kwota uzgodniona z góry.
Nieprawidłowy wynik testu jest gorszy niż brak testu. Gdy zestaw testów zakończy się niepowodzeniem z przyczyn innych niż błędy, inżynierowie uruchamiają go ponownie, aż wynik będzie pozytywny, a w tym momencie przestaje on pełnić rolę sygnału ostrzegawczego. Należy naprawić niestabilność w tygodniu, w którym się pojawi, albo usunąć test. Mniejszy, sprawdzony zestaw testów jest lepszy niż większy, który jest ignorowany.
Na urządzeniach mobilnych najpierw przejrzyj listę urządzeń. Zespoły zamawiające usługi testowania aplikacji mobilnych często wymagają szerokiego zakresu urządzeń, by potem odkryć, że większość testów matrycowych nie wykrywa błędów, które umknęły kilku najlepszym testerom. Wybierz urządzenia i wersje systemów operacyjnych, które faktycznie pojawiają się w twoich danych analitycznych, zautomatyzuj na nich kluczowe ścieżki użytkowania, a „długi ogon” obsługuj ręcznie, gdy konkretne okoliczności wskazują, że warto to zrobić.
Automatyzacja nie zastępuje testera. Zastępuje to tę część tygodnia pracy testera, która polegała na powtarzaniu tych samych czynności, co pozwala mu poświęcić czas na to, czego nigdy nie dało się zautomatyzować — na zastanawianie się, co się stanie, jeśli ktoś prześle plik tysiąc razy większy niż oczekiwano. Argument ten został przedstawiony w dlaczego sztuczna inteligencja nie zastąpi kontroli jakości, i zasada ta ma zastosowanie zarówno w przypadku automatyzacji opartej na skryptach, jak i testów generowanych przez sztuczną inteligencję.
Zaplanuj przekazanie obowiązków już od pierwszego dnia. Właśnie w tym zakresie usługi outsourcingu kontroli jakości najczęściej rozczarowują: zestaw testów działa, ale potem dostawca odchodzi i nikt w firmie nie potrafi go odczytać. Należy nalegać, aby zestaw testów znajdował się w waszym repozytorium i był uruchamiany w waszym potoku CI, a nie w potoku dostawcy, a nad każdym testem znajdował się jednowierszowy komentarz wskazujący, jakie ryzyko ma on wykrywać. Następnie poproś własnego inżyniera, aby uruchomił pełny zestaw testów, naprawił jeden celowo uszkodzony test i dodał jeden nowy test, póki dostawca jest jeszcze dostępny, by odpowiedzieć na pytania — przed wystawieniem ostatecznej faktury, a nie po niej. Każda firma zajmująca się testowaniem automatycznym, którą warto zatrudnić, planuje przekazanie od samego początku, zamiast traktować to jako ostatnią pozycję na liście kontrolnej.
Wniosek
Przy ograniczonym budżecie pierwsze dziesięć testów automatycznych powinno obejmować ścieżki, które powtarzają się w każdym sprincie, kończą się niepowodzeniem bez wyraźnego sygnału i powodują trwałe straty w przypadku ich niepowodzenia. Wszystko, co wciąż jest w trakcie przeprojektowywania, oraz wszystko, co zależy od ludzkiej oceny, pozostaje w trybie ręcznym — nie jako kompromis, ale dlatego, że właśnie tam jest ich miejsce. Należy się spodziewać, że zestaw testów regresyjnych obejmie od jednej piątej do dwóch piątych przypadków testowych i przyniesie większość oszczędności, a na jego utrzymanie w dobrym stanie należy przeznaczyć 10–20% czasu na kontrolę jakości rocznie. Jeśli potrzebujesz zewnętrznej opinii na temat tego, które przepływy powinny znaleźć się w tej pierwszej części, właśnie tym zajmuje się Audyt kontroli jakości służy — kończy się listą priorytetów, a nie zaleceniami dotyczącymi narzędzi.
