Testy akceptacyjne w projektach wdrożeń systemów IT

Poniższy artykuł opisuje jeden z kluczowych etapów w procesie wdrażania systemów IT i będzie się skupiał na przedstawieniu tematu szczególnie w odniesieniu do takich wdrożeń prowadzonych w przedsiębiorstwach produkcyjnych.

Charakterystyka testów akceptacyjnych, czym są testy akceptacyjne?

Definicja prawna testów akceptacyjnych jest… co najmniej średnio strawna:

Testy akceptacyjne oprogramowania to udokumentowane wartości danych wejściowych wprowadzanych do systemu teleinformatycznego i powiązanych z nimi wartości oczekiwanych danych wyjściowych, opisujące zestawy poprawnych odpowiedzi systemu teleinformatycznego na podawane dane wejściowe, pozwalające na sprawdzenie poprawności wdrożenia oprogramowania interfejsowego – Art. 3 pkt 12 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. z 2023 r. poz. 57).

Gdy spróbujemy przetłumaczyć to sobie na bardziej zrozumiały język, możemy stwierdzić, iż testy akceptacyjne (ang. User Acceptance Testing, UAT) mają na celu weryfikację, czy nowo wdrażany system spełnia wymagania i oczekiwania użytkowników końcowych oraz czy jest gotowy do pełnego użytkowania w środowisku produkcyjnym.

Odbiór oprogramowania to jeden z najważniejszych kamieni milowych w projekcie wdrożeniowym. Otrzymujemy wtedy potwierdzenie (albo negację), że dostarczyliśmy Klientowi właściwe rozwiązanie.

Przeprowadzenie testów akceptacyjnych pozwala na sprawdzenie zarówno funkcjonalności systemu, jak i interfejsu użytkownika oraz interakcji z innymi systemami.

Ponadto testowanie akceptacyjne może wystąpić w dwóch kontekstach organizacyjnych: dla oprogramowania zamówionego i dla oprogramowania zakupionego „z półki”. Ten artykuł dotyczy pierwszego kontekstu i ma m.in. na celu podzielenie się doświadczeniami z wdrożeń produktów z rodziny DSR 4FACTORY prowadzonych od lat skutecznie przez DSR.

Podział testów akceptacyjnych

Produkcyjne testy akceptacyjne mają na celu ocenić gotowość systemu do wdrożenia i użytkowania przez Klienta (użytkownika). Istnieje całkiem sporo rodzajów takich testów, aczkolwiek w podejściu stosowanym przez DSR dzielą się one na dwie, główne części.

1. Testy funkcjonalne – koncentrują się na weryfikacji, czy oprogramowanie spełnia wszystkie zdefiniowane wymagania funkcjonalne. Celem jest potwierdzenie, że każda funkcjonalność działa zgodnie z oczekiwaniami i specyfikacją (akceptacyjne wymagania użytkownika). To o tym rodzaju testów w znakomitej większości traktuje w dalszej części ten artykuł.
2. Testy niefunkcjonalne – sprawdzają aspekty jakościowe oprogramowania, które nie są bezpośrednio związane z funkcjonalnością, takie jak:
   • Wydajność: ocena, czy system spełnia wymagania dotyczące wydajności, takie jak szybkość reakcji czy zdolność obsługi wielu użytkowników jednocześnie (w DSR nazywamy je „testami dnia codziennego„).
   • Bezpieczeństwo: testowanie systemu pod kątem odporności na ataki i ochronę danych.
   • Użyteczność: sprawdzanie, czy interfejs użytkownika jest intuicyjny i łatwy w użyciu.

Jak prowadzić testy akceptacyjne? Etapy testów akceptacyjnych oprogramowania

Testowanie akceptacyjne wymaga starannego planowania i koordynacji. Aby testy te mogły być skuteczne, zdecydowanie powinniśmy zacząć od przygotowania planu testów. Plan taki powinien definiować ich cele, określać zakres oraz kryteria sukcesu, a także przedstawiać harmonogram ich przeprowadzenia.

