Techniki testowania w podejściu Risk Based Testing

Maciej Kirkicki Starszy konsultant, PwC Poland 25/04/18

Start adding items to your reading lists:
or
Save this item to:
This item has been saved to your reading list.

Testować czy nie testować? Oto jest pytanie!

Decydując się na nową inwestycję, analizujemy koszty oraz stopę zwrotu. Przebudowa bądź projekt nowego systemu informatycznego, takiego jak choćby system zarządzania produkcją to inwestycja, którą chcielibyśmy sfinalizować jak najniższym kosztem, czerpiąc z tego możliwie największe korzyści (na przykład wzrost produktywności w przypadku wspomnianego przed chwilą systemu).

Obecnie systemy informatyczne osiągają taki poziom skomplikowania, że przetestowanie całego zakresu funkcjonalności dostarczanej przez oprogramowanie jest niewydajne ekonomicznie. Najzwyczajniej w świecie zaangażowanie odpowiednio licznego zespołu w celu wypróbowania wszystkich możliwych ścieżek może okazać się droższe od spodziewanych korzyści wynikających z użytkowania nowoczesnego i wydajnego oprogramowania. Czynnikiem nie do przecenienia jest również czas. Bardzo często, żeby wypracować przewagę technologiczną, kluczowym elementem jest Time To Market, który pozwola być o krok przed konkurencją.

Jak wobec tego pogodzić ogień z wodą i doprowadzić do równowagi pomiędzy czasem, kosztami a potencjalnym zyskiem?

 

Odpowiedź brzmi: „Testować, ale mądrze!” Wykorzystaj: Risk Based Testing

Risk Based Testing, jak sama nazwa wskazuje, jest techniką pozwalającą na redukcję wysiłku wkładanego w weryfikację działania oprogramowania poprzez priorytetyzację zadań na podstawie ryzyka, jakie te zadania ze sobą niosą (im większy wpływ na biznes i większe ryzyko wystąpienia problemu, tym wyżej na liście zadań do zrobienia powinno się znaleźć). 

Zwykle projekty informatyczne prowadzimy w modelu iteracyjnym, gdzie z każdym kolejnym przebiegiem sukcesywnie wdrażamy i testujemy nowe elementy aplikacji. W przypadku dużych systemów to podejście szybko wyczerpuje zakładany czas i budżet. W takich sytuacjach zespół testerski przeprowadza analizę ryzyk związanych z projektem i dostarcza ją pozostałym pracownikom zaangażowanym w projekt.

Sama analiza ryzyka, jak i sposoby jego określania, są pojęciem tak złożonym, że doczekały się obszernych opracowań na swój temat, jak choćby PMBoK (Project Management Body of Knowledge) i z racji jej rozmiarów nie będziemy się nią tutaj szczegółowo zajmować. 

 

Risk Based Testing w pigułce

Dość powiedzieć, że zidentyfikowane ryzyka klasyfikujemy według dwóch kryteriów: prawdopodobieństwa wystąpienia oraz skutku (jak krytyczne jest wystąpienie błędu w danej funkcjonalności dla działania biznesu).

Poziom tych ryzyk można określić za pomocą wielu technik. Jedną z nich jest macierz ryzyk, która pozwala na identyfikację i kwantyfikację zidentyfikowanych problemów. Grupuje ryzyka na podstawie iloczynu: 

poziom ryzyka = prawdopodobieństwo * skutek

Tak uzyskaną macierz łatwo przekuć na priorytety: funkcjonalności obarczone największym ryzykiem mają pierwszeństwo we wdrożeniu i testowaniu. 

Stosownie do założonych terminów i budżetu można wykluczyć z planu testy o najniższym priorytecie, a przez to uelastycznić proces wydawania i utrzymać bardzo krótki Time To Market (kosztem potencjalnego wystąpienia pomniejszych błędów w funkcjonalnościach, które wytypowaliśmy jako mniej krytyczne dla działania produktu). 

Należy pamiętać, że nie jest to model idealny do wszystkich rodzajów wdrożeń: systemy krytyczne, obarczone maksymalnym ryzykiem, nawet w przypadku minimalnych błędów nie mogą być w ten sposób implementowane (jak chociażby systemy sterowania aparaturą medyczną, oprogramowanie stosowane w lotnictwie itp.).

