# Technologiczny Czwartek ze SNOK: testy SAP S/4HANA przy konwersji i przed go-live w UiPath Test Cloud

> Heatmap, Change Impact Analysis i testy wydajnościowe w UiPath Test Cloud przy konwersji do SAP S/4HANA. Z zasadami ISTQB i ograniczeniami narzędzia.

- Source: https://snok.ai/pl/aktualnosci/blog/testy-sap-uipath-test-cloud-konwersja-go-live/
- Author: Jacek Bugajski
- Published: 2026-09-10

---
Change Impact Analysis w UiPath Test Cloud odpowiada na jedno pytanie: których transakcji SAP dotknęły transporty z ostatnich trzydziestu dni. Odpowiedź dzieli je na trzy koszyki. Transakcja dotknięta i pokryta testem to **Fit**. Dotknięta i bez przypisanego testu to **Gap**. Reszta to **Not impacted**.

Lista Gap jest punktem wyjścia tego wpisu. To transakcje, które zmiana dotknęła i którym w Test Managerze nie odpowiada ani jeden przypisany przypadek testowy. Przy konwersji do SAP S/4HANA potrafi ona wykroczyć poza zakres zaplanowanych testów.

Jedno zastrzeżenie od razu, żeby nie budować na tym więcej, niż wytrzyma: Gap mówi o pokryciu, nie o jakości. Nie jest miarą gotowości do go-live - o niej decydują jeszcze wyniki wykonanych testów, stan defektów i ocena ryzyka. Gap jest pierwszą liczbą w tej rozmowie, nie ostatnią. Fit też nie dowodzi, że test jest dobry: mówi tylko, że istnieje i jest przypisany.

Poniżej opisujemy, jak zamykamy listę Gap: co realnie testować po zmianie, jak dołożyć do tego testy wydajnościowe przed uruchomieniem produkcji i gdzie UiPath Test Cloud się kończy. Ostatnią część opisujemy na podstawie dokumentacji producenta, w tym osobnej strony znanych ograniczeń - materiały handlowe zwykle jej nie streszczają.

## Konwersja nie psuje planu testów - unieważnia go

Zestaw testów regresyjnych, który przechodził na SAP ECC przez pięć lat, po konwersji do SAP S/4HANA sprawdza świat, który przestał istnieć. Nie dlatego, że ktoś go zepsuł. Dlatego, że zmieniły się rzeczy, na których stał.

**Model danych.** Universal Journal, którego centralną tabelą jest ACDOCA, konsoliduje dane finansowe i zastępuje część wcześniejszych tabel pozycji i sum, na których opierały się stare raporty i zapytania. Nie znikają przy tym wszystkie dawne struktury - BSEG i BKPF pozostają. SAP dostarcza widoki zgodności, więc stary odczyt może dalej zwracać dane - albo nie, zależnie od sposobu dostępu. Test, który czytał tabelę sum bezpośrednio, trzeba sprawdzić pod tym kątem osobno, zanim uznacie jego zielony wynik za wiążący.

**Dane podstawowe.** Business Partner staje się głównym obiektem danych dla klienta i dostawcy, a integracja CVI jest warunkiem wejścia do konwersji, nie zadaniem na potem. Scenariusze oparte na zastępowanych transakcjach utrzymania klienta i dostawcy wymagają dostosowania do modelu Business Partner. Jeśli w ERP już pracowaliście na tym modelu, zakres dostosowań będzie mniejszy - ale kompletność powiązań CVI i tak trzeba potwierdzić przed konwersją.

**Długość pól.** SAP S/4HANA dopuszcza numery materiału do czterdziestu znaków, ale korzystanie z dłuższych wymaga świadomej aktywacji i sprawdzenia zgodności interfejsów. Skrypt testowy z zaszytym formatem osiemnastoznakowym przechodzi dalej i milczy - do dnia, w którym ktoś wprowadzi dłuższy numer.

