Kto naprawdę odpowiada za jakość oprogramowania?

Za jakość oprogramowania odpowiada cały zespół i cała organizacja, a nie sam dział testów. Kontrola jakości oprogramowania, czyli przede wszystkim testowanie, mówi Wam, w jakim stanie jest produkt. Zapewnienie jakości ustawia proces tak, żeby błędy w ogóle nie powstawały. Sylabus ISTQB Foundation Level 4.0.1 z 2024 roku pisze wprost, że zapewnienie jakości jest odpowiedzialnością każdej osoby w projekcie.

Mimo to po każdym poważnym błędzie na produkcji pada to samo pytanie: „jak testerzy mogli tego nie znaleźć?”. W tym artykule pokazujemy, dlaczego to pytanie prowadzi donikąd, jak rozpisać odpowiedzialność za jakość w macierzy RACI dla dziewięciu ról, jak przeanalizować błąd produkcyjny bez szukania winnych na prawdziwym przypadku, który kosztował firmę 460 mln dolarów w 45 minut, i po czym poznacie, że nowy podział odpowiedzialności działa.

Kto odpowiada za jakość oprogramowania według ISTQB?

Krótka odpowiedź: każdy, kto podejmuje decyzje o produkcie. ISTQB w sylabusie Certified Tester Foundation Level 4.0.1 (2024, rozdział 1.2.2) rozdziela dwa pojęcia, które w firmach często zlewają się w jedno. Testowanie jest podejściem nastawionym na produkt i korygującym, to główna forma kontroli jakości. Zapewnienie jakości (QA) jest podejściem nastawionym na proces i zapobiegawczym, opiera się na założeniu, że dobry proces wykonany poprawnie daje dobry produkt, i według sylabusa jest odpowiedzialnością wszystkich w projekcie.

Ten sam sylabus w rozdziale 1.5.2 opisuje podejście całego zespołu (whole team approach), wywodzące się z Extreme Programming: każda osoba z potrzebną wiedzą może wykonać każde zadanie, a za jakość odpowiadają wszyscy. Testerzy pomagają przedstawicielom biznesu pisać testy akceptacyjne, a z programistami uzgadniają strategię testów i podejście do automatyzacji. ISTQB dodaje uczciwe zastrzeżenie: w systemach krytycznych dla bezpieczeństwa potrzebny bywa wysoki poziom niezależności testów, więc „wszyscy odpowiadają” nie znaczy „nikt nie sprawdza z zewnątrz”.

Jeśli zastanawiacie się, czym na co dzień różni się praca testera od pracy specjalisty QA, rozwijamy to w artykule tester oprogramowania a zapewnienie jakości oprogramowania (QA). Tutaj skupiamy się na tym, jak rozłożyć odpowiedzialność między wszystkie role.

Czym różni się kontrola jakości oprogramowania od zapewnienia jakości?

Kontrola jakości oprogramowania odpowiada na pytanie „czy ten produkt jest dość dobry?”, a zapewnienie jakości na pytanie „czy nasz sposób pracy daje dobre produkty?”. Pierwsza patrzy na wynik, druga na mechanizm. Obie są potrzebne, ale tylko pierwszą da się zrzucić na jeden dział, i właśnie dlatego firmy tak chętnie to robią.

Skala problemu jest policzona od dawna. Raport NIST z 2002 roku szacował roczny koszt niewystarczającej infrastruktury testowania w gospodarce USA na 59,5 mld dolarów, z czego około 22,2 mld dało się ograniczyć lepszym testowaniem i wcześniejszym wykrywaniem błędów. Dwadzieścia lat później raport CISQ z 2022 roku szacuje koszt słabej jakości oprogramowania w USA na co najmniej 2,41 bln dolarów, a sam dług techniczny na około 1,52 bln. Żaden dział testów nie udźwignie takich liczb w pojedynkę.

Dlaczego pytanie „kto zawinił?” psuje jakość?

