Za dużo uwagi poświęcamy usuwaniu błędów zlokalizowanych w procesach testowania oprogramowania, a za mało szukaniu pierwotnych przyczyn ich występowania.

Męczące są dyskusje informatyków o tym, dlaczego oprogramowanie jest ciągle takie zawodne. Różne już słyszałem wytłumaczenia tak łatwego do codziennej obserwacji zjawiska, dlaczego w większości aplikacji znaleźć można pełno błędów: mówi się o rosnącej złożoności, nad którą nie da się zapanować, o coraz większym wyrafinowaniu i bogactwie funkcji zawartych w oprogramowaniu, które trzeba implementować, o trudnościach w kompleksowym testowaniu aplikacji, gdzie liczba potencjalnych scenariuszy testowych rośnie wykładniczo. Jednak nad tym wszystkim dominuje jedno uniwersalne wytłumaczenie - tworzymy wadliwe oprogramowanie, bo taka jest jego natura; to zjawisko przyrodnicze, jak przypływy czy fazy księżyca.

Co za bzdura! Wcale nie musimy mieć ciągle do czynienia z oprogramowaniem pełnym błędów. Przestańmy wreszcie skupiać się na złej jakości produktów IT, a zamiast tego poświęćmy uwagę naprawie nieodpowiednich procesów produkcyjnych oprogramowania. Właśnie tak - produkcyjnych. Oprogramowanie wcale nie różni się od innych produktów wytwarzanych przemysłowo. Samochody, tostery, ekspresy do kawy i komputery - wszystkie te produkty schodzą z taśm produkcyjnych. Jeśli dany produkt po zejściu z linii produkcyjnej ma w sobie defekt, to nie ma co zajmować się jego naprawą - zamiast tego trzeba sprawdzić linię produkcyjną, lokalizując źródło powstawania błędu. Niby dlaczego miałoby być inaczej w przypadku oprogramowania? Błędom w oprogramowaniu trzeba zapobiegać, a nie tylko je wykrywać i potem usuwać.

Bogata i pouczająca jest historia tego, w jaki sposób przemysł samochodowy postępował z defektami na linii produkcyjnej. Pierwsi Japończycy doszli do tego, że najważniejsze jest stworzenie takiej linii, w której nie powstają żadne błędy. Wkrótce potem dołączyli do nich Niemcy i Szwedzi. Dopiero później sami Amerykanie zaczęli produkować lepsze samochody. Jakiegoż to odkrycia dokonał przemysł samochodowy? Chodziło o proces zapobiegania powstawaniu błędów.

Co to znaczy zapobiegać

Przyjrzyjmy się temu bliżej. Można wskazać pięć kluczowych elementów służących do zapobiegania występowaniu błędów w produkcji:

1) identyfikacja błędu;

2) wskazanie przyczyny powstawania błędu;

3) lokalizacja miejsca w procesie produkcyjnym, który jest źródłem powstawania błędów;

4) wprowadzenie procedur mających sprawić, że błędy nie będą się już więcej pojawiać;

5) stały monitoring jakości.

Weźmy dla przykładu linię produkcyjną samochodów. Załóżmy, że stwierdzono, iż pasy w samochodach nie są montowane we właściwy sposób - a to poważna usterka. Dzieje się tak, bo same pasy nie do końca dobrze pasują do napinaczy. Trzeba więc dostarczyć odpowiednie moduły napinające na właściwe miejsce na linii produkcyjnej, a więc tam, gdzie są montowane siedzenia. Monitorowanie procesu montażu odbywa się przez inspekcję naciągnięcia pasów. Natomiast monitoring miejsca, gdzie montowane są pasy, również dostarczyć może wielu ciekawych danych na temat tego, jak wiele czasu można zaoszczędzić dzięki zastosowaniu właściwego narzędzia.

Zapobieganie błędom to coś innego niż ich wykrywanie. To ostatnie to proces wyszukiwania i usuwania błędów po zbudowaniu aplikacji - natomiast sam niewłaściwy proces produkcyjny, będący źródłem tych błędów, pozostaje taki sam. W podanym wyżej przykładzie, usuwanie błędów polegałoby zatem wyłącznie na ich właściwym naciągnięciu, w chwili gdy samochód opuszcza linię produkcyjną. To oczywiście sprawi, że auta trafią na rynek bez tej wady, ale nadal w żaden sposób nie poprawi procesu produkcyjnego, będącego źródłem problemu. Problem nigdy nie zniknie, bo nie usunięto jego rzeczywistych przyczyn.

Tymczasem tak właśnie działa cały przemysł wytwórczy oprogramowania. Wykrywamy błędy, a więc walczymy z objawami zamiast skupić się na przyczynach, czyli niedostatkach procesów wytwórczych. No dobrze - wypadałoby więc zapytać, dlaczego tak się dzieje, dlaczego wciąż w IT wolimy wykrywać niż zapobiegać? Dlaczego nie bierzemy przykładów z rozwiniętych wytwórczych branż, które sobie już z tym poradziły?

Zawsze kiedy stawiam takie pytania, to spotykam się z kontrargumentem, że to nieprawda, bo przecież wdrażane powszechnie w branży IT normy mające doprowadzić do poprawy jakości - takie jak ISO 9001, SEI-CMM czy Six Sigma - mają właśnie na celu doprowadzenie do zapobiegania błędom. To oczywiście prawda, ale nie do końca... Te rozwiązania zapewnienia jakości nie odnoszą się bezpośrednio do zapobiegania błędom, ale raczej są próbą regulacji procesu, którego zamierzeniem jest zapobieganie błędom. Bez wprowadzenia automatyzacji w procesach wytwórczych oprogramowania skutek takich działań zawsze będzie mocno ograniczony.

<hr size=1 noshade>

Na poszczególnych etapach tego rozwoju należy stosować odmienne narzędzia. Cały cykl może zostać objęty rozwiązaniami pozwalającymi na automatyczne zapobieganie powstawaniu błędów w oprogramowaniu. Przerywana strzałka to przykład przekazania informacji zwrotnej o przyczynie powstawania błędów (z testów obciążeniowych) do wymagających korekty standardów kodowania.

<hr size=1 noshade>