Błędy w kodzie - i co z tego?

Oprogramowanie bez błędów? Akurat... Czy spotkaliście się kiedyś w swojej pracy z pojęciem zero bug policy? A może Wasz klient oczekiwał zapewnienia, że w dostarczanej wersji wszystkie błędy zostały poprawione?

Takie sformułowania czasami się pojawiają, choć każdy rozsądny człowiek wiedzieć powinien, że samo testowanie też musi się kiedyś skończyć. Nasza praca, w ograniczonym budżecie i czasie, polega na znalezieniu odpowiedniego momentu, kiedy to czujemy lub raczej kiedy wiemy, na bazie metryk, naszej wiedzy oraz ryzyk, kiedy testowanie powinno się zakończyć.

Błędy a jakość

W jaki sposób ilość błędów w aplikacji przekłada się na jej jakość? Czy mieliście okazje być w projekcie, w którym lista znanych błędów (Known Issue) przekraczała sto, a mimo to klient był zadowolony?

Niektórym być może taka sytuacja będzie wydawać się niemożliwa, ale jednak tak się czasem dzieje. Dochodzi do tego z różnych przyczyn i czasami może to być dla nas niezrozumiałe. W końcu jesteśmy specjalistami, których obecność w projekcie powinna sprzyjać poprawie jakości i zmniejszeniu ilości błędów. Trzeba jednak pamiętać, że jakość to pojęcie względne i dla klienta może oznaczać coś innego niż dla nas. Czasami po prostu brakuje nam informacji, by zrozumieć punkt widzenia naszego zleceniodawcy.

Omówię poniżej przykłady takich sytuacji.

Stary system

W trakcie pracy przy starym systemie zdarza się, że lista znanych błędów bywa naprawdę imponująca. Często może być to dziwne, że mimo usilnych prób tłumaczenia klientowi, że warto te błędy poprawić, nie decyduję się on na to. A przecież może być tak, że część lub nawet większość z defektów, jest w funkcjonalnościach, które nie są już używane, więc ich istnienie nikomu nie przeszkadza. Czasami jest też tak, że aplikacja ma być w niedługim czasie zastąpiona innym rozwiązaniem, ale my o tym nie wiemy. O ile łatwiej byłoby nam zrozumieć decyzję o braku inwestycji pieniędzy w naprawę błędów, gdybyśmy posiadali wiedzę na temat przyszłości testowanej aplikacji.

Nowa aplikacja

Zdarza się też, że pracujemy nad zupełnie nową aplikacją i klient ciśnie na dostarczanie nowych funkcjonalności, a lista znanych błędów rośnie. Może to wynikać bardziej z większego zysku, jaki przyniesie dostarczenie pewnych rozwiązań niż naprawiania błędów, które nie przeszkadzają w usprawnieniu procesów biznesowych. Bywa też tak, że choć wprowadzamy nową aplikację, to jest to tak naprawdę tymczasowe rozwiązanie, a klient równolegle pracuje nad docelowym wdrożeniem. Stąd może wynikać niechęć do dopieszczania każdego szczegółu.

Niewłaściwa aplikacja

Kto miał do czynienia z sytuacją, w której wymagania definiowane były przez osobę, która nie była użytkownikiem końcowym? Tak też się czasem zdarza. Wtedy błędy są dla klienta mniejszym problemem niż to, że przygotowane rozwiązanie nie jest tym, czego oczekiwał end-user. W takim wypadku aplikacja może nie być w ogóle używana, a pieniądze zostały wydane bezpowrotnie.

Krytyczny termin

Może zdarzyć się tak, że klient będzie musiał wdrożyć jakieś rozwiązanie przed konkretnym terminem, gdyż wymaga tego prawo. Wtedy dostarczenie aplikacji z błędami może być mniej kosztowne niż niespełnienie wymogów legislacyjnych, których złamanie może wiązać się z naprawdę dużymi karami finansowymi.

Wnioski

Jak widzicie, sytuacje mogą pojawić się różne. Te przytoczone powyżej z pewnością nie wyczerpują tematu. Zawsze jednak warto uświadamiać klienta ile i jakie błędy (pod względem priorytetu czy ważności) zostały wykryte oraz jakie ryzyko się z nimi wiąże. To może otworzyć możliwość wspólnej decyzji czy chcemy wszystkie te błędy nadal śledzić, czy też nie. Być może dzięki temu będziecie w stanie znacznie skrócić tę listę, bo klient zdecyduje się na naprawę tych najbardziej krytycznych. Możecie też ustalić, że błędy niekrytyczne całkowicie zostaną z tej listy usunięte. Warto też rozmawiać z klientem, aby poznać jego punkt widzenia oraz sposób postrzegania jakości.

Podsumowanie

Nie ma oprogramowania bez błędów. Postrzeganie jakości zależy od punktu widzenia różnych zainteresowanych stron. Czasami duża ilość znanych defektów może nie mieć negatywnego wpływu na zadowolenie klienta, a samo zadowolenie warto sprawdzać. Większym problemem może okazać się aplikacja, która nie dostarcza wartości biznesowej lub zbyt późne dostarczenie rozwiązania z kilkoma błędami, ale które spełnia wymogi legislacyjne. Nie powinniśmy za wszelką cenę dążyć do ideału, a raczej zadbać o to, by klient dostał to czego chce. Inaczej może też być w podejściu produktowym, a nie projektowym.

Oczywiście nie można zapomnieć o tym, że są też aplikację, które muszą spełniać wyśrubowane normy jakości, bo od nich może zależeć np. ludzkie życie. Ale to już zupełnie inna para kaloszy.