Testerzy odpowiadają testerom 16: Analiza mapowania wymagań i testów "wiele do wielu". Przypadek z życia wzięty.

MIREK PISZE:

Chodzi mi o sytuację, kiedy mam do czynienia z mapowaniem wymagania <-> przypadki testowe typu wiele do wielu, czyli np. tak, jak w tabelce poniżej:

Jako część raportu muszę zrobić zestawienie wymagania vs wynik testów (W1: OK, W2: OK, W3: NOK, itd)

Załóżmy, że przypadek testowy "P2" nie przechodzi.
Wiem, że błąd jest spowodowany przez źle zaimplementowane wymaganie "W10".
Wiem też, że wymaganie "W2" jest zaimplementowane dobrze.

Chciałbym więc w raporcie z testów uznać wymaganie "W2" jako "OK" mimo, że jeden z przypadków testowych z nim powiązanych jest "Failed" (przypadek P2). Zawsze tak robiłem (w poprzednich projektach) i nie było z tym problemu.

Dziś zarzucono mi, że nie mogę tak robić i powinienem:
a) mapować wymagania <-> przypadki testowe "jeden do jeden" albo
b) wszystkie wymagania związane z "P2" uznawać za źle zaimplementowane, bo przecież test nie przeszedł.

Udało mi się "obalić" podpunkt a) opierając się o sylabus ISTQB poziomu zaawansowanego. To dobra wiadomość, bo projekt jest skomplikowany i nie dałoby się napisać tak przypadków testowych, żeby mapowanie wymagania <-> testy było jeden do jeden (albo jeden do wielu).

Potrzebuję jeszcze wskazówki, skąd mogę wziąć potwierdzenie na obalenie punktu b) - czyli, że możliwe jest uznanie wymagania za spełnione w przypadku, gdy jeden z przypadków testowych nie przechodzi (a wiem, że błąd jest spowodowany przez problem z innym wymaganiem).
 

TESTERZY ODPOWIADAJĄ:

Ciekawy przypadek, ale zakładam, że nie da się łatwo wskazać źródła do uzasadnienia / obalenia tezy.

Pytanie: dlaczego P2 nie przeszło?

Domyślam się, że może być kilka możliwości:

- P2 realnie nie daje pokrycia W2

- P2 jest na tyle wysokopoziomowy, że podczas wykonywania testów można samodzielnie dopisywać do niego dane i dla konkretnego zestawu danych wiemy, że W2 nie jest zaliczony.

MIREK ODPOWIADA:

Nasze ograniczenia organizacji projektu:

1.      wymagania są dane przez klienta i nie możemy ich zmienić (np. podzielić na mniejsze)

Uzasadnienie: podział wymagań ma mniejsze nie rozwiąże problemu, tylko go przeniesie na inny poziom – wtedy ktoś inny, np. analityk będzie musiał podejmować taką samą decyzję – czy na podstawie podzielonych wymagań uznać wymaganie główne za OK/NOK. W przypadku wymagań wielopoziomowych – problemu tez nie uda się uniknąć.  

2.      nie możemy podzielić przypadków testowych na "mniejsze".

Uzasadnienie: proste przypadki testowe z przykładu poniżej można podzielić na mniejsze, ale w konkretnych zastosowaniach, w realnych projektach – zawsze można dojść do takiej sytuacji, że przypadków testowych nie da się podzielić (szczególnie w przypadku testowania wymagań wielopoziomowych).

Może najlepiej będzie uzasadnić sytuację przy użyciu przykładu:

Testujemy samolot.

Zajmujemy się wycinkiem funkcjonalności - włączaniem silników.

Samolot ma 4 przełączniki do włączania każdego silnika z osobna.

Po włączeniu danego przełącznika powinny wykonać się następujące akcje:

1.      Włączyćdany silnik.

2.      Zapalić diodęw kabinie pilota, która potwierdza, że silnik jest włączony.