Bo uczy ludzi ukrywać problemy, zamiast je zgłaszać. Książka Site Reliability Engineering Google z 2016 roku, w rozdziale o kulturze postmortemów, ujmuje to tak: jeśli w firmie dominuje wytykanie palcami i zawstydzanie osób za „złe” działanie, ludzie nie będą ujawniać problemów ze strachu przed karą. Postmortem bez szukania winnych (blameless) ma wskazać przyczyny incydentu, nie oskarżając nikogo, i zakłada, że każdy działał w dobrej wierze z informacjami, które wtedy miał.

DORA, program badawczy Google Cloud, od lat mierzy to samo zjawisko z drugiej strony. Według DORA kultura organizacji o wysokim zaufaniu, nastawiona na przepływ informacji, pozwala przewidzieć wyniki dostarczania oprogramowania i wyniki całej organizacji, a raport State of DevOps 2019 pokazał, że bezpieczeństwo psychologiczne w zespole przewiduje wydajność dostarczania i produktywność. DORA opiera się na typologii Rona Westruma z 2004 roku, w której jeden wiersz mówi więcej niż niejedna prezentacja o „kulturze jakości”.

Brak winnych nie oznacza braku odpowiedzialności. Oznacza, że odpowiedzialność przypisujecie przed wydaniem, w procesie, a nie po awarii, w rozmowie z działem kadr. Szukanie winnego po incydencie przypomina naprawianie dziury w dachu przez ustalanie, która kropla deszczu spadła pierwsza: bardzo satysfakcjonujące, zupełnie bezużyteczne.

Jak rozpisać odpowiedzialność za jakość w macierzy RACI?

Najprościej w macierzy RACI, w której przy każdej czynności stoi dokładnie jedna osoba rozliczana z efektu. R (Responsible) wykonuje pracę, A (Accountable) odpowiada za wynik i podejmuje decyzję, C (Consulted) wnosi wiedzę przed decyzją, I (Informed) dostaje informację po niej. Hasło „za jakość odpowiadają wszyscy” bez takiej tabeli szybko zamienia się w „za jakość nie odpowiada nikt konkretny”.

Poniżej macierz, od której zaczynamy warsztaty z zespołami. To punkt wyjścia do dyskusji, a nie norma: w Waszej firmie Product Owner może być rozliczany z innych rzeczy, a rolę Head of QA może pełnić lider zespołu testów.

Zwróćcie uwagę na dwa wiersze. Decyzja o wydaniu należy do Product Ownera, nie do testera: tester dostarcza informację o ryzyku, ale to biznes decyduje, czy je przyjmuje. Z kolei testy w potoku CI/CD mają właściciela po stronie DevOps, bo test, który nikt nie uruchamia przy każdej zmianie, z czasem przestaje cokolwiek chronić. Z naszego doświadczenia najwięcej sporów budzi pierwszy wiersz: zarządy chętnie mówią o jakości, rzadziej chcą podpisać akceptowalny poziom ryzyka.

Co konkretnie robi każda rola, żeby jakość nie była przypadkiem?

Macierz mówi, kto decyduje. Poniżej, co każda rola robi w tygodniu pracy. Trzy rzeczy na rolę, bo dłuższej listy i tak nikt nie powiesi nad biurkiem.

Wymagania to miejsce, w którym tester daje najwięcej za najmniej. Jeśli Wasz zespół ma kłopot z przełożeniem historyjek na przypadki testowe, polecamy szkolenie analiza testowa: od wymagań do przypadków testowych, a wczesne włączanie testów do pracy opisujemy w tekście o shift left testing. Liderom, którzy mają tę macierz utrzymywać, dedykujemy QA Leadership Academy, program rozwoju liderów jakości.

Jak wygląda analiza błędu produkcyjnego bez szukania winnych?

