Testy UAT Dynamics 365: praktyczny poradnik

Kiedy potrzebny jest UAT w Dynamics 365

Test akceptacyjny odpowiada na jedno pytanie: czy biznes może wykonywać swoją pracę w tej wersji Dynamics 365? Testują ją ludzie, którzy tę pracę wykonują, własnymi słowami, zanim trafi na produkcję. UAT jest potrzebny w tych momentach.

• Go-live. Pierwsze wdrożenie Dynamics 365 Sales lub Customer Service albo przejście z innego CRM.
• Nowa aplikacja lub moduł. Customer Service obok Sales, nowa aplikacja oparta na modelu dla zespołu, portal klienta lub włączane funkcje Copilot.
• Duża zmiana. Nowa integracja z ERP lub nowy sposób kierowania spraw.
• Aktualizacje od Microsoft. Microsoft nie łączy już zmian w Dynamics 365 w dwie fale wydań w roku. Nowe funkcje i zmiany są wprowadzane przez cały rok. Plany wydań zostały zarchiwizowane w październiku 2026; to, co nadchodzi, jest teraz w roadmapie Microsoft pod adresem aka.ms/AIatWorkRoadmap. Każda aktualizacja może zmienić działanie Państwa systemu, nawet jeśli sami Państwo niczego nie zmienili.

Go-live wymaga pełnego UAT. Aktualizacje wymagają krótszego testu regresji najważniejszych procesów, w stałym rytmie. Więcej w części Po go-live.

Środowiska

Nigdy nie testować na produkcji. W centrum administracyjnym Power Platform każde środowisko ma typ. Do UAT potrzebne jest środowisko piaskownicy.

Kopia produkcji

Najbliżej rzeczywistości jest kopia produkcji w środowisku piaskownicy. Podczas kopiowania środowiska wybiera się, co zostanie skopiowane:

• Wszystko: dostosowania, schemat i wszystkie dane. Najbliżej produkcji, ale zawiera prawdziwe dane klientów i każdy rekord utworzony przez Państwa użytkowników.
• Tylko dostosowania i schematy: konfiguracja bez danych. Własne dane testowe wczytuje się później.

Kopia zastępuje zawartość środowiska docelowego, więc należy ją wykonać przed UAT, nigdy w trakcie. Następnie skierować integracje i przepływy Power Automate na systemy testowe, a nie na produkcję, sprawdzić skrzynki pocztowe i wyłączyć tryb administracyjny środowiska, gdy jest gotowe.

Rozwiązania i build

Zmiany z projektu trafiają do środowiska UAT jako rozwiązania. Należy importować je jako rozwiązania zarządzane, przez potok, jeśli jest dostępny, aby środowisko UAT dostało dokładnie to, co później dostanie produkcja.

• Należy uzgodnić, kiedy rozwiązania są importowane w trakcie testów, np. raz dziennie po triażu. Import w środku testu może zmienić ekran, na którym pracuje tester.
• Należy zapisać, które rozwiązania i wersje są w środowisku UAT. Numer wersji rozwiązania to testowany build, a każde zgłoszenie i każdy ponowny test należy do jednego z nich.

Dane testowe

Testerzy tracą godziny, gdy dane nie są gotowe. Należy je przygotować przed pierwszym dniem testów:

• Konta i kontakty dla każdego typu klienta, który jest testowany, z właściwym właścicielem i jednostką biznesową.
• Produkty i cenniki. Produkt potrzebuje pozycji cennika, zanim będzie można go dodać we właściwej cenie, i musi zostać opublikowany, zanim przedstawiciele handlowi będą mogli go używać. Sprawdzić, czy cennik każdego zespołu sprzedaży jest na miejscu.
• Kolejki, umowy SLA i artykuły bazy wiedzy dla Customer Service: kolejki, do których kierowane są sprawy, aktywne umowy SLA i opublikowane artykuły do wyszukania.
• Otwarte rekordy do pracy: leady, szanse sprzedaży na różnych etapach i otwarte sprawy.
• Bez prawdziwych danych osobowych tam, gdzie da się tego uniknąć. Kopia z opcją Wszystko zawiera je wszystkie, więc należy zamaskować lub zanonimizować to, czego testerzy nie muszą widzieć.

