Skr\u00f3t GxP odnosi si\u0119 do zestawu dobrych praktyk stosowanych w niekt\u00f3rych ga\u0142\u0119ziach przemys\u0142u i dos\u0142ownie rozwija si\u0119 w \u201eGood x Practices\u201d, gdzie \u201ex\u201d mo\u017ce oznacza\u0107 dowolny obszar dzia\u0142ania. Najcz\u0119\u015bciej jest to:<\/p>\n\n\n\n
- \n
- Good Clinical Practices,<\/li>\n\n\n\n
- Good Laboratory Practices,<\/li>\n\n\n\n
- Good Manufacturing Practices.<\/li>\n<\/ul>\n\n\n\n
Dlaczego w\u0142a\u015bnie takie obszary zazwyczaj pojawiaj\u0105 si\u0119 w GxP? System GxP wykorzystywany jest g\u0142\u00f3wnie w przemy\u015ble medycznym, farmaceutycznym, biotechnologicznym i spo\u017cywczym. Jak \u0142atwo zauwa\u017cy\u0107, wszystkie te bran\u017ce w du\u017cym stopniu bezpo\u015brednio wp\u0142ywaj\u0105 na zdrowie, a nieraz i \u017cycie ludzi<\/strong>. Konsekwencje zaniedba\u0144 jako\u015bciowych s\u0105 wi\u0119c tu znacznie powa\u017cniejsze ni\u017c w innych dziedzinach, a to z kolei wymusza du\u017co ostrzejsze regulacje.<\/p>\n\n\n\n
Przepisy te za\u015b narzucane i egzekwowane s\u0105 przez instytucje takie jak:<\/p>\n\n\n\n
- \n
- ameryka\u0144ska FDA (The U.S. Food and Drug Administration),<\/li>\n\n\n\n
- europejska EMA (European Medicines Agency),<\/li>\n\n\n\n
- australijska TGA (The Australian Therapeutic Goods Administration).<\/li>\n<\/ul>\n\n\n\n
Okre\u015blenie \u201edobre praktyki\u201d jest zatem odrobin\u0119 myl\u0105ce, poniewa\u017c stosowanie si\u0119 do regu\u0142 GxP jest obowi\u0105zkiem prawnym ka\u017cdej firmy pozostaj\u0105cej pod nadzorem kt\u00f3rej\u015b z tych agencji<\/strong> [\u017ar\u00f3d\u0142o: 1<\/a>].<\/p>\n\n\n\n
Czym jest walidacja?<\/strong><\/h2>\n\n\n\n
Nietrudno zgadn\u0105\u0107, \u017ce GxP rozci\u0105ga si\u0119 r\u00f3wnie\u017c na obszar testowania oprogramowania. Good Documentation Practices oraz Good Testing Practices to tak\u017ce cz\u0119\u015b\u0107 GxP. Kluczowym za\u015b narz\u0119dziem s\u0142u\u017c\u0105cym do implementacji tych dobrych praktyk jest walidacja<\/strong> [\u017ar\u00f3d\u0142o: 2<\/a>].<\/p>\n\n\n\n
Walidacja, a w zasadzie CSV (Computerized System Validation), to udokumentowany proces zapewniaj\u0105cy, \u017ce system b\u0105d\u017a program komputerowy spe\u0142nia wszystkie ustalone wcze\u015bniej wymagania<\/strong>, realizuje dok\u0142adnie taki cel, do jakiego go zaprojektowano, i robi to w spos\u00f3b sp\u00f3jny i powtarzalny.<\/p>\n\n\n\n
Z tego wynika, \u017ce walidacja jest nieod\u0142\u0105cznym elementem ca\u0142ego procesu tworzenia oprogramowania, a walidator <\/strong>\u2013 czyli osoba, kt\u00f3rej zadaniem jest pilnowanie, aby projekt przestrzega\u0142 regulacji CSV, i dokumentowanie procesu walidacji \u2013 jest zaanga\u017cowany w prac\u0119 ju\u017c od etapu definiowania wymaga\u0144 i szacowania ryzyka.<\/p>\n\n\n\n
Warto na pocz\u0105tku wspomnie\u0107, \u017ce narz\u0119dzie do zarz\u0105dzania testami, w kt\u00f3rym pod czujnym okiem walidatora b\u0119dziemy pracowa\u0107, zosta\u0142o wybrane w\u0142a\u015bnie z jego udzia\u0142em. Test Management System musi bowiem spe\u0142nia\u0107 pewne warunki:<\/p>\n\n\n\n
- \n
- zapewnia\u0107 traceability pomi\u0119dzy testami i wymaganiami,<\/li>\n\n\n\n
- ogranicza\u0107 dost\u0119p i dzieli\u0107 uprawnienia wed\u0142ug r\u00f3l,<\/li>\n\n\n\n
- zapewnia\u0107 tzw. audit trail, czyli \u015bcie\u017ck\u0119 audytu.<\/li>\n<\/ul>\n\n\n\n
W zwi\u0105zku z tym w \u015brodowiskach regulowanych przez GxP wci\u0105\u017c natrafiamy na te same systemy zarz\u0105dzania testami, takie jak:<\/p>\n\n\n\n
- \n
- MicroFocus ALM (dawniej HP ALM\/HP Quality Center),<\/li>\n\n\n\n
- IBM Engineering Test Management (dawniej Rational Quality Manager),<\/li>\n\n\n\n
- Veeva Vault QMS,<\/li>\n\n\n\n
- ValGenesis VLMS,<\/li>\n<\/ul>\n\n\n\n
oraz kilka innych, mniej znanych.<\/p>\n\n\n\n
Rola walidatora<\/strong><\/h2>\n\n\n\n
Udzia\u0142 walidatora w projekcie staje si\u0119 zauwa\u017calny dla tester\u00f3w (a przynajmniej dla test leada) od samego pocz\u0105tku procesu testowego, czyli ju\u017c w chwili tworzenia test planu. W systemach walidowanych istnienie i formalne zatwierdzenie takiego dokumentu dla ka\u017cdego release\u2019u jest wymagane.<\/p>\n\n\n\n
Walidacja definiuje, jak b\u0119dzie przebiega\u0107 proces zatwierdzania test planu (oraz ka\u017cdego innego dokumentu w projekcie), kto b\u0119dzie w nim uczestniczy\u0107 i w jakiej roli (to oznacza r\u00f3wnie\u017c wskazywanie, kto b\u0119dzie autorem danego dokumentu). Walidator jest tu zawsze ostatni\u0105 podpisuj\u0105c\u0105 osob\u0105 i bez jego aprobaty \u2013 a co za tym idzie, bez zatwierdzonego test planu \u2013 rozpocz\u0119cie formalnego etapu testowania nie jest mo\u017cliwe.<\/p>\n\n\n\n
W trakcie samego przegl\u0105du walidator skupia si\u0119 na zgodno\u015bci dokumentu z uprzednio zatwierdzonym wzorcem oraz na tym, czy opisany plan testowania przestrzega regu\u0142 GxP, a je\u015bli nie, to czy odej\u015bcie od zasad (tzw. dewiacja) jest odpowiednio umotywowane, a zwi\u0105zane z tym ryzyko wzi\u0119te pod uwag\u0119.<\/p>\n\n\n\n
Co zwr\u00f3ci uwag\u0119 walidatora?<\/strong><\/h2>\n\n\n\n
Przyk\u0142adowe problemy w test planie, jakie mog\u0105 zwr\u00f3ci\u0107 (i zwr\u00f3c\u0105) uwag\u0119 walidacji:<\/p>\n\n\n\n
- \n
- brak wzmianki o tym, \u017ce testerzy s\u0105 prawid\u0142owo przeszkoleni do wykonywania swoich zada\u0144,<\/li>\n\n\n\n
- niekompletna lista dokumentacji, z kt\u00f3rej pochodz\u0105 nale\u017c\u0105ce do zakresu wymagania,<\/li>\n\n\n\n
- nieprawid\u0142owa lista os\u00f3b zatwierdzaj\u0105cych dokument,<\/li>\n\n\n\n
- problemy z elektroniczn\u0105 kontrol\u0105 dokumentu (dokument nie umieszczony w systemie zarz\u0105dzania dokumentacj\u0105, z\u0142y identyfikator, nieprawid\u0142owy numer wersji itp.),<\/li>\n\n\n\n
- nie wszystkie przypadki testowe zosta\u0142y zawczasu przejrzane i zatwierdzone przez walidacj\u0119.<\/li>\n<\/ul>\n\n\n\n
Ostatni punkt jest niezmiernie istotny \u2013 tak, wszystkie test case\u2019y r\u00f3wnie\u017c s\u0105 przegl\u0105dane formalnie przez walidacj\u0119 (i inne wskazane przez proces osoby, zazwyczaj test leada). W tym przypadku walidatora interesuje g\u0142\u00f3wnie to, czy scenariusz testowy jest odpowiednio szczeg\u00f3\u0142owy, czy zawiera prawid\u0142owe odno\u015bniki do wymaga\u0144 i czy wystarczaj\u0105co dokumentuje ca\u0142\u0105 prac\u0119 testera.<\/p>\n\n\n\n
Najcz\u0119stsze uwagi zg\u0142aszane przez walidacj\u0119<\/strong> na tym etapie<\/h3>\n\n\n\n
Do najcz\u0119stszych uwag na tym etapie nale\u017c\u0105:<\/p>\n\n\n\n
- \n
- brak odniesienia do wszystkich pokrywanych wymaga\u0144,<\/li>\n\n\n\n
- niewystarczaj\u0105ca ilo\u015b\u0107 zbieranych dowod\u00f3w z egzekucji (np. brak instrukcji, aby do\u0142\u0105czy\u0107 zrzut ekranu w kroku sprawdzaj\u0105cym istotn\u0105 funkcjonalno\u015b\u0107),<\/li>\n\n\n\n
- zbyt og\u00f3lne instrukcje lub opisy oczekiwanych rezultat\u00f3w (np. \u201esystem wy\u015bwietla komunikat o b\u0142\u0119dzie\u201d zamiast \u201esystem wy\u015bwietla komunikat o b\u0142\u0119dzie o nast\u0119puj\u0105cej tre\u015bci (\u2026)\u201d, albo \u201estw\u00f3rz nowy dokument\u201d zamiast \u201ekliknij przycisk \u201eNowy dokument\u201d\u201d),<\/li>\n\n\n\n
- nieprawid\u0142owa numeracja krok\u00f3w,<\/li>\n\n\n\n
- u\u017cycie danych testowych niezadeklarowanych na pocz\u0105tku testu,<\/li>\n\n\n\n
- stosowanie nieprecyzyjnego j\u0119zyka (np. \u201estrona \u0142aduje si\u0119 szybko\u201d zamiast \u201estrona \u0142aduje si\u0119 w czasie kr\u00f3tszym ni\u017c 5 sekund\u201d),<\/li>\n\n\n\n
- nieprawid\u0142owa forma gramatyczna instrukcji lub oczekiwanych wynik\u00f3w (w my\u015bl GxP instrukcja powinna by\u0107 napisana w trybie rozkazuj\u0105cym, a oczekiwane wyniki w czasie tera\u017aniejszym z u\u017cyciem strony biernej).<\/li>\n<\/ul>\n\n\n\n
Niekt\u00f3re z tych uwag mog\u0105 si\u0119 wyda\u0107 ma\u0142ostkowe i prowadz\u0105 do podejrzewania walidacji o z\u0142o\u015bliwo\u015b\u0107 i czepialstwo, ale wszystkie one maj\u0105 bezpo\u015brednie \u017ar\u00f3d\u0142o w przepisach prawnych stanowi\u0105cych podstaw\u0119 GxP (szczeg\u00f3lnie w ameryka\u0144skim Code of Federal Regulations, rozdzia\u0142 21, cz\u0119\u015b\u0107 11 \u2013 skr\u00f3towo zwanym \u201e21 CFR part 11\u201d [\u017ar\u00f3d\u0142o: 4<\/a>]).<\/p>\n\n\n\n
Szcz\u0119\u015bliwie nie wszyscy walidatorzy przywi\u0105zuj\u0105 du\u017c\u0105 wag\u0119 do form gramatycznych lub innych kwestii j\u0119zykowych, ale w przypadku konflikt\u00f3w pomi\u0119dzy zespo\u0142em testowym a walidacj\u0105 lub braku zaufania pomi\u0119dzy tymi zespo\u0142ami cz\u0119stotliwo\u015b\u0107 podobnych uwag potrafi czasami znacz\u0105co wzrosn\u0105\u0107.<\/p>\n\n\n\n
Przegl\u0105d \u201etest run\u00f3w\u201d<\/strong><\/h2>\n\n\n\n
A kiedy ju\u017c z sukcesem przebrniemy przez etap zatwierdzania scenariuszy testowych, czas na egzekucj\u0119 test\u00f3w, kt\u00f3ra \u2013 zgadli\u015bcie \u2013 jest tak\u017ce oceniana i zatwierdzana. Wybrane uprzednio narz\u0119dzie do zarz\u0105dzania testami umo\u017cliwia z pewno\u015bci\u0105 szczeg\u00f3\u0142owy zapis wykonania testu (inaczej nie zosta\u0142oby ono dopuszczone do u\u017cytku przez walidacj\u0119).<\/p>\n\n\n\n
Te w\u0142a\u015bnie zapisy, zwane dalej \u201etest runami\u201d, podlegaj\u0105 dok\u0142adnemu przegl\u0105dowi. Walidator zwraca uwag\u0119 na nast\u0119puj\u0105ce problemy:<\/strong><\/p>\n\n\n\n
- \n
- brak zrzut\u00f3w ekranu pokazuj\u0105cych kluczowe kroki testu,<\/li>\n\n\n\n
- zrzuty ekranu niewyra\u017ane, za ma\u0142e, lub nie pokazuj\u0105ce wszystkich istotnych element\u00f3w,<\/li>\n\n\n\n
- zrzuty ekranu niezawieraj\u0105ce daty i godziny wykonania,<\/li>\n\n\n\n
- niedok\u0142adny opis faktycznych wynik\u00f3w akcji (np. \u201ewy\u015bwietla si\u0119 prawid\u0142owy komunikat\u201d zamiast \u201ewy\u015bwietla si\u0119 komunikat o nast\u0119puj\u0105cej tre\u015bci (\u2026)\u201d),<\/li>\n\n\n\n
- niezgodno\u015b\u0107 pomi\u0119dzy instrukcj\u0105 a opisem wykonanej akcji,<\/li>\n\n\n\n
- niezgodno\u015b\u0107 pomi\u0119dzy oczekiwanymi a rzeczywistymi wynikami akcji, kt\u00f3ra nie zosta\u0142a zg\u0142oszona jako defekt ani oznaczona jako dewiacja,<\/li>\n\n\n\n
- test wykonany przez t\u0119 sam\u0105 osob\u0119, kt\u00f3ra go napisa\u0142a (to te\u017c jest niewskazane z punktu widzenia GxP, a sytuacja, w kt\u00f3rej musi tak si\u0119 sta\u0107, powinna by\u0107 opisana w raporcie z test\u00f3w jako dewiacja).<\/li>\n<\/ul>\n\n\n\n
Walidatorzy obserwuj\u0105 oczywi\u015bcie r\u00f3wnie\u017c defekty zg\u0142aszane w trakcie tak formalnej egzekucji i mog\u0105 za\u017c\u0105da\u0107 doprecyzowania opisu zg\u0142oszenia b\u0105d\u017a za\u0142\u0105czonych dowod\u00f3w, stosuj\u0105c te same kryteria, co powy\u017cej.<\/p>\n\n\n\n
Walidacja raportu ko\u0144cowego z test\u00f3w<\/strong><\/h2>\n\n\n\n
\u017badn\u0105 niespodziank\u0105 nie b\u0119dzie ju\u017c fakt, \u017ce ko\u0144cowy raport z test\u00f3w podlega r\u00f3wnie dok\u0142adnemu przegl\u0105dowi, co reszta dokumentacji.<\/p>\n\n\n\n
W my\u015bl GxP walidatorzy b\u0119d\u0105 tu szuka\u0107 takich problem\u00f3w, jak:<\/p>\n\n\n\n
- \n
- niekompletne lub nieprawid\u0142owe warto\u015bci metryk zebranych w trakcie testowania (np. liczba napisanych i wykonanych test\u00f3w, otwartych zg\u0142osze\u0144 defekt\u00f3w, nieprawid\u0142owych egzekucji itp.),<\/li>\n\n\n\n
- przypadki dewiacji nieopisane lub nieumotywowane wystarczaj\u0105co (np. sytuacja, w kt\u00f3rej autor testu sam wykonywa\u0142 sw\u00f3j scenariusz, a nie jest to w raporcie wskazane ani wyja\u015bnione),<\/li>\n\n\n\n
- niezamkni\u0119te zg\u0142oszenia defekt\u00f3w pozostawione bez wyja\u015bnienia i odpowiedniej decyzji,<\/li>\n\n\n\n
- brak zatwierdzonej macierzy \u015bledzenia, odno\u015bnik\u00f3w do niej b\u0105d\u017a inne problemy z tym dokumentem,<\/li>\n\n\n\n
- oraz wszystkie og\u00f3lne problemy z dokumentacj\u0105, wymienione przeze mnie przy okazji omawiania test planu.<\/li>\n<\/ul>\n\n\n\n
Wspomniana macierz \u015bledzenia<\/strong> jest oceniana jedynie pod k\u0105tem zgodno\u015bci z ustalon\u0105 wcze\u015bniej form\u0105 i poprawno\u015bci zawartych w tabelach informacji, niemniej wraz z raportem z test\u00f3w jest niezb\u0119dna<\/strong>, \u017ceby walidator m\u00f3g\u0142 zatwierdzi\u0107 decyzj\u0119 o zako\u0144czeniu testowania.<\/p>\n\n\n\n
![\"oferty](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/08\/praca-m-1.jpg\")
<\/a><\/figure>\n\n\n\nPodsumowanie<\/strong><\/h2>\n\n\n\n
Zdawa\u0107 by si\u0119 mog\u0142o, \u017ce taka ilo\u015b\u0107 dodatkowych zasad, przegl\u0105d\u00f3w i podpis\u00f3w nak\u0142ada na tester\u00f3w du\u017co nadmiarowych obowi\u0105zk\u00f3w i przeszkadza w pracy. Takie wra\u017cenie miewaj\u0105 czasami testerzy zaczynaj\u0105cy swoj\u0105 przygod\u0119 w systemie GxP.<\/p>\n\n\n\n
Warto jednak\u017ce zauwa\u017cy\u0107, \u017ce aby unikn\u0105\u0107 wi\u0119kszo\u015bci problem\u00f3w z walidacj\u0105, o jakich tu napisa\u0142em, wystarczy starannie dokumentowa\u0107 swoj\u0105 prac\u0119, dba\u0107 o dobr\u0105 jako\u015b\u0107 testowania i<\/strong> \u2013 planuj\u0105c testy \u2013 bra\u0107 pod uwag\u0119 czas potrzebny na wszystkie walidacyjne aktywno\u015bci<\/strong>.<\/p>\n\n\n\n
Pami\u0119tajmy te\u017c, \u017ce walidatorzy s\u0105 tylko lud\u017ami, kt\u00f3rzy \u2013 tak jak testerzy i programi\u015bci \u2013 chc\u0105 po prostu wykonywa\u0107 swoj\u0105 prac\u0119. Mo\u017cna (i trzeba) porozumie\u0107 si\u0119 z nimi, a wtedy praca w projekcie stanie si\u0119 \u0142atwiejsza.<\/p>\n\n\n\n
\u0179r\u00f3d\u0142a<\/strong><\/h2>\n\n\n\n