Kwalifikację dla takich systemów skomputeryzowanych, jak aplikacje MS Excel, z powodzeniem możemy formalnie uprościć, tworząc jeden protokół dla kwalifikacji instalacyjnej i kwalifikacji operacyjnej.
    Zaczynamy od opisu systemu. Wiadomości, które powinniśmy zawrzeć w tej części protokołu, to przynajmniej:
• krótki opis systemu zaczerpnięty najlepiej z instrukcji obsługi, zawierający przeznaczenie i wykorzystanie arkusza,
• nazwę aplikacji wraz z numerem wersji,
• lokalizację plików danych,
• minimalne wymagania sprzętowe,
• minimalne wymaganie software’owe.
Czas na właściwą kwalifikację rozpoczynamy od części instalacyjnej.

 Weryfikacja dokumentacji systemu
    Dokumentację dzielimy na:
• dokumentację producenta – najczęściej jest ona tworzona przez specjalistę z naszej firmy, który jest twórcą aplikacji; jest to specyfikacja funkcjonalna, dokładny opis systemu pod kątem sprzętu i oprogramowania; powinniśmy tu mieć zawarte wszystkie zrzuty ekranu,  wszystkie wydruki i raporty, jakie nasz arkusz może generować;
• dokumentację systemową w formacie przyjętym w naszym zakładzie:
- Specyfikację Wymagań Użytkownika,
- instrukcję obsługi aplikacji,
- instrukcję instalacji aplikacji,
- instrukcję dodawania/usuwania użytkownika uprawnionego do korzystania z aplikacji,
- pozostałe dokumenty, których specyfika wynika z uwarunkowań firmy, a które mają wpływ na poprawne funkcjonowanie aplikacji.

 Weryfikacja szkoleń
    Podczas weryfikacji szkoleń musimy wylistować wszystkich pracowników, którzy mają dostęp do aplikacji. Należy udowodnić, że przeszli oni wszystkie niezbędne szkolenia uprawniające do korzystania z arkusza. Logiczne jest, że aby przeszkolić pracownika z obsługi aplikacji, musimy posiadać instrukcję obsługi, sprawdzanąv w punkcie 1.

 Weryfikacja instalacji aplikacji
    Podczas tej weryfikacji sprawdzamy:
• nazwę pliku,
• numer wersji pliku,
• lokalizację pliku,
• wszystkie niezbędne pliki konfiguracyjne (jeżeli dotyczy).
Dodatkowo, należy również zweryfikować środowisko instalacji, a mianowicie, czy są spełnione minimalne wymagania sprzętowe oraz software’owe (np. wersja MS  Office).

 Weryfikacja wyglądu/formatu arkusza aplikacji
     Podczas tej weryfikacji sprawdzamy, czy wygląd otwartego arkusza jest identyczny z tym, który jest prezentowany w instrukcji obsługi. Musimy zwrócić uwagę na:
• położenie i wygląd komórek,
• opisy i tytuły komórek,
• kolory i formaty.

    Po tej części kwalifikacji możemy uznać, że aplikacja jest zainstalowana poprawnie. Należy zwrócić baczną  uwagę na odchylenia, które mogą się pojawić w trakcie powyższych weryfikacji. Ponieważ mamy tu do czynienia z kwalifikacją jednoczęściową (nie jest dzielona na część IQ i OQ), zalecam rozwiązywanie wszystkich odchyleń jeszcze przed przejściem do części operacyjnej. Po zakończeniu części instalacyjnej naszej kwalifikacji przechodzimy do części operacyjnej.

 Testy praw dostępu do folderu sieciowego
    Pamiętamy, że nasz arkusz został zainstalowany w folderze sieciowym, tak aby był możliwy dostęp wielu użytkowników jednocześnie. Dodatkową korzyścią jest powierzenie administracji technicznej działowi IT, który tak czy inaczej nadzoruje dyski sieciowe.
    Podczas testów praw dostępu do folderu musimy zapewnić, że wszyscy użytkownicy, którzy będą korzystać z aplikacji, mają prawo dostępu na odpowiednim poziomie.
    Musimy też przeprowadzić testy negatywne, czyli zapewnić, że użytkownicy spoza grupy autoryzacji nie mają dostępu do folderu sieciowego.
    Jeśli dodatkowo, oprócz zabezpieczeń na poziomie folderu, zostały zaaplikowane zabezpieczenia na poziomie pliku, musimy też je sprawdzić na tym etapie.

 Weryfikacja możliwości multidostępu do pliku (jeśli wymagana)
    Celem umieszczenia aplikacji MS Excel na dysku sieciowym jest możliwość multidostępu – wielu użytkowników pracuje jednocześnie na pliku. Zakładamy maksymalną ilość pracujących użytkowników i podczas testu weryfikujemy:
• możliwość otwarcia pliku przez maks. liczbę użytkowników,
• możliwość przeprowadzenia operacji obliczeniowych przy użyciu różnych danych przez maks. liczbę użytkowników,
• możliwość wydruku.
    Podczas tego testu sprawdzamy, czy obciążenie maks. liczbą użytkowników jednocześnie nie wpływa znacząco na wydajność aplikacji.

 Test zabezpieczeń komórek
     Znając ze specyfikacji funkcjonalnej oraz z instrukcji obsługi, w jaki sposób każda grupa komórek jest zabezpieczona, testujemy co następuje:
• komórki zawierające formuły i funkcje nie mogą być zmienione,
 • komórki przeznaczone do edycji pozwalają użytkownikom na wprowadzanie danych,
