January 5th, 2010
Ryzyko w testowaniu oprogramowania można określić procentowo, jako stopień niepewności czy projekt osiągnie założone cele. Ryzyko określa prawdopodobieństwo wystąpienia nieporządanej, zdefiniowanej wcześniej, sytuacji oraz stopień jej wpływu na powodzenie projektu.
Jakie ryzyka wiążą się z zastosowaniem podejścia typu Risk Based Testing?
- niesprecyzowana defininicja 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 pojedyńczym 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 funkcjonanlość 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)
Tags: priorytety, przypadki testowe, test cases, Testowanie
Posted in Testowanie | 1 Comment »
