Automatyzacja Testów Regresji w środowisku SAP S/4 HANA

Czym są testy regresji w środowisku SAP?

Na wstępie chciałbym zacząć od głównych powodów dynamiki zmian w systemach:

• rosnące oczekiwania użytkowników,
• rozwój skali działalności,
• rozwój technologii,
• nowe otoczenie biznesowe.

Wszystko to sprawia, że technologia oraz systemy ERP stale ewoluują by sprostać coraz to większym wymaganiom organizacji.

W Arvato Supply Chain Solutions opieramy się głównie na systemie SAP, który zapewnia ciągłość operacji logistycznych przy obsłudze naszych klientów. Taki system przetwarza miliony zamówień oraz dokumentów, zatem wszelkie optymalizacje i zmiany pozwalają w znacznym stopniu na zwiększenie efektywności działania oraz poprawę komfortu pracy setkom użytkowników.

Warto jednak zaznaczyć, że proces zmian to nie tylko szansa dla firmy, lecz również ryzyko, które minimalizujemy przez odpowiednie testy systemowe mające na celu zabezpieczyć całość procesu.

Główna rola testów regresji

• potwierdzenie, że niedawno wprowadzona zmiana programu lub kodu nie wpłynęła niekorzystnie na inne istniejące funkcje systemu lub programu,
• upewnienie się, iż w wyniku zmian nie powstały nowe defekty lub nie ujawniły się wcześniej niewykryte błędy w niezmienionej części oprogramowania,
• zapewnienie, że cześć procesu, której nie powinna dotykać zmiana, nie została naruszona.

Powyższe aktywności mogą okazać się bardziej czasochłonne niż samo wykonanie zmiany. Jest to jednak koszt, który trzeba ponieść, aby zminimalizować ryzyko i zapewnić najwyższą jakość usługi.

Aby zobrazować umiejscowienie oraz wagę testów regresji posłużmy się poniższym diagramem:

Diagram dowodzi, że sama zmiana, dla której oczekiwanym efektem jest wpływ na proces sortowania, jest elementem, który – co do zasady – wywołać powinien całą falę aktywności testowych. Z jednej strony musimy upewnić się, że wdrożona zmiana rzeczywiście spełnia swoje założenie biznesowe i działa prawidłowo (testy sortowania). Z drugiej strony jednak, aby w pełni zabezpieczyć proces, należy wykonać dodatkowe testy pełnego procesu, możliwe w wielu wariantach (testy regresji).

Oczywiście zakres aktywności oraz konieczność testów jest uzależniona od specyfiki zmiany oraz jej charakteru, jednak sam diagram ma za zadanie przedstawić ogólny zarys problemu.

Przejście wszystkich scenariuszy testów regresji jest bardzo czasochłonne i wymaga:

• Przygotowania dużej ilości danych testowych (np. dostawy w SAP o odpowiednich parametrach, przygotowane w wielu różnych wariantach procesu). Należy pamiętać, że przygotowanie danych nie niesie bezpośrednio żadnej wartości biznesowej. Jest natomiast aktywnością potrzebną, aby rozpocząć sam test.
• Zespołu testowego, który w określonym czasie wykona kompleksowe testy regresji. W zależności od specyfiki procesu mogą to być dziesiątki lub nawet setki przeróżnych scenariuszy testowych.

Strategia automatyzacji testów regresji w SAP

Powyższe przykłady pokazują możliwe problemy związane z kompleksowymi testami regresji. Ich zrozumienie jest istotne, aby odpowiednio zaadresować sam problem związany z wysiłkiem organizacji potrzebnym do ich wykonania.

Zanim odpowiemy na pytanie, czy warto, postarajmy się zobrazować, czym właściwie jest wspomniana automatyzacja oraz jak mógłby wyglądać docelowy model takiego procesu? W odpowiedzi na to pytanie pomoże nam wcześniej wspomniany diagram procesu wysyłki:

W tym modelu nadal istnieje potrzeba przetestowania zmian oczekiwanych w procesie sortowania (testy sortowania), jednak całość aktywności związanych z testami regresji zostaje zlecona maszynie wirtualnej (robotowi). Odpowiednio zaprogramowany robot symulować będzie użytkownika końcowego systemu, klikając w buttony w aplikacji, wpisując wartości w odpowiednie pola i przechodząc całość procesu biznesowego w wielu wariantach w systemie SAP.