Gdy mamy już plan, przechodzimy do zdefiniowania scenariuszy testowych, czyli opracowania szczegółowych przypadków testowych pokrywających wszystkie kluczowe funkcjonalności systemu, którego poprawność i kompletność przygotowania do uruchomienia produkcyjnego chcemy ocenić/zweryfikować.

Warunkiem niezbędnym by przeprowadzić skuteczny test akceptacyjny oprogramowania, jest przygotowanie środowiska testowego, czyli takiego, które jak najdokładniej odwzorowuje warunki rzeczywiste zwane produkcyjnymi. W metodyce wdrożeń prowadzonych przez DSR, jest to kopia (przygotowywanego już wcześniej) przyszłego środowiska produkcyjnego.

Jeśli mamy środowisko, zestaw scenariuszy oraz plan, śmiało możemy przystąpić do przeprowadzenia testów akceptacyjnych, pamiętając o ich dokumentacji a następnie analizie wyników (przeglądzie, identyfikacji wykrytych problemów oraz ich priorytetyzacji). Naturalnym, kolejnym krokiem jest wprowadzenie poprawek do systemu czyli naprawa błędów po którym następuje ponowne przetestowanie systemu oraz ostateczna akceptacja biznesowa.

Należy pamiętać, że co prawda podczas testowania akceptacyjnego mogą zostać wykryte defekty, ale ich wykrywanie często nie jest celem tego poziomu testów. Testy akceptacyjne są w metodyce wdrożeń DSR ostatnim z całego szeregu innych, wcześniejszych w cyklu wdrożenia oprogramowania aktywności testowych. Poprzedzają je m.in. testy obszarowe-jednostkowe i testy między-obszarowe, w wyniku których przygotowywany do uruchomienia produkcyjnego system powinien być już z dużym prawdopodobieństwem pewności, pozbawiony wad i usterek.

Znalezienie zatem dużej liczby defektów na etapie testowania akceptacyjnego powinno zostać uznane za istotny czynnik ryzyka projektowego.

Kluczowe aspekty testów akceptacyjnych oprogramowania

Rozszerzmy jeszcze kilka wątków poruszanych w poprzednim punkcie. Podczas prowadzenia testów akceptacyjnych warto zwrócić uwagę na kilka kluczowych aspektów:

• Dobór użytkowników-testerów: W proces testowania powinni zostać zaangażowani zarówno ci użytkownicy, którzy bardzo dobrze znają te procesy biznesowe, których przetwarzanie wdrażany system ma wpierać (testy funkcjonalne / tzw. użytkownicy kluczowi) jak również ci, którzy wykonując poszczególne operacje w ramach tych procesów, będą korzystać z systemu na co dzień (testy wydajnościowe/dnia codziennego – tzw. użytkownicy końcowi). Bowiem to testy akceptacyjne użytkownika są główną składową sukcesu opisywanego w tym artykule etapu projektu.
• Dokładność scenariuszy testowych: Scenariusze powinny być jak najbardziej realistyczne i obejmować zarówno standardowe, jak i niestandardowe przypadki użycia (wyjątki procesowe). W głównej mierze powinny pozwalać na testy tzw. styków między-obszarowych (np. przyjęcie wyrobu gotowego z produkcji na magazyn), gdzie poprawne działanie systemu w ramach poszczególnych obszarów powinno być zweryfikowane na wcześniejszym etapie testów oprogramowania.
• Dokumentacja wyników: Wszystkie wyniki testów systemowych powinny być dokładnie dokumentowane, aby ułatwić analizę i śledzenie napraw błędów. Dobrą praktyką jest zbudowanie scenariuszy testowych na takim poziomie szczegółowości, by obserwacje z testów można było umieszczać w odniesieniu do poszczególnych, jasno określonych kroków testów. Pozwala to potem także ponawiać skuteczniej testy i szybciej spełniać oczekiwania użytkowników.
• Komunikacja: Kluczowa dla szybkiego rozwiązywania problemów jest regularna komunikacja między zespołem testującym, deweloperami i interesariuszami. W praktyce pomaga tutaj wspieranie się udostępnianymi on-line arkuszami błędów/usterek (ang. issue logs) czy używanie do rejestracji i przetwarzania zgłoszeń, dedykowanych do tego systemów (np. systemy firmy Atlassian używane przez DSR we współpracy z naszymi Klientami).

