Jeśli jesteś testerem oprogramowania, bądź pracujesz w działach zapewniania jakości oprogramowania, to być może zetknąłeś się już z dokumentem o opisowej nazwie „Plan Testów”. Tego typu dokumentację tworzy się zarówno w dużych, jak i małych firmach, formalnych, jak i mniej formalnych projektach. Chociaż ja sam, nie jestem fanem tworzenia rozdmuchanych dokumentacji – to właśnie Plan Testów jest tym wyjątkowym dokumentem, który warto, a nawet należy starannie wypracować.

Moje doświadczenie wyniesione z wielu firm i projektów – podpowiada mi, że warto poświęcić trochę czasu – nawet jego sporą ilość, na stworzenie tego rodzaju dokumentacji, gdyż na późniejszym etapie korzyści z tej pracy będą duże i wymierne. O jakich korzyściach mowa? Oczywiście mam na myśli, korzyści budżetowe, czyli oszczędność czasu i pieniędzy, a także korzyści wizerunkowe z dobrze przeprowadzonego procesu testowego.

Czym w ogóle jest Plan Testów?

Na początek formalna regułka:

Dobry Plan Testów obejmuje wszystkie fazy testowania w cyklu życia oprogramowania. Plan Testów tworzymy, aby zweryfikować produkt i jego zgodność z przyjętymi standardami.
Precyzyjnie spisane informacje, cele, zakresy, wymagania, role, harmonogramy – pomogą nam podczas procesu testowego uniknąć wielu problemów, takich jak niedomówienia, nieświadomość pracy, jaka jest do wykonania, niewłaściwie rozumiane role poszczególnych osób w projekcie, źle rozumiane założenia projektowe itp.

Wygląd oraz sama organizacja dokumentu mogą być różne w każdej firmie, czy projekcie – nie ma jednego właściwego wyglądu takiej dokumentacji. To, jakie informacje, sekcje, punkty, szczegóły zamieścimy w dokumencie, jest sprawą bardzo indywidualną, a wpływ na to może mieć wiele czynników, takich jak: polityka firmy, rodzaj projektu, aplikacji, metodologia pracy, wymagania projektowe, organizacja zespołu itp. Jednak tworząc i przeglądając dziesiątki Test Planów – śmiało mogę wskazać, co powinien zawierać dobry Plan Testów, a czego w nim lepiej nie umieszczać. Poniżej podzielę się z Wami tą wiedzą.

Kto powinien sporządzić Plan Testów?

Tego typu dokumentację zwykle tworzy lider zespołu testowego bądź kierownik działu testów. Jednak zdarza się, że takie zadanie otrzymuje po prostu najbardziej doświadczony, zaprawiony w bojach specjalista ds. testów. Oczywiście prace nad takim dokumentem są bardzo rozległe i będziemy potrzebować wielu szczegółowych informacji, dlatego zwykle w tworzenie takiego dokumentu jest zaangażowanych kilka osób.

Jakie korzyści uzyskamy, tworząc Plan Testów?

Mam nadzieję, że po tym krótki wstępie, mamy już świadomość, że Plan Testów w projekcie jest czymś pożądanym i oczekiwanym. Próby zaoszczędzenia czasu i zasobów na sporządzenie takiego dokumentu, mogą nas naprawdę dużo kosztować. Na potwierdzenie tej tezy, poniżej wypisze kilka moim zdaniem największych korzyści wynikających z utworzenia Planu Testów.

Korzyści istnienia Planu Testów:

• Jest to swego rodzaju przewodnik po całym procesie testowym. Określa ogólną koncepcję testowania, stosowane praktyki, wymagania i cele
• Zawiera szczegóły dotyczące testowania, przez co uzyskujemy pewność, że proces testowy toczy się według przyjętych założeń, a zespół nie błądzi poza przyjętym zakresem
• Estymacja czasu oraz pracochłonności
• Precyzyjnie określone role i obowiązki każdej osoby w zespole
• Ustalony i spisany harmonogram działań testowych
• Jasno określone wymagania dotyczące zasobów i sprzętu, niezbędnych do realizacji wszystkich prac testowych

Plan testów – co powinien zawierać?

1. Wstęp

Pierwszą sekcją powinien być krótki, ale precyzyjny wstęp, który może zawierać takie informacje jak:

• Cel dokumentu
• Cel działań testowych

