Kiedy powinno się podejmować ryzyko w testowaniu oprogramowania?

Kiedy powinno się podejmować ryzyko w testowaniu oprogramowania?

Marzec 17, 2018 0 przez admin

Sharing is caring!

Kiedy powinno się podejmować ryzyko w testowaniu oprogramowania?

W dzisiejszym szybszym i mądrzejszym świecie , z technologiami, narzędziami i doświadczeniem, jakie mają do swojej dyspozycji firmy zajmujące się oprogramowaniem, możesz założyć, że firmy będą w stanie tworzyć i wypuszczać oprogramowanie, które jest prawie wolne od wad.

Ale tak naprawdę nigdy tak się nie dzieje. Wiele organizacji świadomie wypuszcza produkty z defektami i innymi testami i wersjami pudełkowymi z niesprawdzonymi obszarami funkcjonalności.

Istnieje wiele dobrych powodów, z biznesowego punktu widzenia, dlaczego to ryzyko jest podejmowane przez firmy. Nie zawsze mają one terminy na spełnienie, ale przy ograniczonych środkach przeznaczonych na każdy projekt przekraczanie budżetu jest często mniej atrakcyjne niż wydawanie produktu, w którym mogą występować problemy. W takich przypadkach oprogramowanie z błędami jest lepsze niż żadne oprogramowanie. To uzasadnienie jest całkowicie słuszne, ale kluczem jest zrozumienie, co zostało udowodnione, czego nie udowodniono, a potencjalny wpływ późniejszego przejawiania go jako problemu w wydanym produkcie.

My, jako społeczność testerów, musimy poprawić jakość dostarczania decydentom poprawnych informacji, aby umożliwić im wezwanie “kiedy podjąć ryzyko” uwolnienia lub wdrożenia produktu.

Testowanie jako część działalności ograniczającej ryzyko.

“Ryzyko” definiowane jest jako prawdopodobieństwo lub zagrożenie wystąpienia szkody, obrażeń, odpowiedzialności, straty lub jakiegokolwiek innego negatywnego zdarzenia, którego można by uniknąć, stosując akcje wyprzedzające. W opracowywaniu oprogramowania wymagane jest podjęcie działań wyprzedzających w celu uniknięcia ryzyka.

Z każdą wersją oprogramowania wiąże się ryzyko. Rzeczy mogą być i są pomijane. Decyzja ta, do wydania przed 100% zakończeniem testów i związanymi z nimi problemami, jest kluczem do sukcesu w zakresie opłacalnych, terminowych i odpowiednio przetestowanych wersji oprogramowania. Krótko mówiąc, są to dwa pytania: “kiedy przeprowadzono wystarczające testy?” I, jak zobaczymy poniżej, bezpośrednio związane z tym, “kiedy wystarczająco zminimalizowano ryzyko?”.

Uchwycenie wszystkich “prawdziwych” zagrożeń.

Założeniem tutaj jest to, że nasz projekt, czy to sprawny, wodospad lub którykolwiek z niezliczonych wariantów, zdecydował się zidentyfikować, zestawić, profilować i śledzić ryzyko. Przypadek niektórych sprawnych zwolenników, że proces zwinny został opracowany w celu poradzenia sobie z nieoczekiwanymi problemami i zdarzeniami i dlatego skutecznie nie ma potrzeby identyfikowania ryzyka, radzenie sobie z nimi, gdy stają się problemami, jest zaparkowany na debatę następnego dnia.

Istnieją dwa rodzaje ryzyka, które musimy zidentyfikować i profilować, aby zmaksymalizować prawdopodobieństwo, że nasi decydenci otrzymają duże wezwanie, gdy wystarczy wystarczająco dużo; tradycyjne lub naturalne ryzyko i ryzyko produktu.

Oto przykłady tego, czego moglibyśmy się spodziewać na naszych tradycyjnych dziennikach ryzyka:

Środowisko testowe zostanie zarekwirowane pod kątem poprawki produkcyjnej
Rozwój będzie miał wpływ na datę rozpoczęcia testu
Wyższa niż szacowana gęstość defektów będzie miała wpływ na datę zakończenia testu
Kluczowe zasoby testowe staną się niedostępne
Ale musimy również wziąć pod uwagę ryzyko produktu, takie jak:

Nowy pojedynczy znak w portalu pozwoli niepoprawnie uzyskać dostęp do użytkowników
Link do witryny gromadzenia płatności stron trzecich nie powiedzie się
Po przejściu do trybu “Super Intergalactic Turbo” gra nie powiedzie się na iPadzie
Odcień niebieskiego wyświetlany na niebie gry nie jest spójny w różnych przeglądarkach
Niepoprawne regionalne nagłówki i stopki są stosowane do liter i instrukcji
Ale tylko poczekaj, słyszę twój płacz, to tylko wymagania! Prawidłowo, są, ale aby zapewnić, że otrzymamy duże wezwanie, musimy traktować je jak ryzyko. A dokładniej, profiluj wpływ, jaki na nie wywierają, gdy wykonujemy nasze tradycyjne lub naturalne ryzyko.

Na początku, w ramach inicjowania projektu, definiujemy poziom wymagań, które zostaną sklasyfikowane jako ryzyko produktu, a następnie, przy użyciu naszego narzędzia / metody wyboru ryzyka, określamy wartość liczbową dla każdego ryzyka. Suma tych wartości reprezentuje naszą wartość ekspozycji na ryzyko projektu. Planujemy naszą realizację zgodnie z tradycyjnym podejściem opartym na ryzyku, które powinno zapewnić – o ile to możliwe, że testy związane z ryzykami, które mają najwyższą wartość ekspozycji na ryzyko, są wykonywane w pierwszej kolejności.

akceptowany w zasięgu.

Powyższy wykres wypalenia pokazuje nam, że może się zdarzyć, że decyzja o przerwaniu testów w oparciu o ograniczoną ilość ryzyka zostanie podjęta znacznie wcześniej, niż można się było spodziewać.

Co jeszcze powinno być brane pod uwagę przy podejmowaniu ważnych decyzji.

Istnieje jeszcze jedna część procesu testowania opartego ryzyku, która musi być wzięta pod uwagę i często jest pomijana, gdy nieubłaganie zbliża się deadline. Jest to wpływ strony biznesowej na zespół zajmujący się projektem,

Należy to uwzględnić poprzez odpowiednią reprezentację na wstępnych warsztatach definicji ryzyka i profilowaniu działań w projekcie. Nie wystarcza jednak “przekazywanie” decyzji opartych na ryzyku potencjalnym interesariuszom poprzez protokoły z posiedzeń lub raporty o stanie. W dzisiejszym środowisku pracy, w którym panuje wysokie ciśnienie, świadomość starszych zainteresowanych stron, a nawet ich akceptacja, nie zawsze oznacza zrozumienie.

Wniosek

Podejście to nie powinno być postrzegane jako zmniejszenie ilości testów, ale jeśli zostanie ono rygorystycznie zastosowane, pozwoli na podejmowanie decyzji opartych na ryzyku, kiedy zostaną przeprowadzone wystarczające badania, które zostaną podjęte na podstawie ilościowej, powtarzalnej nauki.

Share Button