Testy end to end: jak unikać testowego spaghetti

W pewnym momencie każda większa organizacja dochodzi do tego samego miejsca. Automatyzacja działa, testy „end to end” rosną, coverage wygląda coraz lepiej, a mimo to wdrożenia dalej są stresujące. Pipeline jest dłuższy niż powinien. Czerwone buildy pojawiają się częściej, niż wynikałoby to z realnych defektów. A najgorsze jest to, że kiedy coś się psuje, nikt nie wie, czy to problem z produktem, testami, środowiskiem czy danymi. Wtedy testy „end to end” przestają być siecią bezpieczeństwa. Zaczynają być makaronem, w którym wszystko jest połączone ze wszystkim i każde dotknięcie kończy się lawiną.

To właśnie nazywamy testowym spaghetti. Nie chodzi o liczbę testów. Chodzi o strukturę, zależności i to, czy testy dają sygnał, czy generują hałas.

Typowy scenariusz wygląda tak: dwa lata temu zespół miał dwadzieścia testów E2E i wszystko działało sprawnie. Dziś ma trzysta, pipeline trwa dwie godziny zamiast dwudziestu minut, a każdy pull request czeka na wynik dłużej, niż trwało jego napisanie. Nikt nie podjął jednej złej decyzji. Setki małych, indywidualnie rozsądnych decyzji złożyły się w system, który dziś spowalnia zespół bardziej, niż go chroni.

Skąd bierze się testowe spaghetti

Najczęściej z dobrych intencji. Ktoś ma produkcyjny incydent, więc dopisuje test end to end, żeby to się nie powtórzyło. Ktoś inny chce podnieść coverage, więc automatyzuje kolejne scenariusze przez UI, bo to jest najbardziej namacalne. Ktoś trzeci dorzuca testy na tej samej ścieżce, tylko z inną kombinacją danych. Po roku masz setki testów, które teoretycznie bronią jakości, ale praktycznie robią trzy rzeczy: wydłużają feedback, zwiększają flakiness i utrudniają diagnozę.

Jest też drugi mechanizm. E2E stają się domyślnym narzędziem do testowania wszystkiego, bo inne poziomy testów są słabe albo nie istnieją. Brakuje testów kontraktowych, brakuje integracji na API, brakuje testów komponentów, więc UI przejmuje całą odpowiedzialność. A UI to najdroższe miejsce do testowania, bo jest wolne, kruche i zależne od wszystkiego.

Oba mechanizmy napędzają się wzajemnie. Im więcej E2E, tym mniej presji, żeby budować testy niższego poziomu, bo „przecież coverage rośnie”. Im mniej testów niższego poziomu, tym więcej nowych scenariuszy trafia domyślnie do E2E, bo to jedyne narzędzie, które zespół ma pod ręką. Bez świadomej interwencji ten cykl nie zatrzymuje się sam, tylko przyspiesza z każdym kwartałem wzrostu produktu.

Pięć objawów, że wchodzicie w spaghetti

Źródło: metodyka i praktyka własna Quality Island z przeglądów suit E2E.

Jeśli widzicie te sygnały, to nie jest kwestia chwilowego kryzysu. To jest kwestia konstrukcji suity.

Pierwszy objaw to czerwone buildy, które coraz częściej kończą się zdaniem to flake. Jeśli zespół przestaje ufać czerwieni, to przestaje działać cały mechanizm kontroli jakości, bo alarm, który ignorujecie w połowie przypadków, przestaje być alarmem.

Drugi objaw to długi czas do diagnozy. Test pada, ale logi są nieczytelne, screenshot nic nie mówi, a odtworzenie problemu wymaga pół godziny zabawy. Wtedy test nie jest narzędziem feedbacku, tylko zadaniem detektywistycznym, a każde takie zadanie kosztuje więcej niż sam błąd, który miało wykryć.

Trzeci objaw to testy, które są długie i obejmują zbyt wiele kroków. Logowanie, wyszukiwanie, dodanie do koszyka, checkout, płatność, mail, tracking. Gdy taki test padnie, nie wiesz, co tak naprawdę się zepsuło. A jeśli nie wiesz, to znaczy, że test jest zbyt gruby.

