Testy regresyjne po wydaniu CRM

Dlaczego CRM potrzebuje testów regresyjnych

Po go-live CRM ciągle się zmienia, nawet gdy Państwa zespół niczego nie zmienia. Salesforce i Microsoft aktualizują platformę dla każdego klienta. Większość zmian to ulepszenia. Niektóre zmieniają stronę, ustawienie domyślne lub sposób działania funkcji, a od czasu do czasu któraś psuje coś, na czym opiera się biznes.

Test regresyjny odpowiada na jedno pytanie: czy to, co biznes zaakceptował przy go-live, nadal działa? To nie jest nowy UAT. To krótka, ukierunkowana kontrola najważniejszych procesów, wykonywana, zanim zmiana dotrze do użytkowników, przez osoby, które znają tę pracę.

Własne wydania wymagają takiej samej kontroli. Nowa integracja, nowe pole w ofercie, zmiana przekierowywania spraw: każda z nich może naruszyć coś, co wcześniej działało.

Salesforce: trzy wydania w roku

Salesforce ma trzy duże wydania w roku: Spring, Summer i Winter. Wydanie Winter pojawia się jesienią i nosi numer następnego roku. Każda org jest aktualizowana w terminach, które Salesforce publikuje z wyprzedzeniem.

• Sandbox preview. Sandboksy na instancji preview dostają nowe wydanie kilka tygodni przed produkcją. To Państwa okno na testy. Przed każdym wydaniem Salesforce podaje, które instancje są w preview i co zrobić, aby sandbox w nim pozostał. Odświeżenie może przenieść sandbox do preview lub z niego, więc należy to sprawdzić odpowiednio wcześnie.
• Release notes. Warto je przeczytać pod kątem używanych chmur i funkcji. Należy szukać tego, co zostanie włączone automatycznie, i tego, co zmienia wygląd stron, na których pracują użytkownicy.
• Release updates. Niektóre zmiany są zapowiadane w Setup z datą, od której zaczynają obowiązywać. Należy je przetestować w sandboksie przed tą datą, aby nie zaskoczyły na produkcji.

Dla Salesforce rytm jest więc z góry określony: runda regresji w oknie preview każdego wydania, trzy razy w roku.

W UAT StudioJako CRM projektu należy wybrać Salesforce. Na około dwa miesiące przed wydaniem strona projektów pokazuje Coming CRM releases z datą sandbox preview, datą wdrożenia na produkcję i linkiem do release notes. Salesforce może jeszcze przesunąć te daty, więc warto sprawdzić release notes.

Dynamics 365: aktualizacje przez cały rok

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 r.; to, co nadchodzi, jest teraz w roadmapie Microsoft pod adresem aka.ms/AIatWorkRoadmap.

Oznacza to, że nie ma już jednego dużego momentu w roku, wokół którego można zaplanować testy. Zmiany przychodzą mniejszymi krokami, częściej. Czekanie na duże wydanie już się nie sprawdza, a testowanie po każdej pojedynczej zmianie to za dużo.

Wybór stałego rytmu

Odpowiedzią jest runda regresji w stałym rytmie, niezależnie od tego, co Microsoft wydaje w międzyczasie:

• Co miesiąc, gdy CRM jest kluczowy dla biznesu, korzystają Państwo z wielu aplikacji i funkcji albo często włączają nowe funkcje.
• Co kwartał przy stabilnej konfiguracji z niewieloma własnymi zmianami.
• Dodatkowa runda przed wdrożeniem własnej zmiany albo gdy zmiana od Microsoft wyraźnie dotyczy jednego z kluczowych procesów.

Terminy należy wpisać do kalendarzy testerów na cały rok. Stały rytm łatwiej utrzymać niż rundę planowaną za każdym razem, gdy coś się pojawi.

Przed każdą rundą

