Projekt automatyzacji, który w trzy lata znalazł osiem błędów

Najrzadszy dokument w automatyzacji testów to nie historia sukcesu. To dyrektorka ds. jakości, która pod własnym nazwiskiem publikuje szczegółową relację z trzyletniego programu, który się nie udał. Carina Gerry, Director of Engineering Quality w SalesLoft, zrobiła dokładnie to w maju 2020 roku we wpisie zatytułowanym „Automation: A Failure Story”. Tytuł niczego nie łagodzi.

Warto jej to oddać. Postmortemy od osób gotowych nazwać projekt, harmonogram i efekty są w tej dziedzinie rzadkie. Większość tekstów o automatyzacji opisuje sukcesy. Ten opisuje zestaw, który działał trzy lata, kosztował sporo pracy przy utrzymaniu i znalazł osiem błędów. Opublikowanie tego wymaga odwagi.

Siedemnastu testerów i rój

W 2015 roku SalesLoft miał dwóch inżynierów QA zajmujących się wydaniami. Jesienią 2016 roku zespół urósł do pięciu osób. Ostatecznie liczył siedemnastu inżynierów QA testujących ręcznie i eksploracyjnie. Regresję obsługiwano przez to, co Gerry nazywa „rojami”: skoncentrowane, ręczne akcje trwające dzień lub dwa przed ważnymi wydaniami.

Model roju skalował się na tyle dobrze, że rósł razem z produktem, ale każde ważne wydanie zamieniał w duże wydarzenie dla całego zespołu. Automatyzacja wydawała się oczywistą odpowiedzią i w tamtym czasie była odpowiedzią powszechnie przyjętą w całej branży.

Zestaw, który nazwali LARS

Zespół zbudował zestaw przeglądarkowych testów regresji o nazwie LARS, korzystając z Capybary, Selenium i Ruby, uruchamiany na AWS EC2. Z czasem rozrósł się do około 300 testów.

Trzysta testów to niebagatelne przedsięwzięcie. Napisanie ich zajmuje miesiące. Utrzymanie wymaga stałej uwagi poświęcanej środowiskom, zależnościom i infrastrukturze. Zanim LARS osiągnął ten rozmiar, pochłaniał znaczną część czasu zespołu QA.

Przez całe życie zestawu utrzymywały się dwa problemy. Pierwszy to czas: pełny przebieg trwał ponad godzinę. Drugi to niezawodność: testy były niestabilne, głównie dlatego, że pisano je pod kruche selektory CSS. Gdy zmieniał się interfejs, selektory się psuły. Gdy selektory się psuły, trzeba było przejrzeć wyniki, zanim ktokolwiek mógł im zaufać.

Zestaw trwający godzinę zmienia swoje miejsce w cyklu wytwarzania. Nie da się go uruchomić przed commitem ani przed otwarciem pull requesta. Uruchamia się go, gdy praca jest już scalona, więc awarie przychodzą jako przerwanie czegoś, czym już się nie zajmujecie. Przestaje być mechanizmem informacji zwrotnej i staje się opóźnionym alarmem.

Trzysta testów, osiem błędów

LARS znalazł trzy–cztery błędy na początku, a w sumie osiem w ciągu mniej więcej trzech lat działania.

To liczba, którą podaje Carina Gerry, i warto się nad nią zatrzymać. Trzysta testów, ponad godzina na przebieg, utrzymywane przez trzy lata, a łączny efekt to osiem błędów. Przy tych liczbach koszt zestawu niemal na pewno przewyższył wartość, którą dał. Mimo to zespół dalej w niego inwestował, zamiast go ograniczyć. Autorka podaje powód wprost: dla projektu nigdy nie zdefiniowano miar sukcesu. Bez celu nie było punktu odniesienia ani uzgodnionego momentu na ponowną ocenę. Projektu nie dało się poprowadzić do sukcesu, bo nikt nie uzgodnił, jak sukces wygląda, i nie dało się go wcześnie zamknąć, bo nie było progu, którego w widoczny sposób nie spełnił.