**Wejście do systemu.** Tam, gdzie docelowy proces przechodzi na aplikacje SAP Fiori, automat sterujący wyłącznie ekranem SAP GUI wymaga rozszerzenia o interfejs przeglądarkowy. Nie kliknie kafla Fiori, choćby proces biznesowy pod spodem był identyczny.

**Kod własny.** Adaptacja modyfikacji podczas konwersji i wyniki ABAP Test Cockpit dla wersji docelowej mówią, co trzeba przepisać. Nie mówią, czy przepisane działa. To zostaje po stronie testów.

SAP Readiness Check dla SAP S/4HANA pokaże Wam simplification items, czyli uproszczenia wymagające decyzji i pracy przed konwersją, w jej trakcie albo po niej, oraz wynik analizy kodu własnego. To dobra lista **zmian**. Lista **testów** jest inna i nikt jej nie dostarczy razem z narzędziem.

## ISTQB nie jest ozdobą w ofercie

Metodyka testów bywa traktowana jak certyfikat do wpisania w przetargu. Przy konwersji SAP trzy zasady z sylabusa ISTQB Foundation Level decydują o kształcie planu i warto je nazwać po imieniu.

**Testowanie gruntowne jest niemożliwe.** Kombinacji procesów, wariantów konfiguracji i danych w dojrzałym systemie SAP nie da się przejść w całości. Priorytetyzacja oparta na ryzyku nie jest więc skrótem dla tych, którym brakuje czasu - jest normalnym sposobem pracy, obok technik projektowania przypadków testowych, które ograniczają liczbę kombinacji przy zachowaniu przyjętego kryterium pokrycia. Zdanie „przetestujemy wszystko” znaczy w praktyce „nie wiemy, co testujemy”.

**Defekty grupują się.** Po konwersji nie rozkładają się równomiernie. Nasza hipoteza na start - do sprawdzenia danymi z konkretnego projektu, nie do przyjęcia na wiarę - jest taka, że skupiska koncentrują się w kodzie własnym, w interfejsach do systemów zewnętrznych i w raportach zbudowanych na starym modelu danych. Zasada mówi, że skupiska istnieją; gdzie dokładnie, pokazują kolejne cykle testów.

**Testy się zużywają.** W sylabusie v4.0 zasada nosi nazwę „Tests wear out”; starsza wersja mówiła o paradoksie pestycydów. Ten sam zestaw testów powtarzany wielokrotnie na niezmienionym oprogramowaniu przestaje znajdować nowe defekty. Po konwersji zmieniło się jednak samo oprogramowanie, więc stara regresja nie tyle traci wartość, ile mierzy coś innego, niż zakładali jej autorzy. Trzeba ją przejrzeć, a nie tylko uruchomić.

Do tego dochodzi rzemiosło, którego nie zastąpi żadne narzędzie: poziomy testów z jasną odpowiedzialnością, kryteria wejścia i wyjścia zapisane liczbą, macierz pokrycia wymagań i klasyfikacja defektów rozdzielająca wagę defektu od priorytetu jego naprawy. Bez tego widok zarządczy w narzędziu pokazuje aktywność, nie gotowość.

Warto też znać osobną ścieżkę ISTQB dla wydajności - Certified Tester Performance Testing. Testy wydajnościowe mają własne pojęcia, własne ryzyka i własny sposób definiowania celów. Nie są trudniejszą wersją testów funkcjonalnych.

## Heatmap i Change Impact Analysis: co realnie testować

Tu zaczyna się część narzędziowa. UiPath Test Cloud odpowiada na pytanie „co testować po zmianie” na podstawie dwóch źródeł: realnego użycia systemu i treści transportów.

