Rzecz o efektywnym zgłaszaniu błędów

Przyszło nam żyć w czasach, gdzie wszelkiego rodzaju systemy informatyczne, te mniej i bardziej zaawansowane towarzyszą nam wszędzie: w banku, w sklepie, na siłowni czy nawet w domu. Wiele z nich składa się z dwóch zależnych od siebie części tj. hardware (sprzęt) i software (oprogramowanie). Rozwój technologii oprócz oczywistych udogodnień zakorzenił w twórcach oprogramowania swego rodzaju “lenistwo” gdyż systemy aktualizacji OTA (over the air), powszechny dostęp do sieci Internet i zwiększona świadomość społeczeństwa sprawiły, że oprogramowanie nie jest już wyrytym w kamieniu monolitem, ale raczej komponentem możliwym do prostej, szybkiej i przede wszystkim mało kosztownej wymiany. Dlatego też w dzisiejszych czasach większy nacisk stawia się na tak zwane konsumenckie testy oprogramowania. Coraz więcej powszechnie używanych aplikacji oferuje użytkownikom wgląd w nowo powstające rozwiązania, dając im możliwość testowania ich i zgłaszania programistom wszelakich problemów. W dzisiejszym artykule postaram się opisać Wam, w jaki sposób zgłaszać efektywne raporty błędów, na co należy zwracać uwagę przy ich pisaniu i chyba najważniejsze, czego unikać przy ich tworzeniu. Przykładem jakim będę się posługiwał będzie system MacOS i jego deweloperska wersja testowa, niemniej jednak techniki zaprezentowane w tym tekście mogą być stosowane w dowolnym środowisku, które ma jakiś system zgłaszania, segregowania i dyskusji o błędach. Po tym przydługim wstępie chciałbym poprosić państwa o zapięcie pasów, gdyż dzisiejszy lot nie obędzie się bez crashy!

Niezbędnik zaprawionego testera, czyli słów kilka o terminologii

Każdy fach charakteryzuje się swoim specyficznym językiem i tak jak policjanci dają komuś “ogon” tak testerzy debugują, zgłaszają bug reporty i testują alphy. Żeby wniknąć między wrony, musisz krakać jak i one. Poniżej zamieściłem kilka terminów, z jakimi będziecie spotykać się na co dzień, jeżeli postanowicie wkroczyć na testerski szlak, czy to hobbystycznie czy być może nawet zawodowo.

• • • Wersja alpha: jedna z pierwszych wersji aplikacji, które zostają pokazane szerszej publiczności, tj. testerom, potencjalnym klientom. Wersje te charakteryzują się wysoką awaryjnością, niedokończonymi funkcjami, błędami, brakami w dokumentacji, interfejsie ITD.
• Wersja beta: wersja testowa aplikacji. Te wersje są już nieco stabilniejsze od poprzedniczek, jednakże wciąż spodziewać się w nich można błędów, niedociągnięć, powolnego działania i ogólnie bałaganu. W wielu środowiskach bety to już poniekąd zamrożone wersje aplikacji, tj. nowe funkcje nie są dodawane w danym cyklu wydawniczym a poprawiane są jedynie błędy.
• RC (release candidate version): wersja aplikacji teoretycznie gotowa do wydania. Wydania RC już zawsze są zamrożone a testerzy szukają w nich poważnych i krytycznych błędów. Jeżeli takowe nie zostaną wykryte, wersja RC staje się wówczas wersją stabilną.
• Semantic versioning (sem-ver): Standard wersjonowania aplikacji który wszyscy znamy i kochamy, tj. x.y.z, gdzie x to główny numer wersji, y to podwersja a Z tak zwana rewizja. Główny numer wersji powinno się zwiększać w razie krytycznych zmian, takich jak na przykład zmiana silnika, biblioteki odtwarzania audio ITD. Podwersję zwiększamy w razie dodania do aplikacji nowych funkcji a rewizja podbija się wraz z poprawianymi w programie błędami. Istnieje kilka odstępstw od tej reguły, na przykład popularny w środowisku .NET format 1.0.0.0, gdzie ostatni człon to tak zwany build, czyli identyfikator kompilacji aplikacji. Takimi szczegółami nie musicie się jednak przejmować, chyba że zmusi was do tego zły szef albo jesteście programistami.
• Crash: nieoczekiwane zakończenie działania aplikacji w wyniku błędu.
• Bug: błąd, zachowanie nieoczekiwane czy nie pożądane.
• Debugowanie: ja spotkałem się z dwoma znaczeniami. Pierwsze z nich dotyczy mojego podwórka i jest to proces, gdzie programista analizuje kod próbując znaleźć i przede wszystkim naprawić błąd. Testerzy używają tego słowa w kontekście szukania błędów i ich opisywania czy reprodukcji.