Potem zmieniła się architektura. SalesLoft przeszedł z Angulara na Reacta i podzielił się na mikroserwisy. Zespół frontendu przeszedł z Ruby na JavaScript. LARS został w tyle w obu znaczeniach: testowany produkt stał się zasadniczo inny, a inżynierowie piszący nowy kod nie mogli utrzymywać zestawu w Ruby. Odpowiedzialność po cichu przeszła na nikogo.

Zestaw umarł 23 stycznia 2019 roku. Zespół wrócił do siedemnastu inżynierów QA testujących ręcznie i eksploracyjnie.

„Codziennie wyłapujemy błędy, zanim trafią na produkcję”.

Tak Gerry opisuje pracę zespołu ręcznego. To nie pocieszenie; to wynik.

Porażka strukturalna, nie techniczna

Patrząc na decyzje podejmowane po drodze, każda w swoim czasie była do obrony. Capybara i Selenium były standardowymi narzędziami automatyzacji przeglądarki w firmach pracujących w Ruby w 2015 roku. Selektory CSS były wtedy sposobem, w jaki większość ludzi lokalizowała elementy. Uruchamianie na EC2 było rozsądnym wyborem infrastruktury. Budowanie testów przeglądarkowych dla aplikacji webowej nie jest samo w sobie błędem.

To, co poszło źle, nie było żadnym pojedynczym wyborem technicznym. Była to kombinacja: brak definicji sukcesu; testy pisane w języku, który nie należał do zespołu frontendu; selektory powiązane ze znacznikami, które zmieniały się przy każdym redesignie; i czas trwania, który stawiał zestaw poza naturalnym rytmem pracy. Każdy problem osobno był do zniesienia. Razem gwarantowały, że z każdym miesiącem zestaw będzie się coraz bardziej oddalał od testowanego kodu, bez uzgodnionego progu, przy którym uznano by, że nie jest już wart inwestycji.

Trzy lata to też wystarczająco dużo czasu, by produkt stał się czymś zasadniczo innym. Każdy program automatyzacji mierzony w latach ściga się z architekturą, pod którą został napisany, a architektura nieustannie się zmienia. Zestaw walczył ze starzeniem się na długo przed tym, zanim migracja z Angulara na Reacta przypieczętowała jego los.

Czy powrót do testów ręcznych był błędem?

Wygodne odczytanie tej historii jest takie, że automatyzacja zawiodła przez błędy implementacji, a lepsza implementacja by się udała. To odczytanie warto zakwestionować.

Siedemnastu testerów eksploracyjnych, którzy codziennie wyłapują błędy, to nie nagroda pocieszenia. Testowanie eksploracyjne prowadzone przez doświadczonych ludzi znajduje te rodzaje awarii, które umykają testom ze scenariuszem: nieoczekiwane interakcje, zachowania zależne od kontekstu, rzeczy, które człowiekowi wydają się nie w porządku, ale przechodzą zero-jedynkową asercję. LARS znalazł osiem błędów w trzy lata. Zespół ręczny znajdował błędy codziennie. Przy tych liczbach praktyka ręczna była skuteczniejsza.

Lekcja nie polega na tym, że zespół powinien był automatyzować bardziej, budować lepsze selektory albo przepisać zestaw na JavaScript, gdy zespół frontendu zmienił język. Polega na tym, że automatyzowanie interakcji w przeglądarce na zmieniającej się architekturze, bez definicji sukcesu i bez jasnej odpowiedzialności, nie wygrywa niezawodnie z kompetentnym zespołem ręcznym przy szybko zmieniającym się produkcie. Automatyzacja nie zawsze jest właściwą odpowiedzią. W świetle tych faktów powrót do modelu, który naprawdę działał, był racjonalną decyzją.

Ten wniosek jest sprzeczny z interesem handlowym każdej firmy sprzedającej doradztwo w zakresie automatyzacji, także naszej. Mówimy to mimo wszystko, bo na to wskazują dowody.