Witaj w piątym rozdziale naszego kursu!

Po zgłębieniu technik projektowania testów, przechodzimy teraz do kluczowego aspektu zarządzania całym procesem – planowania testów.

Bez solidnego planu, nawet najlepsze techniki mogą okazać się chaotyczne i nieefektywne.

Planowanie to fundament, który nadaje strukturę, kierunek i kontrolę nad wszystkimi czynnościami testowymi w projekcie.

Wyobraź sobie budowę domu bez projektu architektonicznego. Byłoby to niezwykle ryzykowne, prawda?

Podobnie jest z testowaniem oprogramowania. Plan testów to nasz projekt, mapa drogowa, która prowadzi nas przez złożony proces zapewniania jakości.

Definiuje on, co, jak, kiedy i przez kogo ma być testowane, jakie zasoby są potrzebne i jakie ryzyka należy wziąć pod uwagę.

W tej lekcji, opierając się na sylabusie ISTQB Foundation Level v4.0 (sekcje FL-5.1.1 K2 do FL-5.1.7 K2), omówimy kompleksowo zagadnienia związane z planowaniem testów:

• Cel i treść planu testów: Po co tworzymy plan i co powinien zawierać?
• Wkład testera w planowanie iteracji i wydań: Jak testerzy uczestniczą w planowaniu w metodykach zwinnych?
• Kryteria wejścia i kryteria wyjścia: Kiedy możemy rozpocząć, a kiedy zakończyć daną czynność testową?
• Techniki szacowania pracochłonności: Jak przewidzieć, ile czasu i wysiłku zajmą testy?
• Priorytetyzacja przypadków testowych: W jakiej kolejności wykonywać testy, aby zmaksymalizować ich wartość?
• Piramida testów: Jak zrównoważyć różne poziomy testów, zwłaszcza automatycznych?
• Kwadranty testowe: Jak sklasyfikować różne rodzaje testów w kontekście biznesowym i technicznym?

Zrozumienie tych koncepcji pozwoli Ci nie tylko efektywnie planować własne działania testowe, ale także skutecznie komunikować się z resztą zespołu projektowego i interesariuszami na temat strategii i postępów w zapewnianiu jakości.

1. Cel i Treść Planu Testów (FL-5.1.1 K2)

Po co nam plan testów? Plan testów nie jest tylko formalnym dokumentem. To narzędzie komunikacji, zarządzania i kontroli.

Jego główne cele to:

• Dokumentowanie strategii: Opisuje, jak zamierzamy osiągnąć cele testowe w ramach dostępnych zasobów i ograniczeń.
• Zapewnienie zgodności: Pomaga upewnić się, że działania testowe spełniają określone kryteria (np. pokrycia wymagań, standardów jakości).
• Komunikacja: Służy jako punkt odniesienia dla całego zespołu projektowego i interesariuszy, informując o zakresie, podejściu, zasobach i harmonogramie testów.
• Zgodność z polityką/strategią: Pokazuje, jak planowane testy wpisują się w ogólną politykę i strategię testów organizacji (lub uzasadnia ewentualne odstępstwa).
• Ukierunkowanie myślenia: Proces tworzenia planu zmusza do przemyślenia potencjalnych wyzwań, ryzyk, potrzebnych zasobów i harmonogramu.

Co powinien zawierać plan testów? Chociaż szczegółowa zawartość może się różnić w zależności od projektu, kontekstu i standardów organizacji (np. ISO/IEC/IEEE 29119-3), typowe elementy planu testów obejmują:

• Kontekst testowania:
  • Zakres: Co będzie testowane (funkcjonalności, moduły, cechy jakościowe), a co jest poza zakresem.
  • Cele testów: Co chcemy osiągnąć poprzez testowanie (np. znalezienie defektów, ocena jakości, budowanie zaufania, spełnienie wymagań).
  • Ograniczenia: Czynniki, które mogą wpłynąć na proces testowy (np. budżet, czas, dostępne zasoby, narzędzia).
  • Podstawa testów: Dokumenty lub artefakty, na podstawie których projektowane są testy (np. wymagania, historyjki użytkownika, specyfikacje, kod).
