Proces testowania. ISTQB 2018

Dobór procesu testowego do konkretnego oprogramowania w konkretnej sytuacji zależy od wielu czynników. Organizacja może w swojej strategii testowej zdefiniować, które czynności testowe wchodzą w skład tego procesu, jakie czynności testowe mają być zaimplementowane oraz w którym momencie cyklu życia oprogramowania powinny mieć miejsce.

Przykładowe czynniki kontekstowe wpływające na proces testowy w organizacji to:

• wykorzystywany model cyklu życia oprogramowania i metodyki projektowe;
• rozważane poziomy testów i typy testów;
• czynniki ryzyka produktowego i projektowego;
• dziedzina biznesowa;
• ograniczenia operacyjne, w tym w szczególności:

a) budżety i zasoby;

b) harmonogramy;

c) złożoność procesu lub projektu;

d) wymagania wynikające z umów i przepisów;

• polityka testów i praktyki obowiązujące w organizacji;
• wymagane normy/standardy wewnętrzne i zewnętrzne.

Dobrą praktyką jest zdefiniowanie mierzalnych kryteriów pokrycia dotyczących podstawy testów (w odniesieniu do każdego rozważanego poziomu lub typu testów). Kryteria pokrycia mogą w praktyce pełnić funkcję kluczowych wskaźników wydajności (ang. Key Performance Indicators — KPI), sprzyjających wykonywaniu określonych czynności i pozwalających wykazać osiągnięcie celów testowania oprogramowania.

Przykładem ilustrującym tę praktykę jest podstawa testów dla aplikacji mobilnej, która może zawierać listę wymagań oraz listę wspieranych urządzeń mobilnych. Każde wymaganie i każde wspierane urządzenie jest elementem podstawy testów. Kryteria pokrycia mogą wymagać co najmniej jednego testu dla każdego elementu podstawy testów. Po wykonaniu testów, ich wyniki są źródłem informacji dla interesariuszy, czy określone wymagania zostały spełnione oraz czy na wspieranych urządzeniach zaobserwowano awarie.

W procesie testowym wyróżnia się następujące, główne grupy czynności:

• planowanie testów;
• monitorowanie testów i nadzór nad testami;
• analiza testów;
• projektowanie testów;
• implementacja testów;
• wykonywanie testów;
• ukończenie testów.

Każda grupa składa się z czynności, które opisano w kolejnych podpunktach. Ponadto, poszczególne czynności w każdej z grup, mogą składać się z kilku pojedynczych zadań różniących się w zależności od projektu lub wersji oprogramowania. Należy również zaznaczyć, że chociaż wiele grup czynności może sprawiać wrażenie logicznie  uszeregowanych, często są one realizowane metodą iteracyjną. Przykładem takiej praktyki jest model zwinnego wytwarzania oprogramowania, który opiera się na krótkich iteracjach, obejmujących projektowanie, tworzenie i testowanie produktu. Iteracje odbywają się w sposób ciągły i są objęte ciągłym planowaniem. W rezultacie czynności testowe są również wykonywane w ramach tego podejścia do wytwarzania oprogramowania w sposób ciągły i iteracyjny. Nawet w przypadku stosowania metod sekwencyjnych, w których czynności są wykonywane krokowo w logicznej kolejności, pewne elementy nakładają się na siebie, są wykonywane łącznie lub równocześnie, bądź są pomijane. W związku z powyższym zwykle konieczne jest dostosowanie głównych czynności do kontekstu danego systemu lub projektu.

Planowanie testów

Planowanie testów obejmuje czynności, których zadaniem jest zdefiniowanie celów testowania oraz określenie podejścia do osiągania celów testowania w granicach wyznaczonych przez kontekst (np. określenie odpowiednich technik testowania i zadań testowych oraz sformułowanie harmonogramu testów, który umożliwi dotrzymanie wyznaczonego terminu). Plany testów mogą być następnie korygowane na podstawie informacji zwrotnych z monitorowania i nadzoru.

Monitorowanie testów i nadzór nad testami

