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?
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ć.
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:
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:
Przykładowa macierz ryzyka
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 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 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").
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.