Rezultat takich działań (testów) może zostać zwrócony na różnych poziomach i przekazać informację zwrotną do osób zaangażowanych w samą zmianę.

Powodów, dla których proces testów regresji warto automatyzować jest wiele i trudno wymienić je wszystkie, jednak do podstawowych możemy zaliczyć:

• minimalizację zasobów ludzkich potrzebnych do wykonania testów regresji,
• większy zakres testów, pozwalający pokryć większą część wymagań biznesowych testami,
• szybszy rezultat oraz informacja zwrotna dla każdego testu,
• możliwość koncentracji uwolnionych zasobów na innych rodzajach testów (np. testy funkcjonalne dot. procesów, które uległy zmianie),
• przygotowanie danych testowych pod testy manualne/funkcjonalne (np. stworzenie wielu dostaw wychodzących w wielu różnych konfiguracjach).

Pamiętajmy, iż wcześniejsze wykrycie defektów i błędów pozwala zaoszczędzić wiele zasobów. Koszt zlokalizowania oraz naprawy błędu na późniejszym etapie cyklu życia systemu jest dużo wyższy niż w przypadku wykrycia go tuż po wykonanej zmianie.

Narzędzia do automatyzacji testów w SAP

Przykład przedstawiony w poprzedniej części artykułu dobrze obrazuje kierunek, którym podąża nasza firma.

W Arvato SCS, kluczowym elementem testowania jest platforma do automatyzacji testów. Generalnie na rynku dostępnych jest szereg specjalistycznych narzędzi, które służą do budowy środowiska testów automatycznych (również SAP) – zarówno dla aplikacji webowych, jak i desktopowych.

W modelu wykorzystanym przez Arvato SCS taką rolę pełni narzędzie UiPath Test Suite, które w dużym uproszczeniu oferuje:

• interfejs użytkownika do budowy testów automatycznych, dający możliwość nagrywania procesu, wykonywania operacji logicznych, pętli oraz interakcji z wszystkimi elementami aplikacji SAP GUI bez potrzeby użycia języków programowania,
• platformę dla użytkowników, pozwalającą uruchamiać stworzone wcześniej testy automatyczne, z różnymi parametrami wejściowymi, które odpowiednio zaprogramowane mogą wpłynąć na decyzje lub aktywności wykonywane przez robota w ramach testu,
• możliwość podłączenia do platformy wielu robotów, na których docelowo będą wykonywane testy automatyczne.

Maszyny wirtualne symulują rzeczywisty system operacyjny, na którym zainstalować możemy przeróżne aplikacje, w tym również SAP.

Taki robot posiada zatem własną aplikację SAP GUI wraz ze zdefiniowanymi połączeniami do systemów SAP, które będą przedmiotem automatyzacji testów regresji.

Robot połączony jest z sercem platformy –  czyli Orkestrator, którego zadaniem jest uruchomienie zaprogramowanego wcześniej testu i przekazanie zadania jego wykonania do wspomnianej maszyny wirtualnej.

Przebieg testu weryfikowany jest przez szereg kroków milowych zaprogramowanych w teście, a sam jego wynik zwracany jest do Orkiestratora w postaci dokładnego logu, zrzutów ekranu oraz stworzonych dokumentów w systemie SAP.

W ten oto sposób robot przejmuje rolę testera systemowego, symulując aktywności użytkownika aplikacji, pozwalając tym samym zdjąć ciężar ręcznego testowania z użytkownika. Zespół testujący może skupić się na innych rodzajach testów systemowych, a powtarzalne zadania związane z testami regresji zlecić platformie automatyzującej.

Model ten jest docelowym kierunkiem, którym podąża obecnie rynek, zarówno w środowisku SAP, jak i innych aplikacji webowych oraz desktopowych. Nowoczesna technologia oraz automatyzacja procesów pozwala eliminować błędy, a tym samym budować przewagę konkurencyjną organizacji.

Automatyzacja testów regresji jest zatem trendem, który pozwoli firmie w długiej perspektywie nie tylko zmniejszyć koszty operacyjne oraz przyspieszyć aktywności związane z procesem testowania, lecz przede wszystkim zapewnić bezpieczeństwo oraz stabilność złożonych procesów w środowisku SAP.