Najlepiej pokazać ją na prawdziwym, publicznie opisanym przypadku. 1 sierpnia 2012 roku system giełdowy firmy Knight Capital przez około 45 minut wysyłał zlecenia, których nikt nie chciał. Według decyzji amerykańskiej komisji SEC z 16 października 2013 roku skończyło się to 4 milionami transakcji na 154 spółkach i stratą ponad 460 mln dolarów. Łatwo zrzucić to na „technika, który się pomylił”. Raport SEC pokazuje coś zupełnie innego: łańcuch decyzji wielu ról na przestrzeni lat.

Według SEC przyczyny wyglądały tak. Stara funkcja „Power Peg” była nieużywana od 2003 roku, ale jej kod został w systemie. W 2005 roku przeniesiono w nim mechanizm liczenia zrealizowanych akcji i nie przetestowano ponownie starej funkcji. W 2012 roku nowa funkcja dostała flagę, która wcześniej uruchamiała Power Peg. Podczas wdrożenia technik nie skopiował nowego kodu na jeden z ośmiu serwerów, a firma nie miała pisemnej procedury, która wymagałaby sprawdzenia wdrożenia przez drugą osobę. Rano system wysłał 97 e-maili z błędem „Power Peg disabled”, ale nie były one zaprojektowane jako alarmy i nikt na nie nie zareagował.

Widzicie wzór? Żadna z sześciu przyczyn nie należała wyłącznie do testerów, a gdyby którąkolwiek przeciąć, awaria najpewniej by nie wystąpiła albo zostałaby szybko zatrzymana. Tak właśnie wygląda analiza bez szukania winnych: pytanie „kto?” zastępujecie pytaniami „co pozwoliło?” i „co zmienimy w procesie?”. Do takiej analizy wystarczy prosty szablon, który możecie skopiować do swojej wiki:

ANALIZA BŁĘDU PRODUKCYJNEGO (bez szukania winnych)
1. Co się stało: objaw, czas trwania, kogo dotknęło, ile kosztowało
2. Oś czasu: fakty z logów i rozmów, bez ocen i bez nazwisk
3. Przyczyny współtworzące: każda przypisana do etapu procesu
   (wymagania, projekt, kod, testy, wdrożenie, monitoring, decyzja)
4. Dlaczego nie złapaliśmy tego wcześniej: który poziom testów
   albo który alarm powinien był zadziałać
5. Działania: co zmieniamy w procesie, właściciel (A z macierzy RACI),
   termin, jak sprawdzimy, że zadziałało
6. Czego się nauczyliśmy: jedno zdanie do udostępnienia całej firmie

Dobre zgłoszenie błędu to połowa takiej analizy, bo oś czasu buduje się z faktów, nie z pamięci. Jak je pisać, pokazujemy w artykule jak poprawnie zgłosić błąd.

Jak sprawdzić, czy wspólna odpowiedzialność za jakość działa?

Po metrykach, które mierzą wynik całego zespołu, a nie jednej roli. Sama liczba defektów znalezionych przez testerów niewiele mówi: duża może oznaczać zły produkt albo świetne testy, mała stabilny produkt albo słabe pokrycie. DORA w przewodniku po metrykach dostarczania oprogramowania opisuje dziś pięć miar w dwóch grupach, przepustowości i niestabilności, i podkreśla, że szybkość i stabilność nie są wyborem jednego kosztem drugiego, bo u większości zespołów idą w parze.

U naszych klientów taki zestaw działa lepiej niż pojedynczy wskaźnik, bo każdy wiersz ma właściciela. Przykład z praktyki: w projekcie dla Argos z branży e-commerce automatyzacja testów i uporządkowanie procesów QA skróciły regresję przed wydaniem z 5 dni do 10 godzin, a liczba błędów krytycznych na produkcji spadła o 46%. Więcej o metrykach, które rozumie zarząd, piszemy w tekstach jak mierzyć jakość oprogramowania oraz KPI QA dla zarządu.

