W poprzednich lekcjach omówiliśmy fundamentalne aspekty testowania: czym jest, dlaczego jest potrzebne, jakie są jego zasady i jak przebiega typowy proces testowy.

Jednak szósta zasada testowania mówiła, że "testowanie zależy od kontekstu".

W tej lekcji rozwiniemy tę myśl, analizując, jak różne czynniki kontekstowe wpływają na sposób przeprowadzania testów, ich zakres, priorytety i ogólną strategię.

Zrozumienie kontekstu jest kluczowe dla dostosowania procesu testowego tak, aby był on jak najbardziej efektywny i przynosił największą wartość w danej sytuacji.

Testowanie nie odbywa się w próżni. Jest integralną częścią szerszego procesu tworzenia oprogramowania i musi być dostosowane do specyfiki organizacji, projektu, produktu i zespołu.

To, co sprawdza się w jednym projekcie, może być zupełnie nieodpowiednie w innym.

Ignorowanie kontekstu może prowadzić do marnowania zasobów na nieistotne testy, pomijania kluczowych ryzyk lub stosowania nieefektywnych metod.

Dlatego tak ważna jest umiejętność analizy kontekstu i podejmowania świadomych decyzji dotyczących strategii testowej.

Kluczowe Czynniki Kontekstowe Wpływające na Testowanie

ISTQB wskazuje na szereg czynników kontekstowych, które mają istotny wpływ na proces testowy. Można je podzielić na kilka głównych kategorii:

1. Interesariusze (Stakeholders)

Interesariusze to wszystkie osoby lub grupy, które są zainteresowane projektem lub na które projekt ma wpływ.

Ich potrzeby, oczekiwania, wymagania i gotowość do współpracy znacząco kształtują proces testowy.

Kim są typowi interesariusze w kontekście testowania? Mogą to być:

• Klienci/Użytkownicy końcowi: Ich oczekiwania co do funkcjonalności, użyteczności, wydajności i niezawodności są kluczowe. Ich zaangażowanie w proces (np. w testach akceptacyjnych) jest bardzo cenne.
• Zarząd/Sponsorzy projektu: Interesują ich głównie cele biznesowe, budżet, harmonogram i ogólne ryzyko projektu. Wyniki testów dostarczają im informacji do podejmowania decyzji.
• Menedżerowie projektu/produktu: Odpowiadają za dostarczenie produktu na czas i w ramach budżetu, spełniającego określone wymagania. Potrzebują informacji o postępach testów i poziomie jakości.
• Programiści: Współpracują z testerami w zakresie identyfikacji i naprawy defektów. Jakość ich pracy wpływa na zakres potrzebnych testów.
• Analitycy biznesowi/Projektanci: Dostarczają podstawę testów (wymagania, projekty). Ich współpraca z testerami jest ważna dla zapewnienia testowalności.
• Zespół operacyjny/Administratorzy: Odpowiadają za wdrożenie i utrzymanie systemu. Interesuje ich stabilność, wydajność i łatwość zarządzania systemem.
• Regulatorzy/Audytorzy: W niektórych branżach (np. finanse, medycyna) mogą narzucać specyficzne wymagania dotyczące procesu testowego i dokumentacji.

Potrzeby i oczekiwania różnych interesariuszy mogą być sprzeczne (np. szybkie dostarczenie vs. wysoka jakość).

Rolą zespołu testowego, często we współpracy z menedżerem projektu, jest zrozumienie tych potrzeb i znalezienie optymalnego balansu, co znajduje odzwierciedlenie w strategii i planie testów.

2. Członkowie Zespołu (Team Members)

Charakterystyka samego zespołu projektowego, w tym zespołu testowego, ma duży wpływ na proces testowania.

Kluczowe aspekty to:

• Umiejętności i wiedza: Poziom wiedzy technicznej, znajomość domeny biznesowej, doświadczenie w testowaniu i znajomość narzędzi wpływają na to, jakie techniki i podejścia mogą być skutecznie zastosowane.
• Poziom doświadczenia: Bardziej doświadczeni testerzy mogą efektywniej stosować techniki oparte na doświadczeniu i lepiej identyfikować ryzyka.
• Dostępność: Liczba dostępnych testerów i czas, jaki mogą poświęcić na projekt, bezpośrednio wpływają na zakres i harmonogram testów.
• Potrzeby szkoleniowe: Jeśli zespół nie posiada wymaganych umiejętności, konieczne może być zaplanowanie szkoleń, co również wpływa na harmonogram i budżet.

Skład zespołu determinuje, co jest możliwe do osiągnięcia w ramach dostępnych zasobów ludzkich.

3. Domena Biznesowa (Business Domain)

Specyfika branży i obszaru biznesowego, dla którego tworzone jest oprogramowanie, ma fundamentalne znaczenie dla testowania.

