Jak zaimplementować Unscripted Testing w systemie oprogramowania jako usługi

Rozszerzając pytanie zadane w temacie, możemy dopowiedzieć: Jak zaimplementować Unscripted Testing w systemie oprogramowania jako usługi i jak uprościć proces w oparciu o ryzyka tak, aby walidacja nie dostała zawału serca?

Przeprowadzanie testów w środowisku walidowanym (GxP) od zawsze było naznaczone dużą ilością dokumentacji. Długi czas tworzenia scenariuszy testowych był podyktowany skryptowymi scenariuszami. Osiągały one niekiedy zawrotną liczbę nawet setki kroków wymaganych do wykonania w jednej sesji testowej.

Liczba kroków generowała wysoką ilość błędów skryptowych odkrywanych w trakcie przeglądu testów przez zespół walidacyjny. Należały do nich małe literówki, ale także błędy zapisów programów do zarządzania testami np. MF ALM.

Testy skryptowe często wymagały tworzenia kopii dla różnych typów testów, których nie dało się sparametryzować. Pojedyncze testy regresyjne sprawdzały jedną ścieżkę przejścia scenariusza testowego, wymagając tworzenia kilku podobnych scenariuszy dla różnych kryteriów akceptacji jednego wymagania.

Przedefiniowanie testów skryptowych

Jak jednak przystąpić do przedefiniowania testów skryptowych, aby zwiększyć wydajność testowania w środowiskach walidowanych biorąc pod uwagę wysokie ryzyka biznesowe i wpływ na zgodność z procedurami?

Na to pytanie odpowiada Exploratory Testing zastosowany wraz z Risk Based Approach.

Testowanie eksploracyjne stawia nacisk na zwiększenie wydajności testowania, na eksplorowanie różnych możliwych ścieżek sprawdzenia kryteriów akceptacji uwalniając kreatywność testerów i budując ich zaangażowanie.

Testy te dzielą się w głównej mierze na:

• Unscripted Exploratory – testy opierające się na sprawdzeniu głównego celu testu przy okazji sprawdzając kryteria akceptacji, dla którego wymagany jest przynajmniej jeden dowód.
• Scenario Based – wymaga dowodów na każde z wymaganych kryteriów akceptacji, dla których przewidziane są osobne kroki w scenariuszu testowym.

Proces wprowadzenia podejścia eksploracyjnego

Jak wiemy, wprowadzenie RBA generuje stworzenie szacunku ryzyk funkcjonalnych (FRA) dla każdego wymagania, zarówno biznesowego – User Story, jak i wymagania funkcjonalnego – Functional Requirement.

Opiszę ten proces w przykładowym projekcie, w którym (wraz z walidacją i analitykiem biznesowym) wprowadziliśmy podejście eksploracyjne.

W projekcie tym wprowadziliśmy więcej zmian niż tylko bazowanie na podejściu eksploracyjnym. Będąc konfigurowalnym, prewalidowanym systemem zewnętrznego dostawcy, system ten był podatny na wprowadzenie również dodatkowego wyznacznika ryzyka – typu implementacji konfiguracji systemu, określanego przez programistów.

Czym jest prewalidowany system?

Projekt, w którym biorę udział, opiera się na środowiskach stworzonych i zwalidowanych pod kątem farmacji z już stworzonymi komponentami dla klinicznych systemów zarządzania.

Dokumentacja Veeva opisuje wszystkie wdrożone funkcjonalności i zatwierdza je podpisami walidatorów. System posiada bardzo dużą część wymaganych, już działających, funkcjonalności, które można przyjąć jako standardowe – Out of the Box. Są także funkcjonalności konfigurowalne – niewymagające tworzenia nowego kodu, tylko modyfikację już istniejących konfiguracji.

Mając na uwadze ryzyka biznesowe, wpływ na życie pacjenta oraz typy implementacji mogliśmy rozrysować poniższy schemat Functional Risk Assessment.

Podejście eksploracyjne w testach akceptacyjnych

Dzięki prewalidacji oraz szerokiemu podziałowi typów implementacji mogliśmy wprowadzić nowe systemowe testy akceptacyjne oparte o podejście eksploracyjne:

• Vendor Leverage – przegląd dokumentacji zewnętrznego dostawcy.
• Configuration Review – przegląd raportu konfiguracji środowiska.
• Unscripted Exploratory – testy pokrywające główną funkcjonalność z przynajmniej jednym dowodem na działanie funkcjonalności, przewidziane dla średnich i wysokich ryzyk zgodności oraz niskiego skomplikowania konfiguracji systemu.
• Unscripted Scenario-based – testy pokrywające poszczególne kryteria akceptacji, każde pokryte przynajmniej jednym dowodem na działanie funkcjonalności, wylistowane w poszczególnych krokach. Są zarezerwowane dla przynajmniej średnich i wysokich ryzyk zgodności i średniego skomplikowania konfiguracji systemu.

Kiedy wprowadzenie testów eksploracyjnych jest możliwe?

