Seria: QA Leadership · Artykuł 9 z 9 · Finał

Ten artykuł mogłem napisać tylko dlatego, że sam popełniłem każdy z opisanych tu błędów. Mój pierwszy dashboard dla zarządu miał dwadzieścia trzy wykresy i byłem z niego naprawdę dumny. Prezes poświęcił mu jakieś dziewięć sekund.

Przez osiem artykułów budowaliśmy warsztat: pięć metryk, wskaźnik decyzyjny, narrację. Zostało ostatnie pytanie, czyli co potrafi to wszystko zepsuć. Odpowiedź jest krótka. Trzy nawyki, które wyglądają niewinnie, a każdy z nich po cichu podkopuje zaufanie do zespołu jakości. Znam je dobrze, bo latami hodowałem wszystkie trzy naraz.

Dobra wiadomość jest taka, że żaden z nich nie wynika ze złej woli ani z braku kompetencji. Wszystkie biorą się z nadmiaru dobrych chęci. I właśnie dlatego tak łatwo w nie wpaść.

Antywzorzec 1: raport, który pokazuje wszystko

czyli dashboard z dwudziestoma trzema wykresami

Logika wydaje się żelazna. Skoro zbieramy tyle danych, pokażmy je. Więcej wykresów znaczy więcej pracy, więcej pracy znaczy więcej wiarygodności. Tak myślałem, przygotowując tamten dashboard (tablicę wskaźników), i tak myśli większość zespołów QA na pewnym etapie dojrzewania.

Uwaga słuchacza działa jednak jak budżet, nie jak studnia. Każdy kolejny wykres wydaje część tego budżetu i pomniejsza to, co zostaje dla pozostałych. Przy sześciu wskaźnikach sala jeszcze nadąża. Przy dwunastu zaczyna wybierać losowo, na co patrzeć. Przy dwudziestu trzech poddaje się po cichu i czeka na kolejny punkt agendy. Nikt tego nie powie głośno, bo wypada docenić włożoną pracę.

Tak to wyglądało
▁▃▅
▂▆▂
%
▅▃▇
▁▁▆
#
▃▂▄
▇▅▃
%
▆▄▂
▄▇▅
#
▂▅▇
▅▂▁
%
▇▂▄
▃▆▄
23 wykresy. Czas uwagi prezesa: około 9 sekund. Pytań: zero.
Tak to wygląda dziś
91%
Confidence Score · GO
94%
DDR
0,4
Escaped / wyd.
12
Wydania
Jeden wskaźnik decyzyjny, trzy liczby wspierające. Reszta w załączniku, na wypadek pytań. Pytania padają na każdym spotkaniu.
Po czym poznasz, że to Twój problem
  • Po prezentacji nikt nie zadaje żadnego pytania. Cisza bywa uprzejmą formą zagubienia.
  • Ktoś regularnie pyta „dobra, ale co z tego wynika", mimo że wszystko przecież pokazałeś.
  • Dashboard jest sumiennie aktualizowany co sprint, a statystyki odwiedzin pokazują trzy wejścia. Wszystkie Twoje.

Wyjście z tego nawyku boli, bo wymaga wyrzucenia rzeczy, nad którymi się napracowałeś. Zasada, która u mnie zadziałała: jeden slajd, jeden wskaźnik decyzyjny, maksymalnie cztery liczby wspierające. Cała reszta ląduje w załączniku i czeka na pytania. Paradoks polega na tym, że odkąd pokazuję mniej, ludzie pytają o więcej.

Antywzorzec 2: liczba, która chodzi sama

czyli 94% bez odpowiedzi na pytanie „to dobrze?"

Scena z życia. Sprint review, na slajdzie „DDR: 87%”, w sali dwanaście osób. Ktoś z biznesu podnosi rękę i pyta, czy to dobry wynik. No właśnie. Osiemdziesiąt siedem procent czego względem czego? Bez punktu odniesienia ta liczba jest szumem, który brzmi jak informacja.

Słuchacz pozbawiony kontekstu zrobi jedną z dwóch rzeczy. Albo dopowie sobie własną interpretację, zwykle błędną, albo przestanie słuchać. Obie opcje pracują przeciwko Tobie. Najgorsze jest to, że nadawca zwykle nie widzi problemu, bo sam kontekst ma w głowie. Wie, że kwartał temu było 74%. Tylko zapomniał, że wie to wyłącznie on.

Zamiast tłumaczyć dalej, po prostu sprawdź to na sobie. Trzy prawdziwe liczby, trzy szybkie decyzje.