Czwarty objaw to zależność od wspólnego stanu. Testy używają tych samych kont, tych samych danych, tej samej puli zasobów. Jeden test zmienia stan, drugi na nim polega, trzeci sprząta, czwarty sprząta źle. To jest klasyczny przepis na nieprzewidywalność, i to jeden z tych problemów, które rosną wykładniczo wraz z liczbą testów, nie liniowo, bo każdy nowy test to nowa potencjalna kolizja ze wszystkimi poprzednimi.

Piąty objaw to automatyzacja tego, co ciągle się zmienia. UI jest przebudowywane, copy się zmienia, layout żyje, a testy są oparte na kruchych selektorach i kolejności kliknięć. Utrzymanie zaczyna kosztować więcej niż wykrywane defekty.

Zasada, która ustawia wszystko na właściwe tory

Testy end to end są potrzebne, ale mają być cienką warstwą. Ich rola nie polega na tym, żeby sprawdzić wszystko. Ich rola polega na tym, żeby potwierdzić, że najważniejsze rzeczy działają w realnym przepływie i że integracja systemu się nie rozjechała.

Jeśli Wasze E2E próbują zastąpić testy jednostkowe, integracyjne i kontraktowe, to przegracie. Nie dlatego, że E2E są złe. Dlatego, że są zbyt drogie, żeby robić wszystko.

Jeśli chcecie, żeby ktoś z zewnątrz spojrzał na Waszą suitę E2E i powiedział wprost, co w niej zostawić, a co przenieść niżej, tak wygląda nasz przegląd testów end to end.

Ile to naprawdę kosztuje, kiedy nikt tego nie liczy

Koszt testowego spaghetti rzadko trafia do żadnego budżetu, bo rozkłada się na dziesiątki małych strat, których nikt osobno nie zauważa. Godzina dłuższy pipeline razy liczba merge’y dziennie. Pół godziny na diagnozę flaky testu razy liczba takich przypadków w tygodniu. Czas programisty, który czeka na wynik zamiast pisać kolejny kawałek kodu. Żadna z tych liczb osobno nie robi wrażenia na zarządzie, ale razem tworzą realny, powtarzalny koszt operacyjny, który rośnie z każdym kwartałem, w miarę jak suita puchnie.

Jest też koszt trudniejszy do policzenia, ale równie realny: erozja zaufania zespołu do własnych testów. Gdy programiści przestają wierzyć czerwonemu buildowi, zaczynają go ignorować, a wtedy cały sens posiadania testów znika, mimo że formalnie suita nadal istnieje i formalnie nadal „działa”. To jest najdroższy moment w cyklu życia testowego spaghetti, bo od niego jest już tylko krok do sytuacji, w której realny defekt przechodzi przez czerwony build, którego nikt nie sprawdził, bo „pewnie flake”.

Jak uniknąć spaghetti w praktyce

Odetnij suity od zależności i wspólnego stanu

Największy prezent, jaki możecie zrobić E2E, to deterministyczność. Każdy test powinien mieć własne dane, własne zasoby i własną ścieżkę sprzątania. Jeśli nie da się tego zrobić w pełni, to przynajmniej izolujcie to, co jest krytyczne. Oddzielcie konta testowe, koszyki, zamówienia, dane klienta. Jeśli dwa testy walczą o ten sam stan, to w długim terminie przegrywacie.

W praktyce oznacza to też inwestycję w API do przygotowania danych. UI nie powinno służyć do robienia setupu, bo setup przez UI jest wolny i kruchy. Setup rób API albo bezpośrednio na poziomie serwisów, a UI zostaw na to, co ma sprawdzić.

Krój testy na mniejsze, celowe scenariusze

Długi test, który sprawdza wszystko, jest kuszący, bo wygląda jak prawdziwa ścieżka użytkownika. Tylko że prawdziwa ścieżka użytkownika to nie jest najlepsza jednostka diagnostyczna.