Dzięki powyższym informacjom łatwo określić, kiedy wprowadzenie testów eksploracyjnych jest możliwe. Dotyczy to głównie niskich i średnich poziomów ryzyka, ale również wysokiego ryzyka przy prostej implementacji konfiguracji.

Można to przedstawić w poniższy sposób:

Implementacja konfiguracji w systemie prewalidowanym to tak naprawdę zmienianie już istniejących bloków kodu (liczby znaków w istniejących polach, ich widoczności, ich obowiązkowości) lub nawet niezmienianie ich wcale (zwykła konfiguracja), co sprawia, że ryzyko wprowadzenia testów eksploracyjnych jest niższe niż w przypadku tworzenia nowego kodu. Co więcej, gdy wymagania wymuszają stworzenie nowego kodu przy wysokich ryzykach matryca implementacji wskazuje na zastosowanie standardowego, skryptowego podejścia.

Jak w praktyce wypada exploratory testing?

Najważniejszym profitem jest czas, który zyskujemy na wczesne testowanie, dzięki zmniejszeniu liczby powstających testów oraz dzięki ich niskiemu skomplikowaniu.

Projekty mogą zyskać mnóstwo czasu dzięki krótkim testom posiadającym maksymalnie kilka kroków, łatwym do przejrzenia zarówno przez kierownika testów jak i zespół walidacyjny.

Czas tworzenia testów w moim projekcie został zmniejszony nawet o 90%, dzięki czemu zyskaliśmy cenne chwile na dokładne przyjrzenie się wymaganiom i testowanie nieformalne przed głównym cyklem testów akceptacyjnych.

Na pewno byliśmy w stanie zauważyć liczbę kroków skryptowych w naszych projektach, wahającą się od 10 do nawet 150 kroków. Mając na uwadze średnio nawet 20 kroków na test, przy pierwszym kroku testowym dla unscripted exploratory, wysiłek, który wkłada zespół testowy i kierownik testów oraz walidacja, zmniejsza się kilkukrotnie. Zyskujemy natomiast czas i energię na dogłębne testowanie wymagań, zamiast pisania tysięcy skryptów.

Testerzy są w stanie sprawdzać kryteria akceptacji, dzięki przeprowadzaniu eksploracyjnych sesji, które są dużo bliższe procesowi użytkowników końcowych, nie są ograniczeni jedną ścieżką wykonywania testu. W związku z tym są w stanie odkryć dużo więcej błędów nieoczywistych dla analityków biznesowych i programistów.

Zwiększenie czasu na testowanie systemu zamiast dłużącego się i nużącego procesu tworzenia skryptów testowych, wpływa pozytywnie na motywację zespołu, zwiększa ich efektywność i nie ogranicza wyobraźni.

Ryzyko związane z wprowadzeniem testów eksploracyjnych

To wszystko wygląda aż za dobrze, gdzie zatem leży ryzyko? Przyjrzyjmy się temu blizej.

Określenie ryzyka dla funkcjonalności

Jedną z większych trudności w projektach może być właśnie określenie ryzyka dla poszczególnych funkcjonalności. Można brać pod uwagę łączenie ryzyka biznesowego z ryzykiem zgodności (business + compliance risks >>> overall risk) oraz skomplikowanie implementacji danej funkcjonalności, opisane przez deweloperów.

Jeśli projekt nie posiada dużej liczby niskich i średnich ryzyk i/lub posiada funkcjonalności, które wymagają implementacji skomplikowanego kodu, testy unscripted będą zawarte w niskim procencie wymagań i przez to nie zmniejszą liczby testów skryptowych aż tak, jakby to było możliwe przy niższych ryzykach.

Mitygacją tego ryzyka może być odpowiednie oszacowania ryzyk systemu wraz z zespołem walidacyjnym.

Jakość wymagań systemowych

Innym ryzykiem jest jakość wymagań systemowych. Jako że testy unscripted posiadają tylko jeden krok weryfikujący funkcjonalność, samo wymaganie musi być wysokiej jakości, aby tester był w stanie dokładnie sprawdzić kryteria akceptacji w eksploracyjnej sesji testowej.

Gdy specyfikacja systemu jest niskiej jakości, testerzy mogą mieć problem z wykonywaniem testów. Szczególnie, gdy zespół testowy się zmienia i nowi testerzy nie posiadają tak dużej wiedzy o systemie. Na szczęście odpowiednie wsparcie testerów poprzez przygotowanie dem funkcjonalności i wystarczającej ilości nagrań przekazów wiedzy, może zmniejszyć ryzyko braków w wiedzy i zrozumienia systemu.

Podsumowanie

W mojej opinii podejście eksploracyjne jest dużo bardziej opłacalne niż podejście tylko i wyłącznie skryptowe. Dzięki implementacji matrycy ryzyk łatwo jest wskazać odpowiedni typ testu dla danej funkcjonalności.

Rezultatem poprawnego użycia testów eksploracyjnych jest dostarczenie jak najlepszej jakości systemu przy jednoczesnym zachowaniu bezpieczeństwa, zwiększeniu wydajności i zmniejszeniu ilości pracy nad dokumentacją.