Odpowiedź.

Określenie granic testowania (scope) to fundamentalne zadanie dla testowania manualnego, które pozwala skupić się na najbardziej istotnych i krytycznych częściach aplikacji.

Historia pytania

Wraz z rozwojem projektów zakres testowanych funkcji rośnie, a ręczne pokrycie wszystkich scenariuszy staje się niemożliwe. Wraz z pojawieniem się Agile/rozwoju inkrementalnego rola określenia scope znacznie wzrosła.

Problem

Jeśli granice testowania są niejasne, pojawia się ryzyko:

Przeprowadzenia nieefektywnego testowania, wydając zasoby na mało znaczące funkcje
Przeoczenia krytycznych błędów w ważnych scenariuszach
Kolizji z pracą innych testerów, co prowadzi do powielania działań

Rozwiązanie

Zakres testowania powinien być określany na podstawie:

priorytetów biznesowych, scenariuszy użytkownika i ryzyk
analizy wymagań, historii użytkowników i specyfikacji
konsultacji z zespołem (analitycy, menedżerowie produktu, programiści)

Kluczowe cechy:

Skupienie na głównych funkcjach i obszarach ryzyka
Wyraźne zarejestrowanie/dokumentowanie zakresu w planie testów, aby uniknąć nieporozumień
Możliwość szybkiego przeglądu scope przy zmianie wymagań

Pytania z pułapką.

Czy zawsze trzeba testować wszystko, co zostało zaimplementowane, nawet najmniejsze szczegóły?

Nie, zasada testowania — skupienie na priorytetowych i krytycznych częściach, szczególnie tam, gdzie najprawdopodobniej wystąpią błędy i błędy będą miały istotny wpływ na biznes.

Czy tester może samodzielnie rozszerzać lub zawężać scope, gdy pojawiły się nowe wymagania bez uzgodnienia?

Nie, wszelkie zmiany scope należy uzgadniać z menedżerem produktu lub liderem zespołu, aby uniknąć luk lub powielania pracy.

Czy wystarczy polegać tylko na dokumentacji technicznej przy określaniu scope?

Nie, należy brać pod uwagę również kontekst biznesowy, rzeczywiste zadania użytkowników, opinie od klienta.

Typowe błędy i antywzorce

Zakres nie jest ustalony i ciągle się zmienia
Ignorowanie priorytetów biznesowych na rzecz funkcji drugorzędnych
Brak komunikacji między członkami zespołu przy zmianie granic testowania

Przykład z życia

Negatywny przypadek

Tester postanawia samodzielnie pokryć wszystkie funkcje i przypadki, w efekcie brakuje czasu na testowanie krytycznych ścieżek, a główne błędy umykają.

Zalety:

Formalnie przetestowano wiele scenariuszy

Wady:

Krytyczne blokujące błędy pozostają niezauważone przez rozpraszanie uwagi
Opóźnienia w terminach z powodu nieuzasadnionego dużego zakresu testowania

Pozytywny przypadek

Na początku sprintu tester uczestniczy w planowaniu, ustala zakres wspólnie z całym zespołem, kładąc nacisk na najważniejsze scenariusze użytkowników, uzgadnia zakres prac i dokumentuje go w Confluence.