Zamiast jednego testu od logowania do płatności, zróbcie kilka krótszych, które mają jasną odpowiedzialność. Jeden test sprawdza logowanie i sesję. Drugi sprawdza dodanie produktu do koszyka. Trzeci sprawdza przejście przez checkout do kroku wyboru metody płatności. Czwarty sprawdza integrację z bramką płatniczą, ale już z przygotowanym koszykiem. Dzięki temu, gdy coś padnie, wiecie, gdzie padło. A to jest różnica między sygnałem a chaosem.

Ta zmiana ma też efekt uboczny, który zespoły doceniają dopiero po fakcie: krótsze testy są szybsze do naprawy, kiedy się zmienia produkt. Jeśli zmienia się krok logowania, poprawiacie jeden mały test, nie przepisujecie całej długiej ścieżki od nowa. Koszt utrzymania rośnie liniowo z liczbą testów, ale spada gwałtownie, gdy każdy test jest mały i ma jedną odpowiedzialność.

Ustal kontrakty i przenieś większość pokrycia niżej

Najlepszy sposób na odchudzenie E2E bez utraty ochrony to przenoszenie ryzyk z UI na API, kontrakty i integracje. Wiele regresji, które dziś łapiecie przez klikane UI, możecie złapać szybciej i stabilniej na poziomie serwisów. Kontrakt API powie Wam, że zmieniło się pole. Test integracyjny powie Wam, że zmieniła się logika. A E2E będzie tylko potwierdzać, że całość spina się z perspektywy użytkownika.

To jest też sposób na skrócenie pipeline, nie przez dokupienie mocniejszych runnerów, tylko przez zmianę struktury. Test API trwa zwykle w milisekundach, test E2E w sekundach albo dziesiątkach sekund. Jeśli przeniesiecie choćby jedną trzecią dzisiejszego pokrycia E2E na poziom API, czas całego pipeline’u potrafi spaść wielokrotnie, nie o kilka procent, bo różnica w koszcie pojedynczego testu jest rzędu wielkości, nie drobnej optymalizacji. To, co dokładnie warto przenosić niżej, a co zostawić w E2E, rozpisaliśmy szerzej w tekście o tym, co się naprawdę opłaca automatyzować.

Przestańcie automatyzować wszystko, zacznijcie automatyzować ryzyko

Każdy test E2E powinien mieć metkę ryzyka. Dlaczego on istnieje. Co chroni. Jaki koszt miałby błąd w tym miejscu. Jeśli nie potraficie tego powiedzieć w jednym zdaniu, test prawdopodobnie jest kandydatem do usunięcia albo przeniesienia niżej.

W dużych projektach suita rośnie, bo nikt nie usuwa testów. A prawda jest taka, że testy też mają cykl życia. Scenariusz, który był krytyczny dwa lata temu, dziś może być marginalny albo pokryty na innym poziomie. Bez regularnego odchudzania każda suita zamienia się w muzeum dawnych problemów.

Zróbcie porządek z selektorami i stabilnością UI

To nie jest temat sexy, ale robi różnicę. Kruchy selektor to kruchy test. Jeśli testy używają selektorów zależnych od layoutu, klasy CSS czy tekstu, to będą padać przy byle zmianie. Stabilne atrybuty testowe są nudne, ale oszczędzają miesiące frustracji. Do tego dochodzi jedna zasada, która ratuje życie. Nie testujcie animacji. Nie testujcie timingów. Testujcie stany. Czekajcie na warunki, nie na czas.

Traktujcie flakiness jak dług, nie jak irytację

Flakiness nie jest drobną usterką. To jest dług jakości w automatyzacji. Jeśli go nie spłacacie regularnie, przestajecie ufać wynikowi suity. A jeśli nie ufacie, to suita przestaje być bramką jakości.

W praktyce działa prosta rzecz. Lista najczęściej padających testów, właściciel i cotygodniowy limit czasu na naprawy. Nie raz na kwartał. Co tydzień. Zaczynacie od tych, które padają najczęściej i najdrożej, czyli blokują pipeline i wymagają triage.

Zróbcie dwa tryby uruchomień zamiast jednej wielkiej suity

