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

> Testy regresji SAP, Oracle, IFS i PeopleSoft przy każdej aktualizacji dostawcy. Jak działa dark testing factory w UiPath Test Cloud i gdzie decyduje człowiek.

- Source: https://snok.ai/pl/aktualnosci/blog/testy-regresji-sap-oracle-ifs-fabryka-testow-uipath/
- Author: Jacek Bugajski
- Published: 2026-10-08

---
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](https://snok.ai/images/blog/fabryka-testow-kalendarz-wydan-pl.webp)

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](https://snok.ai/images/blog/fabryka-testow-poziomy-dojrzalosci-pl.webp)

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](https://snok.ai/images/blog/fabryka-testow-obieg-pl.gif)

**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](https://snok.ai/pl/aktualnosci/blog/testy-sap-uipath-test-cloud-konwersja-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](https://snok.ai/images/blog/fabryka-testow-komponenty-pl.webp)

**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](https://snok.ai/pl/aktualnosci/blog/hitl-gate-uipath-maestro-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](https://snok.ai/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/).

**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](https://snok.ai/pl/produkty/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](https://snok.ai/pl/oferta/automatyzacja-ai/agentic-testing/), a orkiestrację procesów na stronie [UiPath Maestro](https://snok.ai/pl/oferta/automatyzacja-ai/uipath-maestro/). Wcześniejszy wpis o tym, [jak agentic testing zmienia samo szukanie błędów](https://snok.ai/pl/aktualnosci/blog/technologiczny-czwartek-ze-snok-agentic-testing-gdy-testy-same-szukaja-bledow-za/), 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](https://snok.ai/pl/kontakt/). Zaczniemy od wyboru procesu do pilota.

## Źródła

- UiPath, komunikat o dostępności UiPath Test Cloud na Oracle Marketplace, 06.10.2026, https://www.uipath.com/newsroom/uipath-oracle-marketplace-test-cloud (dostęp 07.10.2026)
- UiPath, komunikat o nowościach UiPath Test Cloud (FUSION 2026), 23.09.2026, https://www.uipath.com/newsroom/uipath-enhances-test-cloud (dostęp 07.10.2026)
- UiPath, strona produktu Test Cloud, https://www.uipath.com/product/test-cloud (dostęp 07.10.2026)
- UiPath, Agentic Testing, https://www.uipath.com/platform/agentic-testing (dostęp 07.10.2026)
- UiPath, Agentic software testing for SAP, https://www.uipath.com/platform/agentic-testing/sap-testing (dostęp 07.10.2026)
- UiPath, testowanie aplikacji biznesowych, https://www.uipath.com/platform/agentic-testing/enterprise-applications (dostęp 07.10.2026)
- UiPath, white paper „Dark Testing Factory: accelerated software delivery”, https://www.uipath.com/resources/automation-whitepapers/dark-testing-factory-accelerated-software-delivery (dostęp 07.10.2026)
- UiPath Documentation, Autopilot - manual test generation, https://docs.uipath.com/autopilot/other/latest/user-guide/manual-test-generation (dostęp 07.10.2026)
- UiPath Documentation, Test Manager - SAP Cloud ALM, https://docs.uipath.com/test-manager/automation-cloud/latest/user-guide/sap-cloud-alm (dostęp 07.10.2026)
- Oracle, dokumentacja Fusion Applications: planowanie rodziny środowisk, https://docs.oracle.com/en-us/iaas/Content/fusion-applications/plan-environment-family.htm (dostęp 07.10.2026)
- Oracle, komunikat o wsparciu Premier dla E-Business Suite 12.2 co najmniej do 2037 roku, 18.03.2026, https://www.oracle.com/a/ocom/docs/applications/ebusiness/ebs-122-premier-support-extended-through-at-least-2037.pdf (dostęp 07.10.2026)
- SAP, harmonogram utrzymania SAP S/4HANA Cloud Public Edition, 24.09.2026, https://d.dam.sap.com/x/qgSFemF/S4HANA_3SL_Maintenance_Schedule_for_Customer_Communication_2026Q34_2027Q12_2026_09_24.pdf (dostęp 07.10.2026)
- SAP News, strategia wydań i utrzymania SAP S/4HANA, 15.09.2022, https://news.sap.com/2022/09/new-sap-s4hana-release-maintenance-strategy/ (dostęp 07.10.2026)
- SAP News, utrzymanie SAP Business Suite 7 po 2030 roku, 07.10.2026, https://news.sap.com/2026/10/beyond-2030-sap-business-suite-7-sap-netweaver-customers-third-party-databases-java/ (dostęp 07.10.2026)
- IFS, nowości w IFS Cloud 25R2, 24.10.2025, https://www.ifs.com/en/assets/cloud/what-new-in-ifs-cloud-25r2 (dostęp 07.10.2026)
- Workday, harmonogram wydań, 11.07.2025, https://doc.workday.com/admin-guide/en-us/about-workday-documentation/workday-documentation---in-depth/workday-release-schedule.html (dostęp 07.10.2026)
- Salesforce Help, przygotowanie do wydań głównych, https://help.salesforce.com/s/articleView?id=sf.availability_test_and_prepare_for_major_releases.htm (dostęp 07.10.2026)
- Microsoft Learn, aktualizacje serwisowe Dynamics 365 Finance and Operations, 01.09.2026, https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/get-started/one-version (dostęp 07.10.2026)
- Faros AI, „The Acceleration Whiplash”, AI Engineering Report 2026, https://pages.faros.ai/hubfs/AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf (dostęp 07.10.2026)
- UiPath, pozycja lidera w Gartner Magic Quadrant for AI-Augmented Software Testing Tools, 09.10.2025, https://www.uipath.com/blog/product-and-updates/uipath-named-leader-gartner-mq-for-ai-augmented-software-testing-tools (dostęp 07.10.2026)
- UiPath, pozycja lidera w The Forrester Wave: Autonomous Testing Platforms, Q4 2025, 17.12.2025, https://www.uipath.com/blog/product-and-updates/uipath-named-leader-forrester-wave-autonomous-testing (dostęp 07.10.2026)