Dobra czy zła? Oceń bez kontekstu
Kliknij odpowiedź przy każdej liczbie. Zasada jest jedna: odpowiadasz od razu, tak jak słuchacz na spotkaniu.
Pass rate regresji: 94%
Pytanie było podchwytliwe. Uczciwa odpowiedź brzmi: nie wiem.
Kontekst: trzy poprzednie wydania miały 99%, 98% i 97%. To czwarty spadek z rzędu. Sama wartość wygląda solidnie, kierunek mówi co innego.
Z kontekstem: sygnał ostrzegawczy
12 błędów produkcyjnych w kwartale
Znowu podchwytliwe. Dwanaście, ale na ile wydań?
Kontekst: zespół wypuścił w tym czasie 40 wydań. Wychodzi 0,3 błędu na wydanie, wynik z okolic najwyższej półki. Ta sama dwunastka przy 4 wydaniach byłaby alarmem.
Z kontekstem: bardzo dobry wynik
DDR: 76%
Ostatni raz: bez kontekstu każda odpowiedź to zgadywanie.
Kontekst: rok temu ten zespół miał 58%, pół roku temu 67%. Kilkanaście punktów systematycznego wzrostu. Wartość poniżej podręcznikowego ideału, kierunek wzorowy.
Z kontekstem: droga we właściwą stronę

Lekarstwo jest tanie. Każda liczba wychodzi na spotkanie z jednym z trzech towarzyszy: trendem (jak było wcześniej), punktem odniesienia (benchmark, cel, inna miara) albo mianownikiem (na wydanie, na sprint, zgodnie z artykułem szóstym). Jedno dodatkowe zdanie na slajdzie. Tyle kosztuje różnica między informacją a szumem.

Antywzorzec 3: klątwa wiedzy

czyli flaky testy, race condition i twarz Product Ownera

Kiedyś na statusie z biznesem powiedziałem zdanie, które do dziś pamiętam: „Regresja się sypie, bo mamy flaky testy przez race condition na CI, a coverage dropnął po refactorze”. Product Owner pokiwał głową. Po spotkaniu podszedł i zapytał, czy to znaczy, że będzie opóźnienie. Nic więcej z mojej wypowiedzi nie dotarło.

Psychologia nazywa to klątwą wiedzy. Gdy coś wiemy, tracimy zdolność wyobrażenia sobie, jak to jest nie wiedzieć. Skróty naszego świata wydają się oczywiste, więc mówimy nimi także do ludzi spoza tego świata. Słuchacz z grzeczności kiwa głową, a w środku podejmuje decyzję, żeby następnym razem zapytać kogoś innego. Tak po cichu umiera pozycja doradcy.

Poniżej pięć zdań, które naprawdę padły na spotkaniach. Kliknij każde z nich, żeby zobaczyć wersję, która dociera.

kliknij
„Mamy flaky testy w regresji."
„Część testów raz przechodzi, raz nie, chociaż kod się nie zmienił. Dopóki tego nie uporządkujemy, wynikom nie można w pełni ufać. Pracujemy nad tym, termin: koniec sprintu."
kliknij
„Coverage dropnął do 78% po refactorze."
„Automaty sprawdzają dziś 78 na 100 ścieżek w aplikacji. Po ostatniej przebudowie kodu 22 ścieżki zostały chwilowo bez ochrony. Uzupełniamy je w pierwszej kolejności tam, gdzie chodzi o płatności."
kliknij
„Bloker przez race condition na CI."
„Dwa procesy w systemie budowania ścigają się o ten sam zasób i wynik zależy od przypadku. Do czasu naprawy nie możemy wiarygodnie testować, dlatego wstrzymaliśmy wydanie."
kliknij
„Env stagingowy leżał pół sprintu."
„Środowisko, na którym sprawdzamy zmiany przed produkcją, nie działało przez tydzień. Przez ten czas testy stały. Stąd opóźnienie i stąd prośba o priorytet dla stabilności tego środowiska."
kliknij
„Puściliśmy smoke'i po deployu, wszystko zielone."
„Zaraz po wdrożeniu sprawdziliśmy najważniejsze funkcje. Logowanie, płatności i główny proces zakupowy działają prawidłowo."

Zwróć uwagę, co łączy wersje ukryte pod każdym zdaniem. Żadna nie tłumaczy mechanizmu. Wszystkie tłumaczą skutek i mówią, co dalej. Biznesu nie interesuje, jak działa race condition (wyścig procesów). Interesuje go, czy wydanie wyjdzie w piątek i czy klient coś odczuje. Odpowiadaj na to pytanie, a technikalia zostaw na rozmowy z inżynierami, gdzie są na swoim miejscu.

Prosty test przed każdym spotkaniem: czy zrozumiałaby to moja babcia albo prezes, zależnie od tego, kto budzi większy respekt. Jeśli nie, zdanie wraca do przepisania.

