Dzisiaj postaram się opowiedzieć, jak powinny być zgłaszane błędy. Czego jako programista możesz się spodziewać, czy też możesz oczekiwać od specjalisty do spraw jakości oprogramowania. Gdy pracujesz jako developer, naturalną częścią Twojej pracy jest naprawa zgłoszonych błędów. Na pozór błaha sprawa – może znacznie ułatwić albo w drugą stronę, utrudnić pracę całemu zespołowi.
Zwykle praca testera, specjalisty do spraw jakości oprogramowania kojarzona jest typowo z szukaniem błędów. Jak już nie raz wspominałam – to tylko część naszej pracy. Aby znalezione błędy mogły być naprawione muszą być w jakiś sposób przekazane reszcie zespołowi – dlatego też muszą być zgłoszone. I tu jak zawsze – diabeł tkwi w szczegółach.
Zgłaszanie błędów w praktyce
Wyobraźmy sobie przypadek Stasia. Staś dopiero się uczy, wdraża i ma małe doświadczenie w testowaniu. Pracuje z programistą Rysiem.
Staś testuje, tutaj już opanował podstawowe techniki i jego testowanie przynosi jakieś rezultaty – czyli znajduje błędy. Testował formatkę logowania, rzucił mu się w oczy fakt, że można zalogować się za pomocą plików cookies. Przejrzał dokumentację, gdzie nic nie było na ten temat i stwierdził, że nie będzie tego zgłaszał, bo nie był pewien czy to błąd czy nie. Testował dalej logowanie do aplikacji. Znalazł szereg błędów. Gdy tylko znalazł problem zapisywał go do jedne zbiorczej notki „Problemy formatki logowania”.
Jego notka wyglądała mniej więcej tak: Podczas testów znaleziono szereg nieprawidłowości:
– opcja zapamiętaj hasło nie działa poprawnie
– po zalogowaniu otwiera się sesja innego użytkownika
– przypomnienie hasła nie działa – literówka w tekście informacyjnym: „logujac” a powinno być „logując”
Programista rozpoczął pracę nad tą notką i został zalany różnymi błędami, które de facto przynajmniej w części są zupełnie niezwiązane ze sobą, bo przypomnienie hasła a liczba znaków w haśle – nie są ze sobą specjalnie powiązane. Trudno było zatem Rysiowi nawet wyestymować to zadanie.
Gdy tego dokonał zabrał się za pierwszy punkt „opcja zapamiętaj hasło nie działa poprawnie” – super, ale nie działa to znaczy jak to teraz działa, a jak powinno? Nie wiadomo. Ryś musi iść do Stasia albo do analityka dopytać o szczegóły, musi też sprawdzić jak to dokładnie jest opisane w dokumentacji. Dlatego postanawia wrócić do tego później przechodzi do następnego błędu – „po zalogowaniu otwiera się sesja innego użytkownika” – brzmi poważnie. Ryś stara się kilkukrotnie zalogować za każdym razem proces logowania przebiega prawidłowo, właściwy użytkownik zostaje zalogowany. Nie udaje się tego błędu odtworzyć. Programista przeszedł do kolejnego punktu „przypomnienie hasła nie działa” – po kilku testach Ryszard doszedł do tego, że link, w mailu który przychodzi jako request o reset hasła nie jest prawidłowy. Zdołał naprawić ten błąd. Na końcu literówkę poprawił.
I co dalej? Co powinien zrobić Ryszard? Przepiąć notkę dalej zgodnie z procesem, czyli np. CR a potem testy? Ryszard chce wyjaśnić co autor miał na myśli pisząc „opcja zapamiętaj hasło nie działa poprawnie”. Po rozmowie z analitykiem i Stasiem w końcu wie, jak to naprawić. Nie mniej stracił dodatkowy czas na ustalenie tego.
Została jeszcze kwestia błędu, którego się nie udało powtórzyć. Poszedł do Stasia, poprosił o pokazanie mu tego błędu. Staś pewny siebie usiadł, zaczął odtwarzać błąd, który tym razem się nie pojawił … sam QA był zaskoczony? Dlaczego tak się stało? O prawdopodobnych przyczynach tej sytuacji i popełnionych przez QA błędach opowiem poniżej.
Błędy popełniane przy zgłaszaniu bugów
Nie wiem, nie jestem pewny – lepiej tego nie ruszać
Częsty błąd popełniany przez testerów z małym doświadczeniem. Często widzą coś co ich niepokoi, co im się nie podoba, ale nie zgłaszają tego, ba nawet nie podejdą do innego QA, analityka czy nawet programisty i nie zapytają czy tak faktycznie powinno to działać. Z doświadczenia wiem, że lepiej jest coś zgłosić niż miało by to umknąć. Warto zawsze uczulać mniej doświadczonych testerów na potrzebę eskalowania takich przypadków.
Mało precyzyjne opisy notek
Staś popełnił kardynalny błąd – nie przyłożył się do opisu notki. Przez co potem programista miał problem z odtworzeniem błędu czy zrozumieniem o co chodzi w tym błędzie. Jestem zwolenniczką stosowania szablonu notek. Osobiście używam dwóch – do tworzenia notki oraz do zamykania notki (weryfikacja błędu).
A jak sobie z tym w takim razie radzić?
Szablon tworzonej notki
Notka opisująca zaobserwowany błąd powinna zawierać informacje takie jak:
– Datę obserwacji, numer wersji na jakiej zaobserwowano błąd, commit itp. – coś co pozwala zidentyfikować wersję
– Typ i wersję przeglądarki lub systemu operacyjnego, jeśli testujemy aplikację desktopową
– Opis błędu – czyli co zostało zaobserwowane
– Kroki do odtworzenia błędu – wypunktowane kroki
– Aktualny rezultat – czyli co aktualnie się dzieje po wykonanych krokach
– Spodziewany rezultat – czyli jaki powinien być rezultat po wykonanych krokach
Dodatkowo nie można zapominać o dodaniu warunków wstępnych czy użytych danych testowych (które często podaję w krokach do odtworzenia błędu). Czasami zdarza się tak, że błąd nie jest zawsze reprodukowany z jakiegoś powodu. Np. na 3 na 5 prób udaje się go odtworzyć. Taka informacja też powinna znaleźć się w notce.
Jeśli dysponujemy zrzutami ekranu, logami czy nawet filmami video z odtworzenia błędu – warto je załączać do notki bądź w notce wskazać linka do plików.
Do tego dochodzą aspekty takie jak nadanie notce priorytetu, które to zwykle systemy bugtrackingowe niejako same na nas wymuszają.
Gdy taką notkę, dobrze opisaną, dostanie programista – z pewnością ryzyko, że nie będzie wiedział o co chodzi będzie mniejsze.
Podobnego szablonu używam, gdy weryfikuję (zamykam) notkę. Dlaczego? Ponieważ jest to dodatkowy ślad w historii co zostało przetestowane i w której wersji.
Szablon weryfikacji notki
Notka weryfikacyjna może zawierać następujące informacje:
– Data weryfikacji, wersja na jakiej przeprowadzana jest weryfikacja
– Typ i wersja przeglądarki lub systemu operacyjnego
– Kroki weryfikacji, bądź krótki opis tego co zostało przetestowane
– Podsumowanie zawierające wynik testów czy test przeszedł czy nie. Jeśli nie – to, dlaczego i co powinno zostać naprawione.
Dzięki takiemu komentarzowi przy zamykaniu notki wiadomo co i jak zostało przetestowane. Dlaczego notka została zamknięta lub w drugą stronę, dlaczego została odbita. Przy konieczności ponownej poprawy – programista znowu ma jasną informację co poszło nie tak i co powinno zostać naprawione. Dzięki precyzyjnej identyfikacji wersji – jest w stanie u siebie odtworzyć tą samą wersję.
Notka śmietnik
Muszę się przyznać, że kiedyś sama czasem miałam tendencje do tworzenia takich notek. W notkach było mydło i powidło. Testowałam daną historyjkę i potem w odniesieniu do niego tworzyłam notkę i szłam do programisty z uśmiechem prosząc o fix. Wynikało to z faktu, że chciałam by wszystko było razem naprawione i super działało. To jest zła praktyka. Każdy błąd ma inny priorytet. Dzięki rozbiciu błędów według zasady 1 błąd 1 notka możemy zdecydowanie precyzyjniej a na pewno czytelniej opisać to co zaobserwowaliśmy. Staś, zgrupował wszystkie błędy razem niezależnie od priorytetu. Praca nad notką zajęła Ryszardowi dużo czasu. Nie podzielił tego na mniejsze kawałki, a przez to, że notka nie była precyzyjna – tracił czas na doprecyzowanie jej zamiast skupić się na poprawie błędów.
Brak ponownego sprawdzenia błędu
Czasami ciesząc się, że został znaleziony błąd – z rozpędu jest tworzona notka. Stwórz, dodaj super jest notka dodana zamykamy sprawę aż do momentu, gdy notka nie trafi na ponowne testy. A w ten sposób może ona trafić szybciej niż się nam wydaje i wcale nie z fixem ale ze statusem „Cannot reproduce”. Dlatego tak ważne jest upewnienie się, że błąd jest reprodukowany. Często w opisie notki brakuje jakiegoś detalu, który czasem dla QA jest oczywisty, ale powoduje, że programista nie jest w stanie tego błędu odtworzyć. Czasami sam tester po czasie nie jest w stanie zgłoszonego błędu przez siebie odtworzyć. A to już jest sygnał alarmowy. Dlatego tak ważne jest ponowne sprawdzenie czy aby na pewno jest to reprodukowane.
Przykład z życia wzięty – aplikacje mobilne – został zgłoszony błąd w aplikacji – nie działa obrót ekranu. Przychodzi programista do QA – że nie potrafi odtworzyć błędu – tester pokazuje na swoim urządzeniu – patrz u mnie nie działa. No faktycznie a u mnie działa i też pokazuje – faktycznie działa. Co było przyczyną takich rozbieżności – wersja systemu operacyjnego. Programista miał system po aktualizacji – gdzie rotacja ekranu była inaczej obsługiwana. Dlatego w tym wypadku np. definicja system operacyjny Android 5.0 lub starszy sprawił, że nie było to dość jasno i precyzyjnie określone. A przez to, że nie zostało to sprawdzone ponownie np. na innym systemie – spowodowało to taki problem w komunikacji.
Podsumowanie
Powyższy przykład wydaje mi się jasno pokazał jaki wpływ ma projekt, komunikację w zespolę czy nawet organizacji zespołu ma jakość raportowania błędów. Źle zaraportowany błąd może mieć wpływ na estymacje błędu, poświęcony czas na odtworzenie błędu czy nawet na cały proces. Jeśli tester dobrze opisze notkę – programista bez problemu będzie wiedział co jest do zrobienia, z dużym prawdopodobieństwem natychmiast odtworzy błąd i go naprawi. Nie będzie musiał dopytywać o co chodzi i tym samym tracić cennego czasu.
Dlatego tak często podkreślam, że najważniejsza w zespole jest dobra komunikacja i organizacja. Gdy zespół nie potrafi ze sobą współpracować może to powodować masę konfliktów choćby na tle sytuacji, że notka jest źle opisana. Zawsze należy pamiętać, że gramy do jednej bramki. A tworzenie oprogramowania to praca zespołowa. Świadomość tego jak zgłaszać błędy – jest tylko i wyłącznie wiedzą, która może mieć pozytywny wpływ na projekt.
