7 najczęstszych błędów testerów
Warto uczyć się na błędach - najlepiej na cudzych. Sprawdź, jakie wpadki popełniają testerzy oprogramowania.
1. Brak planowania testów
Zaczynamy od braku planowania testów. Jeśli nie przygotujemy się należycie do sprawdzenia aplikacji (nawet w najprostszy sposób, choćby poprzez checklistę), istnieje duże prawdopodobieństwo, że przeoczymy pewne funkcje, co skutkuje niedokładnymi testami i może doprowadzić do pominięcia potencjalnych błędów. A tego byśmy nie chcieli, prawda? W szczególności, że czasami cena błędu może być wysoka.
Dlatego ważne jest, aby przed przystąpieniem do testowania, przeanalizować, które części oprogramowania muszą być sprawdzone i jakie ścieżki należy przetestować. To pomoże nam w określeniu, gdzie mogą pojawić się ewentualne problemy.
2. Testowanie tylko happy path
3. Nieprecyzyjne zgłaszanie błędów
Następnym problemem jest nieprecyzyjne zgłaszanie błędów. A dlaczego jest to tak istotne? Bo nieprecyzyjnie zgłoszony błąd jest po prostu stratą czasu. Programista otrzymujący niedokładny opis marnuje czas na próbę odtworzenia błędu, a i tak często musi zwrócić się do testera, by ten wyjaśnił mu problem. Tak więc zarówno programista, jak i tester muszą na to poświęcić dodatkową pracę.
Pamiętajcie, że opis błędu powinien ułatwiać jego zrozumienie. Dodajcie informacje, w jakim środowisku odkryliście problem (urzędzenie, system, przeglądarka, środowisko testowe czy produkcyjne) i wypunktujcie, jak kroku po kroku odtworzyć dany błąd. Warto też umieścić zrzuty ekranu, filmiki czy logi z konsoli. Temat ten został szerzej opisany w osobnym wpisie - jak zgłaszać błędy?.
4. Odkładanie zgłaszania błędów na później
Pozostańmy jeszcze chwilę przy błędach. Często zdarza się, że testerzy znajdują błąd, ale nie raportują go od razu. Zamiast tego decydują się zrobić to później, by nie przerywać testów. Jednak taka praktyka może prowadzić do zapomnienia szczegółów i nieprecyzyjnego opisu błędu, co jak już wiecie, utrudnia pracę i marnuje czas. Oczywiście, nie zachęcam Was do spamowania programistom o każdym problemie. Po prostu zapisujcie na bieżąco detale znalezionych błędów.
5. Brak wiedzy domenowej
Całkowite pominięcie wiedzy domenowej to częsty błąd wśród testerów oprogramowania. Umiejętności techniczne to nie wszystko - ważne jest również zrozumienie branży, w której działa aplikacja. Testując na przykład aplikację księgową, warto choćby wiedzieć, czym jest amortyzacja. Wiadomo, nie chodzi mi o zostanie ekspertem w danej dziedzinie, ale podstawowa wiedza domenowa znacząco ułatwia przeprowadzanie efektywnych testów.
6. Nadmierne zaufanie
Kolejną kwestią jest ograniczanie się do testowania tylko optymistycznych scenariuszy, czyli tzw. ścieżek happy path. Niestety, czasami po otrzymaniu wymagań czy opisu danej funkcji, testerzy skupiają się jedynie na najbardziej podstawowych przypadkach. Na przykład, jeśli aplikacja ma konwertować plik .jpg na .pdf, sprawdzamy jedynie, czy operacja przebiega pomyślnie, nie sprawdzając, jak aplikacja zachowa się po próbie konwersji pliku tekstowego. Takie podejście jest niewłaściwe i może prowadzić do przeoczenia wielu błędów - uwierzcie, potem zostaną one odkryte przez użytkowników.
Nie twierdzę, że musicie od razu przygotowywać rozbudowane scenariusze testowe (zresztą, na blogu wspominałem, że przypadki testowe to nie zawsze najlepsze rozwiązanie), ale zastanówcie się, co w danej aplikacji można zrobić odbiegając od podstawowych ścieżek użycia. Pomyślcie, jak klient mógłby klikać po oprogramowaniu i jakie czynności mógłby w nim wykonać.
W myśl zasady, że najlepiej uczyć się na cudzych błędach, przygotowałem dla Was listę najczęściej spotykanych potknięć u testerów oprogramowania. Dotyczy to głównie początkujących, ale i profesjonalistom zdarza się zaliczyć wpadkę. Będąc świadomym niektórych problemów, łatwiej ich unikniecie, co naturalnie sprawi, że staniecie się lepszymi testerami. Wiem o czym mówię, bo sam niejednokrotnie popełniałem poniższe błędy.
Kolejnym zagrożeniem jest nadmierne zaufanie. Jako testerzy często spotykamy się z sytuacją, w której programista zapewnia nas (u mnie działa!), że pewien błąd już nie występuje. W takich sytuacjach musimy być asertywni i upewnić się, że dany element został dokładnie sprawdzony, nawet jeśli ktoś twierdzi, że to tylko niewielka zmiana w kodzie.
7. Nieodpowiednia komunikacja
Na koniec pozostała nieodpowiednia komunikacja w zespole. Najważniejszą zasadą jest nieobwinianie innych osób pracujących przy danym projekcie. Nigdy nie wskazujcie palcem na programistę, że to przecież on pisał kod i dlatego w aplikacji pojawił się błąd. Wszelkie defekty musicie zgłaszać bezosobowo. Oczywiście, na to samo powinniście liczyć z drugiej strony. Mam nadzieję, że nigdy nie traficie na sytuację, w której zostaniecie obwinieni o pominięcie jakiegoś buga. Pamiętajcie - za jakość oprogramowania odpowiada cały zespół, a nie tylko testerzy oprogramowania.
To wszystko na dziś. Proszę, weźcie sobie do serca opisane problemy. Po co powtarzać przetarte już błędy? Wystarczy, że ja je popełniałem 😅
Chcesz być na bieżąco?
Zapisz się do mojego newslettera i otrzymuj wiadomości o nowych wpisach. Przy okazji dorzucę też ciekawe artykuły ze świata IT :)
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