Role zabezpieczeń, jednostki biznesowe i użytkownicy według roli

UAT dowodzi, że każda rola może wykonywać swoją pracę i tylko swoją pracę. W Dynamics 365 zależy to od ról zabezpieczeń, jednostki biznesowej i zespołów użytkownika. Aplikacje również udostępnia się przez role zabezpieczeń: bez właściwej roli użytkownik w ogóle nie widzi aplikacji.

• Należy spisać testowane role, np. przedstawiciela handlowego, kierownika sprzedaży, agenta obsługi i kierownika obsługi, z ich jednostką biznesową.
• Każdy tester dostaje w środowisku UAT użytkownika z dokładnie tą rolą. Każdy użytkownik potrzebuje licencji, także w piaskownicy.
• Gdy jedna osoba testuje kilka ról, należy użyć osobnego użytkownika testowego dla każdej roli albo zmieniać rolę między testami i zapisywać, której użyto.
• Nigdy nie testować z rolą Administrator systemu. Widzi i może wszystko, więc ukrywa właśnie te problemy, które UAT powinien wykryć.

Co przekazać testerom o środowisku

• Adres środowiska UAT. Zwykła zakładka otwiera produkcję.
• Którą aplikację otworzyć, np. Sales Hub lub Customer Service workspace, i na jakie konto się zalogować.
• Że dane są testowe: nic, co zrobią, nie dotrze do prawdziwego klienta, a nic, co zobaczą, nie jest aktualne.
• Do kogo dzwonić, gdy nie mogą się zalogować lub nie widzą aplikacji.

W UAT StudioKażdy tester dostaje Test role, np. rolę zabezpieczeń, i Test account, widoczne nad jego testami jako Log in as …. W Notes for testers są adres środowiska, testowe skrzynki pocztowe i informacja, do kogo dzwonić. Testerzy logują się do UAT Studio kodem wysłanym e-mailem lub przez Sign in with Microsoft.

Przypadki testowe z user stories i procesów

Należy zacząć od procesów biznesu, a nie od tabel w Dataverse. Dwa procesy obejmują większość UAT Dynamics 365:

• Od leada przez szansę sprzedaży do oferty. Przychodzi lead i zostaje zakwalifikowany jako konto, kontakt i szansa sprzedaży. Szansa sprzedaży przechodzi przez przepływ procesów biznesowych, dostaje produkty z cennika, powstaje oferta, która zostaje zatwierdzona i aktywowana, a transakcja jest wygrana i trafia do następnego zespołu lub systemu.
• Obsługa spraw. Sprawa przychodzi e-mailem lub przez portal, jest kierowana do właściwej kolejki lub agenta, przebiega zgodnie ze swoją umową SLA, zostaje rozwiązana za pomocą artykułu bazy wiedzy, w razie potrzeby eskalowana, a następnie zamknięta jako rozwiązana.

Każdy proces należy podzielić na przypadki testowe obejmujące po jednym scenariuszu biznesowym, np. Qualify a lead with an existing account. Następnie sprawdzić, czy każda user story w zakresie ma co najmniej jeden przypadek testowy.

Przepływy procesów biznesowych

Przepływ procesów biznesowych prowadzi użytkowników przez etapy, z krokami, które mogą być wymagane przed przejściem do następnego etapu. Należy testować go tak, jak robi to użytkownik:

• Każdy etap i to, co się dzieje, gdy wymagany krok jest pusty.
• Każde rozgałęzienie i każdą rolę: przepływ może być włączony tylko dla niektórych ról zabezpieczeń.

Routing, umowy SLA i baza wiedzy

W Customer Service wiele pracy odbywa się bez kliknięcia. Należy przetestować to, co system powinien robić sam: e-mail staje się sprawą dla właściwego konta, sprawa trafia do właściwej kolejki, umowa SLA pokazuje właściwy czas i ostrzega, zanim minie, a agent znajduje właściwy artykuł bazy wiedzy.

Kroki zrozumiałe dla testerów biznesowych

Każdy krok należy zapisać jako działanie i oczekiwany wynik, słowami testera. Tam, gdzie to ważne, dodać dane testowe. Tester nigdy nie powinien zgadywać, czy krok się powiódł.

Priorytet i ryzyko