3.      Wysłać informację(w postaci sygnału na magistralę) do pozostałych komputerów w samolocie, żeby poinformować je, że dany silnik pracuje.

Wymagania klienta są spisane w następującej formie:

W1: "Po włączeniu przełącznika odpowiadającego za dany silnik - silnik ma się włączyć"

W2: "Po włączeniu danego silnika - ma się zapalić dioda w kabinie, przypisana do danego silnika"

W3: "Po włączeniu danego silnika - ma zostać wysłany sygnał na magistralę informujący o włączeniu danego silnika"

Są zbudowane 4 przypadki testowe, po 1 dla każdego silnika:

P1:

Krok 1: włącz przełącznik od silnika "1"

Krok 2: sprawdź, czy silnik "1" został włączony

Krok 3: sprawdź, czy zapaliła się dioda od silnika "1"

Krok 4: sprawdź, czy został wysłany sygnał dla silnika "1"

Pozostałe przypadki P2, P3, P4 - analogicznie, dla każdego silnika

Teraz macierz mapowania wymagań i przypadków wygląda tak:

Czyli przypadek P2 testuje wymagania W1, W2 i W3.

Wyniki testu:

Przypadki P1, P3 i P4 przeszły.

Przypadek P2 nie przeszedł. Silnik się włączył, dioda się zapaliła, ale sygnał nie został wysłany.

W takim przypadku jest dla mnie jasne, że wymagania W1 i W2 są spełnione, a wymaganie W3 nie jest spełnione.

Innymi słowy, mimo że przypadek P2 nie przeszedł, to nie uznaję wszystkich wymagań z nim związanych za niespełnione, a tylko te, które rzeczywiście nie przeszły.

TESTERZY ODPOWIADAJĄ:

W3 jest wymaganiem, które realizowane jest dla wielu środowisk, ale gdy jest tak zapisane, przychylam się do tego, że nie jest zaliczone.

Pseudorozwiązaniem jest rozpisać je w Matrycy na cztery wymagania dla czterech silników: W3.1, W3.2, W3.3 i W3.4. Po uruchomieniu testów jak nic wychodzi, że W3.2 jest niespełnione. Jednak jest to poniekąd podział na mniejsze.

Przypadek testowy P2 nie przeszedł, bo nie zostało spełnione wymaganie W3.

Gdyby podzielić przypadek na kroki: P2.1, P2.2, i P2.3, to tylko W3 jest niespełnione.
Nie mogąc dzielić ani wymagań, ani przypadków jesteś w kropce i musisz przyjąć zewnętrzną interpretację. Jest to bez sensu z testerskiego punktu widzenia, ale jest poniekąd logiczne.

MIREK ODPOWIADA:

Teraz upewniłem się, że miałem rację - że jest sens w tym, co przyjąłem za interpretację wyników.

Nie mogłem dzielić wymagań, bo były to wymagania klienta. Potencjalnym rozwiązaniem jest "przepisanie" wymagań klienta na wymagania "wewnętrzne" (i przy okazji podzielenie ich na wygodne, małe porcje) przez zespół analityków. No i wtedy ja mapuję moje przypadki testowe do wymagań wewnętrznych. No a odpowiedzialność za mapowanie wymagań klienta do wymagań wewnętrznych zostawiam analitykom. Problemem jest jak zwykle czas - bo nie mamy na to ani czasu, ani ludzi, żeby przepisywać wymagania i nimi dodatkowo zarządzać.

Nie mogłem podzielić przypadków testowych z powodu ograniczeń narzędzi i spowodowanego tym dużego wzrostu testów - testy trwałyby zbyt długo.

SPRAWDŹ TAKŻE
Testerzy odpowiadają testerom 15
Testerzy odpowiadają testerom 14
Testerzy odpowiadają testerom 13
Testerzy odpowiadają testerom 12
Testerzy odpowiadają testerom 11