• Przeczytać roadmapę Microsoft i komunikaty dla administratorów w centrum administracyjnym Microsoft 365 i zanotować, które zmiany dotyczą Państwa procesów.
• Funkcje w wersji preview najpierw wypróbować w środowisku sandbox, zanim dotrą do użytkowników.
• Upewnić się, że sandbox, w którym odbywają się testy, ma tę samą wersję i te same rozwiązania co produkcja.

W UAT StudioJako CRM projektu należy wybrać Dynamics 365, a każdą rundę rozpoczynać przyciskiem Start a regression round z projektu go-live lub ostatniej rundy.

W UAT StudioW Setup należy wybrać Check the Dynamics 365 updates: Every quarter lub Every month. Strona projektów pokazuje wtedy bieżący okres z linkiem do roadmapy, a administratorzy dostają jeden email na okres, dwa tygodnie przed jego początkiem.

Wybór tego, co testować ponownie

Runda regresji to nie miejsce, by testować wszystko od nowa. Należy wybierać w tej kolejności:

1. Przypadki testowe Must. To, co musi działać każdego dnia: tworzenie oferty, konwersja leada, przekierowanie sprawy, zatwierdzenia. Testować je w każdej rundzie.
2. To, czego dotyczy zmiana. Release notes lub roadmapę czytać z listą własnych procesów obok. Zmiana w ofertach oznacza przypadki testowe ofert, także te Should i Could.
3. Integracje i automatyzacja. Połączenia z ERP, stroną internetową lub pocztą e-mail oraz przepływy działające w tle. Psują się po cichu, więc należy je testować celowo.
4. Przypadki testowe Should, gdy jest czas.

Następnie warto sprawdzić, co własny zespół zmienił od ostatniej rundy. Wszystko, co zbudowano samodzielnie i czego nikt nie przetestował razem ze zmianą platformy, też należy do rundy.

Krótka lista tego, co krytyczne

Raz należy zapisać od dziesięciu do dwudziestu procesów, bez których biznes nie obejdzie się nawet przez dzień. To rdzeń każdej rundy regresji. Listę należy przeglądać co pół roku z właścicielami procesów i po każdej dużej własnej zmianie.

W UAT StudioZ dodatkiem Release readiness Review the release pokazuje, których przypadków testowych dotyczy wydanie Salesforce lub aktualizacja Dynamics 365, z uzasadnieniem, proponuje przypadki testowe dla tego, co nie jest jeszcze pokryte, i wymienia wymagane aktualizacje z datami. Runda regresji dostaje wtedy dokładnie przypadki testowe Must, dotknięte, które zostają, i nowe, które zostały zatwierdzone. Fail w rundzie wskazuje, z którą zmianą przyszedł. €99 miesięcznie: dodaje się go w Plan & billing.

Ponowne wykorzystanie przypadków testowych

Najlepszym testem regresyjnym, jaki Państwo mają, jest zestaw przypadków testowych z UAT przy go-live. Opisują dokładnie to, co biznes zaakceptował, z krokami, danymi testowymi i oczekiwanymi wynikami. Nie należy pisać nowych na każdą rundę.

• Zachować przypadki testowe po go-live, w jednym miejscu, z ich priorytetem.
• Aktualizować je, gdy zmienia się własny proces, aby kolejna runda testowała CRM taki, jaki jest teraz, a nie taki, jaki był przy go-live.
• Sprawdzać dane testowe przed każdą rundą. Odświeżenie sandboksa lub kopia produkcji może usunąć lub zmienić rekordy, z których korzystają przypadki testowe.
• Dodawać przypadek testowy dla każdego poważnego zgłoszenia znalezionego na produkcji, aby następnym razem został wychwycony.

Przypadki testowe, które testerzy biznesowi potrafią wykonać, są tu warte wysiłku: są wykorzystywane wielokrotnie. Zob. Przypadki testowe zrozumiałe dla testerów biznesowych.

W UAT StudioStart a regression round kopiuje przypadki testowe projektu, od którego Państwo zaczynają, z krokami, danymi testowymi i oczekiwanymi wynikami. Można wybrać, które zostaną przeniesione: Must and Should, Only Must lub All test cases in scope; przypadek testowy bez priorytetu liczy się jako Should. Nowy projekt otrzymuje grupy i ustawienia, a testerów zaprasza się w Setup. Nic nie jest wymyślane ani zmieniane.