Oczywiście terminów jest znacznie więcej, ale moim zdaniem to właśnie te są używane najczęściej i zaznajomienie się z nimi pozwoli Wam rozpocząć przygodę z testowaniem i zgłaszaniem błędów.

Układamy puzzle: czyli z czego składa się raport o błędzie?

Każde pismo ma jakąś swoją strukturę, której zachowanie pozwoli jego odbiorcy w prosty i szybki sposób przeskanować tekst w poszukiwaniu interesującej go informacji. Nie inaczej jest w tym przypadku i tak każdy raport o błędzie powinien składać się z kilku sekcji. Niezachowanie porządku podczas jego sporządzania sprawia, że raport ten nie ma wartości, tj. nie może być użyty przez programistów do efektywnego i szybkiego zbadania problemu. Poniżej wyszczególniłem najważniejsze sekcje takiego raportu. Warto w tym miejscu zaznaczyć, że Czasami jakieś firmy mają swój system zgłaszania problemów który może odbiegać nieco od tego przedstawionego tutaj.

• Tytuł: zdawałoby się, że najbardziej oczywista rzecz pod słońcem, ale to właśnie w tej sekcji popełnianych jest najwięcej błędów w tworzeniu raportów. Dobry tytuł powinien
  • A: oddawać naturę problemu. Tytuły w stylu “problem” czy “nie działająca funkcja” w większości przypadków automatycznie dyskwalifikują raport, gdyż tak napisane pismo zmusza odbiorcę do zapoznania się z nim w całości.
  • B: Być krótki, ale jednocześnie unikalny. Oznacza to, że tytuły w stylu “problem z ustawieniami klawiatury” czy “błędy w zachowaniu kursora tekstowego” są już nieco lepsze od poprzednich, ale nie mają unikalności, gdyż problemów z ustawieniami może być wiele, i tak samo kursor może mieć wiele nieoczekiwanych zachowań.
• Priorytet: wielokrotnie spotkałem się z sytuacją, gdzie to zgłaszający musi nadać błędowi odpowiedni priorytet. Najpopularniejszy system priorytetów jest następujący:
  • Sugestia: sugestia nowej funkcji lub poprawa istniejącej.
  • Drobny błąd: nieoczekiwane zachowanie, które jednak nie wpływa znacząco na komfort i bezpieczeństwo korzystania z aplikacji.
  • Poważny błąd: nieoczekiwane zachowanie, które znacząco wpływa na komfort i bezpieczeństwo korzystania z aplikacji. Na przykład niemożność skorzystania z jednej z funkcji, błędy podczas zapisu/odczytu danych ITD.
  • Krytyczny błąd: nieoczekiwane zachowanie powodujące na przykład utratę/uszkodzenie danych, nieoczekiwane zamknięcie aplikacji, wycieki pamięci ITD.
