Jak minimalizować ryzyko wystąpienia defektów i koszty update’u rozwiązań Dynamics 365, wykorzystując testy regresyjne oraz narzędzie RSAT? 

Czym jest regresja i kiedy pojawia się w systemie?

Regres jest przeciwieństwem progresu. O ile progres to synonim postępu, oznacza pozytywną zmianę i jest czymś pożądanym, to jakiegokolwiek regresu wolimy unikać. Niestety zjawisko regresji może dotyczyć również infrastruktury informatycznej, nie wykluczając systemu ERP, który pośredniczy w wielu procesach istotnych dla działania organizacji.

Obecnie aplikacje biznesowe zsynchronizowane są z wieloma innymi narzędziami i ulegają ciągłym zmianom. Firma Microsoft dokłada wszelkich starań, aby regularnie dostarczać swoim odbiorcom aktualizacje usług. Rocznie pojawia się około siedmiu update’ów platformy Dynamics 365, a klienci są zobligowani do wdrożenia co najmniej dwóch z nich. Ponadto wielu przedsiębiorców decyduje się na dostosowanie systemu do swoich potrzeb poprzez zmiany jego standardowych funkcji.

Próba modernizacji systemu może przynieść odwrotny skutek i negatywnie wpłynąć na dotychczas poprawnie przebiegające procesy. W kontekście oprogramowania takie zjawisko nazywane jest regresem, czyli coś wcześniej działało, lecz po modyfikacji kodu programu przestało działać. Takie defekty mogą pojawić się właśnie w odpowiedzi na aktualizację oprogramowania, wprowadzenie poprawki czy modyfikacji, ponieważ każda z tych akcji powoduje zmianę w strukturze kodu systemu.

Jakie skutki może wywołać pojawienie się regresji?

Pamiętajmy, że kluczowym aspektem działania systemu jest zapewnienie ciągłości procesów, a implementacja nowych funkcji nie może odbywać się kosztem jego niezawodności i stabilności. Co, jeśli jednak taki defekt pojawi się w systemie?

Postawmy się w roli producenta, który właśnie wprowadził pewną modyfikację swojego systemu Microsoft Dynamics 365. Następnego dnia okazuje się, że wystąpił problem w module rozrachunków z dostawcami. Jednocześnie przedsiębiorca ma wiele niezrealizowanych zamówień na swoje wyroby i oczekujące zamówienia zakupu na surowce potrzebne do produkcji, których nie jest w stanie zrealizować ze względu na defekt. Produkcja zostaje opóźniona, jak i wiele zależnych procesów. Panuje coraz większy chaos, pracownicy poszukują alternatywnych dróg realizacji standardowych zadań. W ten sposób z pozoru niewielka zmiana na jakiś czas utrudniła codzienne obowiązki wielu osobom, a wyeliminowanie szkód powstałych w jej następstwie wymaga dodatkowego nakładu pracy.

Oczywiście wystąpienie regresji nie musi spowodować wystąpienia aż tak czarnego scenariusza, jednak zawsze będzie wiązać się z niedogodnościami.

Czym są testy regresywne i co jest ich celem?

Czy więc powinniśmy opierać się wszelkim zmianom? Oczywiście, że nie, byłoby to nierozsądne. System ERP z założenia powinien być elastyczny i nieustannie dopasowywać się do nowych wymagań biznesowych. Należy jednak mądrze podejść do jego modernizacji, będąc świadomym możliwości zaistnienia zjawisk niepożądanych. Jak głosi powiedzenie: „Lepiej zapobiegać niż leczyć” i sprawdza się ono również w tym przypadku.

Dobrą taktyką jest testowanie systemu pod kątem wystąpienia regresji. Polega ona na regularnym przeprowadzaniu testów weryfikujących czy dane procesy nadal wykonywane są poprawnie. W praktyce wygląda to tak, że tester bądź specjalny program realizuje dany proces krok po kroku, zaznaczając czy każdy z nich udało się wykonać. Jeśli test się nie powiódł, szybkie wykrycie i zgłoszenie wystąpienia regresji znacznie skróci czas jej eliminacji.

Takie testy mogą być realizowane na każdym etapie działania systemu, jednak szczególnie zalecane jest przeprowadzanie ich po aktualizacji oprogramowania, zmianie wymagań istniejących funkcji czy wprowadzeniu nowych funkcji lub poprawek. W procesie testowym biorą udział osoby dysponujące wiedzą na temat różnorakich operacji biznesowych, często specjalizujące się w obsłudze konkretnych modułów. Skład zespołu powinien być zróżnicowany, tak aby testy pokrywały różne aspekty systemu, także finansowe czy związane z przepisami prawa dla danego kraju lub obszaru terytorialnego.

RSAT, czyli niezastąpiony asystent w testowaniu regresji

Wiemy już, że nie należy lekceważyć testów regresyjnych. Naturalnie nasuwa się pytanie o to, jak skutecznie wdrożyć je w firmie.

Rozważmy testy manualne - wymagają one przygotowania wielu zestawów testowych (ang. Test Suites), a w każdym z nich znajdują się przypadki testowe (ang. Test Cases). Przypadek testowy składa się z listy kroków, które należy wykonać, aby zyskać pewność, że dana funkcjonalność Dynamics 365 działa prawidłowo.

