Jakie są najczęstsze błędy testera oprogramowania i jak im zapobiec?

Testując oprogramowanie na obecność niechcianych błędów, paradoksalnie, sami często popełniamy ich co niemiara. Jednak najlepszą ochroną przed popełnianiem błędów, jest nauka na nich (a jeszcze lepiej - na cudzych) i świadomość ich występowania. Poniżej wymienionych jest kilka przykładów, które zdarzają się dość często i warto mieć je na uwadze.

Błąd nr 1: Niedokładność w opisywaniu znajdowanych bugów

Każda firma ma swoje standardy w temacie zgłaszania błędów. O ile zasady typu: “podaj tytuł zgłoszenia”, “środowisko testowe”, “warunki początkowe” nie sprawiają początkującym testerom oprogramowania wielu problemów, temat opisania procedury odtworzenia już nie jest taki oczywisty. Czasem robimy różne rzeczy odruchowo i nie przyjdzie nam do głowy opisanie danego punktu dokładniej. Zgłaszamy problem w oprogramowaniu, wiemy, że po drodze to deweloper będzie go interpretował, ale powinniśmy podejść do tematu jak najbardziej “maszynowo” i dokładnie.

Przykład: formularz kontaktowy. Zgłaszając błąd w opisie tego co się dzieje, podajemy “Wprowadzam nieprawidłowy adres mailowy i zatwierdzam formularz. Efekt - widzę thank-you page. Spodziewany efekt - widoczny błąd i informacja o konieczności podania prawidłowego adresu mailowego, formularz się nie wysyła”.

Na pierwszy rzut oka wiemy, co się dzieje. To my pisaliśmy ten tekst i wprowadzaliśmy dane - wszystko jest zrozumiałe. Jest tu jednak sporo nieścisłości:

• Nieprawidłowy adres, to znaczy jaki? Czy jest bez znaku @, czy może wpisane są same cyfry? Najlepiej sprecyzować, jakich danych się użyło.
• Fragment zatwierdzam formularz wydaje się być oczywisty, a jednak to także może powodować nieścisłość. Nacisnęliśmy przycisk wyślij, czy może użyliśmy klawisza enter? Wbrew pozorom takie drobnostki mają wpływ na to, czy deweloperowi uda się odtworzyć błąd i zająć jego naprawą.

Nieścisłości prowadzą do tzw. zabawy w ping-ponga. Task jest odbijany od osoby do osoby, budżet jest przepalany na dyskusje i pytania, zamiast na pracę nad problemem.

Błąd nr 2: Testowanie bez znajomości aplikacji

Dostajemy ticketa o tytule strona Blog. Brak opisu, projekt jest nowy, więc nic o nim nie słyszeliśmy, budżet jest bardzo mały, a dodatkowo z powodu założenia “to prosty projekt, szkoda budżetu na dokumentację”, nie mamy się czym posiłkować. W komentarzu widzimy jeden screen z projektu graficznego. Otwieramy zatem projekt i działamy według własnego "widzimisię". Rozpisujemy przypadki i działamy, opierając się na własnym doświadczeniu - przecież chcemy dobrze i mamy głowę na karku. Co może pójść nie tak?

Po rozpisaniu znalezionych defektów okazuje się, że nic nie jest takie, jakie się wydawało. Element X został usunięty, zgodnie z rozmową z klientem sprzed tygodnia, a funkcjonalność Y została rozszerzona. Natomiast wersja mobilna ma odwróconą kolorystykę, ponieważ w ten sposób lepiej się prezentuje. Dodatkowo paragraf Z będzie wdrożony w następnym sprincie, więc na ten element kompletnie nie powinniśmy byli patrzeć.

Abstrahując od faktu, że taka sytuacja w ogóle nie powinna mieć miejsca i tester powinien brać udział w początkowych spotkaniach i dokonywać testów akceptacyjnych, przez domyślanie się czegoś możemy doprowadzić do generowania zbędnych ticketów. Jeśli nie jesteśmy pewni, jak coś powinno działać lub, tak jak w powyższym przypadku, nie mamy nawet opisu wykonanego zadania, natychmiast zwracamy taska deweloperowi, team leadowi, project managerowi lub product ownerowi (w zależności od przepływu pracy w projekcie). W komentarzu powinniśmy poprosić o rozpisanie tego, co faktycznie zostało zrobione w zadaniu. Nie należy interpretować projektu. Jeśli coś nie jest jasne - dopytujemy. W takim przypadku uzyskamy odpowiedzi od razu albo najczęściej kierowanym do nas stwierdzeniem będzie “w sumie dobre pytanie”. Jednak w obu sytuacjach unikniemy straty czasu, co przekłada się na sprawność dowiezienia projektu.

Błąd nr 3: Pisanie testów automatycznych

Ilość błędów popełnianych przez testerów oprogramowania w temacie pisania automatów zasługuje na osobny artykuł. Tutaj jednak zaznaczymy jeden z nich, nagminny u osób, które dopiero zaczęły pisać skrypty. Smutnym trendem początkujących testerów automatyczych jest pisanie testów z myślą, żeby przeszły pozytywnie i działały, a także, żeby było ich jak najwięcej. Więcej asercji oznacza przecież więcej testów i zadowolenie klienta lub product ownera, ponieważ wszystko pięknie wychodzi na raportach.

