TheTarPit

błąd nasz codzienny

Nie ma systemu bez błędów. Im szybciej się z tym pogodzisz tym lepiej.

Ten prosty fakt dla wielu nie jest oczywisty, wręcz przeciwnie — uważają, że to marna wymówka programistów mająca usprawiedliwić brak umiejętności i lenistwo. W rzeczywistości (pomijając sytuacje patologiczne) nie chodzi o wymówki, tylko o zaakceptowanie rzeczywistości i przygotowanie się na zdarzenia, które i tak nastąpią. Błędy w oprogramowaniu są i będą, a system dobry, to taki, w którym pozostały błędy błahe lub ujawniające się zaniedbywalnie rzadko. Nie sposób ukryć, że świadomie dopuszcza się tutaj znacznie szerszy margines błędu niż w jakiejkolwiek innej dziedzinie inżynierii. Murray Cantor w "Software Leadership: A Guide to Successful Software Development" pisze o tym tak:

Kiedy uda się odnaleźć i usunąć jedną usterkę, wtedy czas znalezienia kolejnej dramatycznie wzrasta. W końcu znalezienie kolejnego błędu okazuje się karkołomnym zadaniem. Jeśli odnalezienie kolejnego błędu w kodzie miałoby zająć 40 godzin pracy dwudziestu programistom, to raczej zrezygnujesz z tego i wprowadzisz produkt na rynek. Ogólnie rzeczą niemożliwą jest odnalezienie ostatniego defektu, a w rezultacie stworzenie i sprzedawanie systemu wolnego od wszelkich wad. Osiągnięcie tego standardu wymaga tak długiego testowania, że żadne przedsiębiorstwo nie może sobie na to pozwolić.

Murray Cantor

Jak kierować zespołem programistów

Zatem błędy, defekty, usterki, bugi w oprogramowaniu są chlebem powszednim nawet w "gotowych" systemach, a na etapie rozwoju w szczególności. Zamykanie oczu nie pomaga; błędy trzeba tępić, a przede wszystkim śledzić. W takiej sytuacji dosyć zadziwiający jest fakt, że istnieją projekty, w których praktycznie nie prowadzi się ewidencji i kontroli błędów. Potraktujmy o jako jedną z wielu patologii — w rozsądnym przedsięwzięciu programistycznym BTS musi być.

Na system kontroli błędów należy patrzeć jak na bazę danych. Baza ta może być dowolnie skomplikowana, albo dowolnie prosta — jak kto lubi. W projekcie, przy którym aktualnie pracuję, używamy Flyspraya (w wersji lekko przeze mnie .... udoskonalonej) tylko dlatego, że tak mi łatwiej dyskutować z testerem ("— jest we flysprayu? nie ma, to nie ma o czym rozmawiać"), przydzielać zadania i śledzić co kto dostał do roboty, a szefowi wyraźnie łatwiej zaczynać rozmowę od "popatrzmy na tego flajspreja, ale posortuj tak żeby...". Jednak nic nie stoi na przeszkodzie by było to zupełnie inne narzędzie albo nawet jakiś sprytny arkusz kalkulacyjny czy skrawek bazy danych — kwestia indywidualnych upodobań. Ważne jest jedno: błąd musi być możliwy do opisania i śledzenia, a BTS powinien być postrzegany jako jedno z narzędzi codziennej pracy każdego członka zespołu.

Opis błędu, zgłoszenie niezgodności, "feature request" czy cokolwiek co do tego systemu wpiszesz, może zawierać dziesiątki najróżniejszych pól. Na różnych poziomach organizacji mogą one być przydatne do najróżniejszych celów, choćby do analiz statystycznych. Jednak spece od prowadzenia projektów informatycznych powiadają, że musi sie tam znaleźć przynajmniej:

• kompletny, powtarzalny sposób jego wywołania
• oczekiwane zachowanie systemu i zachowanie faktyczne
• wskazanie osoby odpowiedzialnej
• status, przynajmniej binarny (poprawiony/nie poprawiony)

Najłatwiejsze do ustalenia są dwa ostatnie punkty. Jednak dwa pierwsze to istny koszmar — umiejętność opisania błędu tak, aby ktoś inny go zrozumiał, to sztuka sama w sobie, sztuka trudna i tajemnicza. I to nawet zakładając, że opis jest tworzony przez wewnętrznego testera i przeznaczony dla deweloperów, ludzi znających system co najmniej dobrze. Wbrew pozorom jest to trudne i wymaga sporo doświadczenia — sama instrukcja postępowania czy dowolne wytyczne nie wystarczą jeśli tester (czy ktokolwiek, kto wpisuje nowe zgłoszenia) nie potrafi sam z siebie zrobić tego dobrze^[1]. Dobry i komunikatywny tester to skarb, bo bez porządnych opisów błędów, cały ten system niewiele jest wart...

Jeżeli masz dobrze prowadzoną bazę błędów, jeśli kontrolujesz ile i jakie w systemie są niezgodności, możesz ocenić jak blisko jesteś decyzji "puszczamy tak jak jest, reszta w następnej wersji". W przeciwnym wypadku nie wiesz jak jesteś głęboko, i pewne jest tylko jedno — jesteś głębiej niż ci się wydaje — utoniesz.

Komentarze