Testy potwierdzające i regresyjne – jak przebiegają w praktyce?

Dobrze opisany bug

Nie ma aplikacji idealnej – w każdej można znaleźć błąd, defekt. Wyobraź sobie, że jesteś  testerem manualnym i sprawdzasz poprawność tworzenia przesyłki dla firmy kurierskiej na podstawie formularza. Trzeba w nim wypełnić ręcznie najważniejsze pola: dane nadawcy, dane odbiorcy, numer telefonu, wybrać rozmiar przesyłki, a na końcu kliknąć w przycisk “Zapisz”. Nagle okazuje się, że po zapisaniu nowa przesyłka nie pojawia się na liście i trzeba zgłosić – jak lubią mówić wszyscy testerzy – buga.

Jak poprawnie opisać defekt?

1. Środowisko

W zależności od projektu może być przydatny cały adres URL danego środowiska, na którym testujemy aplikację lub sama jego nazwa, żeby wiedzieć, gdzie należy szukać przyczyny. Jest to ważne, bo zazwyczaj występuje nawet kilka środowisk, na których można wykonywać testy.

2. Użytkownik

Trzeba podać nazwę użytkownika oraz funkcję (rolę), jaką pełni podczas tworzenia aplikacji.  Z reguły są to różni użytkownicy, z określonym zakresem czynności do wykonania.

3. Kroki do reprodukcji

Należy opisać (najlepiej w punktach) wszystkie czynności, które zostały wykonane aż do pojawienia się błędu. Opis tych kroków jest niezwykle istotny: załóżmy, że bug dotyczy na przykład tylko największych rozmiarów przesyłek. Bez podania tej informacji byłyby sprawdzane wszystkie możliwe opcje i w efekcie developer, zajmujący się naprawą tego błędu, niepotrzebnie straciłby czas.

4. Rezultat

Następnie trzeba zapisać wynik, który pojawił się w aplikacji po wykonaniu kroków potrzebnych do reprodukcji, np. “‘Formularz tworzenia przesyłki został zamknięty. Przesyłka nie pojawia się na liście”.

5. Oczekiwany rezultat

Bardzo ważne jest, aby określić, jak powinna poprawnie zadziałać testowana funkcjonalność po wykonaniu kroków, np. “Formularz tworzenia przesyłki został zamknięty. Pojawia się nowa przesyłka z numerem ID na liście”.

6. Dowód błędu

Dowodem na to, że dany błąd występuje, jest screen lub filmik z wykonanego testu manualnego. Jeśli błąd nie zawiera dużej ilości kroków, screen przedstawiający końcowy wynik z zaznaczeniem najważniejszych informacji w zupełności wystarczy. Osobiście polecam narzędzie “Screenpresso”, które w łatwy sposób pozwala na zrobienie poprawnego zrzutu z ekranu. Gdy bug jest bardziej skomplikowany, nagrywam filmik, dzięki czemu niczego nie pominę. Do tworzenia filmików z testów używam narzędzia “Snagit” –  jest płatne, ale według mnie, warto w nie zainwestować.

Warto też zamieścić informacje (logs) z konsoli przeglądarki (web console), która jest jednym z narzędzi developerskich. Logi pozwalają programiście szybciej znaleźć przyczynę defektu. Konsolę można w łatwy sposób włączyć/wyłączyć, korzystając z przycisku F12. Kiedyś najczęściej korzystałem z rozszerzenia “Firebug” do Mozilli Firefox, ale odkąd nie jest już rozwijane, używam web console z Google Chrome.

7. Priorytet

Znalezione przez testera błędy mają różny charakter i w różny sposób wpływają na działanie aplikacji. W większości narzędzi do zarządzania testami do określenia poziomu ważności zgłoszenia służy pole o nazwie priority z rozwijaną listą do wyboru. Zazwyczaj uwzględnia ona trzy poziomy: niski, średni i wysoki. Na tej podstawie ustala się odpowiednią kolejkę napraw bugów.

Na przykładzie naszego formularza tworzenia przesyłki możemy wyjaśnić, jak ocenić defekty według tych 3 kategorii.

• Niski – zgłoszenia, które mają znikomy wpływ na działanie aplikacji i często dotyczą drobnych zmian wizualnych, literówek itp. Przykład – zła nazwa formularza do tworzenia przesyłki.
• Średni – kategoria dla błędów, które mocno utrudniają działanie aplikacji, ale pozwalają nam na dalsze testowanie. Przykład – brak widocznego pola danych nadawcy na liście przesyłek.
• Wysoki – są to bugi, które blokują nam testy i uniemożliwiają dalsze sprawdzanie działania produktu. Przykład – brak nowej przesyłki na liście przesyłek.

