W poprzednich lekcjach omówiliśmy różne modele cyklu życia oprogramowania (SDLC) i przeanalizowaliśmy, jak wybór konkretnego modelu wpływa na strategię i realizację testów.

Chociaż każdy model ma swoją specyfikę, istnieją pewne uniwersalne, dobre praktyki testowania, które, jak podkreśla sylabus ISTQB, mają zastosowanie niezależnie od przyjętego podejścia do wytwarzania oprogramowania.

Stosowanie tych praktyk pomaga zapewnić wysoką jakość produktu końcowego, efektywność procesu testowego oraz lepszą współpracę w zespole projektowym.

W tej lekcji skupimy się na tych fundamentalnych zasadach, które stanowią podstawę profesjonalnego podejścia do testowania w każdym kontekście SDLC.

Uniwersalne Dobre Praktyki Testowania w Kontekście SDLC

Niezależnie od tego, czy pracujemy w modelu kaskadowym, zwinnym Scrumie, czy stosujemy Kanban, pewne fundamentalne zasady dotyczące testowania pozostają niezmienne.

Ich celem jest zapewnienie, że testowanie jest integralną częścią procesu wytwarzania, a nie tylko dodatkiem na końcu, oraz że przyczynia się do budowania jakości od samego początku.

Sylabus ISTQB Foundation Level v4.0 wymienia kilka kluczowych dobrych praktyk:

1. Przypisanie Czynności Testowych do Czynności Wytwórczych:

Ta praktyka podkreśla fundamentalną zasadę, że jakość powinna być wbudowana w proces, a nie tylko sprawdzana na końcu.

Oznacza to, że każdej istotnej czynności związanej z wytwarzaniem oprogramowania – od zbierania wymagań, przez projektowanie architektury, aż po kodowanie – powinna towarzyszyć odpowiednia czynność testowa.

Na przykład, analiza wymagań powinna być powiązana z projektowaniem testów akceptacyjnych, projektowanie architektury z planowaniem testów integracyjnych, a kodowanie modułów z testami modułowymi (jednostkowymi).

Takie podejście zapewnia, że wszystkie kluczowe etapy i produkty pracy procesu wytwórczego podlegają kontroli jakości.

Nie chodzi tylko o testowanie samego kodu, ale również o weryfikację i walidację dokumentacji, modeli, projektów interfejsu użytkownika itp.

Dzięki temu potencjalne problemy i niejednoznaczności mogą być wykryte i naprawione znacznie wcześniej, zanim zostaną zaimplementowane w kodzie, co jest zgodne z zasadą wczesnego testowania.

2. Różne Cele dla Różnych Poziomów Testów:

Testowanie oprogramowania odbywa się na różnych poziomach abstrakcji, takich jak testy modułowe (jednostkowe), integracyjne, systemowe i akceptacyjne (które szczegółowo omówimy w kolejnych lekcjach).

Kluczową dobrą praktyką jest zdefiniowanie dla każdego z tych poziomów konkretnych, odrębnych celów testowych.

Na przykład, celem testów modułowych jest weryfikacja poprawności działania poszczególnych komponentów (np. funkcji, klas) w izolacji.

Celem testów integracyjnych jest sprawdzenie interakcji i przepływu danych między zintegrowanymi modułami lub systemami.

Testy systemowe koncentrują się na weryfikacji całego zintegrowanego systemu pod kątem wymagań funkcjonalnych i niefunkcjonalnych.

Natomiast testy akceptacyjne mają na celu potwierdzenie, czy system spełnia potrzeby biznesowe i oczekiwania użytkowników.

Jasne zdefiniowanie celów dla każdego poziomu pozwala zapewnić odpowiednio szeroki zakres testowania, unikając jednocześnie niepotrzebnej redundancji (powtarzania tych samych testów na różnych poziomach) i luk w pokryciu testowym.

Każdy poziom wnosi unikalną wartość do procesu zapewnienia jakości.

3. Rozpoczynanie Analizy i Projektowania Testów Wcześnie:

Ta praktyka jest bezpośrednim zastosowaniem jednej z siedmiu fundamentalnych zasad testowania – „Wczesne testowanie oszczędza czas i pieniądze”.