W punkcie „Cel dokumentu”, powinniśmy określić, w jakim celu i po co powstał ten dokument.
Dobrym pomysłem, może być sporządzenie krótkiej agendy – czego dotyczyć będzie dalsza część dokumentu. Jaki może być cel Planu Testów? Otóż celem może być określenie ogólnego podejścia do procesu testowego danego oprogramowania, czy wskazanie zakresu testów, podejście za zarządzania ryzykiem, opracowanie harmonogramów itp.
Celem działań testowych może być np. dostarczenie informacji dla interesariuszy, którzy na ich podstawie będą mogli świadomie podjąć decyzję o odbiorze produktu, czy wypuszczeniu / niewypuszczeniu oprogramowania na rynek.

2. Zakres Testów

To moim zdaniem jedna z najważniejszych sekcji całego dokumentu. Ten punkt powinien być konkretny i szczegółowy. Informacje, które się tutaj znajdą będą mieć duży wpływ na budżet i czas realizacji całego projektu / procesu. To tutaj powinniśmy spisać wszystkie typy testów, jakimi zamierzamy poddać obiekt testów. Np. Testy jednostkowe, testy integracyjne, testy funkcjonalne, testy wydajnościowe, testy bezpieczeństwa, testy regresji, testy automatyczne itp.
W tej sekcji warto wyszczególnić również rodzaje testów, które zostaną pominięte i nie zostaną wykonane. Należy sumiennie uargumentować, dlaczego dany rodzaj testów został pominięty lub wykluczony z działań testowych. Np. może być taka sytuacja, że nie będziemy realizować testów bezpieczeństwa, gdyż nie mamy do tego wystarczających kompetencji w zespole (brak pentesterów), lub np. klient zrealizuje te testy po własnej stronie z wykorzystaniem swoich zasobów kompetencyjnych / sprzętowych.

3. Przedmiot testów

W tym miejscu powinniśmy jasno sprecyzować, jaki jest przedmiot testów. Może to być po prostu gotowy, zamówiony przez klienta produkt, ale równie dobrze może to być tylko jeden, bądź kilka komponentów, usług czy modułów.

4. Kryteria zaliczenia / niezaliczenia testów

Kiedy zdefiniujesz już testy, które należy przeprowadzić, musisz wiedzieć, kiedy pojedynczy test będzie „zakończony”. Oznacza to, że musisz zdefiniować kryteria zaliczenia (test pozytywny) i niepowodzenia (test negatywny) dla każdego konkretnego testu.
Aby moc określić status testu (pozytywny, negatywny), będziemy musieli na początku zdefiniować poszczególne metryki, które należy śledzić. Na przykład, jeśli robisz test wydajności, możesz spojrzeć na takie metryki, jak:
• Czas odpowiedzi: łączny czas na wysłanie żądania i uzyskanie odpowiedzi
• Czas oczekiwania: ile czasu zajmuje otrzymanie pierwszego bajtu po wysłaniu żądania
• Średni czas ładowania: średni czas potrzebny na dostarczenie każdego żądania
• Maksymalny czas odpowiedzi: najdłuższy czas potrzebny na zrealizowanie żądania
• Żądania na sekundę: ile żądań można obsłużyć w danej jednostce czasu
• Transakcje udane / nieudane: łączna liczba udanych lub nieudanych żądań
• Wykorzystanie pamięci: Ile pamięci jest potrzebne do przetworzenia żądania

5. Kryteria wejścia / wyjścia

Wcześniej wspomniane kryteria zaliczenia / niezaliczenia testów to nie jedyne kryteria, o których musisz pamiętać, tworząc plan testów, gdyż równie ważne są:

• Kryteria wejścia
Tutaj umieszczamy wszystkie elementy, warunki, które muszą zostać spełnione, aby rozpocząć testowanie, czyli np. działające środowisko testowe, dostępny zespół ludzi o odpowiednich kompetencjach technicznych i biznesowych, czy zakończone określone fazy developmentu.
• Kryteria wyjścia
Określają, kiedy można przerwać testowanie danej funkcji. Czyli osiągamy stan, w którym świadomie stwierdzamy, że dana funkcja działa zgodnie z przyjętymi założeniami.
Rzadziej spisywane są kryteria zawieszenia, ale warto również o nich powiedzieć kilka słów:
• Kryteria zawieszenia
Określają, kiedy należy wstrzymać test. Odpowiadają na pytania: Czy istnieje próg błędów, przy którym należy przerwać testowanie i zacząć szukać rozwiązań? Jakie są kroki, aby go zamknąć i udokumentować to, co zostało zrobione do tej pory?