• Założenia i zależności: Czynniki, które przyjmujemy za prawdziwe (np. dostępność środowiska) oraz zależności od innych zespołów lub zadań.
• Interesariusze: Kto jest zaangażowany w proces testowy (role, obowiązki), jakie są potrzeby rekrutacyjne i szkoleniowe.
• Komunikacja: Jak, kiedy i do kogo będą raportowane postępy, problemy i wyniki testów (np. spotkania, raporty, narzędzia).
• Rejestr ryzyk: Identyfikacja i ocena ryzyk produktowych (związanych z jakością produktu) i projektowych (związanych z procesem testowym). Omówimy to szerzej w lekcji 5.2.
• Podejście do testowania:
  • Poziomy testów: Jakie poziomy testów będą realizowane (np. komponentowe, integracyjne, systemowe, akceptacyjne).
  • Typy testów: Jakie typy testów będą przeprowadzane (np. funkcjonalne, niefunkcjonalne, strukturalne, związane ze zmianami).
  • Techniki testowania: Jakie techniki projektowania testów zostaną użyte.
  • Testware: Jakie produkty pracy testowej zostaną stworzone (np. przypadki testowe, skrypty, dane testowe).
  • Kryteria wejścia i wyjścia: Warunki rozpoczęcia i zakończenia poszczególnych czynności testowych.
  • Niezależność testowania: Jaki poziom niezależności będzie stosowany.
  • Metryki: Jakie wskaźniki będą zbierane do monitorowania postępów i jakości.
  • Dane testowe: Jakie są wymagania dotyczące danych testowych i jak będą zarządzane.
  • Środowiska testowe: Jakie środowiska są potrzebne i jak będą zarządzane.
• Harmonogram: Kluczowe kamienie milowe, terminy i powiązania z ogólnym harmonogramem projektu.
• Budżet: Szacowane koszty związane z zasobami, narzędziami i innymi potrzebami.

Ważne jest, aby plan testów był dokumentem żywym, aktualizowanym w miarę postępów projektu i pojawiania się nowych informacji.

2. Wkład Testera w Planowanie Iteracji i Wydań (FL-5.1.2 K2)

W metodykach zwinnych (Agile) planowanie odbywa się na różnych poziomach, głównie podczas planowania wydania (Release Planning) i planowania iteracji/sprintu (Iteration/Sprint Planning).

Testerzy odgrywają kluczową rolę w obu tych procesach.

Planowanie wydania:

• Cel: Określenie ogólnego zakresu i harmonogramu dla nadchodzącego wydania produktu (obejmującego zazwyczaj kilka iteracji).
• Wkład testera:
  • Definiowanie testowalnych historyjek: Pomoc w tworzeniu historyjek użytkownika i kryteriów akceptacji, które są jasne, kompletne i testowalne (zgodnie z podejściami opartymi na współpracy, lekcja 4.5).
  • Identyfikacja ryzyk: Wskazywanie potencjalnych ryzyk związanych z jakością dla planowanych funkcjonalności.
  • Szacowanie pracochłonności testów: Udział w szacowaniu wysiłku potrzebnego na przetestowanie poszczególnych historyjek lub grup funkcjonalności.
  • Definiowanie strategii testów dla wydania: Określenie ogólnego podejścia do testowania w ramach wydania (np. jakie poziomy i typy testów będą kluczowe, jakie narzędzia zostaną użyte).
  • Planowanie infrastruktury: Identyfikacja potrzeb dotyczących środowisk testowych i danych.

Planowanie iteracji/sprintu:

• Cel: Wybranie historyjek użytkownika z backlogu produktu do realizacji w nadchodzącej iteracji i zdekomponowanie ich na konkretne zadania.
• Wkład testera:
  • Analiza historyjek: Dogłębne zrozumienie historyjek wybranych do sprintu, zadawanie pytań, doprecyzowywanie kryteriów akceptacji.
  • Identyfikacja zadań testowych: Określenie konkretnych zadań związanych z testowaniem danej historyjki (np. projektowanie testów, przygotowanie danych, automatyzacja, wykonanie testów eksploracyjnych).
  • Szacowanie zadań testowych: Oszacowanie pracochłonności poszczególnych zadań testowych.
  • Planowanie testów w ramach iteracji: Ustalenie, jak i kiedy poszczególne historyjki będą testowane w trakcie sprintu (często równolegle z developmentem).
  • Współpraca z programistami: Ustalenie sposobu współpracy przy testowaniu (np. testy jednostkowe, testy integracyjne, przeglądy kodu).

