Przejdź do treści

Testy regresji SAP, Oracle, IFS i PeopleSoft w modelu fabryki testów UiPath Test Cloud

Oracle Fusion ma cztery obowiązkowe aktualizacje w roku, SAP S/4HANA Cloud dwa główne wydania i comiesięczne poprawki, IFS Cloud dwa wydania. Termin wyznacza dostawca. UiPath odpowiada na to wizją dark testing factory: obiegiem, który przy każdej zmianie sam ocenia ryzyko, wykonuje regresję i oddaje człowiekowi decyzję z dowodami.

Jacek BugajskiJacek Bugajski·

6 października 2026 roku UiPath Test Cloud trafił na Oracle Marketplace. Komunikat wymienia zakres wprost: Oracle Fusion Cloud Applications, Oracle E-Business Suite, PeopleSoft, Siebel i JD Edwards. Dwa tygodnie wcześniej, na konferencji FUSION, UiPath zapowiedział na październik autonomiczne wykonanie testów: Autopilot ma zinterpretować ręczny przypadek testowy i wykonać go w aplikacji bez wcześniej zbudowanej automatyzacji. Kierunek, w którym zmierza produkt, UiPath nazywa „dark testing factory”.

Testy regresji SAP, Oracle, IFS i PeopleSoft od lat sprawiają ten sam kłopot: sprawdzają funkcje, których nikt nie zmieniał, w terminie, którego nikt w firmie nie ustalał. Poniżej opisujemy, co UiPath rozumie przez fabrykę testów, jak przez jej komponenty przechodzi pojedyncza zmiana, czym różni się regresja w każdym z czterech systemów i w którym miejscu kończy się autonomia agentów.

Kalendarz wydań ERP ustala dostawca

Model, w którym dział IT sam decydował, kiedy podnieść wersję systemu, dotyczy dziś coraz mniejszej części portfela. Producenci przenieśli klientów do rytmu, który sami wyznaczają.

Oracle Fusion Cloud Applications. Oracle publikuje nowe funkcje cztery razy w roku w aktualizacjach kwartalnych i według własnej dokumentacji są one obowiązkowe dla wszystkich klientów. Środowiska nieprodukcyjne dostają aktualizację około dwóch tygodni przed produkcją - Oracle wiąże te terminy z pierwszym i trzecim piątkiem miesiąca aktualizacji. Tyle zostaje na regresję.

SAP S/4HANA Cloud Public Edition. Dwa wydania rocznie, przed każdym cztery tygodnie na testy, a do tego comiesięczne paczki poprawek (Hotfix Collections) z tygodniową fazą podglądu. W wersji on-premise i Private Edition SAP od 2023 roku wydaje nową wersję co dwa lata, a przez pierwsze dwa lata jej życia dokłada pakiety funkcji co sześć miesięcy.

IFS Cloud. Dwa wydania rocznie, w 2025 roku 25R1 pod koniec maja i 25R2 pod koniec listopada, oraz comiesięczne aktualizacje serwisowe.

Oracle E-Business Suite i PeopleSoft. Tu presja jest inna. Oracle zapowiedział wsparcie Premier dla E-Business Suite 12.2 oraz dla PeopleSoft co najmniej do 2037 roku. Te systemy mogą zostać w firmach jeszcze ponad dziesięć lat, a każdy kolejny obraz aktualizacji PeopleSoft Update Manager trafia na środowisko często obrośnięte latami modyfikacji i integracji.

Pozostałe systemy z portfela działają podobnie. Workday ma dwa wydania rocznie, w marcu i we wrześniu, oraz poprawki co tydzień. Salesforce wydaje trzy razy w roku. Dynamics 365 Finance and Operations wymaga co najmniej dwóch aktualizacji serwisowych rocznie i daje siedem dni na testy przed aktualizacją produkcji. Firma, która ma tylko Oracle Fusion, Salesforce i Workday, dostaje od dostawców dziewięć dużych wydań rocznie, każde z własnym, krótkim oknem testowym.

Liczba dużych wydań rocznie i okno testowe przed produkcją w systemach ERP i SaaS

Do tego dochodzi zmiana po Waszej stronie. SAP potwierdził 7 października 2026 roku, że podstawowe utrzymanie SAP Business Suite 7 kończy się 31 grudnia 2027 roku, a opcjonalne utrzymanie rozszerzone 31 grudnia 2030 roku. W wielu organizacjach konwersje do SAP S/4HANA nakładają się więc na kwartalny rytm systemów chmurowych, często w tych samych zespołach.

