Większość zespołów potrafi powiedzieć, ile trwa pipeline albo ile scenariuszy ma regresja. Znacznie rzadziej ktoś wie, ile minut tygodniowo znika, zanim ktokolwiek uruchomi pierwszy sensowny test na konkretnej zmianie. Ten tekst ma nazwać ten koszt wprost - bez narzędziowego żargonu i bez obietnic „magicznego rozwiązania”.
Po co ten tekst
Mierzycie automatyzację, pokrycie, czas builda. To ważne. Równo ważne jest jednak opóźnienie decyzji, czyli czas od „jest gotowy PR” do „wiemy, co w tej zmianie realnie ryzykowne i co warto sprawdzić najpierw”. W tej luce nie ma jeszcze zielonego ani czerwonego światła z CI - jest tylko czytanie, domyślanie się i pytania na czacie.
Właśnie tam najczęściej giną przypadki brzegowe. Później, na produkcji, łatwo powiedzieć „QA przeoczyło”. Częściej prawda jest bliższa temu, że nikt nie miał wspólnego, krótkiego obrazu zakresu, zanim zaczęło się wykonanie pod presją czasu.
Rozłóżmy jeden PR na czynniki pierwsze
Schemat bywa ten sam, niezależnie czy w trackerze macie Jirę, Azure DevOps, Linear czy kartkę na tablicy:
- Zgłoszenie - co miało być zrobione, dla kogo, pod jakie założenia. Zwykle brakuje tego, co autor miał w głowie: „to i tak tylko refaktor”, „endpoint już był, tylko dopisaliśmy pole”, „feature flag i tak jest wyłączony”.
- Diff - co faktycznie się zmieniło w kodzie i konfiguracji. Tu wychodzą rzeczy, których ticket nie dotyka: migracja, zmiana kontraktu, nowa zależność, warunek w ścieżce, której nikt nie opisał w wymaganiach.
- Mapa wpływu - które moduły, integracje, uprawnienia i ścieżki użytkownika są w grze. To już nie jest czytanie linijka po linijce - to pytanie „co może pójść nie tak, jeśli założenie X jest fałszywe”.
- Wybór zakresu - dopiero teraz sensownie wybieracie scenariusze, checklistę albo pytania do autora. Jeśli kroki 1-3 poszły na skróty, krok 4 kończy się albo „sprawdzę wszystko”, albo „dam znać jak coś znajdę”.
Żaden z tych kroków nie jest „stracony” - to normalna praca inżynierska. Problem zaczyna się wtedy, gdy nie liczycie tego jako kosztu, tylko jako coś, co „i tak QA ogarnie przy okazji”.
Przykład bez nazwiska i bez stacku
Wyobraź sobie zmianę w logice naliczania czegoś w backendzie: ticket mówi o poprawce zaokrągleń dla jednego kraju. W diffie widać też zmianę w warunku cache i dotknięcie wspólnej biblioteki używanej przy wysyłce powiadomień. Osoba z QA czyta ticket pięć minut, diff i powiązane pliki kolejne piętnaście, potem pięć minut na notatki i pytanie na kanale: „czy powiadomienia wchodzą w zakres?” - odpowiedź przychodzi po godzinie, bo autor jest na innej sesji.
Zanim padnie pierwsze „odpal regresję”, minęło pół godziny czystej uwagi tylko na zrozumienie granic zmiany - i to w optymistycznym wariancie. Przy dziesięciu podobnych PR-ach w tygodniu to już pięć godzin, których nie widać w raporcie z testów ani w dashboardzie pipeline’u. Przy dwudziestu PR-ach i dwóch osobach, które robią ten sam typ analizy, rozmowa o „wydajności QA” zwykle omija ten wiersz.
Dlaczego to nie skaluje się wraz z zespołem
Im więcej równoległych zmian, tym większy tłok na tych samych głowach, które „znają system”. Nowa osoba w zespole QA potrzebuje na te same kroki często dwukrotnie więcej czasu, dopóki nie zbuduje mentalnej mapy - co jest fair, ale plan rzadko na to liczy.
Dochodzą:
- Wiedza plemienna - „to oczywiste, że ten serwis woła tamten” - dopóki nie jest oczywiste dla osoby, która robi review tego PR-a.
- Presja sprintu - skróty w opisie zgłoszenia, szybki merge, „testy na stagingu pójdą później”.
- Rozproszenie kontekstu - pięć otwartych kart, trzy wątki na czacie, jeden pilny hotfix obok.
Efekt jest taki sam co przy wąskim gardle w kodzie: kolejka rośnie, jakość decyzji spada, a liczba „przypadków, których nikt nie przewidział” rośnie.
Jak wygląda „dobrze” - bez sprzedaży narzędzia
Nie chodzi o dokument na dziesięć stron. Chodzi o krótki, powtarzalny brief zanim wejdziecie w ciężkie wykonanie - ten sam szkielet przy każdej zmianie, żeby nikt nie wymyślał formatu od zera:
- Intencja - jedno zdanie: po co ta zmiana dla użytkownika lub biznesu.
- Obszary dotknięte - moduły, usługi, kontrakty - na poziomie, na którym zespół się dogaduje.
- Strefy ryzyka - gdzie łatwo o regresję, gdzie są integracje, gdzie są założenia o danych lub kolejności.
- Otwarte pytania - co trzeba potwierdzić z autorem zanim sensownie zamknąć zakres.
Taki brief może powstać przy biurku, na stand-upie albo - jeśli macie proces - jako część definicji „gotowe do testów”. Ważne, żeby istniał przed długim odpaleniem suite’ów, a nie jako komentarz dopisany po fakcie, gdy coś padnie na produkcji.
Samosprawdzenie - policz to nawet na kartce
Weź liczby z ostatniego normalnego tygodnia (nie z tygodnia urlopów):
| Pytanie | Twój szacunek |
|---|---|
| Ile znaczących zmian (PR-ów / branchy / wdrożeń) przechodzi przez QA? | … |
| Ile minut średnio zajmuje jednej osobie sam kontekst (ticket + diff + doprecyzowanie) zanim pada decyzja o zakresie testów? | … |
Tygodniowy podatek (osoba × minuty × liczba zmian) daje rząd wielkości, który rzadko stoi obok „kosztów automatyzacji” w prezentacji dla kierownictwa. Jeśli wychodzi Wam np. 4-8 godzin tygodniowo samej analizy kontekstu przy kilkunastu PR-ach, to już argument za tym, żeby uprościć i ustandaryzować sposób przekazywania zakresu - zanim dorzucicie kolejne dwie godziny suite’u.
Na koniec - i powiązanie z CI
Ten koszt nie żyje w próżni. Gdy pipeline często krzyczy fałszywym alarmem, uwaga, która mogłaby iść w rozumienie zmiany, spędza czas na triage hałasu. O tym drugim biegunie napisałem osobno w wpisie Pipeline, który dokłada wątpliwości zamiast jasnego sygnału - warto czytać oba razem, jeśli chcecie zobaczyć pełny obraz „gdzie znika czas QA zanim padnie słowo pilot”.
Jeśli opis z tego tekstu brzmi jak Wasz poniedziałek, następny rozsądny krok to porozmawiać o zakresie wcześniej i o wspólnym szkielecie briefu - a nie od razu dokładać kolejne pakiety testów w nadziei, że pokrycie samo rozwiąże niejasność intencji.