Różne domeny niosą ze sobą różne ryzyka i wymagania jakościowe:

• Krytyczność obiektu testowego: Systemy, od których zależy ludzkie życie lub zdrowie (np. oprogramowanie medyczne, systemy sterowania lotem), wymagają znacznie bardziej rygorystycznego i formalnego procesu testowego niż np. prosta strona informacyjna. Poziom ryzyka związanego z awarią jest tu kluczowym czynnikiem.
• Zidentyfikowane ryzyka: Każda domena ma swoje specyficzne ryzyka (np. ryzyko bezpieczeństwa w bankowości, ryzyko wydajności w e-commerce, ryzyko zgodności z regulacjami w farmacji). Testowanie musi być ukierunkowane na mitygację tych kluczowych ryzyk.
• Potrzeby rynkowe: Wymagania rynku dotyczące szybkości wprowadzania nowych funkcji (time-to-market) mogą wpływać na priorytety i zakres testów.
• Złożoność domeny: Bardziej złożone domeny biznesowe (np. systemy ubezpieczeniowe, telekomunikacyjne) wymagają od testerów głębszej wiedzy dziedzinowej.

Testowanie musi być dostosowane do specyfiki i ryzyk danej domeny.

4. Ograniczenia Projektowe (Project Constraints)

Każdy projekt działa w ramach pewnych ograniczeń, które bezpośrednio wpływają na możliwości testowania:

• Budżet: Dostępne środki finansowe ograniczają liczbę testerów, czas trwania testów, możliwość zakupu narzędzi czy szkoleń.
• Czas/Harmonogram: Ograniczenia czasowe (deadline'y) wymuszają priorytetyzację i mogą ograniczać zakres testów.
• Zasoby: Dostępność ludzi, sprzętu, oprogramowania, narzędzi i środowisk testowych.
• Wymagania kontraktowe: Umowy z klientami mogą narzucać specyficzne wymagania dotyczące procesu testowego lub kryteriów akceptacji.

Ograniczenia te wymuszają podejmowanie kompromisów i optymalizację działań testowych w ramach dostępnych możliwości.

5. Czynniki Techniczne (Technical Factors)

Aspekty techniczne tworzonego oprogramowania i środowiska również wpływają na testowanie:

• Jakość podstawy testów i obiektu testowego: Niska jakość wymagań lub kodu źródłowego może utrudniać testowanie i wymagać większego wysiłku.
• Złożoność techniczna: Systemy o skomplikowanej architekturze, wykorzystujące wiele technologii lub integrujące się z wieloma innymi systemami, są zazwyczaj trudniejsze i bardziej czasochłonne w testowaniu.
• Wymagania dotyczące jakości produktu: Specyficzne wymagania dotyczące np. wydajności, bezpieczeństwa, niezawodności czy przenośności determinują potrzebę przeprowadzenia odpowiednich typów testów niefunkcjonalnych.
• Dostępność narzędzi: Dostępność i możliwości narzędzi wspierających testowanie (np. do zarządzania testami, automatyzacji, testów wydajności) wpływają na efektywność i zakres możliwych działań.

Wybór technik testowych, narzędzi i podejścia musi uwzględniać te czynniki techniczne.

6. Model Cyklu Życia Oprogramowania (SDLC Model)

Sposób organizacji procesu tworzenia oprogramowania (np. model kaskadowy, iteracyjny, zwinny) ma bezpośredni wpływ na organizację i timing działań testowych. Omówimy to szerzej w Rozdziale 2, ale już teraz warto zaznaczyć, że:

• W modelach sekwencyjnych (np. Waterfall) testowanie jest często oddzielną fazą na końcu projektu.
• W modelach iteracyjnych i przyrostowych (np. RUP, Spiralny) testowanie odbywa się w każdej iteracji.
• W modelach zwinnych (np. Scrum, Kanban) testowanie jest integralną częścią pracy zespołu w krótkich cyklach, często realizowaną równolegle z developmentem.

Proces testowy musi być zintegrowany z wybranym modelem SDLC.

Dostosowanie Procesu Testowego

Analiza wszystkich tych czynników kontekstowych pozwala na świadome dostosowanie procesu testowego.

Obejmuje to decyzje dotyczące:

• Poziomu formalności: Jak szczegółowa powinna być dokumentacja (plany, przypadki, raporty)?
• Zakresu i głębokości testów: Które funkcje i charakterystyki jakościowe są najważniejsze do przetestowania? Jak dogłębnie?
• Wyboru technik testowych: Które techniki będą najbardziej efektywne w danym kontekście?
• Stopnia automatyzacji: Które testy warto zautomatyzować, a które lepiej wykonać manualnie?
• Organizacji zespołu testowego: Jaka struktura zespołu i podział ról będą optymalne?
• Narzędzi wspierających: Jakie narzędzia będą potrzebne i jak zostaną wykorzystane?

Nie ma jednego