Dlaczego zespół testowy przegrywa z tym rytmem

Regresja nie rośnie razem z zakresem zmiany. Rośnie razem z liczbą rzeczy, których zmiana mogła dotknąć: integracji, wariantów konfiguracji, danych podstawowych, ról i uprawnień, raportów. Okno testowe pozostaje tej samej długości, więc testy często przerywa termin, zanim zespół dojdzie do końca listy przypadków.

Równolegle przyspiesza wytwarzanie zmian. Faros AI porównał w raporcie „The Acceleration Whiplash” dane 22 000 programistów i 4 000 zespołów z okresów najniższego i najwyższego wykorzystania narzędzi AI. Przepustowość zadań na programistę wzrosła o 33,7 procent, ale liczba błędów na programistę wzrosła o 54 procent, liczba incydentów przypadających na jedno scalenie zmian (pull request) o 242,7 procent, a zmian scalanych bez żadnego przeglądu przybyło o 31,3 procent. Przegląd zmian nie nadąża za ich tempem.

W modelu procesu, którym pracujemy na warsztatach z klientami, praca zespołu testowego składa się z dwudziestu czynności w czterech fazach: projektowanie testów, ich automatyzacja, wykonanie i zarządzanie. Trzynaście z nich wykonują ludzie. Automatyzacja klasyczna przejmuje w nim głównie wykonanie testów. Projektowanie przypadków, utrzymanie skryptów po zmianie ekranu, przegląd wyników i odróżnianie realnego błędu od niestabilnego testu wciąż czekają na człowieka. To one wyznaczają długość cyklu.

Czym jest dark testing factory według UiPath

Nazwa pochodzi z przemysłu. Fabryka „lights-out” to zakład, w którym roboty pracują bez obsługi na hali, a światło nie jest potrzebne. UiPath przenosi tę metaforę na jakość oprogramowania i opisuje fabrykę testów jako system jakości, który sam planuje, projektuje, wykonuje i utrzymuje testy od początku do końca.

Dwa zdania ze strony produktu warto przeczytać dokładnie. Pierwsze: dark testing factory to kierunek rozwoju Test Cloud, a UiPath zaznacza wprost, że nie jest to osobny produkt. Drugie: fabryka nie zastępuje testerów, tylko podnosi ich rolę. To ważne rozróżnienie, bo „ciemna fabryka” brzmi jak system, w którym nikt nie patrzy. W praktyce chodzi o przesunięcie ludzi z pracy wykonawczej do decyzji o jakości i ryzyku.

UiPath opisuje drogę do tego modelu w pięciu krokach. Na każdym inna jest rola człowieka.

Pięć poziomów dojrzałości testowania: od testów ręcznych do fabryki testów

Typowy zespół z biblioteką automatów stoi między drugim a trzecim poziomem: ma bibliotekę automatów, które ktoś musi utrzymywać, i zaczyna korzystać z asystentów AI przy pisaniu przypadków. Testowanie z agentami zaczyna się od poziomu czwartego, na którym agent pracuje samodzielnie w wąskim, nadzorowanym przebiegu. Piąty poziom różni się od czwartego jednym: system pracuje ciągle, w rytmie zmian, a nie dopiero po tym, jak ktoś go uruchomi.

Obieg jednej zmiany przez fabrykę testów

W naszym modelu jedna fabryka obejmuje jedną aplikację. Portfel składa się z wielu fabryk, każda w innym stanie gotowości, z jedną warstwą nadzoru nad wszystkimi. Animacja poniżej pokazuje obieg pojedynczej zmiany w czterech systemach i cztery różne zakończenia.

Obieg zmiany przez fabrykę testów regresji: sygnał, ocena ryzyka, dobór testów, wykonanie, analiza wyników i decyzja człowieka

1. Sygnał zmiany. Fabrykę uruchamia zdarzenie: transport w SAP, zgłoszenie w Jira, zmiana w repozytorium GitHub, przebieg w potoku CI/CD albo ręczne uruchomienie. W naszym modelu każdy sygnał trafia do rejestru z uzasadnieniem przyjęcia, a sygnał bez wpływu na aplikację nie generuje pracy, tylko zapis powodu tej decyzji.

