Surowa prawda o oprogramowaniu bez usterek

Wiele lat temu, w dniu, w którym zdecydowaliśmy się wydać dużą aktualizację naszego produktu — decyzję, która oczywiście wymagała mojej akceptacji jako dyrektora ds. zapewnienia jakości — szedłem korytarzem, gdy minął mnie dyrektor generalny. 

Zatrzymał mnie i powiedział: „Czyli mogę założyć, że wydajemy produkt bez defektów?”

Nie zastanawiając się tyle, ile prawdopodobnie powinienem, beztrosko odpowiedziałem: „Oczywiście, że nie. Nie ma czegoś takiego jak oprogramowanie bez defektów.” 

Był wstrząśnięty i oburzony moją odpowiedzią. Był na mnie tak zdenerwowany, że zakończył naszą rozmowę i wściekły odszedł korytarzem.

W tamtym czasie złożyłem to na karb faktu, że był nowy w branży oprogramowania i w cyklu życia produktu, ponieważ wcześniej pracował w branży wydawniczej (długa historia — innym razem). Ponieważ wszyscy w zespole deweloperskim wiedzieliśmy, że wydajemy produkt z defektami. Wiedzieliśmy jednak od początku, jakie to były defekty, a to całkowicie zmieniało naszą ocenę ryzyka.

Z niepokojem zauważam jednak, że ostatnio to błędne przekonanie mojego byłego dyrektora generalnego stało się powszechne w naszej branży. Wolne od błędów, „oprogramowanie bez defektów” to nowe przechwałki i hasło, które widzę i słyszę coraz częściej. I to nie tylko ze strony nieświadomych dyrektorów generalnych (wiem, to masło maślane), lecz także ze strony osób z branży, które powinny wiedzieć lepiej. A w rzeczywistości wiedzą. Co bardzo mnie niepokoi.

Istnieje sens, w którym myślenie w kategoriach „zera defektów” nie jest jedynie kłamliwym, obliczonym na własną korzyść nonsensem. Na Zachodzie jest to przeważnie tylko czcza gadanina i pozowanie na pokaz. W Japonii ma to jednak rzeczywiste znaczenie. I dotyczy to wszystkich tamtejszych branż. 

Przez rok pracowałem w Japonii i całkowicie mnie to zaskoczyło, ale w bardzo pozytywny sposób. Ponieważ ich definicja „defektu” bardzo różni się od naszej. Na przykład jeśli na podłodze fabryki zostanie papierek po gumie do żucia, jest to uznawane za defekt — tak samo jak problem z maszyną lub z produktem procesu. Gdybyśmy naprawdę poważnie traktowali „zero defektów”, myślelibyśmy o tej kwestii tak jak Japończycy. Ale tego nie robimy, więc tego nie osiągniemy.

To, co próbowałem powiedzieć temu nieszczęsnemu dyrektorowi generalnemu, być może zbyt dosadnie, to fakt, że każdy współczesny komercyjny program komputerowy jest nieskończenie złożony, a sposoby, w jakie może oddziaływać sam ze sobą lub ze swoim otoczeniem, są zatem również nieskończone. Znalezienie każdego defektu jest możliwe tylko wtedy, gdy mamy nieskończenie dużo czasu na testowanie. Ale nikt z nas nie jest nieśmiertelny.

Nawet gdyby udało się znaleźć każdy, absolutnie ostatni defekt za pierwszym razem, nie mielibyśmy czasu, aby naprawić je wszystkie i wydać produkt w tym stuleciu — czas wprowadzenia produktu na rynek naprawdę ma znaczenie. Zatem nawet jeśli je znajdziemy, będziemy musieli wydać produkt wraz z nimi. 

Cała koncepcja „oprogramowania bez defektów” jest więc z natury urojeniowa.

Skąd wzięła się koncepcja oprogramowania bez defektów?

Źródłem tego urojenia jest przekonanie, że rolą QA jest „zapewnienie” jakości. Niczego takiego nie robi. To zadanie zarządzania produktem i inżynierii. Rolą zapewnienia jakości jest *ocena* tego, jak dobrze udało im się wywiązać z tego zadania.

Istnieje jednak jeszcze jedna zgubna warstwa tego problemu. 