![Heatmap podłączony do systemu produkcyjnego SAP i Change Impact Analysis do systemu jakościowego, oba spięte z Test Managerem, którego wynikiem są trzy koszyki transakcji](https://snok.ai/images/blog/testy-sap-dwa-polaczenia-dwa-pytania.svg)

**Add-on ABAP.** Obie funkcje wymagają dodatku po stronie SAP. Obiekty trafiają do przestrzeni nazw `/UIPATH/`, a dodatek dostarczany jest transportami - osobnym dla Heatmap i osobnym dla Change Impact Analysis. To nie instalacja przez noty SAP ani przez SAINT. Dla ścieżki RFC użytkownik komunikacyjny potrzebuje obiektu uprawnień `S_RFCACL`; przy połączeniu przez usługę sieciową ten wymóg nie występuje.

**Heatmap.** Pokazuje, co i jak intensywnie jest używane w produkcji, nałożone na status pokrycia testami. Wynik Heatmap liczy z pięciu atrybutów SAP o konfigurowalnych wagach, które muszą sumować się do stu: Users z domyślną wagą 40, Intensity 30 oraz Execution, Time i Object po 10. Wagi przestawia się pod priorytety klienta, więc obraz „co ważne” jest decyzją, nie wyrocznią narzędzia. Dane z SAP pobierane są cyklicznie, z odstępem nie krótszym niż godzina.

**Etykietowanie w czasie działania.** Gdy w projekcie Studio włączycie monitorowanie SAP, wykonane transakcje dostają automatyczne etykiety w formacie `TRAN:ME21N` albo `PROG:NAZWA_PROGRAMU`. Dzięki temu Heatmap wie, co zostało przetestowane, bez ręcznego mapowania.

**Change Impact Analysis.** Wejściem są wybrane transporty SAP z okna ostatnich trzydziestu dni - analiza nie obejmuje automatycznie wszystkich zmian wynikających z konwersji. Analiza mapuje wpływ na transakcje, na interfejsy techniczne SAP BAPI, SAP RFC, SAP QUERY i SAP IDOC oraz na transakcje uprawnieniowe wraz z użytkownikami. Widok ma trzy zakładki: UI, API i Security. Dla transakcji w stanie Gap propozycje przypadków testowych może przygotować Autopilot for Testers, ale wynik wymaga przeglądu człowieka - to jest szkic, nie gotowy test.

**Architektura połączeń.** Rekomendacja producenta jest prosta i warto ją przenieść do projektu bez zmian: Heatmap podłączony do systemu produkcyjnego, Change Impact Analysis do systemu jakościowego. Heatmap ma powiedzieć, co jest naprawdę używane. Change Impact Analysis ma powiedzieć, co zmieniacie, zanim zmiana trafi na produkcję.

**Rozliczenie.** Pełna funkcjonalność Change Impact Analysis zależy od jednostek transportowych. Zużywa się jedna jednostka na unikalny transport, a powtórna analiza tego samego transportu jest już bezpłatna. Bez licencji zostaje sam widok ogólny. To ma znaczenie przy planowaniu, bo cutover generuje transporty seriami.

Praktyczny efekt z projektów SAP wygląda tak: zamiast pełnej regresji dostajecie listę transakcji dotkniętych konkretną paczką zmian, z zaznaczonymi lukami w pokryciu. Rozmowa z właścicielem procesu przestaje być targiem o czas i zaczyna być decyzją o ryzyku.

## Testy wydajnościowe: zielona regresja to jeszcze nie gotowy system

Test funkcjonalny odpowiada na pytanie, czy proces działa poprawnie. Test wydajnościowy odpowiada na inne: jak system zachowuje się przy określonym obciążeniu, na przykład wtedy, gdy o ósmej rano wchodzi trzystu użytkowników, a w tle chodzi zamknięcie okresu.

Ten drugi test bywa pomijany, bo wymaga osobnego planu, osobnej infrastruktury i osobnej wiedzy. Zasięg awarii zależy od defektu, nie od jego kategorii - ale część problemów wydajnościowych ujawnia się dopiero przy określonym obciążeniu, wolumenie danych albo współbieżności. Bez testu odtwarzającego te warunki wychodzą po uruchomieniu produkcji, przy pełnej widowni.

### Co robi warstwa SAP

**Przed konwersją.** SQL Monitor i SQL Performance Tuning Worklist pokazują na starym systemie, które fragmenty kodu własnego są realnie kosztowne w produkcji. To dobre wykorzystanie zasady wczesnego testowania: kosztowną instrukcję warto znaleźć przed konwersją i zmierzyć ponownie na systemie docelowym. Część zapytań rzeczywiście przyspiesza po przejściu na nowy model danych, ale która - tego nie da się założyć z góry.

**W trakcie i po.** Monitor obciążenia ST03N i rekordy pojedynczych operacji STAD dają czasy odpowiedzi w podziale na typ zadania. Raport `/SDF/MON` zbiera migawki procesów roboczych, pamięci i procesora do analizy incydentu. SAP Focused Run dokłada monitorowanie realnych użytkowników i syntetyczne monitorowanie użytkownika, czyli powtarzalny pomiar tego samego przebiegu w czasie.

Warto pamiętać, że to warstwa monitorowania i zarządzania, nie generator obciążenia. Powie Wam, jak system znosi obciążenie. Nie stworzy trzystu użytkowników.

### Co robi UiPath Test Cloud

Scenariusze wydajnościowe w UiPath Test Cloud biorą **istniejące automaty funkcjonalne** i uruchamiają je równolegle jako obciążenie. To jest sedno tej propozycji: jeśli macie już zautomatyzowaną regresję procesu zakupowego, nie piszecie skryptu obciążeniowego od zera. Ten sam automat staje się scenariuszem, a Wy dokładacie liczbę użytkowników wirtualnych, czas narastania i progi. Warunkiem jest zgodność automatu ze scenariuszem wydajnościowym: obsługiwane aktywności, wersje pakietów i dane pozwalające na równoległe wykonania.

Obciążenie generujecie przez interfejs użytkownika albo przez wywołania API. Dostępne rodzaje przebiegów to test obciążeniowy, test skokowy, test przeciążeniowy i test wytrzymałościowy. Wyniki - czasy odpowiedzi, błędy, przepustowość - widzicie w Test Managerze obok wyników testów funkcjonalnych, a nie w osobnym narzędziu z osobnym loginem. Przyczyn problemu szuka się dalej w monitorowaniu aplikacji i infrastruktury.

Jednostki licencyjne przeliczają się w stałej proporcji: jeden użytkownik pulpitowy odpowiada dziesięciu przeglądarkowym i stu użytkownikom API. Pakiet obejmuje 2 500 jednostek i 250 środowisk wykonawczych. Jednostki są rezerwowane na czas testu i wracają do puli po jego zakończeniu. Same jednostki nie są jednak całym rachunkiem: wykonanie bezserwerowe zużywa dodatkowo Platform Units, dochodzą też licencje na tworzenie i wykonywanie testów. Ile użytkowników danego typu daje pakiet, trzeba przeliczyć dla konkretnego scenariusza, zanim liczba trafi do oferty.

### Sześć rzeczy, które doszły w sierpniu 2026

Producent opisał je jako pakiet ułatwiający start i skalowanie testów wydajnościowych. Cztery z nich rozwiązują realne problemy projektowe.

![Trzy drogi generowania obciążenia w UiPath Test Cloud: bezserwerowo, na własnych robotach i z Elastic Robot Pools, z limitami i przelicznikiem jednostek licencyjnych](https://snok.ai/images/blog/testy-sap-skad-obciazenie.svg)

**Workflow Analyzer przed uruchomieniem** skanuje automat i wychwytuje to, czego w teście wydajnościowym uruchomić nie można: rozpoznawanie obrazu, OCR, zdarzenia sprzętowe, dostęp do plików lokalnych, wzorce działające tylko na pulpicie oraz rozjazd wersji Studio i pakietów. Wcześniej każda z tych rzeczy przerywała test w trakcie biegu.

**Capacity Planner** zastępuje statyczne szacowanie procesora i pamięci krótką serią sond na realnej infrastrukturze i wyprowadza z nich rekomendację liczby użytkowników wirtualnych.

**Elastic Robot Pools** generują obciążenie z Waszych własnych zasobów w Azure, AWS albo Google Cloud, zamiast ze współdzielonej infrastruktury. Dla klienta z wymogiem lokalizacji danych to mocny argument, choć sam nie zamyka tematu - regiony i przepływy danych pozostałych usług trzeba sprawdzić osobno.

**Metryki odporne na zaporę.** Przy zablokowanym porcie 5671 przesyłanie metryk przełącza się na WebSocket po porcie 443, a w ostateczności na dostarczanie przez API. Dotyczy to samych metryk, nie wszystkich połączeń testu - ale zwykle właśnie ten jeden port bywał powodem, dla którego test czekał w kolejce do zespołu sieciowego.

Do tego doszły raporty przygotowane osobno dla kierownika programu, dewelopera, zespołu infrastruktury i testerów oraz przegląd logów robota z filtrem po grupie obciążenia i wadze zdarzenia.

## Gdzie to nie działa

Ta sekcja jest w tym wpisie po to, żeby nie trzeba było jej odkrywać w trzecim tygodniu projektu.

**Change Impact Analysis wymaga bezpośredniego połączenia z systemem SAP.** Ścieżka z plikiem CSV zasila wyłącznie Heatmap. Jeśli klient nie zgodzi się na takie połączenie, funkcja analizy wpływu po prostu nie działa.

**Wejściem analizy jest użycie systemu i treść transportów.** UiPath zbiera też zależności wykrywane w czasie działania, ale głębokie prześledzenie statyczne, który obiekt ABAP jest używany gdzie i co się stanie po jego zmianie, to inna klasa narzędzi. SAP sprzedaje ją jako SAP Change Impact Analysis by Tricentis, na podstawie LiveCompare oraz chmurowego SeaLights for ABAP. Zakres analizy i model wdrożenia obu rozwiązań warto porównać dla konkretnego krajobrazu systemowego. Przy dużym, mocno zmodyfikowanym systemie te podejścia się uzupełniają. Twierdzenie, że jedno zastępuje drugie, nie utrzyma się w rozmowie z architektem.

**Testy wydajnościowe mają twarde granice wykonania.** Przebieg bezserwerowy w chmurze kończy się po sześćdziesięciu minutach, więc test wytrzymałościowy trwający całą noc wymaga robotów we własnej infrastrukturze albo Elastic Robot Pools. Scenariusze pulpitowe, czyli obciążenie idące przez SAP GUI, nie działają bezserwerowo. Dokumentacja konfiguracji podaje 500 użytkowników wirtualnych na grupę obciążenia i 2 000 na scenariusz, a strona ograniczeń dopuszcza do 10 000 na własnej infrastrukturze. Te zapisy opisują różne warstwy i nie składają się w jedną liczbę, więc limit dla Waszego trybu potwierdźcie u producenta, zanim wpiszecie go do planu testów.

**Obciążenie przez interfejs użytkownika jest drogie.** Jeden użytkownik wirtualny sterujący ekranem zużywa nieporównywalnie więcej zasobów niż użytkownik generowany na poziomie protokołu. To cena za realizm i za ponowne użycie testów funkcjonalnych. Przy scenariuszach na wiele tysięcy sesji trzeba ją policzyć uczciwie, a nie założyć, że skaluje się liniowo.

**Nie ma porównania historycznego przed pierwszym biegiem.** Punktem odniesienia może być dopiero pierwszy zakończony, reprezentatywny przebieg. Trend i regresję widać przez porównanie kolejnych porównywalnych przebiegów, nie po jednym.

**Playwright w Test Manager ma trzy ograniczenia i jedną pułapkę.** Od 4 września 2026 platforma uruchamia gotowe przypadki Playwright w JavaScripcie i TypeScripcie bez przepisywania ich w Studio, ale w trybie dostępności kontrolowanej, wyłącznie na silniku Chromium i wyłącznie bezserwerowo. Pułapka jest w raportowaniu: test, który przeszedł dopiero po ponowieniu, jest raportowany jako zaliczony. Wcześniejsze nieudane próby zobaczycie w zakładce Attempts, a załącznik wyniku niesie znacznik niestabilności. Jeśli rozliczacie stabilność testów, trzeba po tę informację sięgnąć świadomie.

**Model AI w Autopilot for Testers ma datę końca wsparcia.** Wsparcie GPT-4o kończy się 31 października 2026. Przed tą datą trzeba przestawić model w polityce AI Trust Layer, bo połączenia wskazujące wycofany model przestają działać.

**O pozycji rynkowej uczciwie.** UiPath jest jednym z liderów inauguracyjnego Magic Quadrant Gartnera dla narzędzi testowych wspieranych sztuczną inteligencją z października 2025. Jednym z kilku, nie jedynym, i to nadal jest ostatnia edycja tego raportu.

Nie znajdziecie w tym wpisie liczb w rodzaju „siedemdziesiąt procent szybszej automatyzacji”. Krążą w materiałach handlowych i nie mamy dla nich pierwotnego źródła, więc ich nie powtarzamy.

## Jak prowadzimy takie projekty w SNOK

Pracujemy na zasadach i terminologii testowania z sylabusów ISTQB oraz w fazach SAP Activate, bo to dwa układy, które klient i audytor rozpoznają bez tłumaczenia. ISTQB nie jest metodyką prowadzenia projektu - jest wspólnym językiem i zestawem zasad, na których buduje się plan.

Na początku przygotowujemy strategię testów: poziomy, typy, techniki projektowania przypadków, kryteria wejścia i wyjścia dla każdego poziomu, model zarządzania defektami i metryki. Potem plan testów dla każdego poziomu, macierz pokrycia wymagań i przypadki testowe przed automatyzacją, nie po niej. Pracę zamykamy raportem końcowym z rekomendacją uruchomienia albo wstrzymania, ryzykami rezydualnymi i tym, czego świadomie nie przetestowaliśmy.

![Fazy SAP Activate od Explore do Run z przypisanymi poziomami testów według ISTQB, wykonywaną pracą i artefaktem końcowym każdej fazy](https://snok.ai/images/blog/testy-sap-poziomy-na-osi-konwersji.svg)

W fazach SAP Activate rozkłada się to naturalnie. W Explore Heatmap i Change Impact Analysis budują obraz użycia i luk w pokryciu. W Realize powstaje automatyzacja regresji oraz wsparcie testów systemowych i akceptacyjnych. Testy wydajnościowe planujemy w strategii i uruchamiamy tak wcześnie, jak środowisko staje się reprezentatywne. W fazie Deploy wykonujemy regresję przed uruchomieniem, analizę transportów cutoverowych i potwierdzamy uzgodnione kryteria gotowości. W Run analiza wpływu zmian pracuje dalej jako stały radar w utrzymaniu.

Jeszcze jedna zasada, przy której obstajemy od końca lipca 2026. Każdy projekt z komponentem agentowym, a Autopilot for Testers nim jest, ma w planie testów osobny zestaw przypadków sprawdzających odporność agenta na przejęcie instrukcji. Powodem jest opublikowany eksperyment Pawła Cynkara na agencie z twardym zakazem korzystania z wiedzy ogólnej: z sześćdziesięciu ośmiu wektorów ataku dwadzieścia klasycznych odbiło się od zabezpieczeń, a trzy techniki - uzupełnianie luk w zdaniach, wstrzyknięcie treści do bazy wiedzy i prośba o przetłumaczenie reguł - pozwoliły odtworzyć instrukcję systemową w całości. Wniosek jest jeden: zakaz w prompcie nie jest zabezpieczeniem. Raport końcowy z testów bez tej sekcji nie ma czym odpowiedzieć na pytanie o odporność agenta. Szerzej rozwinęliśmy to w tekście o tym, [dlaczego odmowa asystenta AI nie jest zabezpieczeniem](https://snok.ai/pl/aktualnosci/blog/odmowa-asystenta-ai-nie-jest-zabezpieczeniem/) oraz przy [bramce nadzoru w UiPath Maestro](https://snok.ai/pl/aktualnosci/blog/hitl-gate-uipath-maestro-ai-trust-layer/).

SAP i UiPath mamy pod jednym dachem, razem z kompetencjami SAP Basis i bezpieczeństwa SAP. W praktyce znaczy to, że rozmowa o `S_RFCACL`, o skryptowaniu SAP GUI i o wpływie testu obciążeniowego na system produkcyjny toczy się w jednym zespole, a nie między dwoma dostawcami przez protokół ze spotkania.

## Trzy rzeczy, które warto zrobić w tym tygodniu

**Sprawdźcie, czy wiecie, co jest naprawdę używane w produkcji.** Nie z dokumentacji procesów, a z danych. Bez Heatmap wystarczy na start ST03N i lista transakcji z ostatniego kwartału. Transakcje bez śladu użycia w analizowanym okresie to kandydaci do przeglądu z właścicielem procesu - z pamięcią o procesach sezonowych, obowiązkowych i awaryjnych, które uruchamia się rzadko, a przetestować trzeba.

**Uruchomcie SQL Monitor na starym systemie, jeśli konwersja jest przed Wami.** Zbiera dane o realnym koszcie kodu własnego w produkcji. Im dłużej pracuje przed konwersją, tym lepszy obraz dostaniecie.

**Zapiszcie kryteria wyjścia dla go-live jako liczby.** Nie „testy zakończone sukcesem”, a „wszystkie przypadki priorytetu pierwszego zaliczone, zdawalność co najmniej dziewięćdziesiąt pięć procent z uzgodnionego zakresu, zero otwartych defektów krytycznych, czas odpowiedzi dialogu poniżej ustalonego progu przy obciążeniu docelowym”. Próg zdawalności jest ustaleniem projektowym, nie normą ISTQB. Zdanie zapisane wcześniej rozstrzyga spór, który inaczej wybuchnie w piątek cutoverowego weekendu.

---

Zostaje jedno pytanie, które warto zadać sobie przed pierwszym spotkaniem o testach: **czy wiecie, którym transakcjom w Waszym systemie nie odpowiada ani jeden przypisany przypadek testowy?** Żadna z możliwych odpowiedzi nie jest powodem do wstydu, bo taka lista rzadko powstaje sama - narzędzie musi jej poszukać. To jednak pierwsza liczba, od której zaczyna się poważna rozmowa o gotowości do konwersji.

Więcej o samym przesunięciu w podejściu do testów SAP napisaliśmy we wpisie [testowanie SAP jako problem zaufania do release](https://snok.ai/pl/aktualnosci/blog/testowanie-sap-problem-zaufania-do-release/). Jeśli planujecie konwersję do SAP S/4HANA albo uruchomienie nowego modułu i chcecie omówić plan testów, [napiszcie do nas](https://snok.ai/pl/kontakt/).

*Źródła: dokumentacja UiPath Test Manager i Test Cloud (Heatmap, Change Impact Analysis, połączenie RFC, scenariusze wydajnościowe, Playwright), informacje o wydaniach Test Manager z sierpnia i września 2026, dokumentacja SAP Help dla ST03N, STAD, `/SDF/MON` i SAP Focused Run, sylabus ISTQB Foundation Level v4.0 oraz ścieżka Certified Tester Performance Testing. Stan na 9 września 2026.*