2. Ocena ryzyka. To krok, którego klasyczna automatyzacja nie ma w ogóle. W naszym modelu ocenę prowadzi kilka niezależnych ról agentowych: jedna identyfikuje ryzyka wynikające z samej zmiany i celowo nie zna istniejących testów, żeby nie zawężać listy. Kolejne porządkują ryzyka względem obecnego obrazu, ustalają priorytety wobec tolerancji właściciela jakości i oceniają pokrycie: mocne, częściowe, brak albo niepewne. Ostatnia weryfikuje całość niezależnie. Wynikiem jest rekomendacja głębokości testowania: powtórzyć istniejące testy, rozszerzyć zakres albo napisać nowe. Dla SAP UiPath dostarcza tu gotowe narzędzie, Change Impact Analysis, które wskazuje transakcje dotknięte transportem i te z nich, którym nie odpowiada żaden test. Opisaliśmy je szczegółowo we wpisie o testach SAP S/4HANA przy konwersji i przed go-live.

3. Dobór i generowanie testów. UiPath Test Manager jest warstwą sterowania: planowanie, powiązanie przypadków z wymaganiami i wyniki. UiPath deklaruje synchronizację z ponad pięćdziesięcioma narzędziami ALM; dokumentacja opisuje integrację z SAP Solution Manager i SAP Cloud ALM. Autopilot generuje ręczne przypadki testowe bezpośrednio z wymagań, do pięćdziesięciu naraz, z dokumentów tekstowych, arkuszy, plików BPMN, a nawet zrzutów ekranu. Dla brakujących automatów powstaje nowy test do ponownego użycia.

4. Wykonanie regresji. Roboty UiPath Test Cloud uruchamiają testy równolegle w aplikacjach webowych, desktopowych i mobilnych, w SAP GUI i Fiori oraz przez API. Wyzwalaczem może być potok CI/CD: Jenkins, GitLab, GitHub Actions albo Azure DevOps. UiPath zapowiedział też na październik 2026 roku integrację z Playwright w wersji public preview. Ma ona pozwolić zespołom, które mają już testy napisane w Playwright, uruchamiać je z Test Managera bez przepisywania.

5. Analiza wyników. Na tym etapie zespoły tracą najwięcej czasu. W naszym modelu agent analizy odróżnia realny błąd aplikacji od niestabilnego testu. UiPath Healing Agent naprawia w trakcie wykonania między innymi zerwane selektory i problemy z czasem odpowiedzi. Gdy przyczyną jest zmiana ekranu po aktualizacji dostawcy, test zostaje naprawiony i wraca do ponownego przebiegu. Gdy przyczyną jest realny defekt, nasz obieg zakłada zgłoszenie i powrót sprawy do oceny ryzyka.

6. Decyzja o wydaniu. Na końcu stoi raport gotowości: werdykt, dowody, które za nim stoją, i lista nierozstrzygniętych kwestii. UiPath Maestro prowadzi cały obieg jako proces z jawnymi bramkami, w którym ludzie, agenci i automatyzacje pracują w jednym przebiegu. Decyzję o wydaniu podejmuje człowiek.

Komponenty UiPath Test Cloud w jednym obrazie

Architektura fabryki testów w UiPath Test Cloud: warstwa sterowania, agenci, wykonanie i fundament nadzoru

UiPath Test Manager to warstwa sterowania: plan, przypadki, powiązanie z wymaganiami, wyniki i integracje z ALM.

UiPath Maestro koordynuje agentów, automatyzacje i ludzi w jednym przebiegu. Bramki decyzyjne stanowią w nim nazwane, widoczne kroki procesu. Szerzej opisaliśmy to we wpisie o bramkach HITL w UiPath Maestro i AI Trust Layer.

UiPath Autopilot to asystent AI w projektowaniu, automatyzacji, wykonaniu i zarządzaniu testami.

UiPath Healing Agent naprawia automaty w trakcie wykonania.

UiPath Studio i Studio Web służą do budowy testów w trybie low-code i pro-code.

UiPath Agent Builder pozwala zbudować własnych agentów do obsługi procesów specyficznych dla Waszej aplikacji, na przykład rolę oceny ryzyka w obszarze regulowanym.

AI Trust Layer to warstwa nadzoru nad wykorzystaniem modeli AI w platformie.

Test Cloud jest dostępny jako usługa w chmurze (Public Test Cloud) i jako instalacja we własnym środowisku (Private Test Cloud, na Automation Suite). Drugi wariant ma znaczenie tam, gdzie dane testowe nie mogą opuścić organizacji. UiPath zaznacza przy tym, że zakres funkcji zależy od wariantu wdrożenia, wersji i poziomu platformy, więc konkretną konfigurację warto potwierdzić przy projektowaniu rozwiązania.