Monitorowanie testów polega na ciągłym porównywaniu rzeczywistego z zaplanowanym postępem testowania przy użyciu miar specjalnie w tym celu zdefiniowanych w planie testów. Nadzór nad testami polega na podejmowaniu działań, które są niezbędne do osiągnięcia celów wyznaczonych w planie testów (z uwzględnieniem jego ewentualnych aktualizacji). Elementem wspomagającym monitorowanie testów i nadzór nad nimi, jest ocena kryteriów wyjścia, które w przypadku niektórych cykli życia są również nazywane „definicją ukończenia”. Ocena kryteriów wyjścia dla wykonania testów na określonym poziomie testów może obejmować:

• sprawdzenie rezultatów testów i dziennika testów pod kątem określonych kryteriów pokrycia;
• oszacowanie poziomu jakości modułu lub systemu na podstawie rezultatów testów i dziennika testów;
• ustalenie, czy są konieczne dalsze testy (np. w przypadku nieosiągnięcia przez dotychczas wykonane testy pierwotnie założonego poziomu pokrycia ryzyka produktowego, co wiąże się z koniecznością napisania i wykonania dodatkowych testów).

Interesariusze są informowani o postępie w realizacji planu testów za pomocą raportów o postępie testów, które zawierają między innymi informacje o ewentualnych odchyleniach od planu oraz informacje pomagające uzasadnić podjęcie decyzji o wstrzymaniu testowania.

Analiza testów

Celem grupy czynności w analizie testów jest przeanalizowanie podstawy testów w celu zidentyfikowania testowalnych cech i zdefiniowania związanych z nimi warunków testowych. Innymi słowy, analiza testów służy do ustalenia tego, „co” należy przetestować (w kategoriach mierzalnych kryteriów pokrycia).

Główne czynności wykonywane w ramach analizy testów to:

• dokonywanie analizy podstawy testów właściwej dla rozważanego poziomu testów, np.:

a) specyfikacji wymagań, takich jak: wymagania biznesowe, wymagania funkcjonalne, wymagania systemowe, historyjki użytkownika, opowieści (ang. epic), przypadki użycia lub podobne produkty pracy, które określają pożądane zachowanie funkcjonalne i niefunkcjonalne modułu lub systemu;

b) informacji dotyczących projektu i implementacji, takich jak: diagramy lub dokumenty opisujące architekturę systemu lub oprogramowania, specyfikacje projektowe, przepływy wywołań, modele oprogramowania (np. diagramy UML lub diagramy związków encji), specyfikacje interfejsów lub podobne produkty pracy, które określają strukturę modułu lub systemu;

c) implementacji samego modułu lub systemu, w tym kodu, metadanych, zapytań do bazy danych oraz interfejsów;

d) raportów z analizy ryzyka, które mogą dotyczyć aspektów funkcjonalnych, niefunkcjonalnych i strukturalnych modułu lub systemu;

• dokonywanie oceny testowalności podstawy testów i elementów testowych, w celu zidentyfikowania często występujących typów defektów, które mogą powodować problemy z testowalnością, takich jak:

a) niejednoznaczności;

b) pominięcia;

c) niespójności;

d) nieścisłości;

e) sprzeczności;

f) nadmiarowe (zbędne) instrukcje;

• identyfikowanie cech i zbiorów cech, które mają zostać przetestowane;
• definiowanie warunków testowych w odniesieniu do poszczególnych cech oraz określenie ich priorytetów na podstawie analizy podstawy testów — z uwzględnieniem parametrów funkcjonalnych, niefunkcjonalnych i strukturalnych, innych czynników biznesowych i technicznych oraz poziomów ryzyka;
• stworzenie możliwości dwukierunkowego śledzenia powiązań między elementami podstawy testów a związanymi z nimi warunkami testowymi.

Zastosowanie technik czarnoskrzynkowych, białoskrzynkowych oraz technik opartych na doświadczeniu w ramach analizy testów (patrz rozdział 4.), pomaga zmniejszyć prawdopodobieństwo pominięcia ważnych warunków testowych oraz zdefiniować bardziej precyzyjne i dokładne warunki testowe.