Autodiagnoza: sprawdź się, zanim zrobi to za Ciebie sala

Sześć pytań, po dwa na każdy antywzorzec. Zaznacz te, które brzmią znajomo. Bez oszukiwania, nikt nie patrzy.

Ile antywzorców hodujesz?
Kliknij każde zdanie, które pasuje do Twoich raportów
Mój główny raport albo dashboard ma więcej niż osiem wskaźników.Antywzorzec 1
Zdarza się, że po mojej prezentacji nikt nie zadaje ani jednego pytania.Antywzorzec 1
Pokazuję liczby bez porównania z poprzednim okresem albo bez benchmarku.Antywzorzec 2
Słyszałem od kogoś z biznesu pytanie „a to dobrze czy źle?".Antywzorzec 2
Używam słów takich jak flaky, coverage czy regresja przy ludziach spoza IT bez tłumaczenia.Antywzorzec 3
Widziałem, jak ktoś kiwa głową, choć oczy mówiły co innego.Antywzorzec 3
0 / 6
Zaznacz zdania powyżej, a powiem Ci, jak jest.

Cztery tygodnie do pierwszego raportu, który działa

Cała seria za nami, więc na koniec plan minimum. Sprawdzony w praktyce, bez rewolucji, do zrobienia obok normalnej pracy.

T1
Policz DDR i błędy produkcyjne wstecz
Dane za ostatni kwartał siedzą w Jirze i w monitoringu. Dwa filtry, godzina pracy, pierwszy trend gotowy. Szczegóły w artykułach drugim i trzecim.
T2
Dołóż issues per release i liczbę wydań
Ustal definicje, uruchom tagowanie, policz historię za kilka ostatnich wydań. Od teraz każda liczba w raporcie ma mianownik. Artykuły czwarty i szósty.
T3
Zbuduj Confidence Score
Model ważony z dyskwalifikatorem, walidacja na trzech starych wydaniach. Sprawdź, czy liczba zgadza się z tym, co pamiętasz. Artykuł siódmy prowadzi za rękę.
T4
Wyjdź z pierwszym raportem w nowym stylu
Jeden slajd. Wniosek, dowód, rekomendacja, zgodnie z artykułem ósmym. Zero żargonu, każda liczba z kontekstem. A potem obserwuj, co się zmieni w pytaniach z sali.

Dziewięć artykułów później

Zaczęliśmy od diagnozy: QA raportuje aktywność, biznes chce słyszeć o wynikach. Pomiędzy tymi dwoma punktami zmieściło się pięć metryk, jeden wskaźnik decyzyjny, warsztat narracyjny i dzisiejsze trzy przestrogi. To komplet. Nie dlatego, że nie dałoby się dodać kolejnych wskaźników, tylko dlatego, że ten zestaw wystarcza, a wszystko ponad niego zaczyna pracować przeciwko Tobie. Wiesz już dlaczego, pisałem o tym kilka ekranów wyżej.

Jeśli z całej serii miałaby zostać jedna myśl, niech będzie ta: metryki nie służą do udowadniania, że QA pracuje. Służą do tego, żeby firma podejmowała lepsze decyzje. Różnica wydaje się subtelna, a zmienia wszystko, od doboru wskaźników po układ slajdu.

Ostatnie słowo serii
Pojedyncza metryka to fakt. Zestaw metryk to opowieść. A dobrze opowiedziana historia jakości potrafi zmienić pozycję całego zespołu.
Dziękuję, że doszliście ze mną do końca. Jeśli któryś z artykułów przydał się w praktyce, dajcie znać. Piszcie też, gdy coś nie zadziałało, takie wiadomości uczą mnie najwięcej. Do zobaczenia na konferencjach.
Seria: Metryki QA, które biznes chce słyszeć
  • 01
    Diagnoza, trzy filary, pięć metryk, model mapowania QA → KPI
  • 02
    Formuła, progi, dane historyczne, sezonowość, pułapki
  • 03
    Taksonomia, zbieranie danych, koszt każdego typu, jak raportować
  • 04
    Issues per Release przeczytany
    Wdrożenie od zera, związek z procesem wytwórczym, rozmowa z EM
  • 05
    Wskazywanie problemów, nie tylko obserwowanie trendów
  • 06
    Number of Releases przeczytany
    Dlaczego 3 bugi przy 2 releasach to dramat, a przy 15 to sukces
  • 07
    Trzy modele obliczania, wdrożenie, przykłady z praktyki
  • 08
    Odwrócona piramida, techniki przekładu, generator narracji, szablony
  • 09
    3 antywzorce, które niszczą wiarygodność QA finał · czytasz teraz
    Za dużo metryk, brak kontekstu, żargon - autodiagnoza i plan na cztery tygodnie