Testy regresji SAP, Oracle, IFS i PeopleSoft: czym się różnią

SAP. Zmiany w SAP są przenoszone transportami, a UiPath ma dla SAP osobny zestaw funkcji: testy całych procesów w SAP S/4HANA i ECC, w SAP GUI, WebGUI, Fiori i Business Client, opatentowany Heatmap dla SAP oraz Change Impact Analysis dla interfejsu, API (BAPI, RFC, IDoc) i uprawnień. Integracja z SAP Cloud ALM działa w obie strony: przypadki testowe, wykonanie i wyniki widać w obu systemach, w zakresie obsługiwanym przez daną wersję. Przy konwersji z ECC regresja ma dodatkowe zadanie, bo stary zestaw testów sprawdza model danych, który przestaje istnieć. Zakres takiego projektu opisujemy na stronie konwersji do SAP S/4HANA.

Oracle Fusion Cloud Applications. Główną trudnością jest termin zmian. Cztery razy w roku dostawca zmienia ekrany, przepływy i pola w terminie, którego nie da się przesunąć, a między środowiskiem testowym a produkcją mijają mniej więcej dwa tygodnie. To dokładnie ten scenariusz, w którym samonaprawa testów przestaje być ciekawostką: test zerwany przez zmianę ekranu, bez żadnego błędu aplikacji, nie powinien zabierać człowiekowi połowy okna testowego.

Oracle E-Business Suite i PeopleSoft. Systemy z wieloletnim wsparciem przed sobą, w wielu instalacjach z dużą liczbą modyfikacji własnych. Każdy obraz aktualizacji PeopleSoft i każda poprawka E-Business Suite trafia na modyfikacje własne, których dostawca nie testował. Ocena ryzyka zmiany ma tu większą wagę niż samo wykonanie, a biblioteka testów jest wiedzą o systemie, która często nie istnieje nigdzie indziej. Od 6 października 2026 roku UiPath Test Cloud jest dostępny dla obu tych systemów przez Oracle Marketplace.

IFS Cloud. UiPath nie publikuje osobnego materiału o testowaniu IFS i nie będziemy tego dopowiadać. IFS Cloud działa w przeglądarce, więc testujemy go jak aplikację webową: automaty budowane w Studio, selektory pilnowane przez Healing Agent, przypadki generowane z wymagań przez Autopilota. Dwa wydania rocznie i comiesięczne aktualizacje serwisowe dają rytm podobny do Oracle Fusion i taką samą potrzebę regresji przy każdej aktualizacji.

Workday, Salesforce i Dynamics 365. UiPath opisuje Workday i Salesforce na stronie poświęconej aplikacjom biznesowym, w tym regresję przy wydaniach Workday. Dynamics 365 testujemy jak IFS, jako aplikację webową.

Gdzie kończy się autonomia agentów

Fabryka testów nie oznacza systemu bez nadzoru. Granica przebiega w trzech miejscach.

Co system odtwarza sam: wykonanie testu i jego powiązania z aplikacją, środowisko testowe i dane do przebiegu, ponowne uruchomienie po nieudanej próbie.

Co zostaje decyzją człowieka: zmiana w kodzie aplikacji, zatwierdzenie poprawek przed ich wprowadzeniem i zgoda na wydanie mimo otwartego ryzyka. Odtworzenie wykonania testu to nie to samo co naprawa aplikacji. Samonaprawa dotyczy testu i nigdy nie obejmuje kodu Waszego systemu.

Co ustalamy przed uruchomieniem: cel fabryki, podłączone źródła i zasady działania. W naszym modelu testy uruchamiamy wyłącznie w środowisku testowym i na danych zamaskowanych, bez kopii danych produkcyjnych, a produkcja jest dostępna co najwyżej do odczytu. Ryzyko, którego agent nie umie ocenić, trafia do człowieka.

Autonomię ustawiamy trybem pracy, osobno dla każdego etapu. W trybie ręcznym człowiek uruchamia każdą pozycję, w półautonomicznym wyniki czekają na jego zatwierdzenie, w autonomicznym agent zapisuje wyniki bez pytania, ale polityki obowiązują dalej. Budżet działa na dwóch poziomach, z limitem na pojedynczy przebieg i limitem miesięcznym, a reakcję na wyczerpanie puli wybieracie w ustawieniach. Tam, gdzie liczy się rozliczalność zmian, równie ważny jak wynik testu jest jego ślad: skąd pochodzi, kto go zatwierdził i na podstawie jakiej zasady powstał.

