1. Czym jest raportowanie błędów na przykładzie systemu Windows

Odoo image and text block

Zdarza się sytuacja, program przestał odpowiadać system szuka rozwiązania problemu, wyszukane rozwiązanie praktycznie nigdy nic nie pomaga. Jest odpowiedzialna za to Usługa raportowania błędów systemu Windows, która swoim działaniem spowalnia nas i działanie systemu, zabiera gigantyczne zasoby na dysku twardym (nawet podczas kilku sekund działania). Stąd często zaleca ze względu na spowolnienie zaleca się również wyłączenie tej usługi

2. Testowanie oprogramowania

Testowanie określane jest jako „proces sprawdzania oprogramowania w celu zweryfikowania, czy spełnia ono określone wymagania. Jest to również działanie zmierzające do wykrywania błędów”. Zgodnie z tą definicją, testowanie ma na celu wspomóc udoskonalanie produktu informatycznego. Co jednak dzieje się w przypadku, gdy sam proces testowania jest daleki od doskonałości i występują w nim błędy? Jak przekłada się to na jakość pracy i wyniki testów? W praktyce okazuje się, że bardzo łatwo jest popełnić błędy podczas organizacji lub samego wykonywania testów. Niektóre z owych błędów pojawiają się tak często, są powtarzane tak wiele razy przez różnych ludzi, że można określić je mianem klasycznych.

Odoo text and image block

3. Najczęściej popełnianie błędy w testowaniu oprogramowania


 

Brak dociekliwości i dokładności

Często popełnianym błędem jest wykonywanie testów w sposób powierzchowny i niedokładny. Jest to szczególnie widoczne w przypadku testów opartych na specyfikacji funkcjonalnej lub innej dokumentacji wymagań. Niekiedy testerzy wychodzą z założenia, iż sprawdzą tylko to, co jest wyraźnie udokumentowane, bez wgłębiania się w szczegóły i wyszukiwania luk czy niespójności w opisie.

Wykonywanie testów bez zrozumienia działania aplikacji

Dość często zdarza się, że dokumentacja projektowa, stanowiąca podstawę do testowania, nie jest najlepszej jakości. Funkcjonalność nie jest opisana wystarczająco dokładnie, nie obejmuje wszystkich możliwych przebiegów procesu, specyfikacja nie uwzględnia opisów danych lub wyjątków. 

Odkładanie zgłaszania błędów na później

Dość często praktykowanym zwyczajem jest odkładanie zgłaszania błędów na później. Niektórzy testerzy organizują sobie pracę w taki sposób, że realizują w całości pewien etap testów, notują znalezione przypadki, a dopiero po zakończeniu cyklu raportują wyniki w systemie śledzenia błędów.

 Zgłaszanie błędu przed upewnieniem się, że jest to błąd

Czasami tester nie zrozumie do końca logiki aplikacji, nie orientuje się zbyt dobrze w regułach biznesowych lub nie ma wystarczającego doświadczenia – i każdą swoją wątpliwość zgłasza jako błąd. Jeśli na przykład tester nie zna reguł obowiązujących w bankowości i procedur instytucji, której oprogramowanie testuje, może traktować jako błąd sytuacje całkowicie poprawne z punktu widzenia biznesu.

Interpretowanie specyfikacji lub wyników testów według własnego uznania

Zdarza się, iż tester interpretuje specyfikację systemu według własnego rozumienia i zgłasza błędy tam, gdzie ich nie ma. Sytuacja taka ma miejsce szczególnie w przypadku, gdy dokumentacja jest na tyle niedokładna i niejednoznaczna, że dopuszcza wiele możliwości rozwiązań. Przykład – dokumentacja opisuje możliwość dodawania, edycji i usuwania rekordu z tabeli. Niektórych rekordów (np. aktywnych kont użytkownika) nie można usuwać.

Zgłaszanie błędów bez wystarczającego opisu

Najbardziej lakoniczny opis błędu, z jakim się spotkałam to: this button doesn"t work. Wyrażenie to opisywało wszystko – lokalizację błędu, procedurę odtworzenia, etc. Dla zgłaszającego problem był oczywisty, ponieważ widział ów button na ekranie przed oczyma i ewidentnie mógł stwierdzić błędne działanie.

Niewłaściwe zadania postawione przed testami i brak priorytetów

Testowanie zbyt często rozumiane jest jako sprawdzenie, czy produkt informatyczny działa tak, jak powinien działać, a nie czy nie robi czegoś, czego w żadnym wypadku nie powinien. Zbyt często zdarza się podejście polegające na wykonywaniu jedynie testów pozytywnych – czyli sprawdzania, czy aplikacja daje oczekiwane wyniki w przypadku wykonywania oczekiwanych i przewidzianych czynności. 

Pomijanie testowania dokumentacji

Dokumentacja, czy to specyfikacja funkcjonalna, model danych, dokumentacja przypadków użycia, czy przepływ procesu, jest produktem procesu wytwarzania oprogramowania i w związku z tym powinna podlegać testowaniu (czy też przeglądowi) na podobnych zasadach, jak produkowany system informatyczny. 

Niewłaściwe zarządzanie zgłoszonymi błędami

Pierwszy problem najkrócej obrazuje stwierdzenie: Znalazłem buga, zgłosiłem i reszta mnie nie interesuje. Czekam na poprawkę. To dość często występujące podejście do zarządzania błędami. Tester uważa, że wykonuje swoją pracę realizując zaplanowane scenariusze testowe i raportując ich wyniki. Z analizą odpowiedzi na zgłoszenia czeka do następnego cyklu testów.

Postawa: Developer to wróg