• Warto w tym miejscu nadmienić, że niektóre firmy (na przykład Apple) korzystają z własnego systemu klasyfikacji błędów, w którym to zaznaczamy jego rodzaj, a nie właściwą wagę. Moim zdaniem jest to rozwiązanie lepsze, gdyż wtedy nie ma miejsca na subiektywne potrzeby użytkowników. Aplikacja się wyłącza i tak jest.
• Dane diagnostyczne: informacje o systemie, wersji aplikacji, której dotyczy błąd czy sprzęcie. Niektóre rozwiązania (na przykład asystent opinii Apple) zawierają zintegrowane narzędzia, które same te dane zbierają, niemniej jednak w większości przypadków warto jest dodać coś od siebie, na przykład dodatkowe dzienniki aplikacji, screenshot czy nagranie ekranu ilustrujące problem ITD.
• Opis problemu: Jak tytuł jest twarzą dobrego raportu, tak opis jest jego sercem. To właśnie w tym miejscu możemy a nawet powinniśmy szerzej przedstawić nasz problem. Sam opis również składa się z kilku części i każda z nich jest niezwykle ważna, gdyż pozwala deweloperom zrozumieć opisywany błąd
  • Kroki prowadzące do odtworzenia błędu (steps to reproduce): sekcja ta powinna przyjąć formę planu wydarzeń znanego nam doskonale z lekcji języka polskiego, gdzie w punktach opisujemy dokładnie, po kolei co deweloper powinien zrobić, aby natrafić na błąd. Przede wszystkim nie zakładamy, że deweloper ma wiedzę jaką mamy my. Jeżeli istnieje wiele dróg otwarcia danego menu czy uzyskania dostępu do danej opcji, musimy koniecznie opisać sposób z jakiego skorzystaliśmy. Kolejną istotną rzeczą jest, abyśmy pisali pełnymi zdaniami, krótko i na temat. To nie jest miejsce, gdzie możemy pisać eseje o tym, jak to dany program jest zły czy nie przemyślany.
  • Oczekiwany rezultat (expected result): Co, naszym zdaniem powinno się stać po wykonaniu kroków przedstawionych w poprzedniej części? Na przykład “prędkość mowy powinna wrócić do wartości domyślnej”. Ktoś może się zastanawiać po co to komu w ogóle potrzebne, a ja już spieszę z wyjaśnieniem. Czasami błędy jakie zgłaszają testerzy nie są tak na prawdę błędami, a pewnego rodzaju nieporozumieniem na linii programista, tester. Dobre opisanie spodziewanego rezultatu pozwala wykluczyć takie przypadki już na wstępnym etapie badania problemu.
  • Faktyczny rezultat (actual result): co się stało? Jak w poprzednim punkcie opisujemy zachowanie, jakie zaszło. W tym miejscu możemy odwołać się do załączonego zrzutu ekranu czy nagrania.
• Kategoria: tutaj wybieramy, jakiej części systemu dotyczy problem. Na przykład dla MacOS są to komponenty typu dostępność, Safari, Ustawienia i tak dalej.

Nasza przygoda z problemem nie kończy się jednak po wysłaniu zgłoszenia. Czasem może dojść do sytuacji, w której deweloper względnie zespół deweloperów skontaktuje się z testerem w celu udzielenia dodatkowych informacji. Dokładnie tak, jak w przypadku powyżej, należy słuchać instrukcji dewelopera i postępować zgodnie z nimi w celu efektywnego rozwiązania problemu.

A kiedy tak właściwie zgłosić problem?

Zanim usiądziemy i zaczniemy sporządzać raport czy to ręcznie, czy przy pomocy narzędzia takiego jak Asystent Opinii najpierw musimy zastanowić się nad kilkoma rzeczami.

• Czy to co zgłaszamy jest błędem? Aby to zweryfikować powinniśmy podejść do sprawy po raz kolejny.
• czy ponowna próba również skończy się wystąpieniem problemu?
• Czy dobrze rozumiemy badaną funkcję?
• Czy dokumentacja aplikacji nie posiada informacji na temat możliwości wystąpienia danego problemu (warto szukać w sekcjach typu “troubleshooting” czy “FAQ”).
• jeżeli dany system nam na to pozwala, warto zobaczyć czy dany błąd nie został już wcześniej zgłoszony. Jeśli tak to przed otwarciem nowego raportu należy zastanowić się, czy nasza sprawa wniesie coś nowego do istniejącego już zgłoszenia.
• W reszcie należy przemyśleć, czy naszego problemu nie można rozbić na inne mniejsze. Dobry raport o błędzie powinien dotyczyć jednej, konkretnej sprawy. Wynika to z faktu, że bardzo często raporty przypisywane są do konkretnych deweloperów lub zespołów deweloperskich, które to mogą nie mieć kompetencji do rozwiązania części naszego raportu, jeżeli zawiera on więcej niż jedno zgłoszenie.

Podsumowanie

Ten artykuł znacznie odbiegał od tych, które pisałem wcześniej. Niemniej jednak uważam, że poruszane zagadnienie jest niezwykle ważne szczególnie w środowisku osób niewidomych, gdzie bardzo popularne jest testowanie wersji poglądowych chociażby systemu iOS czy MacOS. Do tak zwanych betatestów należy zapisać się nie z myślą o tym, że będziemy mieli dane funkcje wcześniej od reszty społeczeństwa tylko raczej z nastawieniem na wykonywanie pracy, która dzięki naszemu trudowi i poświęceniu sprawi, że ci mniej odważni czy techniczni z nas będą mogli korzystać z dopieszczonego, doszlifowanego i wolnego od błędów produktu.

Tymczasem ja życzę wam miłego testowania i odmeldowuję się,

Arkadiusz Świętnicki