Po czym poznać, że Twój pipeline testów jest za wolny, by mieć sens

Pipeline testów miał dawać bezpieczeństwo. W praktyce w wielu firmach stał się rytuałem, który wszyscy omijają, a potem jeszcze udają, że to „dla dobra jakości”. Nie dlatego, że ludzie są leniwi. Dlatego, że są pragmatyczni. Jeśli informacja zwrotna przychodzi za późno, przestaje wpływać na decyzje. A testy, które nie wpływają na decyzje, są tylko kosztowną dekoracją.

Pipeline ma działać jak radar i jak hamulec awaryjny. Jeśli radar pokazuje przeszkodę godzinę po tym, jak ją minęliście, to nie jest radar, tylko raport historyczny. I tu jest najważniejsza informacja tego tekstu: wolny pipeline nie zwiększa jakości. Wolny pipeline uczy zespół omijania jakości. Poniżej pokazujemy, po czym poznać, że Wasz już to robi, i jak go skrócić w cztery tygodnie bez wielkiego projektu.

Gdzie naprawdę przebiega granica bólu

W teorii każdy pipeline „działa”. W praktyce liczy się jedno pytanie: czy deweloper dostaje wynik na tyle szybko, żeby nadal mieć w głowie kontekst zmiany i coś z tym zrobić tu i teraz. Granica bólu pojawia się wtedy, gdy wynik testów przestaje być częścią codziennego rytmu pracy. Commit, chwila oczekiwania, zielone albo czerwone, reakcja. Jeśli ta chwila zamienia się w pół godziny, a potem w godzinę, reakcja przenosi się na „później”. A „później” w IT ma złą reputację z bardzo dobrego powodu.

Program badawczy DORA od lat mierzy zdolność zespołów do dostarczania oprogramowania czterema wskaźnikami: częstotliwością wdrożeń, czasem od zmiany w kodzie do produkcji, odsetkiem wdrożeń kończących się awarią i czasem przywracania usługi. Wolny pipeline psuje wszystkie cztery naraz. Wydłuża czas dostarczenia, zniechęca do częstych wdrożeń, a przez większe paczki zmian podnosi ryzyko awarii i wydłuża jej naprawę. Dlatego w tym temacie nie chodzi o wygodę deweloperów. Chodzi o to, jak szybko firma zamienia pomysł w działającą funkcję i jak często coś się przy tym psuje.

Siedem sygnałów, że pipeline jest już za wolny

Poniżej macie objawy, które są bardziej wiarygodne niż samo patrzenie na licznik minut. Czas jest ważny, ale jeszcze ważniejsze jest to, co ten czas robi z zachowaniem zespołu.

Dlaczego czerwony przestaje znaczyć „czerwony”

Czwarty sygnał zasługuje na osobny akapit, bo zabija pipeline szybciej niż długość. Testy niestabilne, które raz przechodzą, a raz nie przy tym samym kodzie, uczą zespół, że wynik jest losowy. Google opisało to zjawisko na własnej skali w tekście o niestabilnych testach: mniej więcej 1,5 procent wszystkich uruchomień dawało wynik niestabilny, blisko 16 procent testów miało jakiś poziom niestabilności, a aż 84 procent obserwowanych przejść z „przeszedł” na „nie przeszedł” dotyczyło testu niestabilnego. Innymi słowy: większość czerwonych wyników nie była sygnałem o kodzie, tylko szumem.

Źródło: Google Testing Blog, „Flaky Tests at Google and How We Mitigate Them”, 2016, dane z wewnętrznej infrastruktury testowej Google.

Skala Waszego projektu jest inna, ale mechanizm ten sam. Jeśli w zestawie jest kilkadziesiąt testów, które co jakiś czas padają bez powodu, deweloper po trzech takich przypadkach przestaje czytać raport i klika „uruchom ponownie”. Od tego momentu pipeline może być nawet szybki, a i tak nie ma sensu, bo nikt mu nie wierzy. Dlatego porządek z niestabilnością robi się równolegle ze skracaniem czasu, nie po nim.

Prosty test: czy pipeline jeszcze wpływa na decyzje

Jeśli chcecie to sprawdzić bez debat, zróbcie trzy obserwacje przez jeden tydzień. Nie potrzebujecie narzędzi, wystarczy kartka przy tablicy zespołu.