Duże organizacje wygrywają tym, że nie próbują uruchamiać wszystkiego zawsze. Mają szybki zestaw, który leci na każdą zmianę i ma dać decyzję merge. I mają zestaw głębszy, który leci cyklicznie, nocą albo przed releasem, żeby wyłapać szersze ryzyka. Jeśli wszystko leci zawsze, pipeline staje się korkiem. Jeśli nic nie leci zawsze, pipeline staje się fikcją. Potrzebujecie dwóch prędkości.

Jak zacząć, jeśli już jesteście w spaghetti, nie dopiero go unikacie

Jeśli powyższe brzmi znajomo i suita już dziś jest duża, wolna i niestabilna, nie zaczynajcie od wielkiego projektu przepisania wszystkiego naraz. Taki projekt rzadko się kończy, bo konkuruje z bieżącą pracą i zawsze przegrywa. Lepszy start to trzy kroki rozłożone na kilka tygodni, nie miesięcy.

Pierwszy krok: policzcie, ile testów w suicie jest oznaczonych jako niestabilne albo regularnie pomijane, i zróbcie z nich osobną listę. Drugi krok: dla dziesięciu najdłużej trwających testów sprawdźcie, czy da się je skrócić albo przenieść część ich odpowiedzialności na API. Trzeci krok: wprowadźcie metkę ryzyka dla nowych testów od razu, żeby przestać dokładać kolejne warstwy tego samego problemu, zanim skończycie porządkować stare. Po miesiącu takiej pracy suita nie będzie idealna, ale przestanie się pogarszać, a to jest punkt, z którego dopiero da się realnie poprawiać.

Krótka checklista, która ratuje E2E przed spaghetti

Jeśli chcecie sprawdzić, czy idziecie w dobrą stronę, zadajcie sobie kilka pytań.

Źródło: metodyka i praktyka własna Quality Island z przeglądów suit E2E.

Jeśli na któreś z tych pytań odpowiedź brzmi nie, to nie jest porażka. To jest sygnał, gdzie jest największy zwrot z inwestycji w naprawę.

Nasza perspektywa

Przegląd suity E2E pod kątem wartości i ryzyka to jeden z częstszych powodów, dla których klienci trafiają do nas z uporządkowaną, ale wolną automatyzacją. W projekcie dla Argos w e-commerce uporządkowanie procesów QA i przeniesienie części pokrycia z UI niżej skróciło regresję przed releasem z pięciu dni do dziesięciu godzin, przy jednoczesnym spadku liczby błędów krytycznych na produkcji o 46 procent. To nie były dwa osobne efekty. Krótsza regresja i mniej błędów wzięły się z tej samej zmiany strukturalnej: mniej testów w najdroższym miejscu, więcej w tańszych.

Pierwszy wniosek: zespoły rzadko przesadzają z E2E świadomie. Suita rośnie po trochu, decyzja po decyzji, każda z osobna rozsądna, aż w sumie staje się problemem, którego nikt nie zaplanował. Dlatego regularny przegląd suity, nie jednorazowa akcja porządkowa, jest jedynym trwałym rozwiązaniem.

Drugi wniosek: firmy, które boją się usuwać testy, kończą z większym ryzykiem, nie mniejszym. Test, któremu nikt nie ufa, bo jest flaky, daje fałszywe poczucie bezpieczeństwa gorsze niż jego brak, bo maskuje dziurę zamiast ją pokazywać.

Trzeci wniosek: najlepszy moment na odchudzenie suity to nie kryzys, tylko regularny rytuał. Zespoły, które raz na kwartał poświęcają jeden dzień na przegląd suity E2E, usuwanie martwych testów i przenoszenie pokrycia niżej, nigdy nie dochodzą do stanu, w którym pipeline trwa dwie godziny. Zespoły, które czekają na kryzys, muszą później robić w tydzień to, co można było robić po trochu przez rok.

Powiązane na Strefie QA

• Automatyzacja testów: co się naprawdę opłaca automatyzować, a co nie
• 10 oznak braku kontroli przez Twojego dostawcę software’u
• Testy bezpieczeństwa aplikacji: minimalny zestaw działań dla zarządów

Źródła:

• Case study klienta Quality Island: Argos, e-commerce, zakres pracy i wyniki potwierdzone przez klienta
• Testy end to end, Quality Island
• Metodyka i praktyka własna Quality Island z przeglądów suit E2E