Ten sam model w naszym produkcie: SNOK MDM

Zanim zaproponowaliśmy ten model klientom, wprowadziliśmy go u siebie. Testy naszej aplikacji SNOK MDM automatyzujemy w UiPath: przy każdej zmianie aplikacja przechodzi regresję reguł jakości danych i słowników, a testy jakości danych działają w trybie ciągłym. Nowa wersja nie czeka, aż zespół ręcznie przejdzie przez wszystkie ekrany.

Dla klientów SNOK MDM podział pracy jest prosty. Po ich stronie zostaje określenie scenariuszy testowych, czyli opis procesów i danych, które mają działać po każdej zmianie. Budowę automatów, ich uruchamianie i utrzymanie po zmianach w aplikacji bierzemy na siebie - na licencjach UiPath, które klient posiada, albo na licencjach, które dostarczamy wraz z licencją SNOK MDM.

Pilot fabryki testów: jedna aplikacja, jeden proces

Pilotaż zaczynamy od jednej aplikacji i jednego procesu, na przykład zamknięcia miesiąca w SAP albo procesu zakupowego w Oracle Fusion przed najbliższą aktualizacją kwartalną.

Do pilotażu potrzebne są cztery rzeczy: wybrany proces, źródła sygnałów o zmianach, dostęp do środowiska testowego i właściciel jakości po Waszej stronie. Rezultatem pilotażu jest fabryka dla tego procesu, biblioteka przypadków i danych testowych, ślad decyzji z artefaktami oraz raport gotowości z listą braków. Po pilocie są trzy możliwe decyzje: rozszerzyć model na kolejne procesy, utrzymać zakres pilota albo zakończyć bez dalszych zobowiązań. Pierwszy krok, warsztat zakresu, nie wymaga zmian w Waszym środowisku ani decyzji zakupowej.

UiPath ma pozycję lidera w dwóch raportach analitycznych o testowaniu: Gartner Magic Quadrant for AI-Augmented Software Testing Tools z 2025 roku i The Forrester Wave: Autonomous Testing Platforms z czwartego kwartału 2025 roku. SNOK jest partnerem UiPath Platinum. Zakres usług opisujemy na stronie agentic testing, a orkiestrację procesów na stronie UiPath Maestro. Wcześniejszy wpis o tym, jak agentic testing zmienia samo szukanie błędów, pokazuje, od czego zaczęła się ta zmiana.

Jeżeli najbliższa aktualizacja Waszego ERP ma już datę, a plan regresji jeszcze nie, napiszcie do nas. Zaczniemy od wyboru procesu do pilota.

Źródła

Tematy:Technologiczny Czwartektesty regresjiUiPath Test CloudSAP S/4HANAOracle
Spodobał się artykuł? Proszę podać go dalej:

Więcej z serii

Technologiczny Czwartek

Technologiczny Czwartek ze SNOK: SAP w energetyce, Snowflake i agenci UiPath - jak zbudować dane pod AI z nadzorem

SAP on-premise, system rozliczeniowy i kilkanaście aplikacji dziedzinowych to typowy krajobraz spółki energetycznej. Pokazujemy architekturę, w której dane trafiają do Snowflake zgodnie z licencją SAP, SNOK MDM rozstrzyga tożsamość klienta i dostawcy, a agenci UiPath działają pod kontrolą.

Technologiczny Czwartek ze SNOK: SAP MDG, Reltio czy SNOK MDM - kto ma pilnować jednej prawdy o Waszych danych

SAP ma dziś w portfolio SAP MDG oraz przejęte w maju Reltio. Porównujemy oba podejścia ze SNOK MDM: gdzie rozwiązanie może działać, jakie dane obejmie i jak szybko pokaże pierwszy wynik.

Jeden dostawca, pięć nazw - dlaczego dział zakupów nie widzi własnych wydatków

Ten sam dostawca istnieje w pięciu systemach pod pięcioma zapisami nazwy, więc dział zakupów siada do negocjacji z pięcioma średnimi kontrahentami zamiast z jednym dużym. Skąd bierze się rozjazd rekordów, co przez niego znika z pola widzenia, czym jest rekord obowiązujący i jak sprawdzić to u siebie bez projektu.

Skontaktuj się z nami

Skontaktuj się z namiNapisz na office@snok.ai