Kto testuje i jak długo

Kto

Runda regresji wymaga mniej osób niż UAT, ale nadal powinny one pochodzić z biznesu. Warto poprosić jednego lub dwóch kluczowych użytkowników na proces: osoby, które wykonują tę pracę codziennie i od razu zauważą, że coś jest nie tak. Administrator CRM przygotowuje rundę i testuje to, co działa w tle, ale nie powinien być jedynym testerem.

Niech te same osoby testują runda po rundzie. Stają się szybsze i zauważają drobne zmiany, które nowy tester by przeoczył.

Czas trwania

• Przygotowanie: dzień lub dwa na przeczytanie zmian, wybór przypadków testowych i sprawdzenie danych testowych.
• Testowanie: kilka godzin na testera, rozłożonych na jeden lub dwa dni przy rundzie miesięcznej, do tygodnia przy wydaniu Salesforce z wieloma zmianami.
• Poprawki i ponowne testy: zarezerwować kilka dni, zanim zmiana trafi na produkcję, na znalezione zgłoszenia.

W przypadku Salesforce wszystko to musi się zmieścić w oknie preview. Należy zacząć na początku okna, a nie w ostatnim tygodniu.

Rejestrowanie znalezionych problemów

Zgłoszenia należy rejestrować jak w UAT: krok, oczekiwany wynik, co stało się zamiast tego, zrzut ekranu i link do rekordu. Codziennie robić ich triaż z zespołem CRM. Przy zgłoszeniu spowodowanym przez platformę najpierw zajrzeć do release notes lub roadmapy: często jest to znana zmiana z ustawieniem do dostosowania.

W UAT StudioKażda runda zapisuje swoje wydanie, build i środowisko, więc raport go/no-go mówi, co przetestowano. Po poprawkach Start round 2 na dashboardzie z opcją Failed and blocked only testuje ponownie tylko to, co nie zadziałało; wyniki wcześniejszej rundy zostają zachowane.

Sign-off przed produkcją

Runda regresji kończy się jak UAT, decyzją, tylko krócej. Kryteria wyjścia należy uzgodnić raz i stosować je w każdej rundzie:

• Każdy przypadek testowy Must zakończył się wynikiem pozytywnym.
• Żadne zgłoszenie Critical nie jest otwarte.
• Każde otwarte zgłoszenie High ma obejście zaakceptowane przez biznes albo poprawkę, zanim zmiana trafi na produkcję.

Właściciel każdego procesu daje sign-off za swoją część: zaakceptowane, zaakceptowane z warunkami lub odrzucone. Przy wydaniu Salesforce nie da się zatrzymać aktualizacji, więc odrzucenie oznacza poprawkę lub obejście przed datą produkcyjną oraz komunikat dla użytkowników. Przy własnej zmianie odrzucenie oznacza, że zmiana czeka.

Wynik każdej rundy należy zachować. Po roku mają Państwo jasny zapis tego, co przetestowano po każdej zmianie i kto to zaakceptował. Jak przygotować decyzję, opisuje Decyzja go/no-go.

W UAT StudioRunda regresji to osobny projekt, z wydaniem jako Release, więc jej raport go/no-go mówi, którego wydania CRM dotyczy. Właściciele procesów dają sign-off dla każdej grupy, a sign-off dotyczy tej rundy.

Do bezpłatnego użytku

Checklista UAT na go-live CRM sprawdza się także przy rundzie regresji, jako bezpłatny plik Excel. Dla każdej platformy: UAT Salesforce i UAT Dynamics 365.

Salesforce jest znakiem towarowym Salesforce, Inc. Microsoft i Dynamics 365 są znakami towarowymi grupy spółek Microsoft. UAT Studio nie jest powiązane z Salesforce ani Microsoft ani przez nie popierane.