Redakcja
Wyobraź sobie następujące scenariusze, w których Twoim zadaniem jest całościowa ocena jakości produktu:
- Jesteś pierwszą osobą, która testuje dany produkt / jesteś pierwszym testerem w projekcie i podczas testów znajdujesz defekty, które nie wynikają z ostatnio wprowadzonych zmian.
- Oferujesz usługę testowania oprogramowania i wygrałeś przetarg na sprawdzenie jakości danego produktu.
Aby uczynić pracę jeszcze trudniejszą, załóżmy, że oprogramowanie ma jedynie wysokopoziomowe założenia biznesowe, ale nie ma aktualnych wymagań. Nie ma też żadnej osoby, którą możesz zapytać, jak oprogramowanie ma działać. W praktyce zapewne taka osoba by była, ale nie miałaby dla Ciebie czasu, albo jej odpowiedzi nie stanowiłyby jednoznacznie o tym, jak oprogramowanie ma działać.
Co możesz zrobić w takiej sytuacji? Oczywiście odpowiedź, że przetestujesz wszystko przy pomocy eksploracji jest oczywista, jednak jak ułożyć swoją pracę, aby miała ona ręce i nogi?
Oto propozycja.
0. Znajdź odbiorcę Twojej pracy
Coś, co wydaje się być oczywiste, nie zawsze takie jest. Jeśli decydujesz się na przygotowanie całościowego raportu jakości oprogramowania, potrzebujesz jasno określonego odbiorcę. Taka osoba jest nam potrzebna, aby nie tylko formalnie przyjąć od nas raport z prac, ale żeby wykorzystać pozyskane od nas informacje do dalszych prac.
1. Zinwentaryzuj wszystkie dostępne informacje
O przydatnej w takiej sytuacji heurystyce SMILGIN pisaliśmy tutaj.
Nie przejmuj się, że informacje mogą być lub też są nieaktualne, mało znaczące lub bez pewności, czy są ważne. Nauka oprogramowania ma na celu poznawać je, a w procesie poznania niekoniecznie zbieramy tylko wartościowe dane. Próbujemy tu czepiać się każdego skrawka dostępnej informacji.
2. Zaplanuj testy
W oparciu o informacje z punktu 1. zaplanuj co i jak będziesz testować. Nie ma opcji, abyś nie miał(a) niczego. Na końcu masz software i możesz w tym miejscu przejść do punktu 3.
3. Uruchom oprogramowanie
Sprawdź czy i jak działa. Wykonaj tzw. testowanie powierzchowne zbliżone do testowania dymnego. Polega ono na tym, że zamiast testować wszystko dogłębnie, starasz się próbkować oprogramowanie w wielu miejscach, próbując "dotknąć" każdą funkcję przynajmniej raz. W przeciwieństwie do testowania dymnego nie zatrzymasz się tylko na najważniejszych funkcjach i tylko na wysokopoziomowych uruchomieniach, ale postarasz się wywołać funkcje również na niższym poziomach. Przykładowo, w heurystyce CRUD nie tylko sprawdzisz możliwość stworzenia rekordu danych, ale również możliwość jego odczytania, wyedytowania i usunięcia. Przy czym wykonuj jedynie testy pozytywne.
Postaraj się wypisać wszystkie funkcje, zastanów się nad wspieranymi środowiskami, rozważ, co potrzebujesz, by w pełni przetestować oprogramowanie (np. jakiś dodatkowy sprzęt, dostęp do innego systemu itd.).
Kroki 2 i 3 powtórz aż do uzyskania obrazu co i jak testować.
4. Uruchom test run
Zbierz wszystkie informacje wśród których powinny znaleźć się:
- co oczywiście działa,
- co oczywiście nie działa,
- co wdaje Ci się, że działa,
- co wydaje Ci się, że nie działa,
- oczywiste defekty,
- wątpliwe defekty,
- sugestie.
Dodatkowo spisz czas, jaki poświęcasz na poszczególne obszary funkcjonalne.
5. Przygotuj raport
W najprostszej wersji będziesz miał(a) wypełnioną po brzegi bazę zgłoszeń z nowymi defektami oraz sugestiami poprawy. W wersji rozbudowanej powstanie raport, który całościowo pokaże jakość oprogramowania.
Raport taki często będzie stanowić podstawę do rozmowy w projekcie o tym, co jest, a co nie jest defektem; co działa, a co nie działa. Żaden ze stworzonych raportów defektów nie będzie marnowaniem czasu. Przykładowo, defekt ze statusem "Work as designed" (lub podobnym) będzie nośnikiem wiedzy dla innych członków zespołu o tym, jak coś ma się zachowywać.
Pozbierane metryki możesz użyć zarówno do oceny jakości oprogramowania, jak i do oceny własnej pracy.
Po takich działaniach masz obraz jakości produktu. Ze względu na nieskończoność testowania nie będzie on w 100% całościowy, ale będzie ważnym kamieniem milowym w projekcie. Do tego raportu i do tego stanu wiedzy o oprogramowania możesz się odnosić w przyszłości, pokazując np. co się zmieniło.