W pewnym momencie istnieje ryzyko, że skupiając się na tym, żeby automaty pokrywały jak najwięcej modułów, zapomnimy o podejściu twórczym w naszych testach. Zaczynamy nastawiać się bardziej na to, żeby testy przechodziły, niż żeby faktycznie testowały nasz projekt. Świadomość tego ryzyka i dobre planowanie testów pomaga rozwiązać ten problem. Dobrze jest także łączyć testowanie automatyczne z manualnym tam, gdzie wiemy, że automaty pokrywają, na przykład, tylko testy dymne.

Błąd nr 4: Popadanie w rutynę

Wiele osób jest znużonych testowaniem po raz kolejny tego samego, a nie zawsze wszystko można łatwo zautomatyzować. W takich sytuacjach możemy kilkukrotnie sprawdzać jedną funkcjonalność systemu. Niestety bez porządnie napisanych scenariuszy testowych, z każdą kolejną próbą tracimy “wenę” do tworzenia skomplikowanych testów. Pojawia się założenie, że skoro coś “zawsze działało” to przecież już nie trzeba tego sprawdzać. Takie podejście bywa zgubne. Tester powinien być odporny na rutynę. Fakt, że coś przeszło test ileś razy, nie znaczy że kolejny raz także przejdzie. Dokładność i sumienność to cechy bardzo ważne w tym zawodzie.

Błąd nr 5: Nadmierna ufność zespołowi i brak asertywności

Jakkolwiek kontrowersyjnie to brzmi - tester oprogramowania nie może ufać komuś całkowicie na słowo. Wiele razy słyszeliśmy, że bug został poprawiony i możemy wysłać produkt do klienta. Czasem spotykamy też określenie, że lokalnie deweloperowi wszystko działa poprawnie, więc problemy mogą wynikać z samego środowiska testerskiego i na staggingu na pewno nie wystąpią. Jeśli niedoświadczony tester spotka się z takim podejściem, istnieje ryzyko, że ulegnie i faktycznie będzie pozwalał, żeby takie sytuacje miały miejsce. Musi jednak wiedzieć, że asertywność jest w tym zawodzie bardzo ważna.

Zdarza się, że programista nie poprawi błędu i powie, że to zrobił. Jednak czasami tester nie jest postrzegany jako osoba, która pomaga w możliwości poprawy danego programu, a widzi się go bardziej jako kogoś, kto się "czepia". Z drugiej strony należy jednak pamiętać, że jeśli nie znamy projektu wystarczająco, deweloperzy mogą mieć rację, mówiąc słynne hasło: “to nie bug, to feature”.

Błąd nr 6: Komunikacja z zespołem

Tester nie jest osobą, która “wytyka błędy”. W testowaniu chodzi o dbałość o jakość oprogramowania (całym zespołem, nie jednostkowo) poprzez weryfikację jego zgodności z projektem. Oczywiście, że świat byłby piękniejszy, gdyby tester udowadniał tylko, że wszystko działa w 100% dobrze, bez żadnych zwrotek, a bugi nie występowałyby w ani jednym fragmencie programu. Marzenia marzeniami, a świat światem - błędy były, są i będą. Co więcej zdarzają się one nawet w projektach pisanych przez najbardziej doświadczonych seniorów. Znalezienie defektu i zgłoszenie go nie jest jednoznaczne z atakiem na programistę. Odpowiednia komunikacja z zespołem jest bardzo ważna, zarówno podczas pracy z doświadczonymi programistami jak i juniorami. Bugi nie są niczyją winą i należy unikać niepotrzebnych emocji oraz pejoratywnych słów w naszym zgłoszeniu i rozmowie.

Błąd nr 7: Nieświadomość specyfiki zawodu

Nie każdy zostanie porządnym testerem, tak jak nie każdy będzie wybitnym cukiernikiem, dekarzem czy bankierem. Pomijając cechy i umiejętności, jak np. dokładność, skrupulatność, spostrzegawczość, należy nastawić się na konieczność ciągłego rozwoju, pracy nad sobą i zdobywania wiedzy. Bez poszerzania wiedzy, zarówno odnośnie działania i tworzenia oprogramowania jak i nowinek technicznych i rozwiązań stricte do testów, nie osiągnie się sukcesu w testowaniu. Czy to oznacza, że należy porzucić wizję pracy jako tester oprogramowania? Bynajmniej! Po prostu wybierając ten zawód, należy mieć świadomość tego co nas czeka i że nie zawsze będzie łatwo.

Błędy popełniane przez testerów - podsumowanie

Błędy popełniamy wszyscy. Gdyby tak nie było, przyznajmy szczerze, praca testera także straciłaby na znaczeniu. Należy z nich jednak wyciągać wnioski i pilnować się, żeby nie popełniać tych samych błędów cyklicznie. Dobrym momentem w pracy, na taki “rachunek sumienia” są scrumowe retrospektywy. Wtedy cały zespół może przeanalizować określone działania i wyłapać momenty, w których mógł pracować lepiej. Warto wykorzystać ten czas, ale nie należy panikować i próbować poprawiać wszystkiego naraz. Polecamy ustalenie sobie jasnych celów polepszenia danego aspektu.

​