Testowanie zwinne - techniki

Techniki testowania z tradycyjnego testowania mogą być również używane w testowaniu zwinnym. Oprócz tego w projektach zwinnych używane są specyficzne techniki testowania i terminologia zwinna.

Podstawa testu

W projektach zwinnych backlog produktu zastępuje dokumenty specyfikacji wymagań. Zawartość rejestru produktu to zazwyczaj historie użytkowników. W historyjkach użytkownika uwzględniono również wymagania niefunkcjonalne. Zatem podstawą testów w projektach Agile jest historia użytkownika.

Aby zapewnić testowanie jakości, dodatkowo jako podstawę testów można również uznać:

Doświadczenie z poprzednich iteracji tego samego projektu lub poprzednich projektów.
Istniejące funkcje, architektura, projekt, kod i cechy jakościowe systemu.
Defekty danych z bieżących i poprzednich projektów.
Opinie klientów.
Dokumentacja użytkownika.

Definicja ukończenia

Definicja ukończenia (DoD) to kryteria stosowane w projektach zwinnych w celu zapewnienia ukończenia działania w zaległości Sprint. DoD może się różnić w zależności od zespołu Scrum, ale powinien być spójny w ramach jednego zespołu.

DoD to lista kontrolna niezbędnych działań, które zapewniają implementację funkcji i cech w historyjce użytkownika wraz z niefunkcjonalnymi wymaganiami, które są częścią historyjki użytkownika. Historia użytkownika osiąga etap Gotowe po wykonaniu wszystkich czynności na liście kontrolnej DoD. DoD jest wspólny dla całego zespołu.

Typowy DoD dla historyjki użytkownika może zawierać -

Szczegółowe testowalne kryteria akceptacji
Kryteria zapewniające spójność historii użytkownika z innymi w iteracji
Konkretne kryteria związane z produktem
Funkcjonalne aspekty zachowania
Cechy niefunkcjonalne
Interfaces
Wymagania dotyczące danych testowych
Pokrycie testowe
Refactoring
Wymagania dotyczące przeglądu i zatwierdzenia

Oprócz DoD for User Stories wymagany jest również DoD -

na każdym poziomie testowania
dla każdej funkcji
dla każdej iteracji
do wypuszczenia

Informacje testowe

Tester musi mieć następujące informacje o teście -

Historie użytkowników, które należy przetestować
Powiązane kryteria akceptacji
Interfejsy systemowe
Środowisko, w którym system ma działać
Dostępność narzędzi
Pokrycie testowe
DoD

W projektach zwinnych, ponieważ testowanie nie jest czynnością sekwencyjną, a testerzy mają pracować w trybie współpracy, obowiązkiem testera jest:

Uzyskuj na bieżąco niezbędne informacje testowe.
Zidentyfikuj luki informacyjne, które mają wpływ na testowanie.
Rozwiązuj luki we współpracy z innymi członkami zespołu.
Zdecyduj, kiedy zostanie osiągnięty poziom testu.
Zapewnij wykonanie odpowiednich testów w odpowiednim czasie.

Projektowanie testów funkcjonalnych i niefunkcjonalnych

W projektach zwinnych można stosować tradycyjne techniki testowania, ale nacisk kładzie się na wczesne testowanie. Przypadki testowe muszą być przygotowane przed rozpoczęciem implementacji.

Do projektowania testów funkcjonalnych testerzy i programiści mogą korzystać z tradycyjnych technik projektowania testów typu Black Box, takich jak:

Partycjonowanie równoważności
Analiza wartości brzegowych
Tabele decyzyjne
Przejście stanu
Drzewo klas

W przypadku projektowania testów niefunkcjonalnych, ponieważ wymagania niefunkcjonalne są również częścią każdej historyjki użytkownika, techniki projektowania testów czarnoskrzynkowych mogą być używane tylko do projektowania odpowiednich przypadków testowych.

Testowanie eksploracyjne

W projektach zwinnych czas jest często czynnikiem ograniczającym analizę testów i projektowanie testów. W takich przypadkach techniki testowania eksploracyjnego można łączyć z tradycyjnymi technikami testowania.

Testowanie eksploracyjne (ET) definiuje się jako równoczesne uczenie się, projektowanie testów i ich wykonywanie. W testowaniu eksploracyjnym tester aktywnie kontroluje projekt testów w trakcie ich wykonywania i wykorzystuje informacje uzyskane podczas testowania do projektowania nowych i lepszych testów.

Testowanie eksploracyjne jest przydatne, aby uwzględnić zmiany w projektach zwinnych.

Testowanie oparte na ryzyku

Testowanie oparte na ryzyku to testowanie oparte na ryzyku niepowodzenia i ograniczające ryzyko przy użyciu technik projektowania testów.

Ryzyko związane z jakością produktu można zdefiniować jako potencjalny problem z jakością produktu. Ryzyka związane z jakością produktu obejmują -

Ryzyka funkcjonalne
Niefunkcjonalne ryzyko związane z wydajnością
Ryzyka związane z niefunkcjonalną użytecznością

Należy przeprowadzić analizę ryzyka, aby ocenić prawdopodobieństwo (prawdopodobieństwo) i wpływ każdego ryzyka. Następnie priorytetyzuje się ryzyko -

Wysokie ryzyko wymaga obszernych testów
Niskie ryzyko wymaga tylko testów pobieżnych

Testy są projektowane przy użyciu odpowiednich technik testowania w oparciu o poziom ryzyka i charakterystykę ryzyka każdego ryzyka. Następnie przeprowadzane są testy w celu ograniczenia ryzyka.

Testy dopasowania

Testy dopasowania to automatyczne testy akceptacyjne. Narzędzia Fit and FitNesse mogą służyć do automatyzacji testów akceptacyjnych.

FIT wykorzystuje JUnit, ale rozszerza funkcjonalność testowania. Tabele HTML służą do wyświetlania przypadków testowych. Fixture to klasa Java znajdująca się za tabelą HTML. Urządzenie pobiera zawartość tabeli HTML i uruchamia przypadki testowe w testowanym projekcie.