Test management

Test Management

Zarządzanie testami czyli test management można porównać do sztuki planowania i kierowania testami w taki sposób by osiągnąć sukces. Pod wieloma względami jest to podobne do zarządzania projektem, ale jednak nie jest to to samo. Z pewnością zarządzanie testami musi odbywać się w oparciu o zarządzanie projektem. Kierownik testów jest kimś w rodzaju pośrednika pomiędzy zespołem testowym, zespołem developerów a managementem wyższego stopnia. Dlatego niezbędne jest, by test manager pełnił rolę reprezentanta, który w pełni rozumie w jaki sposób testowanie przyczynia się do realizacji celów biznesowych.
W tym artykule dowiesz się trochę więcej na temat wartości biznesowej testowania. Będzie to pierwszy artykuł z serii na temat zarządzania testami.

Wartość biznesowa testów

Na pierwszy rzut oka, można stwierdzić, że testowanie nic nie zmienia. Produkt, który jest testowany, po przeprowadzeniu samych testów zasadniczo jest taki sam. Więc czy testowanie dostarcza jakąś wartość?
Zastanów się, czy wartością można nazwać fakt, że organizacja często oszczędza (czas, pieniądze) dzięki ulepszeniom opartych na informacjach, które są dostarczane po zakończonych testach.

Czasami trudno zrozumieć i wyrazić czym jest wartość, zarówno dla nas samych, jak i dla innych osób w organizacji. Dlatego tak istotne jest, by kierownicy testów znali i dobrze rozumieli wartość, którą przynosi testowanie i wiedzieli jak ją wyrazić, aby pozostali członkowie zespołu mogli również to zrozumieć. Kierownicy testów muszą przekazywać tą wartość testerom, członkom zespołu oraz kierownictwu wyższego szczebla.

Cel testów

Możemy powiedzieć, że jednym z celów testowania jest zbieranie informacji na temat testowanego produktu. Bo czym jest gromadzenie logów z działania aplikacji, raportów z testów czy incydentów? Na tej podstawie możemy uzyskać bardzo wiele przydatnych informacji na temat testowanego oprogramowania. Im więcej mamy informacji na temat oprogramowania, tym łatwiej jest nam znaleźć w nim błędy albo konkretną ich przyczynę.

Przypadki biznesowe

Ustanowienie uzasadnienia biznesowego dla procesu testowania nie jest proste, ponieważ nie wiemy (z góry), jakie oszczędności testowanie nam dostarczy. Nie wiemy też ile wad produktu zostanie ujawnionych.
Sposób w jaki możemy wyrazić wartość testowanego produktu opiera się na koszcie jakości. Można to wyrazić jako wartość poprawy:

  • Produktu = (koszt awarii nieznalezionych – koszt awarii znalezionych) – koszt detekcji.0
  • Decyzji = (koszt złej decyzji – koszt dobrej decyzji) – koszt podjęcia decyzji.
  • Procesu = (koszt używania starego procesu – koszt używania lepszego procesu) – koszt ulepszenia procesu.

Te trzy aspekty składają się na całość przypadków biznesowych na potrzeby testów.
Na sam koniec tego wstępu należy jeszcze zaznaczyć, że wartość możemy wyrazić ilościowo lub jakościowo. Wartości ilościowe można przedstawić jako liczbę np. kwota pieniędzy. Wartości jakościowych nie można obliczyć tak jak wartości ilościowych, ale za to mogą być wyrażone w postaci innych terminów czy wręcz w postaci odczuć.

Wartość poprawy produktu

Jednym z celów tworzenia oprogramowania jest niezawodność produktów, które dostarczamy klientom. Niezawodność to prawdopodobieństwo, że oprogramowanie nie spowoduje awarii systemu przez określony czas w określonych warunkach. Niezawodność produktu jest mierzona prawdopodobieństwem wystąpienia usterek w produkcie w trakcie użytkowania.

Im mniej błędów pozostanie w wydanym przez nas oprogramowaniu, tym wyższa będzie jego niezawodność, a co za tym idzie, niższe ryzyko awarii. Ryzyko projektu waha się od ignorowalnego do zagrażającego życiu ludzi lub firm.
Jak już wielokrotnie wspominałam, im szybciej znajdziemy błąd i go naprawimy, tym jego koszt będzie mniejszy. Koszty znalezienia i naprawy błędu rosną w czasie. Jeśli awaria nastąpi, gdy oprogramowanie już działa produkcyjnie, koszty będą bardzo wysokie, ponieważ potrzebne będzie wprowadzenie poprawek, włączając w to koszta, które może ponieść klient. Analitycy i programiści, którzy muszą naprawić błędy prawdopodobnie zostaną oderwani od swoich bieżących zadań, co z kolei może prowadzić do opóźnień w ich projekcie, nad którym pracowali do tej pory.

Błędy, które nie zostaną zaopiekowane paradoksalnie mogą się “mnożyć”. Błędy wprowadzone na wczesnym etapie będą powodować coraz to więcej problemów.

