Testerzy, którzy trafiają do projektu bądź instytucji stosującej praktyki GxP, są często zaskoczeni panującym tam rygorystycznym podejściem do jakości i dużą ilością dodatkowych reguł i obostrzeń, wpływających na ich codzienną pracę.
Z czego takie surowe podejście wynika? Opowiedzmy o tym od początku.
Czym jest GxP?
Skrót GxP odnosi się do zestawu dobrych praktyk stosowanych w niektórych gałęziach przemysłu i dosłownie rozwija się w „Good x Practices”, gdzie „x” może oznaczać dowolny obszar działania. Najczęściej jest to:
- Good Clinical Practices,
- Good Laboratory Practices,
- Good Manufacturing Practices.
Dlaczego właśnie takie obszary zazwyczaj pojawiają się w GxP? System GxP wykorzystywany jest głównie w przemyśle medycznym, farmaceutycznym, biotechnologicznym i spożywczym. Jak łatwo zauważyć, wszystkie te branże w dużym stopniu bezpośrednio wpływają na zdrowie, a nieraz i życie ludzi. Konsekwencje zaniedbań jakościowych są więc tu znacznie poważniejsze niż w innych dziedzinach, a to z kolei wymusza dużo ostrzejsze regulacje.
Przepisy te zaś narzucane i egzekwowane są przez instytucje takie jak:
- amerykańska FDA (The U.S. Food and Drug Administration),
- europejska EMA (European Medicines Agency),
- australijska TGA (The Australian Therapeutic Goods Administration).
Określenie „dobre praktyki” jest zatem odrobinę mylące, ponieważ stosowanie się do reguł GxP jest obowiązkiem prawnym każdej firmy pozostającej pod nadzorem którejś z tych agencji [źródło: 1].
Czym jest walidacja?
Nietrudno zgadnąć, że GxP rozciąga się również na obszar testowania oprogramowania. Good Documentation Practices oraz Good Testing Practices to także część GxP. Kluczowym zaś narzędziem służącym do implementacji tych dobrych praktyk jest walidacja [źródło: 2].
Walidacja, a w zasadzie CSV (Computerized System Validation), to udokumentowany proces zapewniający, że system bądź program komputerowy spełnia wszystkie ustalone wcześniej wymagania, realizuje dokładnie taki cel, do jakiego go zaprojektowano, i robi to w sposób spójny i powtarzalny.
Z tego wynika, że walidacja jest nieodłącznym elementem całego procesu tworzenia oprogramowania, a walidator – czyli osoba, której zadaniem jest pilnowanie, aby projekt przestrzegał regulacji CSV, i dokumentowanie procesu walidacji – jest zaangażowany w pracę już od etapu definiowania wymagań i szacowania ryzyka.
Warto na początku wspomnieć, że narzędzie do zarządzania testami, w którym pod czujnym okiem walidatora będziemy pracować, zostało wybrane właśnie z jego udziałem. Test Management System musi bowiem spełniać pewne warunki:
- zapewniać traceability pomiędzy testami i wymaganiami,
- ograniczać dostęp i dzielić uprawnienia według ról,
- zapewniać tzw. audit trail, czyli ścieżkę audytu.
W związku z tym w środowiskach regulowanych przez GxP wciąż natrafiamy na te same systemy zarządzania testami, takie jak:
- MicroFocus ALM (dawniej HP ALM/HP Quality Center),
- IBM Engineering Test Management (dawniej Rational Quality Manager),
- Veeva Vault QMS,
- ValGenesis VLMS,
oraz kilka innych, mniej znanych.
Rola walidatora
Udział walidatora w projekcie staje się zauważalny dla testerów (a przynajmniej dla test leada) od samego początku procesu testowego, czyli już w chwili tworzenia test planu. W systemach walidowanych istnienie i formalne zatwierdzenie takiego dokumentu dla każdego release’u jest wymagane.
Walidacja definiuje, jak będzie przebiegać proces zatwierdzania test planu (oraz każdego innego dokumentu w projekcie), kto będzie w nim uczestniczyć i w jakiej roli (to oznacza również wskazywanie, kto będzie autorem danego dokumentu). Walidator jest tu zawsze ostatnią podpisującą osobą i bez jego aprobaty – a co za tym idzie, bez zatwierdzonego test planu – rozpoczęcie formalnego etapu testowania nie jest możliwe.
W trakcie samego przeglądu walidator skupia się na zgodności dokumentu z uprzednio zatwierdzonym wzorcem oraz na tym, czy opisany plan testowania przestrzega reguł GxP, a jeśli nie, to czy odejście od zasad (tzw. dewiacja) jest odpowiednio umotywowane, a związane z tym ryzyko wzięte pod uwagę.
Co zwróci uwagę walidatora?
Przykładowe problemy w test planie, jakie mogą zwrócić (i zwrócą) uwagę walidacji:
- brak wzmianki o tym, że testerzy są prawidłowo przeszkoleni do wykonywania swoich zadań,
- niekompletna lista dokumentacji, z której pochodzą należące do zakresu wymagania,
- nieprawidłowa lista osób zatwierdzających dokument,
- problemy z elektroniczną kontrolą dokumentu (dokument nie umieszczony w systemie zarządzania dokumentacją, zły identyfikator, nieprawidłowy numer wersji itp.),
- nie wszystkie przypadki testowe zostały zawczasu przejrzane i zatwierdzone przez walidację.
Ostatni punkt jest niezmiernie istotny – tak, wszystkie test case’y również są przeglądane formalnie przez walidację (i inne wskazane przez proces osoby, zazwyczaj test leada). W tym przypadku walidatora interesuje głównie to, czy scenariusz testowy jest odpowiednio szczegółowy, czy zawiera prawidłowe odnośniki do wymagań i czy wystarczająco dokumentuje całą pracę testera.
Najczęstsze uwagi zgłaszane przez walidację na tym etapie
Do najczęstszych uwag na tym etapie należą:
- brak odniesienia do wszystkich pokrywanych wymagań,
- niewystarczająca ilość zbieranych dowodów z egzekucji (np. brak instrukcji, aby dołączyć zrzut ekranu w kroku sprawdzającym istotną funkcjonalność),
- zbyt ogólne instrukcje lub opisy oczekiwanych rezultatów (np. „system wyświetla komunikat o błędzie” zamiast „system wyświetla komunikat o błędzie o następującej treści (…)”, albo „stwórz nowy dokument” zamiast „kliknij przycisk „Nowy dokument””),
- nieprawidłowa numeracja kroków,
- użycie danych testowych niezadeklarowanych na początku testu,
- stosowanie nieprecyzyjnego języka (np. „strona ładuje się szybko” zamiast „strona ładuje się w czasie krótszym niż 5 sekund”),
- nieprawidłowa forma gramatyczna instrukcji lub oczekiwanych wyników (w myśl GxP instrukcja powinna być napisana w trybie rozkazującym, a oczekiwane wyniki w czasie teraźniejszym z użyciem strony biernej).
Niektóre z tych uwag mogą się wydać małostkowe i prowadzą do podejrzewania walidacji o złośliwość i czepialstwo, ale wszystkie one mają bezpośrednie źródło w przepisach prawnych stanowiących podstawę GxP (szczególnie w amerykańskim Code of Federal Regulations, rozdział 21, część 11 – skrótowo zwanym „21 CFR part 11” [źródło: 4]).
Szczęśliwie nie wszyscy walidatorzy przywiązują dużą wagę do form gramatycznych lub innych kwestii językowych, ale w przypadku konfliktów pomiędzy zespołem testowym a walidacją lub braku zaufania pomiędzy tymi zespołami częstotliwość podobnych uwag potrafi czasami znacząco wzrosnąć.
Przegląd „test runów”
A kiedy już z sukcesem przebrniemy przez etap zatwierdzania scenariuszy testowych, czas na egzekucję testów, która – zgadliście – jest także oceniana i zatwierdzana. Wybrane uprzednio narzędzie do zarządzania testami umożliwia z pewnością szczegółowy zapis wykonania testu (inaczej nie zostałoby ono dopuszczone do użytku przez walidację).
Te właśnie zapisy, zwane dalej „test runami”, podlegają dokładnemu przeglądowi. Walidator zwraca uwagę na następujące problemy:
- brak zrzutów ekranu pokazujących kluczowe kroki testu,
- zrzuty ekranu niewyraźne, za małe, lub nie pokazujące wszystkich istotnych elementów,
- zrzuty ekranu niezawierające daty i godziny wykonania,
- niedokładny opis faktycznych wyników akcji (np. „wyświetla się prawidłowy komunikat” zamiast „wyświetla się komunikat o następującej treści (…)”),
- niezgodność pomiędzy instrukcją a opisem wykonanej akcji,
- niezgodność pomiędzy oczekiwanymi a rzeczywistymi wynikami akcji, która nie została zgłoszona jako defekt ani oznaczona jako dewiacja,
- test wykonany przez tę samą osobę, która go napisała (to też jest niewskazane z punktu widzenia GxP, a sytuacja, w której musi tak się stać, powinna być opisana w raporcie z testów jako dewiacja).
Walidatorzy obserwują oczywiście również defekty zgłaszane w trakcie tak formalnej egzekucji i mogą zażądać doprecyzowania opisu zgłoszenia bądź załączonych dowodów, stosując te same kryteria, co powyżej.
Walidacja raportu końcowego z testów
Żadną niespodzianką nie będzie już fakt, że końcowy raport z testów podlega równie dokładnemu przeglądowi, co reszta dokumentacji.
W myśl GxP walidatorzy będą tu szukać takich problemów, jak:
- niekompletne lub nieprawidłowe wartości metryk zebranych w trakcie testowania (np. liczba napisanych i wykonanych testów, otwartych zgłoszeń defektów, nieprawidłowych egzekucji itp.),
- przypadki dewiacji nieopisane lub nieumotywowane wystarczająco (np. sytuacja, w której autor testu sam wykonywał swój scenariusz, a nie jest to w raporcie wskazane ani wyjaśnione),
- niezamknięte zgłoszenia defektów pozostawione bez wyjaśnienia i odpowiedniej decyzji,
- brak zatwierdzonej macierzy śledzenia, odnośników do niej bądź inne problemy z tym dokumentem,
- oraz wszystkie ogólne problemy z dokumentacją, wymienione przeze mnie przy okazji omawiania test planu.
Wspomniana macierz śledzenia jest oceniana jedynie pod kątem zgodności z ustaloną wcześniej formą i poprawności zawartych w tabelach informacji, niemniej wraz z raportem z testów jest niezbędna, żeby walidator mógł zatwierdzić decyzję o zakończeniu testowania.
Podsumowanie
Zdawać by się mogło, że taka ilość dodatkowych zasad, przeglądów i podpisów nakłada na testerów dużo nadmiarowych obowiązków i przeszkadza w pracy. Takie wrażenie miewają czasami testerzy zaczynający swoją przygodę w systemie GxP.
Warto jednakże zauważyć, że aby uniknąć większości problemów z walidacją, o jakich tu napisałem, wystarczy starannie dokumentować swoją pracę, dbać o dobrą jakość testowania i – planując testy – brać pod uwagę czas potrzebny na wszystkie walidacyjne aktywności.
Pamiętajmy też, że walidatorzy są tylko ludźmi, którzy – tak jak testerzy i programiści – chcą po prostu wykonywać swoją pracę. Można (i trzeba) porozumieć się z nimi, a wtedy praca w projekcie stanie się łatwiejsza.
Zostaw komentarz