W niektórych przypadkach w wyniku analizy testów, definiowane są warunki testowe, które mają być wykorzystywane jako cele testów w kartach opisów testów. Karty opisu testów są typowymi produktami pracy w niektórych odmianach testowania opartego na doświadczeniu.

Jeśli istnieje śledzenie powiązań między wspomnianymi powyżej celami testów a podstawą testów, możliwy jest pomiar pokrycia uzyskanego w trakcie testowania opartego na doświadczeniu.

Identyfikowanie defektów na etapie analizy testów jest istotną potencjalną korzyścią, zwłaszcza gdy nie stosuje się żadnego innego procesu przeglądu i/lub gdy proces testowy jest ściśle powiązany z procesem przeglądu. Czynności wykonywane w ramach analizy testów pozwalają zweryfikować, czy wymagania są spójne, prawidłowo wyrażone i kompletne, a także sprawdzić, czy właściwie odzwierciedlają one potrzeby klienta, użytkowników i innych interesariuszy. Warto w tym miejscu podać przykład takich technik jak: wytwarzanie sterowane zachowaniem (ang. Behavior Driven Development — BDD) i wytwarzanie sterowane testami akceptacyjnymi (ang. Acceptance Test Driven Development — ATDD), które obejmują generowanie warunków testowych i przypadków testowych na podstawie historyjek użytkownika i kryteriów akceptacji przed rozpoczęciem tworzenia kodu.

Przewidują one również weryfikację i walidację historyjek użytkownika i kryteriów akceptacji oraz wykrywanie występujących w nich defektów.

Projektowanie testów

Podczas projektowania testów warunki testowe są przekształcane w przypadki testowe wysokiego poziomu, zbiory takich przypadków testowych oraz w inne testalia. W związku z tym, o ile analiza testów odpowiada na pytanie: „co należy przetestować”, o tyle projektowanie testów odpowiada na pytanie: „jak należy testować”.

Główne czynności wykonywane w ramach projektowania testów to:

• projektowanie przypadków testowych i zbiorów przypadków testowych oraz określenie ich priorytetów;
• identyfikowanie danych testowych niezbędnych do obsługi warunków testowych i przypadków testowych;
• projektowanie środowiska testowego oraz zidentyfikowanie wszelkich niezbędnych narzędzi i elementów infrastruktury;
• tworzenie możliwości dwukierunkowego śledzenia powiązań między podstawą testów, warunkami testowymi, przypadkami testowymi i procedurami testowymi.

Rozwinięcie warunków testowych w przypadki testowe i zbiory przypadków testowych na etapie projektowania testów, wymaga często użycia technik testowania.

Tak jak w przypadku analizy testów, projektowanie testów może również skutkować identyfikacją podobnych typów defektów w podstawie testów, co jest ważną potencjalną korzyścią.

Implementacja testów

Podczas implementacji testów tworzone i/lub dokańczane są testalia niezbędne do wykonania testów, w tym szeregowanie przypadków testowych w ramach procedur testowych. W związku z tym, o ile projektowanie testów odpowiada na pytanie: „jak testować?”, o tyle implementacja testów odpowiada na pytanie: „czy mamy wszystko, co jest potrzebne do uruchomienia testów?”.

Główne czynności wykonywane w ramach implementacji testów to:

• opracowanie procedur testowych i określenie ich priorytetów oraz, potencjalnie, utworzenie skryptów testów automatycznych;
• utworzenie zestawów testowych (na podstawie procedur testowych) oraz skryptów testów automatycznych (jeśli istnieją testy automatyczne);
• uporządkowanie zestawów testowych w harmonogram wykonywania testów w sposób zapewniający efektywny przebieg całego procesu;
• zbudowanie środowiska testowego (włączając w to - jeśli to konieczne - jarzma testowe, wirtualizację usług, symulatory i inne elementy infrastrukturalne) oraz sprawdzenie, czy zostało ono poprawnie skonfigurowane;
• przygotowanie danych testowych i sprawdzenie, czy zostały poprawnie załadowane do środowiska testowego;
• zweryfikowanie i zaktualizowanie możliwości dwukierunkowego śledzenia powiązań między podstawą testów, warunkami testowymi, przypadkami testowymi, procedurami testowymi i zestawami testowymi.