Implementacja testów akceptacyjnych – najlepsze praktyki

Prowadząc projekty wielu różnych wdrożeń systemów informatycznych (nowe implementacje systemu ERP 4FACTORY, wdrożeń ich nowych wersji (tzw. upgrade’ów) czy wdrożeń i testów oprogramowania rodziny DSR 4FACTORY), mieliśmy okazję planując, a potem przeprowadzając testy akceptacyjne, zarówno „wpadać w różne dołki” jak i nauczyć się z nich skutecznie wychodzić. Poniżej chcemy podzielić się zdobytymi w tym procesie doświadczeniami.

Tworzenie testów akceptacyjnych warto oprzeć na jak najszybszym zaangażowaniu w proces ich zaprojektowania tych użytkowników, którzy będą potem testy te wykonywać . Im szybciej (na wcześniejszym etapie projektu) zostaną oni włączeni, tym szybciej będziemy mieć szansę zrozumieć ich potrzeby i oczekiwania. Jak powiedzieliśmy to sobie już wcześniej, są one potem odzwierciedlane za pomocą różnorakich scenariuszy testowych. I tutaj pojawia się kolejna, dobra praktyka – elastyczność. Prowadząc testy, powinniśmy być zawsze gotowymi do dostosowania scenariuszy testowych i ich planu w odpowiedzi na zmieniające się wymagania (wpływanie na kryteria akceptacji) lub odkryte w trakcie testów problemy. Kolejną, ważną rzeczą, o której powinniśmy pamiętać są regularne przeglądy postępów i wyników testów z interesariuszami, aby podtrzymać i zapewnić zgodność z wcześniej zdefiniowanymi oczekiwaniami. W przypadkach gdzie jest to możliwe do zastosowania, warto postarać się o wykorzystanie narzędzi do automatyzacji testów, aby zwiększyć efektywność i dokładność testowania. Trzeba jednak uczciwie podkreślić, że często w odniesieniu do dużych i skomplikowanych systemów wspierających procesy biznesowe w przedsiębiorstwach produkcyjnych, przygotowanie efektywnych i skutecznych reguł bardziej kompletnej automatyzacji (pomijając już nawet kwestię ich implementacji) jest bardzo trudne lub po prostu niemożliwe.

Wreszcie należy także pamiętać o zapewnieniu odpowiedniego przeszkolenia dla użytkowników-testerów, aby mogli oni efektywnie prowadzić produkcyjne testy akceptacyjne, a co za tym idzie, nabierać biegłości w późniejszym użytkowaniu systemu.

Testowanie akceptacyjne oprogramowania – jeszcze o testach niefunkcjonalnych

Poświęćmy teraz jeszcze chwilę czasu na spojrzenie na niefunkcjonalne testy akceptacyjne. Wspomnieliśmy o nich już na początku artykułu, przyjrzyjmy się zatem im teraz jeszcze trochę bliżej. Każdy z poniższych rodzajów testów stosowany jest przez nas w DSR, chociaż część z nich tylko wewnętrznie. Przyjmuje się, że wykonywanie testów akceptacyjnych to jeden z ostatnich poziomów (wraz z przygotowaniem i realizacją tzw. planu przejścia oraz samym uruchomieniem produkcyjnym) sekwencyjnego cyklu życia oprogramowania.

Zdarza się jednak, że testy wykonywane mogą być również na innych etapach wdrożeń – czego przykłady opisane są poniżej.

