Systemy śledzenia błędów
Cel
Wbrew nazwie (śledzenie błędów), systemy o których piszę służą raczej do rejestrowania wymaganych zmian - czymkolwiek by były (błędami do usunięcia, rozszerzeniami do dodania, operacjami administracyjnymi do wykonania). Mają następujące podstawowe zastosowania, które mogą być ze sobą łączone:
- jeszcze w trakcie trwania projektu - rejestracja rzeczy które mniej lub bardziej warto zrobić ale nie ma na to na razie czasu - warto jednak by gdzieś ten pomysł został;
- pod koniec - usprawnienie przebiegu informacji o błędach wykrywanych w trakcie testów i zapewnienie, że żaden wykryty błąd nie zostanie zapomniany i że każdy trafi do właściwej osoby;
- po wdrożeniu - ułatwienie osobom świadczącym wsparcie techniczne rejestrowania zgłaszanych przez klientów problemów i wymaganych zmian - wraz z automatycznym powiadamianiem o nich odpowiedzialnych za poszczególne komponenty;
- jeśli nasi klienci są tym zainteresowani (i im na to pozwolimy) - mogą oni bezpośrednio wprowadzać opisy problemów a także obserwować co się z nimi dzieje (w szczególności być powiadamiani o rozwiązaniu lub odrzuceniu problemu).
Przy okazji (budujemy bazę informacji) mamy możliwość generowania mniej lub bardziej sensownych ale efektownie wyglądających raportów typu liczba zgłoszonych i usuniętych błędów tygodniowo.
Jak tego nie należy robić
Do ewidencji błędów i wymaganych zmian nie należy stosować pobazgranych karteczek, emaili kopiowanych do jakiegoś dziwnego folderu, jednego wielkiego dokumentu w jakimś edytorze, list ToDo w programie PIM ani tym bardziej wyśmienitej pamięci Zyzia programisty. Rozwodzić się nad tym dużo nie będę, kto stosował takie metody, ten wie jakie mają niedostatki. Pozwolę sobie jedynie zwrócić uwagę, że lista zmian do wprowadzenia - jakkolwiek byłaby przechowywana - powinna mieć następujące cechy:
- gwarantować, że żadna informacja nie zginie;
- być dostępna dla całego zespołu a nie tylko dla jednego programisty - i nie ginąć gdy ten wyjedzie na urlop lub zmieni pracę;
- pozwalać na oznaczanie rzeczy poprawionych w sposób inny niż ich skasowanie;
- umożliwiać natychmiastowe odnalezienie listy błędów które ma usunąć konkretny programista oraz listy błędów w konkretnym produkcie.
To oczywiście absolutne minimum!
Właściwe narzędzia
Słówko o komercji
Istnieje bardzo obszerny zestaw komercyjnych produktów do rejestracji i monitorowania błędów - w szczególności większość producentów komercyjnych narzędzi do kontroli wersji sprzedaje takie pakiety (mniej lub bardziej zintegrowane z swoim narzędziem do kontroli wersji - przy czym integracja oznacza ułatwianie wiązania konkretnych wersji kodu z usuwaniem konkretnych błędów). Narzędzia tego typu mają jednak pewne poważne wady:
- drogo kosztują;
- często są płatne od stanowiska - a przy tego typu narzędziach zależy nam by mógł je używać każdy pracownik i jak najwięcej klientów;
- trudno je przerabiać - a chęć modyfikacji w tego typu zastosowaniach pojawia się często.
Z drugiej strony, komercyjne produkty są zwykle bardziej dopieszczone (choćby estetyka wyglądu czy ilość raportów), mają też bardziej zaawansowaną obsługę specyfiki biznesowej (jak choćby rejestrowanie i raportowanie czasochłonności prac albo złożone modele uprawnień).
Nie będę robił tutaj obszernego przeglądu, wspomnę jednak o dwóch produktach:
- FogBugz Joela Spolsky'ego został stworzony z szczególną atencją dla zapewnienia ergonomii pracy, w sensowny sposób wspiera też potrzeby menedżera projektu
- Jira firmy Atlassian ładnie wpisuje się w szerszą gamę produktów obsługujących komunikację w zespole.
Oczywiście możliwości jest wiele, wiele więcej, poszukiwanie haseł typu issue tracking, ticket tracking czy bug tracking dostarcza mnóstwa propozycji.
Narzędzia Open Source
Sytuację wśród narzędzi Open Source w znacznej mierze zdeterminowała Bugzilla. Jej pojawienie się pod koniec lat 90-ych stanowiło znaczący przełom, przewyższała znacznie ówczesne darmowe alternatywy (jak Jitterbug lub GNATS), nic więc dziwnego że błyskawicznie zdobyła wielką popularność. Obecnie Bugzilla jest używana nie tylko przez wielkie i małe projekty open-source (z projektami Mozilla - dla której oryginalnie Bugzilla powstała, KDE i Gnome na czele) ale też przez wiele komercyjnych firm i organizacji.
Obecność Bugzilli istotnie utrudniła powstawanie konkurencyjnych narzędzi, po pierwsze zbudowanie konkurencyjnej funkcjonalności wymaga dosyć znaczącego wkładu pracy, po drugie projekty które raz wdrożyły system monitorowania błędów rzadko i niechętnie go zmieniają.
Nie będę się tu kusił na pełne omówienie, zwrócę tylko uwagę na następujące zalety bugzilli:
- dość czytelny przeglądarkowy interfejs użytkownika,
- model przywilejów i uprawnień pozwalający na ustalanie komu co wolno widzieć i co zmieniać.
- obsługa wszystkich istotnych funkcji standardowego modelu zarządzania zgłoszeniami,
- liczne narzędzia czy skrypty umożliwiające jej integrowanie z systemami zarządzania wersjami.
Nie bez znaczenia jest też fakt, że mnóstwo osób korzystało z bugzilli w takim czy innym projekcie i umie jej używać.
Bugzilla ma też oczywiście wady. Jej interfejs jest dość surowy i do wielu zastosowań przeładowany. O ile drobne poprawki dostosowujące do specyfiki projektu czy organizacji można zrobić dość łatwo, o tyle poważniejsze zmiany natrafiają na mur zagmatwanego kodu perlowego i dziwacznej miejscami struktury bazy danych. Nie jest też łatwo wpisać bugzillę w bardziej złożone zestawy narzędzi.
Jest oczywiście świat poza bugzillą. Ciekawymi projektami które zdołały osiągnąć dojrzałość i uzyskać bazę użytkowników są np. Roundup (Python), Mantis (PHP) czy RT (Perl) - język implementacji podaję, bo dostosowując aplikację się z nim prawdopodobnie zetkniemy.
Inną popularną tendencją jest wbudowywanie bugtrackera w bardziej złożone zintegrowane narzędzia. Sztandarowym przykładem ogólnodostępnego programu jest tutaj Trac (udane połączenie wiki, webowego interfejsu do Subversion i bugtrackera), obsługę błędów mają też wbudowaną systemy typu SourceForge czy Launchpad.
Obszerniejszą listę bugtrackerów można znaleźć w wikipedii.
Jak to działa
Rozmaite wymieniane w tym rozdziale szczegóły dotyczą bugzilli ale koncepcja jest wspólna dla wszystkich narzędzi tego typu.
Cykl obsługi błędu
Typowy cykl obsługi błędu (czy też rozszerzenia) wygląda następująco:
- dowolna osoba (posiadająca odpowiednie uprawnienia) wprowadza informację o błędzie czy też rozszerzeniu;
- system automatycznie określa osobę odpowiedzialną za pakiet którego dotyczy błąd, przypisuje go jej i generuje powiadomienie (email);
- odpowiedzialna osoba akceptuje poprawkę (co oznacza tak, problem leży w mojej gestii) albo stwierdza, że właściwym odpowiedzialnym jest kto inny - i przypisuje błąd jemu (może tu chodzić zarówno o przydzielenie pracy w ramach modułu realizowanego przez kilka osób, jak o stwierdzenie, że błąd widoczny w programie A jest faktycznie błędem w bibliotece B itp, może się też zdarzyć, że dany błąd jest kolejnym objawem jakiegoś wcześniej zarejestrowanego błędu);
- toczą się prace związane z obsługą błędu, w trakcie których mogą być do niego dołączane kolejne informacje, może on być przepisywany kolejnym odpowiedzialnym itp;
- ostatecznie odpowiedzialny kończy pracę nad błędem na jeden z kilku sposobów - oznaczając że błąd został poprawiony, stwierdzając, że poprawiony z jakichś przyczyn nie będzie albo uznając, że zgłoszenie błędu było niepoprawne;
- jeśli błąd usunięto, oryginalny autor albo inna odpowiednio uprawiona osoba weryfikuje, czy błąd faktycznie został usunięty - i bądź ponownie go aktywuje, bądź oznacza że poprawka została zweryfikowana;
- po ostatecznym rozwiązaniu problemu (np. po opublikowaniu albo instalacji u klienta wersji pozbawionej błędu) błąd jest zamykany.
Podstawowe atrybuty błędu
Oprócz samego opisu błędu, jego aktualnego stanu i odpowiedzialnego oraz daty wprowadzenia, definiowane są jeszcze rozmaite dodatkowe atrybuty. Do najważniejszych należą:
- rodzaj błędu - np. błąd krytyczny (uniemożliwiający działanie systemu/programu), błąd poważny (nie działa lub błędnie działa jakiś ważny moduł), błąd niezbyt istotny (drobna niedogodność, jakaś niekonsekwencja czy nieelegancja), konkretne potrzebne rozszerzenie, wartościowy luźny pomysł;
- waga, czyli de facto informacja jak szybko musi to zostać poprawione - natychmiast, jak najszybciej, w normalnym trybie, w dowolnej przyszłości;
- numer wersji programu w którym wykryto błąd;
- platforma, środowisko systemowe.
Powyższa lista często jest adaptowana do potrzeb danej organizacji.
Sposób korzystania z aplikacji
Aplikacje do rejestracji błędów mają dosyć proste i lekkie interfejsy. Wprowadzenie informacji o nowym błędzie a także modyfikacja stanu, treści lub atrybutów istniejącego to po prostu wypełnienie odpowiedniego formularza w przeglądarce WWW (czasem można też założyć zgłoszenie wysyłając odpowiednio sformatowany email).
O istotnych zmianach stanu błędu zgłaszający i odpowiedzialny są dodatkowo powiadamiani pocztą elektroniczną.
Do tego dochodzą funkcje raportujące - tak szczegółowe, czyli głównie możliwość wyszukiwania błędów według rozmaitych kryteriów (wszystkie aktywne błędy za które jest odpowiedzialny X, wszystkie aktywne błędy w module Y, wszystkie błędy poprawione w ostatnim tygodniu), jak ogólne - statystyki liczby zgłoszonych i usuniętych błędów w poszczególnych modułach.
Wreszcie, nieraz jest możliwa taka czy inna forma priorytetowania zgłoszeń (ustalania co jest ważne, a co nie), a także mechanizmy ich eskalacji (przypominania o sprawach dawno zapomnianych).
Uprawnienia
Jeśli używamy aplikacji w ramach sporej organizacji a tym bardziej gdy udostępniamy ją klientom lub użytkownikom w internecie - potrzebujemy odpowiedniego modelu uprawnień. Obejmuje on niezależnie:
- uprawnienia do wykorzystywania poszczególnych modułów;
- niezależne od modułów klasyfikowanie błędów na wewnętrzne i publicznie dostępne.
Pierwsza sprawa jest dosyć oczywista - w ramach jednej bazy wiedzy możemy przechowywać informacje o błędach w kilku niezależnych aplikacjach, użytkownik aplikacji A nie musi widzieć co się dzieje z aplikacją B.
Druga kwestia jest nieco subelniejsza - niekiedy wykorzystując publicznie dostępną aplikację chcemy niektóre błędy ukryć przed klientami (np. obserwacje na temat nieeleganckich rozwiązań w kodzie, sprawy bardzo techniczne). W tym wypadku zazwyczaj wystarczy klasyfikacja błędów na "ogólniedostępne" i "wewnętrzne". Taki model uprawnień może być ortogonalny do modelu uprawnień związanego z podziałem na moduły.
Funkcje dodatkowe
Na obrzeżach systemów obsługi błędów pojawiają się niekiedy interesujące funkcje dodatkowe. Przykładowo, Bugzilla daje możliwość głosowania, który błąd powinien być usunięty jako pierwszy (każdy użytkownik ma do dyspozycji kilka głosów i przypisuje je najbardziej dotkliwym dlań błędom), Roundup potrafi przyjmować nowe zgłoszenia lub komentarze dotyczące starych zgłoszeń via email a Trac pozwala wiązać zgłoszenia do rozwiązania z planem projektu.