Niedawno omawiałem tę właśnie kwestię z deweloperem oprogramowania. Zwrócił mi uwagę, że sposób, w jaki wyjaśniono mu znaczenie „oprogramowania bez defektów”, był zgodny z tym, co właśnie powiedziałem. Oznacza to wydanie produktu ze wszystkimi błędami, które zespół uznał za konieczne naprawić przed wydaniem. A następnie wydanie go ze wszystkimi defektami, których zespół postanowił nie naprawiać. Nawiasem mówiąc, mój rozmówca nie zgadzał się z tą definicją.

To wyraźnie tylko semantyczna zasłona dymna i gra pozorów. W rzeczywistości wydajecie produkt z defektami i wiecie o tym, ale używacie hasła „zero defektów”, aby ukryć ten fakt przed samymi sobą — oraz oczywiście przed kierownictwem. Wszyscy wiemy, że łatwo zahipnotyzować je pustymi hasłami, które sprawiają, że czuje się skuteczne.

To selektywne ograniczanie liczby defektów, nic więcej.

Jak odejść od oszustwa związanego z zerem defektów?

Podstawą tego oszustwa jest sam język — język, który kształtuje i narzuca nasz sposób myślenia, zanim w ogóle zaczniemy konceptualnie odpowiadać na to, co przekazuje. To właśnie ten fałszywy język tworzy od początku sytuację, w której musimy wyjaśniać, dlaczego jest błędny. W ten sposób zaczynamy być osaczani przez słownictwo hasła.

To bardzo powszechna praktyka w tworzeniu oprogramowania. Niestety nie ogranicza się ona do okłamywania samych siebie w kwestii „zera defektów”. Przenika każdy poziom naszego myślenia i działania — jako testerów, w procesie tworzenia, w stosowanych metodykach oraz w naszych metrykach.

Spójrzmy, zacznijmy stawiać czoła rzeczywistości dotyczącej tego, co robimy i czego nie robimy. A pierwszym krokiem w tym procesie naprawczym jest używanie języka, który uczciwie opisuje to, co robimy i czego nie robimy. Ponieważ jeśli sam język, którego używamy do komunikowania tych realiów, jest z gruntu oszukańczy, nieuczciwy i urojeniowy, nie tworzymy wysokiej jakości oprogramowania. Produkujemy propagandę. 

Inny problem z dyskursem dotyczącym „oprogramowania bez defektów” polega na tym, że nawet jeśli jest to szczerze przyjmowany cel — w tym sensie, że ludzie szczerze wierzą, iż jest on możliwy, a nie jest jedynie ćwiczeniem z cynizmu — to użyteczność tego pomysłu ogranicza inny, poważniejszy problem. Problem ten można ująć następująco: 

Jak można w ogóle wiedzieć i udowodnić, że znaleziono „wszystkie” defekty, które można znaleźć w testowanym oprogramowaniu? A nie tylko liczbę defektów, które udało się znaleźć w wyznaczonym czasie? Jak można udowodnić samym sobie, że zbiór znalezionych błędów jest kompletnym zbiorem błędów rzeczywiście zawartych w oprogramowaniu? 

Nie można. Wymagałoby to bowiem jakiegoś procesu zewnętrznego wobec samego zapewniania jakości, który pozwoliłby to ustalić. W przeciwnym razie byłby to po prostu argument kołowy. A czym miałby być ten zewnętrzny proces? 

I jest to prawdą niezależnie od tego, ile błędów już znaleziono. Można było znaleźć ich milion. Nie dowodzi to jednak, że gdzieś w cieniach oprogramowania nie czai się błąd milion pierwszy.

Czy koncepcja braku defektów ma jakąś wartość?

Rażące problemy logiczne i epistemologiczne związane z mówieniem i myśleniem w kategoriach „oprogramowania bez defektów” są po prostu nie do przezwyciężenia. Sam tego określenia nie da się uratować, niezależnie od tego, jak je przeformułujemy. 

Jeśli jednak wyjdziemy poza zwodniczy slogan i przyjrzymy się temu, co sprawia, że jest on atrakcyjny i konceptualnie trafny dla skądinąd myślących ludzi, znajdziemy coś wartościowego, na czym można się skupić.

To „coś” jest innym pytaniem, ale takim, które odpowiada na praktyczne i emocjonalne potrzeby pozornie zaspokajane przez fałszywy dyskurs o oprogramowaniu bez defektów — i robi to w sposób bardziej spójny oraz możliwy do obrony.