Testy alfa i beta

Chociaż te rodzaje testów kojarzą się bardziej z testowaniem tzw. oprogramowania pudełkowego (ang. off-the-shelf software), to w praktyce używane są one także podczas wytwarzania oprogramowania z definicji wymagającego dedykowanego wdrożenia.

Testy alfa (ang. Alpha Testing)

Testy alfa są zwykle przeprowadzane w kontrolowanym środowisku przez wewnętrzny zespół firmy, zanim oprogramowanie zostanie udostępnione użytkownikom zewnętrznym. Celem jest wczesne wykrycie i naprawa błędów oraz weryfikacja, czy system jest gotowy do testów beta. Taki rodzaj testów przechodzą wszystkie nasze produkty z rodziny DSR 4FACTORY, np. SFC 4FACTORY czy CMMS+EAM 4FACTORY.

Testy beta (ang. Beta Testing)

Testy beta są prowadzone przez rzeczywistych użytkowników końcowych w ich naturalnym środowisku pracy. Umożliwiają one zebranie opinii i doświadczeń z pierwszej ręki oraz identyfikację problemów, które mogą nie wystąpić w kontrolowanym środowisku testowym. W ramach wdrożeń nowych produktów nierzadko korzystamy obopólnie z dobrych relacji z naszymi Klientami, prowadząc wtedy z nimi „wdrożenia testowe” (tzw. Early Adapters). Z tego typu testów korzystamy także w przypadkach wprowadzania nowych udoskonaleń funkcjonalnych, gdzie weryfikacja czy taka zmiana spełnia oczekiwania użytkowników może mieć miejsce jeszcze przed rozpoczęciem testowania systemowego.

Testy zgodności (ang. Compliance Acceptance Testing)

Testy zgodności weryfikują, czy oprogramowanie spełnia określone standardy, przepisy prawa, regulacje branżowe czy wewnętrzne polityki organizacji (akceptacja zgodności z kontraktem). Przykładem mogą być testy zgodności z przepisami RODO dotyczącymi ochrony danych osobowych. Ten rodzaj testowania akceptacyjnego może być czasami niezbędny do spełnienia określonych wymagań formalnych.

Testy operacyjne (ang. Operational Acceptance Testing – OAT)

Testy operacyjne koncentrują się na sprawdzeniu, czy oprogramowanie jest gotowe do pracy w rzeczywistym środowisku produkcyjnym pod kątem operacyjno-technicznym. Pisząc wprost – obejmują one testy procedur operacyjnych, takich jak tworzenie kopii zapasowych, odzyskiwanie danych, monitoring systemu oraz zarządzanie wydajnością. Ten rodzaj testów jest szczególnie istotny, gdy dostarczamy/wdrażamy systemy w chmurze (testy operacyjne są standardem w przypadku wdrożeń w DSR Cloud). Głównym celem tego typu produkcyjnych testów akceptacyjnych, jest uzyskanie pewności, że operatorzy lub administratorzy systemu będą w stanie zapewnić użytkownikom prawidłową pracę systemu w środowisku produkcyjnym, nawet w wyjątkowych i trudnych warunkach.

Testy regresyjne (ang. Regression Acceptance Testing)

Testy regresyjne są wykonywane po wprowadzeniu poprawek lub zmian w oprogramowaniu, aby upewnić się, że nowe zmiany nie wpłynęły negatywnie na istniejące funkcjonalności. W testach akceptacyjnych produkcyjnych regresja jest szczególnie istotna, aby potwierdzić, że system po poprawkach wciąż spełnia wszystkie wymagania użytkowników. Ten rodzaj testów wykonywany jest każdorazowo w DSR w przypadku produktów z rodziny DSR 4FACTORY w momencie, gdy planowane jest wprowadzenie nowej wersji oprogramowania i niezbędnym jest upewnienie się, że nowowprowadzone w kolejnej wersji funkcjonalności nie powodują niewłaściwego działania tych, które były już wcześniej używane/dostępne.

