Testy UAT Salesforce: praktyczny poradnik

Kiedy potrzebny jest UAT w Salesforce

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

• Go-live. Pierwszy Sales Cloud lub Service Cloud albo przejście z innego CRM.
• Nowa chmura lub duża zmiana. Dodanie Service Cloud obok Sales Cloud, CPQ, nowa integracja z ERP lub nowy sposób kierowania spraw.
• Każde wydanie Salesforce. Salesforce ma trzy wydania w roku: Spring, Summer i Winter. Wydanie Winter przychodzi jesienią i nosi numer kolejnego roku. Każde wydanie może zmienić działanie Państwa orga, nawet jeśli sami Państwo niczego nie zmienili.
• Sandbox preview. Sandboksy na instancji preview dostają nowe wydanie kilka tygodni przed produkcją. To jest okno na testy. Przed każdym wydaniem Salesforce publikuje, które instancje są w preview i co zrobić, aby sandbox tam pozostał. Warto sprawdzić to na czas, bo odświeżenie może przenieść sandbox do preview lub poza nie.

Go-live wymaga pełnego UAT. Wydanie wymaga krótszego testu regresji najważniejszych procesów. Więcej w części Po go-live.

Sandbox

Nigdy nie testować na produkcji. Salesforce ma cztery typy sandboksów. Dwa z nich nadają się do UAT.

Zaplanować odświeżenie

Odświeżenie zastępuje całą zawartość sandboksa nową kopią produkcji. Każdy typ sandboksa ma minimalny czas między odświeżeniami, a sandbox Full ma najdłuższy. Dlatego trzeba to zaplanować:

• Odświeżyć przed UAT, nigdy w trakcie. Sprawdzić, kiedy sandbox można odświeżyć następnym razem.
• Wdrożyć wydanie do sandboksa po odświeżeniu. Praca, która istniała tylko w sandboksie, znika.
• Wykonać kroki po odświeżeniu: skierować integracje i named credentials na systemy testowe, a nie na produkcję, oraz wyłączyć zaplanowane zadania, które nie powinny się uruchamiać.
• Sprawdzić dostarczalność e-maili. Nowy lub odświeżony sandbox wysyła tylko e-maile systemowe. Odpowiedzi web-to-lead, zatwierdzenia i e-maile do spraw wymagają więcej, ale sandbox Full zawiera prawdziwe adresy e-mail Państwa kontaktów. Przed włączeniem należy użyć adresów testowych.

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, regionem i typem rekordu.
• Produkty i cenniki. Produkt musi mieć cenę w standardowym cenniku, zanim może znaleźć się w innym cenniku. Sprawdzić, czy cenniki każdego zespołu sprzedaży są aktywne.
• Otwarte rekordy do pracy: szanse sprzedaży na różnych etapach, otwarte sprawy oraz sprawy bliskie kamienia milowego, jeśli testowane są entitlementy.
• Bez prawdziwych danych osobowych tam, gdzie da się tego uniknąć. Sandbox Full kopiuje wszystko, więc należy zamaskować lub zanonimizować to, czego testerzy nie muszą widzieć.

Użytkownicy według profilu i zestawu uprawnień

UAT dowodzi, że każda rola może wykonywać swoją pracę i tylko swoją pracę. Należy utworzyć użytkownika testowego dla każdej testowanej kombinacji profilu, roli i zestawów uprawnień, np. przedstawiciela handlowego, kierownika sprzedaży i agenta obsługi. Każdy tester dostaje własnego użytkownika, więc dwie osoby nigdy nie pracują jednocześnie na tym samym użytkowniku.

Po odświeżeniu Salesforce dodaje nazwę sandboksa do każdej nazwy użytkownika i .invalid do adresu e-mail każdego użytkownika. Należy ustawić e-mail każdego użytkownika testowego na adres, który tester czyta, w przeciwnym razie resety haseł i e-maile z zatwierdzeniami nigdzie nie dotrą.

Log in as pozwala administratorowi zobaczyć Salesforce oczami innego użytkownika. To dobry sposób, aby przyjrzeć się problemowi zgłoszonemu przez testera. W samym teście testerzy używają własnego użytkownika testowego: tylko tak wiadomo, że profil i zestawy uprawnień są prawidłowe.

Co przekazać testerom o sandboksie

• Adres sandboksa. Zawiera nazwę sandboksa albo logowanie odbywa się przez test.salesforce.com. Zwykła strona logowania Salesforce otwiera produkcję.
• Ich nazwę użytkownika, która kończy się nazwą sandboksa, oraz sposób otrzymania hasła.
• Ż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ć, zanim stracą cały poranek.

W UAT StudioKażdy tester dostaje Test role i Test account, widoczne nad jego testami jako Log in as …. W Notes for testers są adres sandboksa, testowe skrzynki pocztowe i informacja, do kogo dzwonić.