Podczas opracowywania przypadku biznesowego bywa, że mamy do czynienia z elementem estymacji. Wynika to z tego, że firmy często nie wiedzą ilu błędów można się spodziewać, jak wiele może kosztować ich znalezienie oraz ich naprawa. Oczywiście tutaj z pomocą może przyjść doświadczenie oraz dane historyczne na temat testów i błędów. W ten sposób będzie nam łatwiej oszacować ryzyko, a zatem przygotować realne estymacje.

Przykład

Wróćmy do wykresu i przyjmijmy założenia.
W przypadku znalezienia błędu na produkcji – koszt naprawy może wynieść 10000 jednostek. W przypadku znalezienia błędu na etapie wewnętrznych testów ten koszt wyniesie 1000 jednostek. A gdy zostanie znaleziony na etapie projektowania i wymagań koszty będą wynosić odpowiednio 100 i 10.
Jeśli założymy, że korekta wady wymagań kosztuje 2 jednostki, a koszt wykrycia błędu wynosi 4, to w ten sposób uzyskamy kalkulację:
(210000 – 21000) – 4 = 17996 jednostek
Wartość znalezienia błędu w systemie na etapie testów zamiast na produkcji wynosić będzie 17996 jednostek.
(21000)-(2100) – 4 = 1796
Wartość znalezienia błędu w systemie na etapie projektowania zamiast na etapie testowania wynosi 1796.
A teraz za te jednostki wyobraź sobie np. walutę. I zobacz jak wielka to różnica.
Badania mówią, że około 50% wad wykrytych w całym cyklu życia produktu można przypisać defektom wprowadzonym podczas prac nad specyfikacją wymagań. Dużo, prawda?
To pokazuje, jak ważne jest testowanie na wczesnym etapie.

Wartość poprawy decyzji

Gdy podejmujemy różne decyzje np. takie dotyczące wydania produktu (lub też nie), zaufanie do produktu wydaje się być kluczowe. Zaufanie to jest proporcjonalne do jakości i ilości informacji jakie będziemy posiadać na temat wydania. W miarę postępu testów będziemy mieć coraz więcej informacji (co, jak zostało przetestowane, jakie błędy zostały usunięte, które nadal pozostają) co z kolei teoretycznie powinno nam ułatwić podjęcie decyzji. Wartość świadomych decyzji (podpartych wiedzą)ma charakter jakościowy a nie ilościowy.

Przeanalizujmy powyższy diagram.
Mając dobry kod i dobry test będziemy mieć zaufanie co do jakości produktu. Jeśli będziemy mieć złej jakości kod i złej jakości testy (np. będzie ich bardzo mało) – będziemy świadomi, że jakość produktu jest nieznana (lub nawet bym powiedziała – zła).
Nieco bardziej skomplikowana jest sytuacja, gdy mamy dobrej jakości kod, ale złe testy – też nie możemy mieć zaufania do oprogramowania. Natomiast gdy mamy złej jakości kod, ale wystarczającą ilość testów, to jesteśmy w stanie przewidzieć jakość. Ta ostatnia sytuacja występuje jednak bardzo rzadko.
Tak naprawdę nie tylko ważne decyzje na temat produktu mogą być podejmowane na podstawie wyników testów. Czasami dobra dokumentacja testowa, wyniki testów mogą pomóc nam dowieść, że wykonaliśmy wszystkie czynności jak należy. Ba, nawet w skrajnych przypadkach może stanowić dowód w sprawie, gdyby ktoś zarzucał firmie np. jakieś zaniechanie. Wtedy takie testy również mają wartość jakościową dla firmy.

Wartość poprawy procesu

Z punktu widzenia poprawy procesu informacje uzyskane na podstawie przeprowadzonych testów są nieocenione w analizie tego, jak dobrze procesy służą organizacji. Wyniki takiej analizy można wykorzystać do zidentyfikowania procesu, który może być przedmiotem doskonalenia. Poprawie może ulec zarówno proces testowania, jak i inne procesy.
Z upływem czasu, wyniki testów mogą nam powiedzieć, jak działała inicjatywa poprawy procesu w organizacji. Gdy proces testowania ulegnie poprawie, liczba awarii spadnie, a reputacja organizacji w zakresie dostarczania produktów wysokiej jakości powinna wzrosnąć. Wartość poprawy procesu jest jakościowa.

Podsumowanie

Jak widzisz zagadnienie związane z test management jest to dosyć rozległy temat. Warto go zrozumieć. Zapamiętaj 3 podstawowe zagadnienia z tego artykułu – wartość poprawy produktu, decyzji oraz procesu. Testowanie jest procesem, który wymaga dobrego zarządzania. W kolejnym artykule dowiesz się jeszcze więcej o zarządzaniu testami w tym o dokumentacji testowej która niezwykle się przydaje.

Na codzień pracuje jako Lead Software Quality Assurance Engineer w firmie Emphie Solutions . Testowanie to jest to co lubi najbardziej. Prywatnie kocha gotować, grać w gry planszowe i podróżować. Jest niepoprawną kociarą.
PODZIEL SIĘ