Tomasz Mielnik
Jakie ryzyka wiążą się z zastosowaniem podejścia typu Risk Based Testing?
- niesprecyzowana definicja ryzyka – umieszczanie ryzyk i błędów w jednej grupie
- subiektywna ocena wpływu ryzyka na projekt oparta na “pasujących” czynnikach
- brak przeglądów listy ryzyk w kolejnych fazach SDLC
Testując oprogramowanie nie da się sprawdzić wszystkich scenariuszy (tak jak nie da się znaleźć wszystkich błędów). Dlatego tak ważne jest podjęcie decyzji co testujemy, a czego nie. Na których obszarach aplikacji skupić uwagę, a które uznać za “niezagrożone”. Testowanie np. metodami czarnej skrzynki z użyciem klas równoważności czy wartości brzegowych zapewnia co prawda pokrycie funkcjonalności testami, ale przy okazji powoduje, że liczba przypadków testowych (test cases) rośnie. Co więcej nie wszystkie z nich są tak samo istotne z punktu widzenia jakości systemu, czasu, który mamy na testowanie oraz wymagań klienta.
Sposobem na zmniejszenie liczby przypadków testowych jest wybranie tych funkcjonalnych obszarów aplikacji, które są najbardziej podatne na błędy oraz tych, których uszkodzenie może spowodować największe koszty.
Gdzie i kiedy spodziewać się największej liczby błędów?
To tylko kilka czynników, które warto wziąć pod uwagę przy ustalaniu zakresu testów aplikacji. Moim zdaniem - ważnych, ale jak zwykle wszystko zależy od kontekstu i danego projektu.
Złożone funkcjonalności
Złożoność jest jedną z najczęstszych przyczyn powstawania błędów: wiele zmiennych użytych w kodzie, rozłożony na wiele kroków przepływ danych, skomplikowana logika biznesowa, zgromadzenie w jednym module wielu funkcji, których interfejsy wychodzą na zewnątrz.
Obszary systemu, które zostały zmodyfikowane/przepisane
Testy regresywne powinny załatwić sprawę. Jednak i one mają swoje priorytety, które mogą zmienić się po wprowadzeniu zmian w funkcjonalności. Innego rodzaju zagrożeniem przy wyborze scenariuszy testowych do testów regresywnych jest paradoks pestycydów.
Wiele zmian w pojedynczym module systemu może być symptomem źle wykonanej analizy. To sygnał, aby otworzyć plik z wymaganiami i przypadkami użycia (Use Cases) - jeśli mamy ich zaktualizowaną wersję.
Liczba osób zaangażowanych w programowanie/testy
Im więcej osób jest zaangażowanych w zadanie tym większy nakład środków i czasu na komunikację. Wydłużony przepływ informacji prowadzi do ich zniekształcenia, nadinterpretacji czy pomijania. Może działać to zarówno podczas kodowania jak i przy testach.
Jakość wykonania testów (nie mówię tu o jakości aplikacji, ale o jakości pracy) jest ważniejsza niż odpowiedź na pytanie “Zostało nam trzy tygodnie na testy. Ile dodatkowych osób możemy w nie zaangażować?”. Jedną z metryk (z pewnością nie najlepszą) wydajności testera jest liczba zgłoszonych przez niego błędów.
Trudno jest porównać trójosobowy, doświadczony zespół testowy i zgłoszone przez niego błędy ukryte w architekturze systemu z 10-cioosobową grupą nie-testerów, którzy testują w międzyczasie i chcąc wykonać przypadek testowy, a więc przejść z ekranu A na ekran B, zaglądają np. do kodu aplikacji.
Presja czasu, zarówno przy kodowaniu jak i testach
Błędne estymacje czasu, problemy w komunikacji, sytuacje nieprzewidziane podczas fazy analizy ryzyka projektu. Wszystko to powoduje opóźnienia zarówno w fazie kodowania jak i testów. Brak czasu jest wrogiem jakości. Skłania do pomijania pierwotnie obranej ścieżki i stosowania skrótów.
Pytania jakie warto zadać przed podjęciem decyzji co testujemy:
- które elementy aplikacji mogą zostać przetestowane we wczesnej fazie SDLC?
- które części kodu/moduły są najbardziej skomplikowane i dlatego najbardziej narażone na wystąpienie błędów?
- która funkcjonalność jest najważniejsza z punktu widzenia zastosowania projektu?
- która funkcjonalność jest najbardziej widoczna dla klienta?
- które z testów mają najlepszy współczynnik pokrycia obszarów o wysokim ryzyku do czasu potrzebnego na testowanie?
- które z wymagań zostały zmienione lub ogólnie zdefiniowane?
- która funkcjonalność ma największy wpływ na bezpieczeństwo aplikacji?
- która funkcjonalność ma największy wpływ na finanse?
- Które elementy testowanej aplikacji mają największe znaczenie dla klienta?
- które aspekty podobnych, ukończonych poprzednio projektów powodowały problemy?
- które elementy podobnych, ukończonych projektów powodowały największe problemy w fazie utrzymania (maintenance)?
- co programiści uznają na najbardziej narażony na ryzyko element aplikacji?
- która część systemu była tworzona pod presją czasu?
- jaki rodzaj problemów może spowodować negatywną reakcję klienta?
- jaki rodzaj testów może pokryć możliwie najwięcej funkcjonalności?
- które z poprzednio wykonanych przypadków testowych powodowały wykrycie błędów? (test case value)
Powyższy artykuł jest przedrukiem z wygasłego bloga testerskiego testowanie.net