Nie każdy przypadek testowy jest równie ważny. Każdy należy oznaczyć jako Must, Should lub Could: Must to to, co musi działać od pierwszego dnia, np. tworzenie oferty lub kierowanie sprawy. Należy dodać ryzyko: ile kosztuje błąd w tym miejscu po go-live. Testerzy zaczynają od Must i wysokiego ryzyka, więc ważne testy zostaną wykonane, nawet gdy zabraknie czasu.

Należy dodać też ścieżki negatywne: puste pole wymagane, rabat powyżej limitu, użytkownik z innej jednostki biznesowej, który nie powinien widzieć rekordu.

W UAT StudioPrzypadki testowe można zaimportować z Excela z kolumnami Priority i Risk, odczytać z Azure DevOps Test Plans albo zacząć od scenariuszy Dynamics 365 z biblioteki szablonów, dodatku do każdego płatnego planu. Dzięki AI test design AI proponuje przypadki testowe na podstawie Państwa user stories w Azure DevOps, także na własnym modelu Państwa firmy, np. Microsoft Foundry / Azure OpenAI. Nic nie staje się przypadkiem testowym, dopóki Państwo tego nie zatwierdzą.

Testerzy

Należy wybrać osoby, które wykonują tę pracę na co dzień: opiekunów klientów, agentów obsługi i ich kierowników do zatwierdzeń, kolejek i pulpitów nawigacyjnych. Testerów warto wziąć z każdego zespołu i kraju, który korzysta z Dynamics 365, bo ich procesy, jednostki biznesowe i cenniki się różnią.

Ile czasu

Czas na testera należy uzgodnić z jego przełożonym i zostawić czas na ponowne testy. Testerzy, którzy nadal odbierają telefony lub odwiedzają klientów, nie skończą.

Kick-off

Warto zacząć od krótkiego kick-offu: dlaczego ich test jest ważny, jak otworzyć środowisko UAT, jak zapisać wynik i jak zarejestrować zgłoszenie. Każdy tester powinien zalogować się raz podczas kick-offu i otworzyć aplikację. Większość problemów z licencjami, rolami i niewłaściwym środowiskiem wychodzi wtedy, a nie w dniu testów.

Jeden dzień testów czy tydzień

Jeden dzień testów daje skupienie i szybkie odpowiedzi oraz pasuje do małego zakresu. Tydzień w blokach po kilka godzin zostawia miejsce na nowe buildy i ponowne testy oraz pasuje do go-live z wieloma procesami. W obu przypadkach należy ustalić stałą porę triażu każdego dnia.

W trakcie UAT

Rejestrowanie zgłoszeń

Dobre zgłoszenie można naprawić bez spotkania. Należy prosić testerów o:

• Krok, czego oczekiwali i co stało się zamiast tego.
• Zrzut ekranu strony, z komunikatem o błędzie, jeśli się pojawił.
• Link do rekordu. Jest w pasku adresu przeglądarki i prowadzi konsultanta prosto do szansy sprzedaży lub sprawy, w której wystąpił problem.
• Użytkownika i rolę zabezpieczeń, z którymi testowali.

W UAT StudioRozszerzenie przeglądarki dla Chrome i Edge pokazuje testy w panelu bocznym obok Dynamics 365. Nieudany krok zabiera ze sobą zrzut ekranu, link do rekordu i komunikaty o błędach ze strony. Rola testera jest widoczna w zgłoszeniu obok jego nazwiska.

Triaż

Codziennie należy przejrzeć nowe zgłoszenia, wspólnie z biznesem i zespołem Dynamics 365. Każdemu nadać wagę i osobę, która je naprawi, oraz zdecydować:

• Naprawa: prawdziwy problem, naprawiany w tym wydaniu.
• Odrzucenie: Dynamics 365 działa zgodnie z projektem albo test był błędny.
• Wniosek o zmianę: życzenie, a nie defekt. Trafia do backlogu, nie do tego wydania.

Zgłoszenia do naprawy należy przekazać programistom, często w Azure DevOps, ze zrzutem ekranu i linkiem do rekordu.

Ponowny test

Gdy poprawka znajdzie się w nowym buildzie w środowisku UAT, tester, który znalazł zgłoszenie, ponownie testuje krok. Należy zapisać, na którym buildzie wykonano każdy ponowny test. Po dużej poprawce należy ponownie przetestować także procesy wokół niej.