Oznacza ona, że czynności związane z analizą i projektowaniem testów dla danego poziomu testów powinny rozpoczynać się jak najwcześniej, równolegle do odpowiadającej temu poziomowi fazy cyklu wytwarzania oprogramowania.

Na przykład, analiza wymagań biznesowych powinna być podstawą do rozpoczęcia projektowania testów akceptacyjnych.

Specyfikacja techniczna systemu powinna inicjować projektowanie testów systemowych.

Projektowanie modułów powinno prowadzić do tworzenia testów modułowych.

Takie podejście pozwala na wczesne wykrywanie defektów nie tylko w kodzie, ale przede wszystkim w specyfikacjach i projektach, zanim jeszcze zostaną one zaimplementowane.

Wczesne znalezienie i naprawienie błędu w wymaganiach jest wielokrotnie tańsze niż naprawa defektu wynikającego z tego błędu, który został już zakodowany i przetestowany na wielu poziomach.

4. Wczesne Zaangażowanie Testerów w Przeglądy Produktów Pracy:

Ta praktyka jest ściśle powiązana z poprzednią i stanowi kluczowy element realizacji podejścia „Shift Left” (przesunięcie w lewo), które omówimy bardziej szczegółowo w jednej z kolejnych lekcji.

Polega ona na aktywnym angażowaniu testerów w proces przeglądu różnych produktów pracy (dokumentów, modeli, prototypów, a nawet kodu) natychmiast po udostępnieniu ich pierwszych wersji roboczych.

Testerzy, dzięki swojej wiedzy, doświadczeniu i specyficznej perspektywie (skupionej na potencjalnych problemach i ryzykach), mogą wnieść ogromną wartość do procesu przeglądu.

Mogą identyfikować niejednoznaczności, niespójności, braki w wymaganiach, błędy w projektach czy potencjalne problemy z testowalnością.

Wczesne wykrycie i usunięcie tych problemów na etapie dokumentacji jest znacznie bardziej efektywne niż czekanie, aż zostaną one zaimplementowane w kodzie.

Aktywne uczestnictwo testerów w przeglądach wzmacnia współpracę w zespole i przyczynia się do budowania wspólnego zrozumienia produktu i jego jakości.

Znaczenie Dobrych Praktyk Niezależnie od Modelu SDLC

Warto podkreślić, że wymienione dobre praktyki nie są zarezerwowane dla konkretnego modelu SDLC.

Mają one fundamentalne znaczenie we wszystkich podejściach do wytwarzania oprogramowania.

Niezależnie od tego, czy pracujemy w sztywnym modelu kaskadowym, czy w elastycznym Scrumie, wczesne rozpoczynanie testowania, angażowanie testerów w przeglądy, definiowanie jasnych celów dla poziomów testów i powiązanie testowania z wytwarzaniem zawsze przyniesie korzyści w postaci wyższej jakości produktu, niższych kosztów i mniejszego ryzyka projektowego.

Oczywiście, sposób implementacji tych praktyk może się różnić w zależności od modelu.

Na przykład, w modelach zwinnych wczesne zaangażowanie testerów jest często realizowane poprzez ich stałą obecność w zespole deweloperskim i udział w codziennych spotkaniach oraz planowaniu sprintów.

W modelach sekwencyjnych może to oznaczać formalne zaproszenie testerów do udziału w przeglądach specyfikacji wymagań czy projektu architektury.

Podobnie, powiązanie czynności testowych z wytwórczymi w Scrumie może oznaczać tworzenie kryteriów akceptacji i testów automatycznych w ramach tego samego sprintu, w którym powstaje dana funkcjonalność, podczas gdy w modelu V może to być bardziej formalne mapowanie faz wytwarzania na poziomy testów.

Kluczowe jest jednak zrozumienie samej idei stojącej za tymi praktykami i dążenie do ich stosowania w możliwie najszerszym zakresie, dostosowując konkretne mechanizmy do kontekstu projektu i organizacji.

Profesjonalny tester powinien znać te zasady i potrafić je zastosować w praktyce, niezależnie od środowiska, w którym pracuje.