Przypadki testowe z user stories i procesów

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

• Od leada do płatności. Lead przychodzi przez web-to-lead, zostaje przypisany i skonwertowany. Szansa sprzedaży dostaje produkty z cennika, powstaje oferta, która zostaje zatwierdzona, transakcja jest wygrana, a zamówienie lub umowa trafia do następnego zespołu lub systemu.
• Obsługa spraw. Sprawa przychodzi przez email-to-case lub portal, jest kierowana do właściwej kolejki lub agenta, przebiega zgodnie ze swoim entitlementem i kamieniami milowymi, zostaje rozwiązana za pomocą artykułu bazy wiedzy, w razie potrzeby eskalowana, a następnie zamknięta.

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

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, który nie powinien widzieć rekordu.

W UAT StudioPrzypadki testowe można zaimportować z Excela z kolumnami Priority i Risk albo zacząć od scenariuszy Salesforce z biblioteki szablonów, dodatku do każdego płatnego planu. Testerzy widzą najpierw swoje przypadki testowe Must.

Testerzy

Należy wybrać osoby, które wykonują tę pracę na co dzień: przedstawicieli handlowych, agentów obsługi i ich kierowników do zatwierdzeń, prognoz i raportów. Testerów warto wziąć z każdego zespołu i kraju, który korzysta z Salesforce, bo ich procesy i cenniki się różnią.

Ile czasu

Należy prosić o czas na testera, a nie na zespół, i uzgodnić go z jego przełożonym. Scenariusze trzeba zaplanować tak, aby każdy tester wiedział, ile ma do zrobienia. Należy zostawić czas na ponowne testy po poprawkach. 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 zalogować się do sandboksa, jak zapisać wynik i jak zarejestrować zgłoszenie. Każdy tester powinien zalogować się raz podczas kick-offu. Większość problemów z użytkownikami i hasłami wychodzi wtedy, a nie w dniu testów.

Jeden dzień testów czy tydzień

• Jeden dzień testów, w jednej sali lub na jednym połączeniu, daje skupienie i szybkie odpowiedzi. Pasuje do małego zakresu i testerów, których trudno zwolnić na dłużej.
• Rozłożenie na tydzień, w blokach po kilka godzin, zostawia miejsce na poprawki i ponowne testy między blokami. 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.
• Link do rekordu. Jest w pasku adresu przeglądarki i prowadzi programistę prosto do szansy sprzedaży lub sprawy, w której wystąpił problem.
• Użytkownika, którym testowali, aby zespół wiedział, jakiego profilu i zestawów uprawnień użyto.

W UAT StudioRozszerzenie przeglądarki dla Chrome i Edge pokazuje testy w panelu bocznym obok Salesforce. Nieudany krok zabiera ze sobą zrzut ekranu, link do rekordu i komunikaty o błędach ze strony. Zgłoszenie pokazuje rekord jako link, łącznie z sandboksem.

Triaż

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

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

Ponowny test

Gdy poprawka zostanie wdrożona w sandboksie, 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. Tylko fakty. Bez niespodzianek na spotkaniu go/no-go.

W UAT StudioTriaż odbywa się na wspólnym ekranie z Fix, Reject i Change request. Ready for retest wysyła e-mail do osoby wykonującej ponowny test. Dzienne podsumowanie e-mailem lub w Microsoft Teams pokazuje wyniki i zgłoszenia z poprzedniego dnia.

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 płatności 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.
• Sandbox, wydanie 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.

Runda regresji na każde wydanie Salesforce

Po go-live wydania przychodzą dalej: trzy w roku. Każde może zmienić stronę, flow lub uprawnienie. Przypadki testowe z UAT to najlepszy test regresji, jaki Państwo mają, bo opisują dokładnie to, co zaakceptował biznes.

• Zachować przypadki testowe po go-live, z ich krokami, danymi testowymi i oczekiwanymi wynikami.
• Przeczytać release notes nadchodzącego wydania i sprawdzić, które funkcje zostaną włączone automatycznie.
• Sprawdzić, czy sandbox UAT jest w sandbox preview, i zaplanować rundę w oknie preview.
• 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 wydanie trafi na produkcję.

W UAT StudioWystarczy wybrać Salesforce jako CRM projektu. Strona projektów pokazuje wtedy nadchodzące wydania Salesforce z datą sandbox preview, datą wdrożenia na produkcję i release notes. Start a regression round kopiuje wybrane przypadki testowe: 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 Salesforce, opisuje strona UAT Salesforce.

Salesforce, Sales Cloud i Service Cloud są znakami towarowymi Salesforce, Inc. UAT Studio nie jest powiązane z Salesforce ani przez nie rekomendowane.