Każdy napisany fragment kodu, każda aplikacja, gra, usługa, które zostały przeznaczone do powszechnego użytku powinny zostać przetestowane. Każdy programista stanął nieraz przed zadaniem, które polegało na poprawie istniejących już funkcjonalności. Zapewne niejednokrotnie otrzymał raport błędu brzmiący: “XYZ nie działa.” Brakowało w nim informacji, sensownego opisu lub prawdziwych danych.

Chcę Was dziś przekonać, że w pracy testera bardzo ważne są zdolności “miękkie”, sposób porozumiewania się z innymi oraz przekazywania informacji. W 7. i 8. punkcie dekalogu testera zajmę się komunikacją oraz poprawnym raportowaniem błędów.  

#7 Komunikacja 

„Jestem dobrym testerem, bo potrafię znaleźć błędy.” To zdanie powinno brzmieć inaczej: „Jestem dobrym testerem, bo potrafię w jasny i poprawny sposób zgłosić znalezione błędy.” Dla testera jasna i precyzyjna komunikacja oraz poprawne raportowanie znalezionych defektów to chleb powszedni. Sama wielokrotnie w ciągu dnia komunikuję się z koleżankami i kolegami programistami, aby wspomóc ich w dostarczaniu oprogramowania jak najwyższej jakości. Dzięki temu, że zgłaszam błędy we właściwy sposób, deweloperzy mogą zaoszczędzić sporo czasu i wysiłku potrzebnego na ich naprawianie. 

Praca testera to nie tylko pilnowanie jakości i ciągłe sprawdzenie zgodności wymagań. To także praca z ludźmi o różnych typach osobowości i charakterach. Tester musi zdawać sobie sprawę, że prędzej czy później będzie musiał poinformować zespół, że coś nie działa. I że ludzie będą reagować na informacje o błędzie w różny sposób. „Błądzić jest rzeczą ludzką” jednak niektórzy mogą poczuć się dotknięci, skrytykowani lub wziąć taką informację bardzo do siebie. Inni mogą dojść do wniosku, że nie będą wykonywać poleceń testera i zareagują w inny, nieprzewidywalny sposób. Jeszcze inni potraktują to jako kolejne zadanie do wykonania. Będąc testerem, nie unikniesz konfrontacji, gdy przynosisz “złe wieści”. Jednak niezależnie od przyczyny wystąpienia błędu – zadaniem testera jest jego zgłoszenie.  

Aby uniknąć nieoczekiwanych sytuacji, skoncentruj się i opieraj jedynie na faktach. Przyjmij neutralny ton głosu. Nie obwiniaj nikogo i nie krytykuj. Jeśli znaleziony przez ciebie błąd powtarza się regularnie od dłuższego czasu, nie ubolewaj nad tym faktem, lecz porozmawiaj z programistami – może uda się wspólnie wypracować rozwiązanie. Staraj się swoimi wypowiedziami i zachowaniem wprowadzić ład i zapanować nad sytuacją, zamiast podgrzewać atmosferę. Prawidłowa komunikacja w zespole jest kluczem do sukcesu.  

#8 Prawidłowe zgłaszanie błędów 

Skuteczna komunikacja to także poprawne zgłaszanie defektów. Co z tego, że błąd został odnaleziony, jeśli tylko tester wie, gdzie występuje i jak go odtworzyć. Gdy programista musi zmierzyć się ze zgłoszonym problemem, powinien od razu po przeczytaniu opisu wiedzieć, na czym on polega. Jeśli musi prosić o więcej informacji, czy aby to tester pokazał, jak zreprodukować dany błąd, lub mówi, że błędu nie da się zreprodukować, oznacza to, że został on źle zgłoszony. W takiej sytuacji często więcej czasu traci się na próbę odtworzenia problemu niż jego faktyczną naprawę.

Pamiętaj, że raport/zgłoszenie jest dokumentacją, która pokazuje różnicę pomiędzy stanem oczekiwanym a obecnym i ma jak najskuteczniej pomóc programiście. Jak w takim razie powinien wyglądać dobrze przygotowany raport? 

Nadaj mu odpowiedni tytuł

Tytuł to pierwsza rzecz, jaką widzi programista otrzymujący raport. Ważne więc, by Twój tytuł: 

  • był jasny i zrozumiały dla wszystkich,
  • zawierał słowa kluczowe, dzięki czemu będzie można go skategoryzować lub przypisać do odpowiedniej osoby w projekcie (np. do mobile, backend, frontend dewelopera),
  • nie był ogólnikowy. Zamiast pisać: “Problem z zakupem”, napisz: “Problem z wyborem sposobu płatności w czasie zakupu jako zarejestrowany użytkownik”.