Wady testów akceptacyjnych (a może tylko wyzwania?)

Mimo tego, że przeprowadzenie testów akceptacyjnych jest kluczowym elementem procesu wdrażania oprogramowania i naprawdę bez nich trudno wyobrazić sobie zakończenie go z sukcesem, istnieją również pewne wady (które można też traktować jako wyzwania) związane z ich wykonywaniem Przyjrzyjmy się niektórym z nich.

Proces testowania może być kosztowny i czasochłonny, szczególnie w dużych projektach. Zaangażowanie użytkowników końcowych, tworzenie szczegółowych scenariuszy testowych, przeprowadzanie testów oraz analiza wyników wymagają znacznych zasobów, zarówno ludzkich, jak i finansowych. Może to prowadzić do opóźnień w harmonogramie projektu oraz zwiększenia jego kosztów. To właśnie konieczność zaangażowania użytkowników końcowych jest jedną z głównych wad testów akceptacyjnych. Użytkownicy często mają inne obowiązki i mogą nie mieć czasu ani wystarczającej motywacji do pełnego zaangażowania się w testy. Brak zaś odpowiedniego zaangażowania może prowadzić do niekompletnego przetestowania systemu, co z kolei zwiększa ryzyko wystąpienia problemów po wdrożeniu.

Ponadto testowanie akceptacyjne często opierają się na subiektywnych ocenach użytkowników końcowych. To, co dla jednego użytkownika może być akceptowalne, dla innego może być problematyczne. Różnice w oczekiwaniach i doświadczeniach użytkowników mogą prowadzić do trudności w osiągnięciu konsensusu co do tego, czy oprogramowanie jest gotowe do wdrożenia.

Inną, istotną wadą są ograniczenia środowiska testowego. Testy akceptacyjne są zazwyczaj przeprowadzane w specjalnie przygotowanym środowisku testowym, które nie zawsze idealnie odzwierciedla rzeczywiste warunki produkcyjne. Niektóre problemy mogą nie zostać zatem wykryte przy zastosowaniu tej formy testów akceptacyjnych, a pojawić się dopiero po wdrożeniu systemu w rzeczywistym środowisku produkcyjnym.

I wreszcie testy akceptacyjne czasami mogą nie uwzględniać wszystkich zależności między różnymi modułami systemu lub zewnętrznymi systemami. Może to prowadzić do problemów z integracją, które ujawniają się dopiero po pełnym wdrożeniu.

Podsumowanie

Testy akceptacyjne są niezbędnym elementem wdrożeń systemów IT w przedsiębiorstwach produkcyjnych. Skuteczne przeprowadzenie tych testów wymaga starannego planowania, zaangażowania użytkowników i elastyczności. Najlepsze praktyki, takie jak wczesne zaangażowanie interesariuszy, regularne przeglądy postępów oraz automatyzacja testów, mogą znacznie zwiększyć szanse na pomyślne wdrożenie systemu. Prawidłowo przeprowadzone testy akceptacyjne zapewniają, że wdrażany system spełnia wymagania i jest gotowy do efektywnego użytkowania w środowisku produkcyjnym.

Życzymy owocnych testów!

Autor: Piotr Słowiński

Project Manager PMP® DSR S.A. z 15 -letnim doświadczeniem we wdrażaniu rozwiązań ERP 4FACTORY (QAD); w DSR S.A. od 10 lat pracuje na stanowisku Starszego Kierownika Projektów. Certyfikat PMI PMP® zdobyty w roku 2012. Ponad 50 projektów implementacyjnych dla Klientów DSR (wdrożenia i upgrade'y systemu ERP 4FACTORY oraz wszystkich rozwiązań z oferty DSR 4FACTORY w wielu różnych konfiguracjach). Doświadczenie w prowadzeniu projektów w zespołach od kilku do kilkudziesięciu osób.