Jeśli pierwsza liczba jest największa, pipeline działa. Jeśli rośnie druga, jest za wolny. Jeśli rośnie trzecia, stracił zaufanie i sam czas już go nie uratuje. W większości audytów, które robimy, zespoły są zaskoczone nie liczbą minut, tylko tym, jak rzadko wynik pipeline’u realnie zatrzymał jakąkolwiek decyzję.

Dlaczego wolny pipeline jest droższy, niż myślicie

Koszt wolnego pipeline’u nie polega tylko na tym, że ludzie czekają. Polega na tym, że system pracy uczy się złych nawyków. Testy są omijane. Problemy są odkładane. Zmiany są większe, bo nikt nie chce przechodzić przez bramkę zbyt często, a większe zmiany mają większe ryzyko. To efekt domina, który na końcu podnosi odsetek wdrożeń kończących się awarią i liczbę błędów, które docierają do klienta. Rachunek za to wystawia produkcja, a jak wysoki potrafi być, piszemy w tekście o tym, dlaczego „testujemy na produkcji” bywa mądrym wyborem, ale rzadko.

Odwrotny kierunek też jest policzalny. U klienta z e-commerce, dla którego porządkowaliśmy procesy QA i automatyzację, regresja przed wydaniem trwała 5 dni. Po przebudowie zestawu testów i włączeniu go do pipeline’u trwa 10 godzin. Ten sam klient potwierdził spadek liczby błędów krytycznych na produkcji o 46 procent i redukcję awarii w okresach szczytowych o 72 procent. Szybka pętla informacji zwrotnej nie jest wygodą dla programistów. Jest różnicą między wydaniem raz na tydzień a wydaniem, kiedy biznes tego potrzebuje. Zespół Quality Island napisał dotąd ponad 450 000 testów automatycznych i najczęstszy wniosek z tej pracy brzmi: nie liczba testów decyduje o jakości, tylko to, czy ich wynik dociera na czas.

Cztery tygodnie na skrócenie pipeline’u

Da się to zrobić bez wielkiej rewolucji, jeśli potraktujecie to jak projekt optymalizacji przepływu, a nie jak projekt „więcej automatyzacji”. Kolejność jest celowa: najpierw dane, potem szybkie wygrane, potem struktura, na końcu utrzymanie.

Dwie uwagi praktyczne. Równoległość w większości współczesnych narzędzi to nie projekt, tylko konfiguracja: Playwright ma wbudowany podział zestawu na części uruchamiane na osobnych maszynach, a GitHub Actions pozwala uruchomić to samo zadanie w macierzy równoległych przebiegów. Jeśli Wasz pipeline nadal idzie sekwencyjnie, to nie „taki mamy setup”, tylko marnowanie czasu zespołu. Druga uwaga dotyczy testów end to end: to, że da się coś przetestować przez interfejs, nie znaczy, że trzeba. Jak wybrać, co naprawdę warto automatyzować, piszemy w tekście o tym, co się opłaca automatyzować, a co nie, a jak uniknąć testowego spaghetti przy dużej skali, w artykule o testach end to end na dużą skalę.

Podsumowanie

Zbyt wolny pipeline przestaje realnie chronić jakość i zaczyna ją symulować. Jeśli nikt nie czeka na wyniki testów, to nie są one mechanizmem kontroli, tylko formalnością. Siedem sygnałów z tego tekstu i trzy liczby z jednego tygodnia obserwacji powiedzą Wam więcej niż licznik minut. A brak kontroli jakości ma to do siebie, że nie stanowi większego problemu aż do pierwszego poważnego incydentu.

W Quality Island robimy audyt pipeline’u od strony danych i zachowań zespołu: gdzie ucieka czas, które testy psują pętlę informacji zwrotnej i co da się skrócić w pierwszym tygodniu. Kończymy listą konkretnych szybkich wygranych, planem przebudowy struktury testów i metrykami utrzymania, tak żeby pipeline wrócił do roli narzędzia decyzyjnego, a nie rytuału. Jeśli chcecie zacząć samodzielnie, zacznijcie od tygodnia pierwszego: same dane o czasie i niestabilności zwykle wystarczają, żeby przekonać zespół, że problem jest realny.