Metryka dojrzałości automatyzacji

Samo posiadanie zestawu testów automatycznych nie oznacza, że organizacja potrafi z nich efektywnie korzystać. Bez właściwej metody pomiaru łatwo popaść w złudne poczucie jakości. Co w sytuacji gdy testy istnieją, ale działają wybiórczo, są trudne w utrzymaniu albo nie dają wiarygodnej informacji zwrotnej? 

Jedną z propozycji rozwiązania tego problemu jest tzw. metryka dojrzałości automatyzacji opublikowana >> tutaj <<. Jej autor sugeruje, że dzięki zestawowi kryteriów ocenianych w stali (np. 0-4) można określić, na jakim etapie rozwoju automatyzacji znajduje się zespół i jakie kolejne kroki mogą być przed nim. 

Jakie obszary bierze pod uwagę metryka

Według autora, dojrzałość automatyzacji można analizować w dziewięciu wymiarach, takich jak:

• pokrycie funkcjonalności testami automatycznymi (jaki procent funkcjonalności produktu jest realnie sprawdzanych przez testy i na jakich poziomach (unit, integracja, UI, E2E)),
• integracja z CI/CD (czy testy są uruchamiane automatycznie i czy pipeline traktuje je jako decydujący sygnał jakości),
• utrzymywalność i przegląd testów (czy testy podlegają tym samym standardom przeglądu i refaktoryzacji co kod produkcyjny), 
• stabilność i czas działania środowisk testowych (czy środowiska testowe są stabilne),
• przygotowanie i automatyzacja danych testowych (w jakim stopniu dane są przygotowywane automatycznie),
• paralelizacja uruchomień (czy testy można uruchamiać równolegle),
• czas wykonania pełnego zestawu (jak długo trwa uruchomienie pełnego zestawu),
• udział programistów i testerów w automatyzacji, czy automatyzacja jest wspólną odpowiedzialnością zespołu, czy ogranicza się do wąskiej grupy osób
• stabilność i powtarzalność wyników. 

Otrzymany dzięki temu wynik jest celem samym w sobie, a w połączeniu z wizualizacją, pozwala łatwiej zrozumieć, gdzie zespół stoi dziś i które elementy wymagają największej uwagi.

Jak mierzyć?

W praktyce metrykę można oprzeć na mierzalnych wskaźnikach, takich jak:

• % testów uruchamianych w CI/CD
• średni czas wykonania pełnego zestawu testów
• % odsetek testów niestabilnych (flaky tests)
• % pokrycia kodu testami jednostkowymi i integracyjnymi 
• % udziału testów przeglądanych w ramach code review
• stopień automatyzacji przygotowania danych testowych.

Uzyskane dane można gromadzić w raportach CI/CD, systemach monitoringu jakości (np. SonarQube, Allure, TestRail z integracją i inne) czy dedykowanych dashboardach. 

Przykład użycia

Zdefiniowane wcześniej kryteria ocenione w skali 0-4 można zwizualizować nie tylko w kontekście obecnej sytuacji, ale również zaplanować rozwój automatyzacji w funkcji czasu. Oczywiście można również użyć skali jak nasza organizacja „progresuje” np. miesiąc do miesiąca. 

Przykładowe użycie narzędzia:

Kryteria oceny – cztery poziomy dojrzałości

Z jednej strony możemy motywować się poprzez osiąganie coraz to wyższych ocen w poszczególnych kryteriach, ale również określenie poziomu naszej dojrzałości. Autor konceptu proponuje 4 poziomy. 

Poziom podstawowy (Nascent) (0-9 punktów)

W innym, wolnym tłumaczeniu „powstający”, „początkujący”. Automatyzacja praktycznie nie istnieje albo działa w sposób przypadkowy.

• testy są uruchamiane lokalnie, 
• brak repozytorium i standardów,
• minimalne pokrycie testami, 
• niski poziom kompetencji zespołu w automatyzacji,
• deweloperzy nie angażują się w tworzenie testów.

Wynik: testy nie stanowią wiarygodnego źródła informacji o jakości. 

Poziom rozwijający się (Developing) (10-19 punktów)

Istnieją pierwsze fundamenty automatyzacji, ale proces jest fragmentaryczny.

• kod testów trafia do repozytorium, lecz brakuje code review,
• testy uruchamiane są nieregularnie, często tylko na poziomie UI/E2E,
• dane testowe są ręczne lub zaszyte w kodzie, 
• deweloperzy nadal mają ograniczony udział,
• pokrycie testami jest niskie do średniego.

Wynik: testy istnieją, ale pipeline nie opiera się na nich w pełni. 

Poziom ustalony (Estabilished) (20-29 punktów)

Automatyzacja staje się stabilnym elementem procesu wytwarzania oprogramowania.

• testy uruchamiane są regularnie w CI/CD, 
• pojawia się paralelizacja, 
• pokrycie testami jest wysokie, pass rate 71-90%,
• część danych testowych generowana jest automatycznie, 
• deweloperzy sporadycznie współtworzą testy, 
• mechanizmy self-healing zaczynają być wdrażane. 

Wynik: automatyzacja daje wiarygodny obraz jakości, ale brakuje pełnej optymalizacji i równowagi pomiędzy poziomami testów.

Poziom zaawansowany (Advanced) (30-40 punktów)

Najwyższy poziom, w którym automatyzacja jest integralną częścią procesu. 

• dominacja testów jednostkowych i komponentowych,
• pełna integracja z CI/CD,
• wykonanie zestawu zajmuje poniżej godziny dzięki paralelizacji, 
• stabilność na poziomie 95%+ pass rate, 
• aktywny udział deweloperów i QA,
• dane testowe w pełni automatyczne i konfigurowalne, 
• self-healing i retry stosowane systemowo,
• code review obejmuje testy,
• wyniki natychmiast trafiają do zespołu.

Wynik: automatyzacja działa szybko, stabilnie i przewidywalnie, wspierając każdą zmianę w kodzie. 

Metryka ma sens tylko wtedy, gdy prowadzi do konkretnych działań. Warto wyznaczać mierzalne cele, np. zwiększenie udziału testów uruchamianych w CI/CD z 60% do 90% w kwartale, skrócenie czasu wykonania pełnego zestawu z 2 godzin do 30 minut czy redukcja flaky tests do poziomu <2%.

Najważniejsze jest dopasowanie celów do obecnego etapu. Zespół na poziomie Developing nie powinien zaczynać od wdrażania self-healing testów, jeśli wciąż brakuje mu stabilnego CI/CD.

O czym warto pamiętać

Jak każda metryka, także ta niesie ze sobą pewne ryzyka. Nadmierne skupienie się na liczbach może prowadzić do mylnego poczucia bezpieczeństwa. Wysokie pokrycie testami nie gwarantuje jakości, jeśli testy są słabe. Innym zagrożeniem jest fałszywe poczucie bezpieczeństwa. Pipeline może pokazywać stabilne wyniki, a mimo to pozostawiać obszary całkowicie nieprzetestowane. 

Bonus

W ramach artykułu udostępniamy także opracowane przez nas narzędzie do samodzielnej analizy dojrzałości automatyzacji. To prosty arkusz Excel z automatycznym wykresem radarowym, dostępny dla subskrybentów serwisu testerzy+.

>> pobierz narzędzie <<

Podsumowanie

To podejście jest jedną z propozycji, które mogą pomóc w uporządkowaniu myślenia o automatyzacji testów. Nie każdy zespół musi w pełni zgadzać się z przedstawionymi poziomami, ale sam fakt uporządkowania obszarów i pokazania ich na osi czasy może być użytecznym punktem odniesienia.