Opisz problem

To najważniejszy i najtrudniejszy element zgłaszania defektu. Im dokładniej opiszesz problem, tym większa szansa na jego skuteczną i szybką naprawę. 

Opis powinien zawierać następujące dane:

  • Wersję aplikacji oraz wersję i środowisko testowe, na jakim występuje problem,
  • Czas i datę wystąpienia błędu,
  • Warunki wstępne (cache, działające firewalle, aplikacje mogące mieć wpływ na testowaną funkcjonalność),• Oczekiwany i aktualny rezultat testu,
  • Testowe dane, które zostały użyte w teście,
  • Kroki do odtworzenia błędu opisane jak najbardziej szczegółowo, 
  • Przypuszczenia, wskazówki i wnioski, dlaczego błąd mógł wystąpić, na co ma lub może być wpływ oraz jak istotny jest to błąd.

Dodaj załączniki

Chińskie przysłowie mówi, że jeden obraz wart więcej niż tysiąc słów. Podobnie jest w przypadku raportowania błędów. Im więcej elementów wizualnych, które mogą naprowadzić programistę i wskazać mu drogą, tym lepiej. Ważne jest, aby były one adekwatne i faktycznie wyrażały wystarczająco dużo. 

Mogą to być:

  • Obrazki i zrzuty ekranu – korzystając z dowolnych programów graficznych, wskaż strzałką miejsce wystąpienia problemu na zdjęciu. Jeśli masz taką możliwość – pokaż, jak coś powinno wyglądać, a jak wygląda.
  • Wideo – za pomocą różnych narzędzi można nagrać krótki film z dźwiękiem lub bez. Jest to szczególnie przydatne w bardzo skomplikowanych ścieżkach. Film powinien prezentować cały proces wystąpienia błędu, a nie jedynie rezultat. Pamiętaj też, aby był on spójny z krokami spisanymi w opisie problemu. 
  • Pliki logów – w tym przypadku pamiętaj, aby dostarczać pliki w formacie najbardziej preferowanym przez programistów. 

Określ ważność i priorytet problemu 

Podczas zgłaszania błędu powinieneś stwierdzić, jak krytyczny jest on dla systemu oraz w jak szybkim czasie należy go naprawić. Ważność określa, jak duży wpływ na całość systemu będzie miał konkretny defekt i jakie wiążą się z nim konsekwencje. 

Błąd może być:

  • Krytyczny – awaria systemu, bloker, z dużym ryzykiem utraty danych
  • Ważny – niespełnione wymagania lub niepoprawne zaimplementowanie funkcjonalności 
  • Średni – mniejsze problemy systemu nie wpływające na bezpieczeństwo lub funkcjonowanie systemu
  • Niski – problemy nie mające wpływu na funkcjonowanie systemu, błędy kosmetyczne  

Z kolei priorytet określa, jak szybko błąd powinien zostać naprawiony:

  • Pilny
  • Z następnym wydaniem
  • Przy okazji 

Podsumowanie

Dobrze przygotowany raport błędu to podstawa pracy testera. Po znalezieniu problemu zanotuj go. Sprawdź czy odkryty problem istnieje naprawdę – zweryfikuj go. Nie bój się poświęcić więcej czasu na diagnozę błędu, pomyśl o przyczynach i przetestuj funkcjonalność “dookoła” – może znajdziesz coś jeszcze. Śmiało wpisuj swoje przypuszczenia i wnioski – dzięki temu część pracy programistów będzie już zrobiona. Poświęć chwilę na przeczytanie raportu i dokładne jego sprawdzenie. A potem najważniejsze – pamiętaj o ludziach i o tym, by we właściwy sposób zakomunikować znalezione usterki. Nie wyolbrzymiaj znaczenia błędu i nie wskazuj winnych. Problem zawsze dotyczy funkcjonalności, a nie twórcy tej funkcjonalności.  

***

Mam nadzieję, że przedstawione przeze mnie wskazówki i podpowiedzi pomogą Ci w codziennej pracy. Pozwolą skutecznie komunikować się z zespołem i sprawią, że praca stanie się przyjemniejsza i bardziej efektywna. 

Kolejna i ostatnia część dekalogu testera już wkrótce.  Jeśli chcesz przypomnieć sobie o czym pisałam w poprzednich odcinkach, czytaj część 1 i część 2. Jeżeli chcesz podzielić się własnymi doświadczeniami albo skomentować ten odcinek poradnika, zostaw komentarz. 

Software Tester at Aspire Systems Poland. Agile believer, following the Agile manifesto both in her professional and private life. Passionate about databases and IT project management.