Kwestia, z którą ludzie zajmujący się oprogramowaniem naprawdę próbują się tutaj zmierzyć, uciekając się do samooszukiwania, jest zwodniczo prosta. Mianowicie: „Kiedy wiemy, że możemy zakończyć testowanie?” 

To jedyne pytanie, które zadaję kandydatom na stanowiska kierownicze w obszarze zapewniania jakości w mojej organizacji. Ponieważ tak naprawdę jest to jedyne pytanie, na które musi odpowiedzieć zapewnianie jakości. A jeśli nie potrafi, zapewnianie jakości jest całkowitą stratą czasu. Aby odpowiedzieć na to pytanie, musimy najpierw odpowiedzieć na wcześniejsze pytanie. 

Brak defektów a % pokrycia testami

Skąd wiemy, czy znalezione już defekty — niezależnie od tego, ile ich jest — można wiarygodnie uznać za odzwierciedlenie zakresu ryzyka wynikającego ze sposobu określenia wymagań i zaprojektowania testowanego oprogramowania? W takim stopniu, aby z przekonaniem stwierdzić, że pozostałe niewykryte defekty stanowią akceptowalne ryzyko dla decyzji o udostępnieniu oprogramowania publicznie?

Ujęte w ten sposób pytanie pokazuje, że nie jest to pytanie dotyczące defektów. Jest to pytanie dotyczące pokrycia testami. Analiza znalezionych błędów, niezależnie od ich ogromnej liczby, nie znaczy nic, jeśli nie można jej skorelować z analitycznym rozumieniem osiągniętego dotychczas pokrycia testami i zestawić z pokryciem, które dopiero ma zostać osiągnięte w ramach działań związanych z zapewnianiem jakości. 

Ponieważ jeśli ten zbiór znanych defektów, niezależnie od czasu poświęconego na testowanie, reprezentuje zaledwie 30% rzeczywistego pokrycia testami — a nie wie się o tym — to nie ma żadnych racjonalnych podstaw, aby wiedzieć, co oznaczają one w kontekście decyzji o wdrożeniu oprogramowania.

Prawdziwa dyskusja na temat naprawdę skutecznych działań związanych z zapewnianiem jakości, a także ich prawdziwy cel, nie mogą dotyczyć „braku defektów”, lecz raczej „100% pokrycia testami”. Z powodów, które podałem powyżej. 

Ogromną zaletą tego sposobu myślenia o jakości oprogramowania jest to, że opiera się on na definicji odpowiedniego pokrycia testami, opracowanej przez zespół zapewniania jakości jeszcze przed rozpoczęciem testów. Dzięki temu samą tę definicję można zweryfikować względem specyfikacji, wymagań, wcześniejszych problemów zgłaszanych przez klientów i ich potrzeb itd., a następnie w razie potrzeby zmodyfikować.

Dalsze działania: testowanie bez luk

Myślenie o tym problemie w kategoriach defektów zawodzi właśnie dlatego, że nie jest to coś, co można sensownie zdefiniować z wyprzedzeniem, ponieważ liczbę i wagę problemów można odkryć dopiero po przeprowadzeniu testów. 

Co więcej, nie ocenia się tego względem istniejącej wcześniej, sensownej definicji tego, co próg „zera” mógłby właściwie oznaczać. Definiowanie sukcesu za pomocą zmiennej, która sama jest niezdefiniowana i niemożliwa do zdefiniowania, jest stratą czasu.

Dlatego jedynym sposobem na ocalenie idei oprogramowania bez defektów jest ukierunkowanie tego sposobu myślenia i planowania na testowanie bez luk. Motywacja stojąca za mantrą braku defektów sama w sobie nie jest błędna. Została jedynie skierowana z dala od swojego prawdziwego celu. Dokonaj tej korekty, a sensowne i mierzalne definicje akceptowalnej jakości oprogramowania staną się możliwe.

Jeśli jesteś gotów dowiedzieć się więcej, a jednocześnie uczyć się od ekspertów i prezesów, oto podcast, który powinien Ci się spodobać: WSPÓŁPRACA, SZTUCZNA INTELIGENCJA I KONTENERYZACJA (Z MICHAELEM RITCHSONEM Z NASA)

Powiązany artykuł: 10 NAJLEPSZYCH NARZĘDZI DO ŚLEDZENIA DEFEKTÓW W TESTOWANIU OPROGRAMOWANIA