Wrogość pomiędzy testerami a programistami występuje dość często – jest przejawem pewnej rywalizacji oraz faktu, iż nikt nie lubi przyznawać się do pomyłki – a zgłaszanie błędów jest nieraz traktowane przez programistę jako atak na jego umiejętności. Zdarza się też, że komunikacja pomiędzy zespołami ogranicza się do wymiany informacji w systemie śledzenia błędów, a obie strony nie są zainteresowane nawiązaniem bardziej bezpośredniego kontaktu.

4. Efektywne zgłaszanie błędów 

Jak często widzisz programistów, którzy żądają więcej informacji na temat opisanego przez ciebie błędu? Jak często słyszysz, że błędu nie da się powtórzyć i spędzasz czas nad zgłoszonym już i opisanym bugiem?
Kończy się na tym, że więcej czasu poświęcamy na tego rodzaju przypadki niż na samo testowanie. Problem leży w jakości raportów o błędach.

Kiedy odkrywasz defekt, informujesz o nim programistę. Raport błędu jest nośnikiem tej informacji. Głównym celem tworzenia raportu jest umożliwienie programiście zobaczenie i zrozumienie problemu.

W skrócie: raport błędu jest dokumentem, który opisuje różnicę pomiędzy oczekiwanym rezultatem i aktualnym stanem np. funkcji systemu. Dostarcza też informacji jak wywołać błąd ponownie.

Po znalezieniu defektu.
– Zapisz tę informację od razu jak tylko upewnisz się, że to błąd. Nie czekaj do końca dnia.

– Poświęć czas na diagnozę błędu, który zgłaszasz. Pomyśl o możliwych przyczynach. Może okazać się, że odkryjesz więcej problemów w tym samym miejscu systemu. Nadmień o swoich przypuszczeniach przy opisywaniu błędu. Programiści będą ci wdzięczni, że zrobiłeś tę część pracy.

– Nie wysyłaj raportu od razu. Daj sobie czas na ponowne przeczytanie go i ewentualne dodanie/poprawienie części opisu.

– Nie wyolbrzymiaj znaczenia błędu w opisie.

– Jakikolwiek znalazłeś błąd pamiętaj, że opis dotyczy zaistniałej sytuacji nie zaś osoby, która kodowała daną funkcjonalność.

Odoo text and image block

5. Systemy raportowania błędów

Odoo image and text block

JIRA 

System do śledzenia błędów i zarządzania projektem firmy Atlassian, JIRA. Niezwykle ważnym aspektem w firmie jest obieg informacji. Cały projekt może zostać całkowicie zrujnowany, kiedy jedna wyłącznie wiadomość nie dotrze do właściwej jednostki. Dlatego też, nieocenione znaczenie dla poszczególnych firm może mieć licencja JIRA. Jest to narzędzie, pozwalające na kontrolę realizacji działań IT. Dodatkowo, wspiera ona sprawne przesyłanie informacji w trakcie wybranych projektów. Wspomniany system świetnie kieruje przepływem zadań, jak również procesami. Warto skoncentrować na nim swoją uwagę, jeżeli mamy do czynienia ze zbliżonymi zagadnieniami, gdyż spełnia on wymagania najbardziej wybrednych klientów. Po tym, jak zdecyduje się na program JIRA, bez problemu uda się kierować zadania do użytkowników i mieć nad ich wypełnianiem kontrolę. Zdołamy tu rozdzielić zadania priorytetowe od tych raczej mniej ważnych. Poza tym, system ten na bieżąco informuje o tym, jakie są rezultaty działań w konkretnych zespołach. Z jego pomocą jest szansa także, by dostarczyć wiedzę dotyczącą postępu prac każdego działu, który bierze udział w projekcie. Jak można zauważyć, dzięki temu, że w obszarze firmy zostanie przeprowadzona jira konfiguracja uda się zarządzać czasem pracy zatrudnionych na danym stanowisku osób. Tak samo pracownicy, jaki kadra zarządzająca wielu korporacji, są zadowoleni z użytkowania z tego oto systemu.

TRAC

System Trac wyróżnia się prostym i przejrzystym interfejsem, a także zintegrowanym mechanizmem Wiki (umożliwiającym stworzenie kolekcji artykułów - np. bazy wiedzy). Podobnie jak poprzednicy, Trac posiada polską wersję językową,  pozwala  tworzyć linki i odnośniki, bezproblemowe rozwiązanie usterek, zadania Zestawienia zmian, plików i stron wiki. 

Odoo text and image block
Odoo image and text block

Bugzilla

Jest to popularne, darmowe i otwarte oprogramowanie w architekturze klient-serwer do tworzenia serwisów internetowych służące do raportowania błędów. Aplikacja ta została napisana przez programistów z Fundacji Mozilla w języku Perl. Nad polską wersją programu pracuje zespół Aviary.pl. Może być również stosowane do aplikacji komercyjnych.  Bardzo ważnym elementem tego systemu jest to, że zwykle każdy użytkownik może raportować błędy. Następnie dany raport dopinany jest do odpowiedniego programisty, który może zająć się tym problemem. Zgłoszeniom można nadawać różne statusy. Ponadto Bugzilla daje możliwość dodawania załączników i umieszczania własnych komentarzy. Podczas raportowania błędów w Bugzilli mamy możliwość zgłaszania własnych pomysłów i sugestii związanych z rozwojem programu. Niekiedy takie rozwiązanie może okazać się równie istotne jak samo raportowanie błędów. Minusem tego rozwiązania jest możliwość otrzymywania bezużytecznych zgłoszeń, lecz na szczęście takim można przydzielać odpowiedni status. Z Bugzilli korzysta ok. 1300 różnego rodzaju korporacji, organizacji i projektów, a wśród nich można znaleźć Facebook, NASA, Mozilla, Ecplipse, Open Office, Apache, dystrybucje Linux i wiele innych.