Codzienny status

Komitetowi sterującemu należy codziennie wysyłać krótki status: postęp względem planu, otwarte zgłoszenia według wagi i to, co blokuje. Bez niespodzianek na spotkaniu go/no-go.

W UAT StudioTriaż odbywa się na wspólnym ekranie z Fix, Reject i Change request. Zgłoszenie staje się elementem pracy Bug w Azure DevOps; gdy zostanie tam ukończone, zgłoszenie ma status Ready for retest, a tester dostaje e-mail. Każda runda zachowuje swoje wydanie, build i środowisko. Nowe zgłoszenia, rundy i sign-offy trafiają na kanał w Microsoft Teams.

Sign-off i go/no-go

UAT kończy się decyzją biznesu. Kryteria wyjścia należy uzgodnić przed pierwszym dniem testów, aby nikt nie spierał się o nie na końcu:

• Żadne zgłoszenie Critical nie jest otwarte.
• Każdy przypadek testowy Must zakończył się wynikiem pozytywnym.
• Każde otwarte zgłoszenie High ma obejście lub termin poprawki zaakceptowany przez biznes.
• Każdy przypadek testowy w zakresie ma wynik.

Kto podpisuje

Sign-off daje właściciel każdego procesu, np. dyrektor sprzedaży dla procesu od leada do oferty i kierownik obsługi klienta dla obsługi spraw. Wybiera: zaakceptowane, zaakceptowane z warunkami lub odrzucone. Każdy warunek należy zapisać, z informacją, kto go realizuje i do kiedy. Następnie komitet sterujący decyduje o go-live.

Co trafia do raportu

• Co było w zakresie, a czego nie przetestowano.
• Wyniki według procesu lub zespołu oraz według priorytetu.
• Środowisko, rozwiązania i build, które przetestowano.
• Otwarte zgłoszenia według wagi, z decyzją dla każdego z nich.
• Sign-offy z ich warunkami oraz znane ryzyka na pierwsze tygodnie.

W UAT StudioSign-off dla każdej grupy: Accepted, Accepted with conditions lub Rejected. Domyślnie nikt nie może zaakceptować, dopóki otwarte jest zgłoszenie Critical. Raport go/no-go jest gotowy jako PDF lub slajdy, gdy tylko pojawi się ostatni wynik.

Rundy regresji w stałym rytmie

Po go-live aktualizacje przychodzą dalej, przez cały rok, a każda może zmienić formularz, przepływ lub uprawnienie. Przypadki testowe z UAT to najlepszy test regresji, jaki Państwo mają: opisują dokładnie to, co biznes zaakceptował.

• Należy wybrać rytm, np. rundę regresji co miesiąc lub co kwartał, i już teraz wpisać terminy do kalendarzy testerów.
• Przed każdą rundą należy przeczytać roadmapę Microsoft i komunikaty dla administratorów oraz zanotować, które zmiany dotyczą Państwa procesów.
• Funkcje w wersji zapoznawczej lub we wczesnym dostępie należy najpierw wypróbować w środowisku piaskownicy, zanim dotrą do użytkowników.
• Ponownie przetestować przypadki testowe Must, a jeśli starczy czasu, także Should, z kilkoma testerami z biznesu.
• Rejestrować zgłoszenia tak jak w UAT i naprawić je, zanim zmiana dotrze do użytkowników.

W UAT StudioWystarczy wybrać Dynamics 365 jako CRM projektu. Start a regression round kopiuje wybrane przypadki testowe z wcześniejszego UAT, z ich krokami, danymi testowymi i oczekiwanymi wynikami: Must and Should, Only Must lub All test cases in scope.

Do bezpłatnego użytku

Wszystko, co trzeba załatwić przed UAT, w trakcie i po, opisuje checklista UAT na go-live CRM, dostępna też jako bezpłatny plik Excel. Co UAT Studio robi dla UAT Dynamics 365, opisuje strona UAT Dynamics 365.

Microsoft, Dynamics 365, Power Platform, Azure DevOps i Microsoft Teams są znakami towarowymi grupy firm Microsoft. UAT Studio nie jest powiązane z Microsoft ani przez niego rekomendowane.