Aktywny udział testerów w planowaniu na obu poziomach jest kluczowy dla wczesnego wykrywania problemów, zapewnienia testowalności i budowania jakości od samego początku.

3. Kryteria Wejścia i Kryteria Wyjścia (FL-5.1.3 K2)

Kryteria wejścia (Entry Criteria): Definiują warunki, które muszą być spełnione, aby można było rozpocząć daną czynność testową (np. poziom testów, konkretne zadanie testowe).

Określają one gotowość do rozpoczęcia testów.

Przykłady kryteriów wejścia dla testów systemowych:

• Dostępność środowiska testowego.
• Dostępność podstawy testów (np. zatwierdzone wymagania, historyjki użytkownika).
• Dostępność testware (np. przygotowane przypadki testowe, dane testowe).
• Dostępność testowanego obiektu (np. skompilowana i wdrożona wersja aplikacji).
• Spełnienie kryteriów wyjścia dla wcześniejszego poziomu testów (np. testów integracyjnych).

Kryteria wyjścia (Exit Criteria) / Definicja Ukończenia (Definition of Done - DoD): Definiują warunki, które muszą być spełnione, aby można było uznać daną czynność testową za zakończoną.

Określają one, kiedy osiągnęliśmy wystarczający poziom pewności co do jakości.

W metodykach zwinnych często używa się terminu Definition of Done (DoD), który jest wspólnie uzgodnionym przez zespół zestawem kryteriów określających, kiedy historyjka użytkownika lub inny element pracy jest faktycznie ukończony (nie tylko zakodowany, ale też przetestowany, zintegrowany, udokumentowany itp.).

Przykłady kryteriów wyjścia / DoD:

• Wykonanie wszystkich zaplanowanych przypadków testowych.
• Osiągnięcie wymaganego poziomu pokrycia (np. pokrycia wymagań, pokrycia kodu).
• Brak znanych krytycznych defektów.
• Liczba pozostałych defektów o niższym priorytecie poniżej ustalonego progu.
• Spełnienie wymagań dotyczących wydajności, bezpieczeństwa itp.
• Zatwierdzenie wyników testów przez interesariuszy.

Definiowanie i monitorowanie kryteriów wejścia i wyjścia pomaga w zarządzaniu procesem testowym, podejmowaniu decyzji o rozpoczęciu i zakończeniu testów oraz komunikowaniu statusu i poziomu zaufania do jakości produktu.

4. Techniki Szacowania Pracochłonności Testów (FL-5.1.4 K2)

Szacowanie pracochłonności testów to proces przewidywania, ile czasu i wysiłku będzie potrzebne na wykonanie zaplanowanych czynności testowych.

Jest to kluczowy element planowania, wpływający na harmonogram, budżet i alokację zasobów.

Szacowanie jest z natury niepewne, ale istnieją techniki, które pomagają uzyskać bardziej wiarygodne wyniki.

Czynniki wpływające na pracochłonność testów:

• Cechy produktu: Złożoność, rozmiar, wymagania jakościowe, dostępna dokumentacja, ryzyka produktowe.
• Cechy procesu wytwórczego: Stabilność procesu, stosowane narzędzia, model cyklu życia, presja czasu.
• Cechy zespołu: Doświadczenie i umiejętności testerów oraz innych członków zespołu, komunikacja w zespole.
• Wyniki testowania: Liczba i dotkliwość znalezionych defektów, ilość potrzebnych re-testów.

Popularne techniki szacowania:

