Ryzyko Produktowe vs Ryzyko Projektowe

Jedną z czynności, jaką dobrze jest wykonać podczas procesu testowania, jest identyfikacja, a następnie uwzględnienie określonych ryzyk. Wszystkie ryzyka możemy podzielić na ryzyka produktowe oraz ryzyka projektowe.

Ryzyka produktowe – ryzyka bezpośrednio powiązane z przedmiotem testów.

Ryzyka projektowe – ryzyka związane z zarządzaniem i kontrolą projektu (testowego), np. braki w zasobach, rygorystyczny harmonogram, zmieniające się wymagania itp.

Szerszy opis wspomnianych ryzyk przeczytasz poniżej.

Ryzyka produktowe

Inaczej nazywane ryzykami jakościowymi. Ich definicja w słowniku ISTQB jest dość lakoniczna. Myślę, że dobrym jej rozwinięciem będzie określenie, że do tych ryzyk zaliczymy wszystkie zdarzenia, które mogą wystąpić w trakcie trwania projektu, powodując, że produkt nie będzie spełniał założonych celów. Poniżej zamieszczone są przykłady, związane z ryzykiem produktowym:

błędy związane z integracją ze sprzętem,
brak pamięci w urządzeniu,
niepoprawne zaokrąglenia.

Ryzyka projektowe

Zamienną nazwą są ryzyka planowania, czyli wszystkie zdarzenia, które mogą spowodować, że nie uda się zakończyć projektu przy zakładanych atrybutach, czyli na przykład harmonogramu czy budżetu. Przykładami takich ryzyk mogą być:

absencja członków zespołu,
brak dostarczenia sub-produktów przez wykonawców,
opóźnienia w developmencie.

Ryzyka w procesie testowym

1	W pierwszym kroku powinniśmy się skupić na identyfikacji wszystkich ryzyk. Jeśli nie jest to pierwszy projekt, najlepszym punktem wyjścia do zrealizowania tego jest przegląd dokumentów z retrospektyw z poprzednich projektów. Dzięki temu będziemy mogli stworzyć wstępną listę. Co więcej, można ją uzupełnić o dane z sesji burzy mózgów czy wykonać niezależną, subiektywną analizę projektu. W niektórych przypadkach jest możliwość skorzystania z zewnętrznych lub wewnętrznych list kontrolnych.
2	Mając już spisane wszystkie ryzyka, możemy podejść do ich podziału na ryzyka projektowe oraz produktowe. Trzeba mieć świadamość, że nie będą to listy zamknięte, a nowe ryzyka będą się pojawiać podczas trwania projektu.
3	W kolejnym kroku należy przystąpić do oceny ryzyk, kiedy to każdemu z nich przypisujemy odpowiednie prawdopodobieństwo wystąpienia, a także wpływ ewentualnego zajścia danego zdarzenia. Najczęściej prawdopodobieństwo określa się w skali od 1 do 5. Z kolei wpływ dobrze jest zapisywać słownie, ze względu na potrzebę raportowania kierownictwu, a następnie również przetłumaczyć na skalę w zakresie 1-5, przyjmując jako wykładnię krytyczność wpływu. Dobrymi przykładami wpływu danego ryzyka może być utrata reputacji, złamanie prawa, czy negatywny wpływ na bezpieczeństwo.
4	Następny etap to łagodzenie zidentyfikowanych ryzyk. W przypadku ryzyk jakościowych, do każdego należy przypisać odpowiednią liczbę testów, która pokryje je w pełni. W przypadku braku testów dla wybranych ryzyk oznacza to, że zostały one zaakceptowane przez zespół. W przypadku ryzyk planowania, sprawa jest trochę bardziej skomplikowana, gdyż w niektórych przypadkach nie jesteśmy stanie dokonać wcześniej żadnych działań, aby je zminimalizować. W takim przypadku dobrą opcją jest przygotowanie potencjalnych działań naprawczych, dzięki czemu reakcja na wystąpienie konkretnego ryzyka będzie szybsza oraz bardziej właściwa. Takimi działaniami może być zorganizowanie potencjalnego zastępstwa, czy posiadanie alternatywnych źródeł dostaw.

Jak widzimy, zarządzanie ryzykiem podczas całego procesu testowego jest istotnym elementem. Wynika z tego także szereg korzyści, takich jak ułatwione przydzielanie priorytetów do konkretnych wymagań, a później testów. Z punktu widzenia całego projektu możemy znacznie szybciej wykryć zagrożone obszary, a dzięki temu kluczowe defekty. Dodatkowo wiemy które obszary należy bardziej przetestować w głąb. Wdrażając wszystkie czynności łagodzące ryzyka, możemy ograniczyć skutki działań niepożądanych do minimum.