• komórki z zablokowaniem widoku w pasku formuł funkcjonują prawidłowo (nie widzimy, jaka formuła/ funkcja jest tam wpisana),
• pozostałe zabezpieczenia na poziomie arkusza i skoroszytu (jeśli takie występują).

 Test prawidłowego działania sprawdzania poprawności danych
    Testujemy komórki przeznaczone do wprowadzania danych. Dla każdej grupy komórek (dzielimy je w zależności od typu danych, które mają być wprowadzane, np.: data, liczba całkowita, liczba dziesiętna, tekst itp.) prowadzimy test pozytywny oraz test negatywny. Równocześnie w tym teście weryfikujemy poprawność komunikatów i alarmów, jeśli są zaimplementowane w aplikacji.

 Test funkcji i formuł obliczeniowych
    W tym teście weryfikujemy następujące elementy:
• poprawność wprowadzonych formuł i funkcji (Czy została użyta właściwa funkcja? Czy zostało użyte właściwe adresowanie? itp.) – odsyłam w tym miejscu do pierwszej części artykułu,
• poprawność algorytmu obliczeń – zalecam użycie trzech różnych zestawów danych testowych; obliczenia wykonujemy przy pomocy walidowanej aplikacji, równolegle sprawdzając alternatywną metodą; najczęściej metoda ta to nic innego jak kalkulator – dobrze, jeśli ma wydruk, który możemy załączyć do wyniku testu; weryfikujemy poprawność wyniku oraz założoną dokładność i format wyświetlania wyniku.

 Test poprawności wydruku
    W tym teście weryfikujemy funkcjonalność drukowania arkusza wynikowego. Najprościej jest, używając danych z testu nr 9, wykonać trzy wydruki testowe i zweryfikować, że:
• dane i wygląd arkusza na ekranie komputera są identyczne z wydrukiem,
• format wydruku jest identyczny z tym opisanym w instrukcji obsługi,
• wszystkie dane/tytuły/opisy są czytelne, cały arkusz mieści się na wydruku,
• wydruk posiada elementy identyfikujące:
- użytkownika,
 - datę i czas wydruku,
- nazwę i wersję aplikacji.
Na tym powinna się skończyć kwalifikacja instalacyjno-operacyjna arkusza MS Excel. Od chwili podpisania raportu z kwalifikacji przez wszystkie uprawnione osoby, aplikacja staje się elementem nadzorowanym przez System Jakości GMP.

 Najczęstsze pomyłki
    Na koniec, ku przestrodze, podam przykłady najbardziej „popularnych” błędów”, z jakimi spotykamy się przy audicie statusu kwalifikacji aplikacji MS Excel.
    Jako pierwszy, powtarzający się błąd, wymienię kwestie poprawnego udokumentowania systemu. Zacznijmy od początku, tak jak każe nam podejście Cyklu Życia systemu skomputeryzowanego. Zapewne większość naszych aplikacji nie posiada Specyfikacji Wymagań Użytkownika, popularnego dokumentu URS. Jak wiadomo, bez tego trudno prowadzić kwalifikację czegokolwiek, bo jak tu zweryfikować poprawność działania aplikacji, skoro nie wiemy, czego mamy po niej oczekiwać – wszakże takie informacje zawsze są zawarte w URS.
    Kolejny dokument, jakiego często brakuje naszemu systemowi, to standardowa instrukcja obsługi i konserwacji systemu. Zakłada się, że arkusz MS Excel jest tak prosty i intuicyjny, że instrukcja byłaby czystą sztuką dla sztuki. Niestety, jest to poważny błąd, nie tylko formalny.
    Często przydatne są również takie dokumenty, jak lista uprawnionych użytkowników, dokument zawierający hasło administratora do zmian w arkuszu (winien być chroniony i przechowywany w określonym miejscu), instrukcje instalacji itp. itd.
    Istotnym błędem, jaki często powtarza się w związku ze sprawowaniem kontroli nad aplikacjami, jest traktowanie ich jako bytu kompletnie niezależnego od systemu kontroli zmian. Raport z kwalifikacji systemu skomputeryzowanego, jakim jest niewątpliwie aplikacja MS Excel, stanowi swego rodzaju certyfikat niezmienności wersji aplikacji. Każda zmiana, nawet najdrobniejsza, musi zostać potraktowana jako element wejściowy do załadowanego systemu kontroli zmian, i przejść formalną drogę każdej zmiany w zakładzie. Dopiero potem możemy zabierać się za poprawy, zmiany, modyfikację, które na pewno będą musiały być poparte przynajmniej częściową rekwalifikacją systemu zgodnie z wnioskami z analizy wpływu.
    Dosyć częstą „bolączką” sprawowania kontroli nad aplikacjami są aspekty tajności haseł, a właściwie braku takiej tajności. Z praktycznego punktu widzenia, bardzo uciążliwe dla użytkowników jest stosowanie się do formalnych wymogów logowania do systemu, ochrony hasła itp. Szczególnie daje się to we znaki, kiedy na jednym komputerze pracuje kilku użytkowników. O ile łatwiej jest skorzystać z log’inu kolegi, o tyle prościej jest poprosić kolegę, aby zalogował się na moje konto i zrobił proste operacje na arkuszu, wydrukował – bo ja akurat mam  inną analizę na głowie. Pamiętajmy, to jest niezgodne z wymaganiami prawnymi zawartymi w Aneksie 11...

Autor: Paweł Nidecki, Pliva Kraków

Artykuł został opublikowany w magazynie "Przemysł Farmaceutyczny" nr 3/2011

Źródło fot.: www.sxc.hu