Checklista UAT na go-live CRM

Przed UAT

Większość nieudanych UAT psuje się właśnie tutaj: niejasny zakres, scenariusze, których nikt nie sprawdził, testerzy bez działającego konta.

Zakres

• Uzgodnić, które procesy i user stories wchodzą w zakres UAT, i zapisać, co nie wchodzi.
• Wyznaczyć dla każdego procesu właściciela z biznesu: osobę, która daje sign-off.
• Uzgodnić, co oznaczają Critical, High, Medium i Low, zanim zostanie zarejestrowane pierwsze zgłoszenie.

Przypadki testowe

• Napisać jeden przypadek testowy na każdy scenariusz biznesowy, słowami osób, które będą go testować.
• Każdemu krokowi nadać czynność i oczekiwany wynik, a tam, gdzie to ważne, także dane testowe.
• Oznaczyć każdy przypadek testowy jako Must, Should lub Could, aby najważniejsze zostały przetestowane w pierwszej kolejności.
• Dodać ścieżki negatywne: błędną wartość, brakujące pole, użytkownika bez właściwej roli.
• Sprawdzić, czy każda user story w zakresie ma co najmniej jeden przypadek testowy.
• Poprosić kluczowego użytkownika z biznesu o przejrzenie scenariuszy przed dniami testowymi.

Testerzy

• Wybrać testerów, którzy wykonują tę pracę na co dzień, z każdego zespołu korzystającego z systemu.
• Przypisać każdemu testerowi grupę i własne scenariusze.
• Zablokować dni testowe w ich kalendarzach i zwolnić ich z codziennych obowiązków.
• Przeszkolić ich w pół godziny: jak zapisać wynik i jak zarejestrować zgłoszenie.

Środowisko i dane testowe

• Przygotować środowisko testowe podobne do produkcji: konfiguracja, integracje i dane.
• Utworzyć konto testowe dla każdej roli i sprawdzić, czy na każde można się zalogować.
• Załadować dane testowe: klientów, produkty, cenniki i otwarte rekordy.
• Wszędzie, gdzie to możliwe, używać danych testowych zamiast danych klientów.
• Uzgodnić, kiedy w dniach testowych poprawki są wdrażane do środowiska testowego.

Harmonogram

• Zaplanować dni testowe w blokach, ze stałą codzienną porą na triaż.
• Zarezerwować czas na rundę ponownych testów po poprawkach.
• Ustalić termin spotkania go/no-go i już teraz zaprosić komitet sterujący.
• Sprawdzić kalendarz wydań Salesforce lub Dynamics 365: wydanie platformy w środku UAT zmienia to, co jest testowane.

Kryteria wejścia

• Test systemowy jest zakończony i żaden defekt Critical z niego nie jest już otwarty.
• Środowisko testowe, konta testowe i dane testowe są gotowe.
• Biznes przejrzał przypadki testowe.
• Każdy tester został zaproszony i raz się zalogował.

W trakcie UAT

Dni powinny być krótkie, a informacje w jednym miejscu, aby problemy były wykrywane, rozstrzygane i naprawiane tego samego dnia.

Codzienny stand-up

• Zaczynać każdy dzień od piętnastu minut: co przetestowano, co blokuje, co jest zaplanowane na dziś.
• Porównywać postęp każdej grupy z planem i przesuwać testerów tam, gdzie są potrzebni.

Rejestrowanie zgłoszeń

• Rejestrować jedno zgłoszenie na jeden problem, z krokiem, oczekiwanym wynikiem i tym, co stało się zamiast niego.
• Dodać zrzut ekranu i link do rekordu.
• Najpierw poszukać istniejącego zgłoszenia, aby ten sam problem nie został zarejestrowany dwa razy.
• Dopilnować, aby każdy nieudany krok miał zgłoszenie albo uzasadnienie, dlaczego go nie ma.

Triaż

• Prowadzić triaż codziennie, wspólnie z biznesem i zespołem deweloperskim.
• Każdemu nowemu zgłoszeniu nadać wagę, priorytet i osobę, która je naprawi.
• Dla każdego zdecydować: naprawić, odrzucić czy zamienić na wniosek o zmianę.
• Wnioski o zmianę umieszczać w backlogu, nie w tym wydaniu.

Ponowne testy

• Po wdrożeniu poprawki zlecić ponowny test testerowi, który znalazł problem.
• Zapisywać, na jakim wydaniu i buildzie wykonano każdy ponowny test.
• Po dużej poprawce rozpocząć nową rundę i ponownie przetestować procesy wokół poprawki.

Zamknięcie UAT

UAT kończy się decyzją. Należy ją podjąć na podstawie faktów i zapisać, kto o czym zdecydował.

Kryteria wyjścia

• 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 lub termin poprawki zaakceptowany przez biznes.
• Każdy przypadek testowy w zakresie ma wynik.

Sign-off

• Poprosić właściciela każdego procesu o sign-off: zaakceptowane, zaakceptowane z warunkami lub odrzucone.
• Zapisać każdy warunek, wraz z tym, kto go realizuje i do kiedy.

Go/no-go

• Prowadzić spotkanie go/no-go z liczbami na ekranie, a nie z pamięci.
• Zapisać decyzję, warunki i to, kto ją podjął.

Raport

• Określić, co było w zakresie i czego nie przetestowano.
• Pokazać wyniki według grup i priorytetów oraz przetestowane wydanie i build.
• Wymienić otwarte zgłoszenia według wagi, z decyzją dla każdego z nich.
• Dodać sign-offy wraz z ich warunkami.
• Wskazać znane ryzyka i obejścia na pierwsze tygodnie po go-live.

Po go-live

• Zachować przypadki testowe: to test regresji na następne wydanie CRM.
• Zapisać, co zrobić inaczej w następnym UAT, póki wszystko jest świeże.