• Techniki oparte na metrykach (Metrics-based): Wykorzystują dane historyczne z poprzednich projektów lub iteracji (np. średni czas testowania podobnej funkcjonalności, liczba przypadków testowych na punkt funkcyjny). Wymagają posiadania wiarygodnych danych historycznych.
• Techniki oparte na opinii ekspertów (Expert-based): Polegają na zebraniu opinii doświadczonych testerów, programistów lub menedżerów. Przykłady:
  • Wideband Delphi: Ustrukturyzowana technika grupowej estymacji, mająca na celu osiągnięcie konsensusu poprzez kilka rund anonimowych szacunków i dyskusji.
  • Planning Poker: Popularna w Agile technika, gdzie członkowie zespołu jednocześnie pokazują karty z wartościami reprezentującymi szacowany wysiłek (często w punktach historyjek - Story Points), a następnie dyskutują różnice, aż do osiągnięcia konsensusu.

W praktyce często stosuje się kombinację różnych technik, aby uzyskać bardziej wiarygodne szacunki.

Ważne jest również regularne aktualizowanie szacunków w miarę postępów projektu i pojawiania się nowych informacji.

5. Priorytetyzacja Przypadków Testowych (FL-5.1.5 K2)

W większości projektów nie ma wystarczająco dużo czasu ani zasobów, aby wykonać wszystkie możliwe testy.

Dlatego kluczowe jest priorytetyzowanie przypadków testowych – ustalenie kolejności ich wykonywania, tak aby najważniejsze testy zostały przeprowadzone jako pierwsze.

Pozwala to zmaksymalizować wartość testowania w ograniczonym czasie i skupić się na najbardziej krytycznych obszarach.

Czynniki wpływające na priorytetyzację:

• Ryzyko: Testy dotyczące obszarów o najwyższym ryzyku (największe prawdopodobieństwo wystąpienia defektu i/lub największy wpływ biznesowy awarii) powinny mieć najwyższy priorytet.
• Wymagania: Priorytety wymagań biznesowych (np. kluczowe funkcjonalności dla klienta).
• Zależności: Przypadki testowe, od których zależą inne testy, mogą wymagać wcześniejszego wykonania.
• Złożoność: Bardziej złożone obszary mogą wymagać wcześniejszego lub bardziej intensywnego testowania.
• Historia defektów: Obszary, w których wcześniej znajdowano dużo błędów, mogą wymagać wyższego priorytetu.

Jak priorytetyzować?

Priorytetyzacja powinna być wynikiem współpracy zespołu i uwzględniać perspektywę biznesową.

Można stosować różne skale priorytetów (np. Wysoki/Średni/Niski, P1/P2/P3/P4) i przypisywać je do poszczególnych przypadków testowych lub grup testów.

Ważne jest, aby priorytety były jasno zdefiniowane i komunikowane.

6. Piramida Testów (FL-5.1.6 K2)

Piramida testów to model wizualizujący zalecane proporcje między różnymi poziomami testów automatycznych w projekcie.

Została spopularyzowana przez Mike'a Cohna i jest szczególnie istotna w kontekście zwinnego wytwarzania oprogramowania i ciągłej integracji/ciągłego dostarczania (CI/CD).

Struktura piramidy:

• Podstawa (najszersza): Testy jednostkowe (Unit Tests):
  • Testują małe, izolowane fragmenty kodu (np. pojedyncze funkcje, metody, klasy).
  • Pisane zazwyczaj przez programistów.
  • Są szybkie w wykonaniu, stabilne i dają precyzyjną informację zwrotną o lokalizacji błędu.
  • Powinno ich być najwięcej.
• Środek: Testy integracyjne / usług (Integration / Service / API Tests):
  • Testują interakcje między różnymi komponentami, modułami lub usługami (np. komunikację między API, interakcję z bazą danych).
  • Mogą być pisane przez programistów lub testerów automatyzujących.
  • Są wolniejsze i mniej stabilne niż testy jednostkowe, ale weryfikują współpracę części systemu.
  • Powinno ich być mniej niż testów jednostkowych.
• Szczyt (najwęższy): Testy interfejsu użytkownika (UI / End-to-End Tests):
  • Testują system jako całość z perspektywy użytkownika końcowego, poprzez interakcję z interfejsem graficznym (GUI).
  • Pisane zazwyczaj przez testerów automatyzujących.
  • Są najwolniejsze, najbardziej kruche (podatne na zmiany w UI) i najtrudniejsze w utrzymaniu.
  • Powinno ich być najmniej, skupiając się na kluczowych przepływach biznesowych.

