Testy funkcjonalności są istotnym elementem zapewniania jakości w ramach każdego procesu wdrożenia rozwiązań SAP, zarówno w środowiskach, które dopiero są budowane, jak również tam, gdzie wdrożone funkcjonalności podlegają sukcesywnemu rozwojowi. Potrzeba zapewnienia szybkiego przetestowania poprawności działania pojawi się nie tylko we wdrożeniu SAP „od zera”, ale i w projekcie upgrade, gdzie kompleksowo należy sprawdzić działanie systemu po podniesieniu wersji, czy też rollout, gdzie testom podlega już wcześniej wdrożone rozwiązanie referencyjne.
W tego typu przypadkach SAP AG przychodzi z pomocą zespołom projektowym oraz IT, oferując narzędzia testów automatycznych eCATT (ang. Extended Computer Aided Test Tool), które istotnie usprawniają proces testów, adresując wiele problemów, które pojawiłyby się przy braku ich wykorzystania.
Przygotowanie eCATT do pracy wiąże się z pewną pracą i zaangażowaniem, które przedstawimy w tym artykule. Jednak ta inwestycja zwróci się firmie z dużym zyskiem wszędzie tam, gdzie mamy do czynienia z dużą skalą testowanych rozwiązań lub też ze złożonym środowiskiem SAP, podlegającym częstym zmianom.
Efektem wykorzystania eCATT jest:
- zmniejszenie pracochłonności przygotowania kolejnych testów,
- redukcja ewentualnych kosztów zewnętrznych (związanych z zakupem usług konsultantów, zaangażowanych w testy),
- przyspieszenie całego procesu testowania (co za tym idzie, zmniejszenie ryzyka projektowego, poprzez przyspieszenie gotowości rozwiązania do kolejnych czynności wdrożeniowych),
- uwolnienie zasobów wewnętrznych, zaangażowanych w żmudne czynności testowania, na rzecz innych, istotniejszych i bardziej rozwojowych zadań projektowych.
eCATT w środowisku SAP
eCATT jest zestawem narzędzi (transakcji SAP) zintegrowanych w środowisku ABAP Development Workbench od wersji 6.20 serwera aplikacyjnego Web Application Server. Oferuje szereg usprawnień w procesie przygotowania scenariuszy testowych, jak również w procesie zarządzania testami. eCATT jest rozszerzeniem dla poprzedniej wersji tych narzędzi o nazwie CATT, która nie była oparta o serwer WAS (od wersji SAP R/3 4.0B), a więc ograniczona była do możliwości technologicznych poprzedniej generacji serwerów. Obecnie dostępna wersja narzędzi eCATT umożliwia także testowanie aplikacji Web.
Niewątpliwą zaletą eCATT jest dostarczanie narzędzi w ramach podstawowego pakietu, bez potrzeby instalacji dodatkowych komponentów, jak również bez potrzeby wykupienia dodatkowej licencji przez firmy, które z tych narzędzi chcą skorzystać.
Istotnym elementem planowania środowiska testowego w oparciu o eCATT jest jego centralizacja, polegająca na umiejscowieniu narzędzi na centralnym serwerze aplikacyjnym, z którego połączenia z innymi systemami będą realizowane za pomocą standardowego protokołu RFC. Można tu wykorzystać istniejący w środowisku serwer aplikacyjny, na którym wykonywane są testy lub, co jest lepszym rozwiązaniem, umiejscowić eCATT na platformie SAP Solution Manager, uniezależniając je tym samym od obecnego środowiska. Środowisko eCATT na SAP Solution Manager, który stał się już nieodzownym komponentem, staje się integralną częścią oferowanych przez to narzędzie funkcjonalności centralnego utrzymania rozwiązań, dając w przyszłości możliwości szerszej z nimi integracji, np. z systemem obsługi zgłoszeń serwisowych.
Do przygotowania środowiska eCATT, z technicznego punktu widzenia, wymagana jest jedynie jego aktywacja poprzez ustawienie parametrów serwera aplikacyjnego i SAP GUI, by uruchamianie eCATT było możliwe. Należy zwrócić uwagę na konfigurowanie wyłącznie serwerów wykorzystywanych do testów.
Połączenia z systemami zewnętrznymi w oparciu o RFC definiowane są bezpośrednio za pomocą narzędzi środowiska eCATT poprzez kontenery danych systemowych. W celu zapewnienia możliwości uruchomienia transakcji na zdalnych systemach, bez potrzeby ponownego logowania testujących, sugerowane jest wykorzystanie połączeń RFC typu ‘trusted’. W rozproszonym środowisku może również wystąpić potrzeba udrożnienia połączeń sieciowych pomiędzy platformą eCATT a systemami zewnętrznymi SAP. Właściwe ustawienie parametrów aktywacji eCATT oraz połączeń RFC, czy też definicji użytkowników testowych i połączeń sieciowych, to jedyne zadania, w które na początku prac zaangażowani będą administratorzy systemów.
Możliwości eCATT
Możliwości eCATT dla testowanych rozwiązań są szerokie, jednak podstawowym ograniczeniem jest możliwość wykorzystania narzędzia jedynie w zakresie technologii SAP.
Podstawą jest wykorzystanie SAP GUI (Windows/Java) oraz WebGUI jako front-endu dla testowanych rozwiązań. Tym samym możliwe jest wykonanie testów podstawowych transakcji SAP jak również tych bardziej zaawansowanych, zawierających kontrolki ActiveX oraz komponenty WebDynpro. Co więcej, w ramach pojedynczego scenariusza, realne jest wykonanie kroków testów za pomocą różnych front-endów. Poza testowaniem w oparciu o GUI, możliwe jest także przygotowanie testów dla modułów funkcyjnych, a także wykorzystanie WebService lub WebDynpro.
Jako środowisko testów automatycznych opartych o eCATT, poza samymi narzędziami, należy też rozpatrywać tworzone za pomocą narzędzi obiekty, w tym:
- Kontenery z definicjami połączeń systemowych, które umożliwiają odseparowanie konfiguracji połączeń od innych obiektów, tym samym dając możliwość ponownego wykorzystania tych połączeń, bez potrzeby ich powtórnej definicji i umieszczania statycznie w ramach skryptu testowego.
- Kontenery danych podstawowych, które pozwalają na niezależne od skryptu przygotowanie danych do testu. Zaletą tego podejścia jest możliwość ponownego wykorzystania kontenera z danymi w ramach innych scenariuszy testowych.
- Scenariusze testowe, które są zapisem kroków testu przygotowanych jako nagrania transakcji, wzbogaconych o dodatkowe kontrole, zapisy do logu itp. Zewnętrznie opatrzone parametrami dla ponownego użycia w ramach złożonych, tzw. łańcuchowych, skryptów testowych.
- Konfiguracje scenariuszy łączące scenariusz testowy z kontenerami danych podstawowych oraz połączeń systemowych.
- Katalogi testów będące zbiorem scenariuszy testowych możliwych do selekcji w ramach planów testów.
- Plany testów umożliwiające łączenie skryptów na potrzeby wykonania ich w określonym ciągu przez testerów.
Ponadto w ramach obiektów narzędzi eCATT należy wyróżnić użycie typowego mechanizmu systemowego wersjonowania obiektów pozwalającego na elastyczne zarządzanie przygotowywaniem skryptów. Środowisko umożliwia też proste raportowanie statusu wykonania testów, w przypadku błędów możliwe jest bezpośrednie przejście do szczegółowego logu dla sprawdzenia przyczyny, komentarzy testerów itp.
Jak to działa?
Proces przygotowania testów automatycznych rozpoczyna się od zdefiniowania przypadku testowego „na papierze”, poprzez bardzo dokładne opisanie kolejnych kroków testowanego procesu do poziomu wypełnianych pól na ekranie i wszelkich innych czynności, które użytkownik wykonuje, realizując proces w systemie. Elementem jego jest również zdefiniowanie danych testowych. Taką definicję wykorzystuje programista opracowujący skrypt testowy, realizując na jej podstawie nagranie transakcji. Po przygotowaniu nagrania, podlega ono sprawdzeniu w testowym uruchomieniu, uzupełniany jest ponadto o dodatkowe sprawdzenia kod skryptu. Po stwierdzeniu gotowości skryptu, następuje jeszcze zdefiniowanie jego interfejsu poprzez zamianę statycznych przykładowych danych na parametry wejściowe i wyjściowe.
Teraz przystępuje się do zdefiniowania danych testowych w kontenerze danych, które mogą zostać załadowane np. zewnętrznie z arkusza Excel przygotowanego przez użytkownika procesu. Po zdefiniowaniu skryptu testowego i kontenera danych podstawowych, można opracować obiekt konfiguracji, który połączy w sobie wcześniej zdefiniowane obiekty i umożliwi uruchomienie testu w docelowej konfiguracji. Tak zdefiniowany skrypt i dane możliwe są do wielokrotnego użycia.
Przygotowując skrypt, należy zwrócić uwagę na automatyczne uzupełnianie danych niezależnie od niego, np. na podstawie wariantów transakcji czy parametrów użytkownika. W przypadku wykorzystania użytkowników testowych, wymagane jest zdefiniowanie identycznych parametrów, jak dla użytkownika rzeczywistego.
W środowisku eCATT można definiować także obiekty umożliwiające zarządzanie zbiorem skonfigurowanych skryptów oraz definiowanie i realizację testów przez testerów. Obiekty konfiguracji skryptów umieszczane są w katalogach testowych, które można dowolnie definiować, zależnie od wymagań co do ich struktury. Jest to jednak nadrzędny poziom i w związku z tym przy niedużej liczbie skryptów mnożenie struktur katalogowych może utrudnić ich utrzymanie. Bardzo istotne znaczenie do realizacji testów mają plany testów, które również definiuje się w formie obiektu. Do planu można włączyć skrypty testowe z różnych katalogów i finalnie przypisać użytkowników, którzy będą je wykonywać.
Przygotowane wg powyższych zasad skrypty testowe są gotowe do użycia bezpośrednio za pomocą narzędzi eCATT w trybie synchronicznym i asynchronicznym jak również w przypadku takiej potrzeby możliwe jest zdefiniowanie wykonania testów w tle.
Na etapie przygotowania testów programista może skorzystać z uruchomienia skryptu w trybie debugger’a mając tym samym możliwość pełnej kontroli i przeglądu kolejnych kroków uruchamianego testu.
Wykonanie testów można śledzić w dostarczanych przez SAP AG prostych raportach monitorowania, gdzie możliwe jest szybkie sprawdzenie statusu kompletu wykonywanych testów, jak również szczegółów (logu) wykonania poszczególnego skryptu w przypadku błędu.
Wdrożenie eCATT w środowisku SAP
Przymierzając się do wdrożenia narzędzi i procedur automatycznego testowania w środowisku SAP opartych o skrypty eCATT, należy zwrócić uwagę na szereg aspektów. Proces wdrożenia eCATT jest typowym projektem z obszaru IT, który znajdzie się w portfelu firmy wyłącznie wtedy, gdy znajdzie poparcie kierownictwa i zarządu firmy, czyli, by to nastąpiło, niezbędne jest przygotowanie szacunków kosztów, a także korzyści z wykorzystania tego typu rozwiązań.
W rachunku kosztów uwzględnić należy m.in.:
- Inicjalne koszty przygotowania katalogu testowego
- Koszty opracowania procedur IT dla wykorzystania automatycznych testów
- Koszty utrzymania automatycznych testów
W kosztach przygotowania katalogu testowego, który może być sporządzony w formie projektu pilotowego, poza kosztami konsultacji specjalisty wdrożeniowego, wymagane jest uwzględnienie kosztów opracowania szczegółowych definicji procesów przez użytkowników kluczowych, kosztów warsztatów z narzędzi eCATT dla zespołu IT oraz warsztatów dla zespołu testerów. W projekcie pilotowym warto skupić się na automatyzacji testów kluczowych dla firmy procesów.
Efektem projektu, poza katalogiem testowym ze zdefiniowanymi skryptami testowymi, przeszkolonym zespołem, będą również instrukcje administratora, testera i developera testów. Część z tych instrukcji stanie się składową obowiązujących procedur IT wykorzystania testów automatycznych. W ramach utrzymania automatycznych testów, należy uwzględnić również ewentualne aktualizacje zdefiniowanych skryptów testowych w związku z podniesieniem wersji, rozszerzeniem funkcjonalności itp.
Przy szacowaniu korzyści natomiast należy uwzględnić dostępne benchmarki dla wykorzystania testów automatycznych. Wg opracowań SAP dla realizowanych wdrożeń eCATT szacuje się skrócenie czasu wykonania testów o ok. 80 do nawet 90%, w porównaniu do wykonywania testów ręcznie. Procent będzie tym wyższy im więcej będzie powtórzeń testu, np. dla wcześniej utworzonych kolejnych wariantów danych podstawowych. Istotnym elementem szacunku korzyści jest znaczące zwiększenie jakości procesu testów, które mogą być wykonane w dowolnym momencie, wielokrotnie i w maksymalnie powtarzalny, kompletny sposób.
Bezpieczniej, szybciej, taniej
W czasach, gdy ograniczanie kosztów staje się strategicznym celem firmy, wykorzystanie testów automatycznych w oparciu o eCATT może stanowić bardzo istotny element ograniczenia kosztów IT utrzymania systemów SAP w środowisku podlegającym ciągłym zmianom oraz testom, gdzie wymagane jest maksymalne zapewnienie bezpieczeństwa istniejącym procesom przy wdrażaniu nowych rozwiązań.
Automatyzacja testów w takim środowisku poza zwiększeniem bezpieczeństwa i jakości procesu testowania może także znacząco przyspieszyć cykl wdrażania nowych rozwiązań, ograniczając czas testów regresji, czy też znacznie eliminując ilość zgłoszeń błędów.
W konsekwencji znaczne ograniczenie wymaganego czasu rutynowych testów może długofalowo przynieść firmie korzyść w postaci możliwości zagospodarowania zaoszczędzonego czasu na zadania istotniejsze dla rozwoju firmy.