W każdym innym przypadku podejście risk based przynosi korzyści w postaci szybkiego wprowadzenia produktu na rynek, sprawnego zarządzania kosztami projektu i w końcu zwiększenia częstotliwości dodawania nowych funkcjonalności lub poprawek do błędów.

W skrócie proces wygląda następująco:

  • opracowanie listy ryzyk na podstawie wyliczonego priorytetu
  • przeprowadzenie testów, które sprawdzają funkcjonalności objęte ryzykiem
  • wraz z „odpadaniem” kolejnych potencjalnych problemów, adaptacja aktywności testowych w celu eliminacji kolejnych potencjalnych zagrożeń

 

Przykładowa macierz ryzyka

Przykładowa macierz ryzyka

Dalsze usprawnianie procesu testowania opartego o zarządzanie ryzykiem

Jeśli zdecydowaliśmy się na model, w którym sukcesywnie dodajemy nowe funkcjonalności, podczas gdy nasza aplikacja już jest w użyciu, to coraz częściej pożądaną praktyką jest łączenie kilku metodyk w jednym procesie opartym o risk based testing: TDD (Test Driven Development) i BDD (Behavior Driven Development).

Test Driven Development

Test Driven Development polega na odwróconym procesie wytwarzania oprogramowania. Mianowicie, programista zanim napisze kod spełniający dane wymaganie (np. kalkulację zniżki dla zadanego kryterium), najpierw stworzy program sprawdzający kod, który ma dopiero napisać. Tak więc najpierw powstanie program, który sprawdzi czy inny program działa zgodnie z oczekiwaniem.

Zaletą tego podejścia jest to, że napisane testy są integralną częścią oprogramowania i mogą być uruchamiane każdorazowo, gdy dokonywane są zmiany w kodzie. Pozwala to na ogromną oszczędność czasu i pieniędzy, ponieważ w przypadku stabilnych wymagań (czyli takich, które raz zdefiniowane nie ulegają częstym zmianom), testy te są powtarzalne i dają nam niemal natychmiast informację na temat stanu aplikacji, zanim jeszcze zaczniemy testy "właściwe" (a więc zaangażujemy zasoby w testowanie, co wiąże się z kosztami).

 

Behavior Driven Development

Behavior Driven Development jest niejako rozszerzeniem metodyki Test Driven - polega na definiowaniu potencjalnych przypadków użycia aplikacji i opisaniu ich w taki sposób, że mogą potem stanowić jednoznaczną instrukcję dla użytkownika.

Wymaga to pewnego usztywnienia w tworzeniu wymagań, ponieważ ograniczeni jesteśmy wtedy narzędziami i językami stosowanymi w tej metodyce (jak np. Cucumber i Gherkin). Tak więc od samego początku osoby zaangażowane w projekt tworzą przypadki testowe, które łatwo potem przekuć w testy automatyczne, ponieważ trzymają się one ściśle określonej składni (potocznie w IT nazywane "podejściem given when then").

 

Zidentyfikowanie podstawowych ryzyk w podejściu Risk Based Testing jest kluczowe

Pozwala to na wytypowanie scenariuszy do automatyzacji, dzięki czemu minimalizujemy szanse na wystąpienie krytycznego błędu po wejściu systemu do użytkowania. 

Projekty prowadzone w sposób dojrzały, z prawidłową identyfikacją potencjalnych problemów, pozwalają na czerpanie w pełni z wypracowanych metodyk. Mamy pewność, że inwestujemy w automatyzację testów kluczowych dla funkcjonowania biznesu, dzięki czemu nie narażamy się na niepotrzebne koszty, albowiem zautomatyzowanie testów niestabilnych wymagań (czyli takich, które ulegają częstym zmianom) może okazać się nieefektywne i drogie.

Bardzo częstym błędem jest automatyzacja testów "na siłę", co powoduje, że zniechęcamy się do tego typu praktyk. Mądre połączenie testów automatycznych z zarządzaniem ryzykiem w projekcie pozwala na szybkie dojście do stabilnych wdrożeń, będąc jednocześnie sposobem na szybsze uzyskanie zakładanych rezultatów. W tak skonstruowanym środowisku dużo łatwiej o podejmowanie krytycznych decyzji dotyczących wypuszczenia produktu, a przez to utrzymania konkurencyjności.

 

Skontaktuj się z nami

Marcin Ciesielski
Partner, Customer Technology
Tel.: +48 500 002 379
Email

Monika Kaczyńska
Dyrektor, PwC Poland
Tel.: +48 572 729 509
Email

Obserwuj nas