Regresja oparta na ryzyku — co uruchamiać, gdy nie da się uruchomić wszystkiego
Wybierz, które testy regresji idą na pull request, które czekają na noc, a które powinny wyjść z suite.
Ten wpis jest częścią serii Jakość w CI/CD. Jeśli pominąłeś poprzedni, przeczytaj Część 6 — Continuous testing w continuous delivery.
Wprowadzenie — suite urosła szybciej niż pipeline
Regresja kiedyś kończyła się przed lunchem. Potem urosła. Pull request czeka czterdzieści minut, ludzie restartują czerwone joby i ktoś proponuje pominąć testy „tylko tym razem”.
Ta propozycja jest już decyzją. I tak wybierasz, czego nie uruchamiać. Pytanie brzmi, czy wybór jest zapisany.
Ten wpis nie jest o tym, co automatyzować na początku. Jest o suite, która już istnieje i nie mieści się w czasie, który masz.
Oceniaj test, nie historyjkę
Każdemu testowi regresji daj cztery liczby, od 0 do 3:
| Sygnał | 0 | 3 |
|---|---|---|
| Koszt porażki | Literówka w stopce | Ruszają się pieniądze, wyciekają dane albo nie da się zalogować |
| Bliskość zmiany | Obszar nie zmieniał się od miesięcy | Diff dotyka tego kodu albo jego kontraktu |
| Świeży sygnał | Od 90 dni nie padł i nie złapał błędu | W ostatnim miesiącu padł na prawdziwym defekcie |
| Czas | Poniżej 10 sekund | Powyżej 2 minut albo wymaga wspólnego środowiska |
Dodaj je. Wysoki wynik idzie na pull request. Niski czeka na noc albo wychodzi z suite.
Bliskość zmiany liczy się na każdy pull request. Pozostałe trzy liczby wystarczy przeglądać co tydzień. Wynik nie jest wieczny.
Wystarczą trzy kubełki
- Pull request. Podróż, której awaria psuje biznes, i test na tyle stabilny, że mu ufasz. Limit to czas, nie liczba testów. Dwadzieścia minut to rozsądny sufit.
- Noc. Prawdziwe pokrycie, które jest za wolne, za szerokie albo zależy od danych, których nie odświeżysz na każdy commit.
- Kwarantanna. Niestabilne albo czerwone bez właściciela. Taki test nie blokuje merge. Ma właściciela i datę. Po dwóch tygodniach bez właściciela usuń go.
Test, który zawsze jest nocny, nie jest siatką bezpieczeństwa. To raport, którego nikt nie czyta. Jeśli noc pada, a kolejny krok to „uruchom ponownie”, kubełek jest zły.
Bliskość bez wróżenia
Nie potrzebujesz idealnego grafu wpływu. Zacznij od tagów zgodnych z obszarami, które zespół i tak nazywa:
- name: Regression for this change
run: npx playwright test --grep @checkout
if: contains(github.event.pull_request.labels.*.name, 'area:checkout')Dopóki etykiet nie ma, odpalaj na pull requeście tylko kubełek pull requestu, w całości. Firefox, pełny reset danych i każdy przypadek brzegowy w tym kubełku to sposób, w jaki wraca czterdzieści minut.
Co znaczy „usuń”
Test, który przez kwartał nie padł i nie był powodem złapania błędu, jest kandydatem. Przeczytaj go, zanim usuniesz. Czasem to jedyne sprawdzenie przepisu, reguły płatności albo uprawnienia. Takie zostają, nawet gdy są wolne. Idą na noc, nie znikają.
Usunięcie duplikatu jest bezpieczniejsze niż usunięcie jedynej asercji. Dwa testy E2E, które klikają ten sam przycisk i czekają na ten sam toast, to jeden test.
Podsumowanie
Suite regresji to budżet. Minuty pull requestu wydaj na koszt porażki i na kod, który naprawdę się zmienił. Noc dostaje resztę. Nic nie dostają testy, których nikt nie naprawi.
Zadanie na ten tydzień: Zmierz suite na pull requeście. Każdy test powyżej dwóch minut, który nie blokuje wydania, przenieś na noc. Do kwarantanny wrzuć to, co padło bez defektu w ostatnich dwóch tygodniach.
Następny wpis w serii: Część 8 — Co QA bierze na siebie po wdrożeniu.