Dlaczego piramida? Model piramidy sugeruje, że powinniśmy dążyć do posiadania dużej liczby szybkich i tanich testów jednostkowych u podstawy, mniejszej liczby nieco wolniejszych testów integracyjnych pośrodku i tylko niewielkiej liczby najwolniejszych i najdroższych testów UI na szczycie.

Odwrócenie tej proporcji (tzw. "stożek lodowy" lub "odwrócona piramida") prowadzi do długiego czasu oczekiwania na wyniki testów, niestabilności i wysokich kosztów utrzymania automatyzacji.

Piramida testów pomaga zespołom podejmować świadome decyzje dotyczące strategii automatyzacji testów.

7. Kwadranty Testowe (FL-5.1.7 K2)

Kwadranty testowe (Agile Testing Quadrants) to model spopularyzowany przez Briana Maricka, który pomaga zespołom zwinnym myśleć o różnych rodzajach testów potrzebnych do zbudowania wysokiej jakości produktu.

Model dzieli testy na cztery kwadranty w oparciu o dwie osie:

• Oś pozioma: Wspierające zespół (Supporting the Team) vs. Krytykujące produkt (Critiquing the Product).
• Oś pionowa: Zorientowane na biznes (Business Facing) vs. Zorientowane na technologię (Technology Facing).

Opis kwadrantów:

• Q1 (Górny lewy): Zorientowane na technologię, Wspierające zespół:
  • Cel: Wspieranie programistów w tworzeniu kodu wysokiej jakości.
  • Przykłady: Testy jednostkowe, testy komponentowe, testy API (często zautomatyzowane, związane z TDD).
• Q2 (Górny prawy): Zorientowane na biznes, Wspierające zespół:
  • Cel: Wspieranie zespołu w zrozumieniu i implementacji wymagań biznesowych.
  • Przykłady: Testy funkcjonalne, testy historyjek użytkownika, prototypowanie, symulacje (często zautomatyzowane, związane z ATDD/BDD, ale też manualne testy eksploracyjne).
• Q3 (Dolny lewy): Zorientowane na technologię, Krytykujące produkt:
  • Cel: Ocena wewnętrznych aspektów jakościowych produktu.
  • Przykłady: Testy wydajności, testy obciążeniowe, testy bezpieczeństwa, testy niezawodności, testy eksploracyjne skupione na technologii (często wymagają specjalistycznych narzędzi i wiedzy).
• Q4 (Dolny prawy): Zorientowane na biznes, Krytykujące produkt:
  • Cel: Ocena produktu z perspektywy użytkownika końcowego i biznesu.
  • Przykłady: Testy eksploracyjne (scenariusze użytkownika), testy użyteczności, testy akceptacyjne użytkownika (UAT), testy alfa/beta (głównie manualne).

Jak używać kwadrantów? Model kwadrantów nie jest sztywną regułą, ale narzędziem do myślenia i dyskusji w zespole.

Pomaga upewnić się, że zespół uwzględnia różne perspektywy i rodzaje testów potrzebne do zapewnienia kompleksowej jakości.

Zachęca do myślenia o tym, kto powinien być zaangażowany w dany rodzaj testów i jakie narzędzia lub techniki mogą być odpowiednie.

Podsumowanie

Planowanie testów to nieodłączny element profesjonalnego podejścia do zapewniania jakości.

Niezależnie od stosowanej metodyki, zrozumienie celu i treści planu testów, roli testera w planowaniu, znaczenia kryteriów wejścia/wyjścia, technik szacowania i priorytetyzacji jest kluczowe.

Modele takie jak piramida testów i kwadranty testowe dostarczają cennych ram koncepcyjnych, pomagających zespołom w podejmowaniu świadomych decyzji dotyczących strategii testowania i automatyzacji.

Pamiętaj, że planowanie to proces ciągły, wymagający adaptacji i współpracy całego zespołu.