Wyobraźmy sobie, że w proces testowania angażujemy wyznaczony zespół, przekazujemy mu „instrukcję testowania”, po czym każdy z członków bada przypisany mu moduł. To, że cały proces pochłonie ogromną liczbę godzin, nie ulega wątpliwości. Oczywiście im bardziej rozbudowany bądź zmodyfikowany jest nasz system, tym więcej czasu zajmie jego przetestowanie. Ponadto konieczność powtórzenia tego niewdzięcznego zadania pojawi się ponownie wraz z podniesieniem wersji środowiska lub gdy zdecydujemy się na wprowadzenie zmian w naszym systemie ERP.

Taka wizja nie zachęca do manualnego testowania regresji. Jaka jest więc alternatywa? Oczywiście automatyzacja opisanego procesu. Z pomocą przychodzi Regression Suite Automation Tool, w skrócie RSAT, czyli narzędzie firmy Microsoft dedykowane automatycznym testom regresyjnym systemu Dynamics 365.

RSAT działa w prosty sposób - wystarczy dostarczyć mu „instrukcję” zawierającą opis procesu, a on zrealizuje go automatycznie. W stworzeniu takiej instrukcji pomaga wbudowany w Dynamics 365 Task Recorder. Przy pomocy tego narzędzia jesteśmy w stanie zarejestrować prawie każdy proces biznesowy i zapisać go w formie nagrania.

‍

Kolejnym nieodłącznym elementem RSAT-a jest w pełni zintegrowana z nim platforma Azure DevOps, a jej usługa - Test Plans - ułatwia zarządzanie testami oraz ich wynikami.

Jak działa RSAT?

Przyjrzyjmy się kilku aspektom technicznym testowania przy użyciu RSAT.

• Jeśli posiadamy skonfigurowanego RSAT-a oraz nagranie procesu stworzone przy użyciu Task Recordera, możemy przejść do tworzenia testów.
• Każdy przypadek testowy bazuje na osobnym nagraniu, na podstawie którego RSAT generuje zestaw plików, w którego skład wchodzą pliki wykonywalne z kodem C# oraz konfigurowalny plik Excel przechowujący parametry testu.
• Podczas uruchomienia testu RSAT, z udziałem frameworku Selenium, automatycznie otwiera przeglądarkę, przechodzi do naszego systemu i powtarza wszystkie kroki zawarte we wskazanym nagraniu.
• Jeśli odwzorowywany proces przebiegnie bez przeszkód, test zakończy się powodzeniem.
• Jeśli programowi nie udało się poprawnie wykonać w naszym środowisku któregoś z kroków, test zakończy się niepowodzeniem i wyświetlona zostanie wiadomość na temat błędu.

‍

W ten sposób RSAT wyręcza człowieka i za pomocą testów przeczesuje system w poszukiwaniu anomalii.

Efekty wykonania nieudanych testów wymagają oczywiście uwagi, ale dzięki możliwości przesyłania wyników na platformę Azure DevOps ich analiza staje się prostsza. Poszczególne osoby biorące udział w procesie testowym mogą śledzić zachodzące postępy i zarządzać planami testów, których dla projektu może być kilka. Co więcej, integrując RSAT z Azure Pipelines, zyskamy możliwość stworzenia harmonogramu testów - z jego pomocą testy mogą być inicjowane cyklicznie o wyznaczonych godzinach.

Jak wdrożyć RSAT?

Jeśli posiadasz platformę Dynamics 365 Finance and Operations w wersji minimum 15 lub nowszą, nic nie stoi na przeszkodzie wdrożenia opisanego rozwiązania. Aby było to możliwe, potrzebna jest licencja Azure DevOps Test Manager lub Test Plans oraz arkusz kalkulacyjny Microsoft Excel. Natomiast najnowszą wersję aplikacji RSAT można za darmo pobrać ze strony Microsoft. Narzędzie można zainstalować na dowolnym komputerze z systemem Windows 10, Windows 11 lub Windows Server 2016, ponieważ ze środowiskiem testowym zawsze będzie łączyć się za pośrednictwem przeglądarki internetowej. Jeśli chodzi o wymagania techniczne, to wszystko.

Najważniejszą kwestią jest opracowanie kompleksowego zestawu testów dopasowanego do naszego systemu ERP. Należy rozważyć, które komponenty aplikacji mają znaczenie krytyczne bądź są szczególnie podatne na błędy. Testy najważniejszych funkcji powinny posiadać wyższy priorytet i być przeprowadzone w pierwszej kolejności. Połowę sukcesu stanowi poprawne zarejestrowanie procesów, na których bazować będą testy. Testy stworzone na podstawie nagrań mogą być później modyfikowane i uruchamiane przez różnych użytkowników systemu. Niektóre testy oparte na uniwersalnych procesach mogą być przeprowadzane w różnych modułach, a także w wielu firmach istniejących w systemie.

Podsumowanie

Reasumując, Task Recorder umożliwia nagrywanie procesów realizowanych w Dynamics 365; RSAT na podstawie nagrań tworzy zautomatyzowane testy, którymi możemy zarządzać w Azure DevOps Test Plans. Dzięki temu pakietowi narzędzi jesteśmy w stanie odwzorowywać powtarzalne procesy oraz sprawdzać, czy uprzednio działające funkcjonalności nie zostały uszkodzone podczas implementacji nowych. Testy wykonywane przez RSAT pomogą szybko wykryć anomalie, a tym samym zmniejszyć lub wyeliminować koszty związane z ich usunięciem. Dlatego, jeśli zależy nam na ciągłości procesów biznesowych, warto jak najszybciej wdrożyć testowanie regresji w naszym systemie.

Obejrzyj symulację testów regresyjnych z użyciem narzędzia RSAT dla Microsoft Dynamics 365:

‍