Od czego zacząć porządkowanie odpowiedzialności za jakość?

Od danych o Waszych własnych błędach, nie od nowego narzędzia. Pięć kroków, które w naszych projektach dają efekt w ciągu jednego kwartału:

1. Weźcie 20 ostatnich błędów z produkcji. Przy każdym zapiszcie etap, na którym powstał (wymagania, projekt, kod, wdrożenie), i etap, na którym powinien był wyjść. Zwykle jedna luka dominuje.
2. Wypełnijcie macierz RACI na jednym spotkaniu. Z Product Ownerem, liderem programistów, testów i DevOps. Każdy wiersz musi mieć dokładnie jedno A, inaczej wraca rozmycie.
3. Ustalcie kryteria wejścia i wyjścia. Na przykład: historyjka bez kryteriów akceptacji nie wchodzi do sprintu, wersja bez zielonej regresji nie wychodzi na produkcję.
4. Wprowadźcie analizę błędów bez szukania winnych. Szablon z tego artykułu wystarczy na start. Liczy się właściciel i termin każdego działania.
5. Mierzcie co miesiąc trzy liczby. Change fail rate, defekty, które uciekły na produkcję, i czas regresji. Po kwartale porównajcie z punktem wyjścia.

Jeśli wolicie zrobić to z moderatorem z zewnątrz, prowadzimy warsztaty QA dla zespołów i kadry zarządzającej, na których macierz odpowiedzialności powstaje razem z zespołem. Gdy problem jest szerszy niż podział ról, punktem startu jest audyt QA, a dla całej organizacji strategia jakości oprogramowania. Tak pracowaliśmy z PKO BP: audyt istniejących procesów QA, strategia jakości dla całej organizacji oraz szkolenia i warsztaty dla zespołów QA. Jak przełożyć strategię na codzienny plan, opisujemy w artykule strategia testowania w organizacji.

Zespołom, które chcą zbudować kompetencje samodzielnie, polecamy szkolenia zarządzanie jakością w całej organizacji i strategia testowania od A do Z; przeszkoliliśmy już ponad 2500 specjalistów. O tym, dlaczego system jest ważniejszy niż heroizm pojedynczych osób, ciekawie pisze też Strefa QA w tekście o jakości jako kulturze, a nie dziale, a o kulturze jakości w największych zespołach rozmawiamy co roku na Testing Ground Conference.

Powiązane na blogu Quality Island

• Tester oprogramowania a specjalista QA: czym się różnią
• Jak mierzyć jakość oprogramowania
• Strategia testowania w organizacji
• KPI QA dla zarządu: jak mówić językiem CFO
• Jak skrócić testy regresyjne z 5 dni do 10 godzin

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024, rozdziały 1.2.2 (testowanie a zapewnienie jakości) i 1.5.2 (podejście całego zespołu).
• Google, Site Reliability Engineering, rozdział Postmortem Culture: Learning from Failure, 2016. Stąd zasady postmortemu bez szukania winnych i jego rodowód z opieki zdrowotnej i lotnictwa.
• DORA, Generative organizational culture, z typologią Rona Westruma (BMJ Quality & Safety, 2004) i wnioskami ze State of DevOps 2019.
• DORA, DORA’s software delivery performance metrics. Stąd pięć metryk przepustowości i niestabilności.
• NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002. Stąd 59,5 mld i 22,2 mld dolarów.
• CISQ, The Cost of Poor Software Quality in the US: A 2022 Report, 2022. Stąd 2,41 bln i 1,52 bln dolarów.
• U.S. Securities and Exchange Commission, Release No. 70694, In the Matter of Knight Capital Americas LLC, 16.10.2013, dokument 34-70694 w serwisie sec.gov. Stąd przebieg i przyczyny awarii z 1 sierpnia 2012 roku.
• Quality Island, case study Argos i zakres współpracy z PKO BP, dane własne, 2026.