Oprogramowanie bez błędów? Akurat…

Czy spotkaliście się w swojej pracy kiedyś 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 pojawiają się czasami, 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 ma znalezieniu odpowiedniego momentu kiedy 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.

Poniżej znajdziecie kilka przykładów

• 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ć z większego zysku jaki przyniesie dostarczenie pewnych rozwiązań niż naprawianie 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? Zdarza się tak czasem. Wtedy błędy są mniejszym problemem dla klienta, 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 bezpowrotnie wydane.
• krytyczny termin – może być też tak, że klient musi wdrożyć jakieś rozwiązanie przed konkretnym terminem, bo 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 dużymi karami finansowymi.

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 w ogóle zostaną z tej listy usunięte. Warto też rozmawiać z klientem, by poznać jego punkt widzenia i sposób postrzegania jakości.

Podsumowanie

Nie ma oprogramowania bez błędów. Postrzegania 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.

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. To już zupełnie inna para kaloszy. Inaczej może też być w podejściu produktowym, a nie projektowym.

A jaki jest twój punkt widzenia?

Podziel się swoimi spostrzeżeniami na ten temat w komentarzach.