Zadania związane z projektowaniem i implementacją testów są często łączone. Etapy projektowania i implementacji testów mogą być realizowane i dokumentowane w ramach wykonywania testów — zwłaszcza w przypadku testowania eksploracyjnego oraz innych typów testowania opartego na doświadczeniu. Testowanie eksploracyjne może odbywać się na podstawie testów, uruchamiane są zestawy testowe, zgodnie z harmonogramem wykonania testów.

Główne czynności przeprowadzane w ramach wykonywania testów to:

• zarejestrowanie danych identyfikacyjnych i wersji elementów testowych bądź przedmiotu testów, narzędzi testowych i testaliów;
• wykonywanie testów ręcznie lub przy użyciu narzędzi do wykonywania testów;
• porównanie rzeczywistych wyników testów z oczekiwanymi;
• przeanalizowanie anomalii w celu ustalenia ich prawdopodobnych przyczyn (np. awarie mogą być wynikiem defektów w kodzie, ale mogą się pojawić również wyniki fałszywie pozytywne);
• raportowanie defektów oparte na obserwowanych awariach;
• zarejestrowanie (zalogowanie) wyniku wykonania testów (np. zaliczenie, niezaliczenie, test blokujący);
• powtórzenie czynności testowych w wyniku działań podjętych w związku z wystąpieniem anomalii albo w ramach zaplanowanego testowania (np. testowania potwierdzającego, wykonywania poprawionego testu i/lub testowania regresji);
• zweryfikowanie i zaktualizowanie możliwości dwukierunkowego śledzenia powiązań między podstawą testów, warunkami testowymi, przypadkami testowymi, procedurami testowymi i wynikami testów.

Ukończenie testów

Ukończenie testów polega na zebraniu danych pochodzących z wykonanych czynności testowych w celu skonsolidowania zdobytych doświadczeń, testaliów oraz innych stosownych informacji.

Czynności związane z ukończeniem testów są wykonywane w momencie osiągnięcia kamieni milowych projektu, takich jak: przekazanie systemu lub oprogramowania do eksploatacji, zakończenie realizacji (lub anulowanie) projektu, zakończenie iteracji projektu zwinnego (np. w ramach spotkania retrospektywnego), ukończenie poziomu testów bądź zakończenie prac nad wydaniem pielęgnacyjnym (ang. maintenance release).

Główne czynności wykonywane w ramach ukończenia testów to:

• sprawdzenie, czy wszystkie raporty o defektach są zamknięte oraz wprowadzenie żądań zmian lub pozycji do rejestru produktu w odniesieniu do wszelkich defektów, które nie zostały rozwiązane do momentu zakończenia wykonywania testów;
• utworzenie sumarycznego raportu z testów, który zostanie przekazany interesariuszom;
• dla wersji końcowych: zarchiwizowanie środowiska testowego, danych testowych, infrastruktury testowej oraz innych testaliów, do ponownego wykorzystania w przyszłości;
• przekazanie testaliów zespołom odpowiedzialnym za pielęgnację, innym zespołom projektowym i/lub innym interesariuszom, którzy mogą odnieść korzyść z ich użycia;
• przeanalizowanie zdobytych doświadczeń omawianych na wszystkich etapach projektu w celu ustalenia, jakie zmiany będą konieczne w przypadku przyszłych iteracji, wydań i projektów;
• wykorzystanie zebranych informacji do zwiększenia dojrzałości procesu testowego.

Tekst (prawie) w całości pochodzi z sylabusa ISTQB 2018. Zostały z niego usunięte nagłówki odesłania. Choć jako źródło wiedzy sylabus może być postrzegany jako zbyt "ciężki" i "toporny", w małych dawkach jest to bardzo wartościowe kompendium wiedzy.

Całość można pobrać ze strony.