6. Lista wymagań / funkcjonalności do przetestowania

Często w Planie Testów występuje sekcja, w której umieszczamy spisy konkretnych funkcjonalności, które należy odpowiednio przetestować. W tym miejscu częstą praktyką jest załączanie wcześniej przygotowanych historyjek użytkownika (user story) czy różnego rodzaju scenariuszy testowych pod konkretne funkcjonalności.

7. Środowisko testowe

Wyniki testów będą zależeć w takim samym stopniu od testowanej funkcji, jak i środowiska, na którym ją testujesz. W ramach Planu Testów musisz określić, jaki sprzęt, oprogramowanie, system operacyjny będzie niezbędny i wykorzystywany podczas procesu testowego.
Umieszczamy tu szczegółowe konkrety konfiguracyjne, gdyż pozwoli to uniknąć nieścisłości i niedopowiedzeń, a w konsekwencji błędnej konfiguracji. Na przykład, jeśli zamierzasz określić system operacyjny, który ma być używany podczas testów, podaj również wersję/edycję systemu operacyjnego, a nie tylko nazwę. Tak samo postępujemy z całą resztą software’u oraz hardware’u.

8. Harmonogram testów

W tej sekcji określamy (w stopniu możliwie najbardziej precyzyjnym i konkretnym ) ogólny harmonogram testów, które zamierzamy przeprowadzić. Warto podzielić harmonogram na fazy oraz typy testów wraz z ich określonymi przedziałami czasowymi (datami). Pamiętajmy, aby przy określaniu terminów, dawać sobie lekki zapas czasu na mniej lub bardziej nieprzewidziane sytuacje, problemy i trudności.

9. Raportu z testów

To miejsce jest bardzo istotne z punktu widzenia klienta, gdyż to tutaj określamy, jakie artefakty z testów dostarczymy na koniec procesu testowego. To na podstawie właśnie tych informacji, dokumentów klient będzie podejmował decyzję np. o wypuszczeniu / niewypuszczeniu obiektu testów na rynek. Zwykle tutaj dajemy informację, że na koniec testów dostarczymy np. listę przypadków testowych, które zostały przeprowadzone wraz z ich statusami, skrypty testów automatycznych, wszelkie raporty z testów.

10. Lista narzędzi

Umieszczamy tutaj listę wszelkich narzędzi, które będą brać udział w procesie testowym.
Często taka lista może być dość obszerna, dlatego w takim wypadku należy podzielić te narzędzia na grupy zastosowania, np. narzędzia do testów automatycznych, narzędzia do zarządzania defektami, narzędzia do raportowania itp.

11. Zarządzanie incydentami, błędami

Tutaj należy określić proces, który dotyczy zarządzania wykrytymi incydentami od ich znalezienia, po naprawę, a kończąc na retestach. Oczywiście taki proces w każdej firmie może być nieco inny. Wygląd takiego procesu może również zależeć od wykorzystywanych narzędzi, a także od wielkości i organizacji zespołu testowego. W ramach takiego procesu jednak zawsze należy zwrócić uwagę na takie elementy jak: proces zgłaszania błędów, proces retestowania błędów, proces omawiania i rozwiązywania błędów itp.

12. Role i odpowiedzialność

Zwykle w końcowym fragmencie Planu Testów powinna znaleźć się sekcja, w której to precyzyjnie powinniśmy określić role i odpowiedzialności w proponowanym procesie testowym. Ten punkt jest oczywiście tym bardziej istotny, im większy zespół testowym bierze udział w testach. Określamy tutaj wszystkie role, jakie biorą udział w testach, a więc np. tester manualny, tester automatyzujący, test manager, analityk testowy itp. Każda rola powinna zawierać swój precyzyjny zakres odpowiedzialność.

13. Ryzyka

Na koniec dokumentu możemy spisać ryzyka, o których mamy jakąkolwiek wiedzę, a które wydają się na tyle istotne, że mogą mieć wpływ na proces testowy oraz testowaną aplikację.

Autor: Tomasz Stelmach