Zdarza się, że pole priority nie jest dostępne. W takich sytuacjach radziłem sobie, dodając taką kategorię na końcu nazwy zgłoszenia albo ustawiając kolory, np. niski = kolor zielony, średni = kolor żółty i wysoki = kolor czerwony.

W jednym z projektów spotkałem się z podziałem na pola priority i severity. Pole priority dotyczyło priorytetu naprawy przez developerów (zarządzał tym manager projektu), a pole severity – wpływu błędu na działanie aplikacji (wypełniał je tester tworzący zgłoszenie błędu).

8. Etykieta (label)

Często w narzędziach do zarządzania testami znajduje się pole label, jak np. w bardzo popularnej Jirze. Jest to etykieta ułatwiająca filtrowanie, sortowanie błędów itd. W tym polu – w zależności od projektu – można dodać takie określenia, jak: nazwa sprintu (gdy pracujemy w metodyce Agile), numer releasu, nazwa fazy testów, w której został znaleziony defekt, a także – przy większych projektach – wyjaśnienie czy błąd jest funkcjonalny, czy dotyczy złych danych.

Obraz – Proces testów manualnych.

Testy potwierdzające jako podstawa sprawdzania

Po zgłoszeniu błędu i otrzymaniu informacji, że został naprawiony, możemy przystąpić do wykonania tzw. testu potwierdzającego. Aby go poprawnie przeprowadzić, należy wybrać to samo środowisko i tego samego użytkownika oraz wykonać kroki reprodukcyjne opisane w zgłoszeniu. Test obejmuje tylko zakres opisany w bugu, nie rozszerzamy go.
Po poprawnym wykonaniu testu i pojawieniu się oczekiwanego rezultatu w aplikacji, zamieszczamy screen/filmik i dodajemy komentarz do zgłoszenia. Po wykonaniu tych czynności możemy uznać, że błąd został naprawiony i zamknąć zgłoszenie.

Moim zdaniem, warto pamiętać o dodaniu komentarza oraz zrzutu z ekranu/filmiku z re-testu. W jednym z projektów, w których brałem udział, testy manualne bez takich informacji były traktowane jako nieważne.

Testy regresyjne – znalezienie nowych błędów

Wszystkie testy manualne sprawdzające, czy ostatnie poprawki nie naruszyły dotychczas prawidłowo działających obszarów produktu, zaliczane są do testów regresyjnych. Testy regresyjne (nazywane też regresywnymi) są idealną okazją do znalezienia nowych defektów w aplikacji.

Dobrym przykładem będzie sytuacja, gdy po sprawdzeniu, że nowa przesyłka pojawia się na liście i zamknięciu zgłoszenia, wykonujemy również test opcji anulowania formularza do tworzenia takiej przesyłki (przed zgłoszeniem błędu działało to poprawnie). Po przeprowadzeniu testu okazuje się, że formularza nie da się anulować i okno w aplikacji nadal jest otwarte. To powód, dla którego warto przeprowadzać tego rodzaju testy. Z doświadczenia wiem, że często gdy poprawia się daną funkcjonalność, można łatwo uszkodzić powiązane z nią inne obszary produktu.

W zależności od wielkości projektu testy regresyjne można przeprowadzać w różny sposób. Gdy aplikacja nie jest rozbudowana, najlepiej zrobić listę jej najważniejszych obszarów przy użyciu tzw. słów kluczowych, np: tworzenie przesyłki, anulowanie przesyłki itp. i po każdym zamknięciu błędu wykonywać takie testy. W przypadku dużej aplikacji, gdy tych obszarów jest więcej i nie wystarczy czasu na sprawdzenie wszystkich, najlepiej ustalić z osobą prowadzącą projekt, co ma najwyższy priorytet. Wówczas można dostosować się do potrzeb i przeprowadzić tylko te testy regresyjne, które są najpilniejsze.

Podsumowując – od zakresu wykonanych testów manualnych zależy, czy zaliczamy je do  potwierdzających czy regresyjnych. Oczywiście trzeba pamiętać, że poprawnie opisany defekt to podstawa dobrej współpracy między testerem, a developerem. Dzięki temu  szanujemy swój czas i nie tracimy go na dodatkowe ustalenia wynikające ze złego opisu zgłoszenia.

Mam nadzieję, że moje wskazówki okażą się przydatne i pomogą Wam udoskonalić  opisywanie zgłoszeń błędów w aplikacji, a co za tym idzie – lepiej rozróżniać testy  potwierdzające i regresyjne.