Przypadki testowe zrozumiałe dla testerów biznesowych

Dlaczego testerzy biznesowi potrzebują innych przypadków testowych

Test systemowy wykonują osoby, które zbudowały system lub dobrze go znają. Test akceptacyjny użytkownika wykonują osoby, które z niego korzystają: znają pracę, a nie konfigurację. Nie wiedzą, które pole jest nowe, który przepływ działa w tle ani co miał na myśli programista.

Dlatego przypadek testowy UAT musi działać dla kogoś, kto:

• zna proces biznesowy na pamięć, ale nie zna nowych ekranów;
• ma kilka godzin między innymi zadaniami, a nie tydzień;
• nigdy nie powinien zgadywać, czy krok się powiódł, czy nie;
• przy niejasnym kroku zatrzyma się i będzie czekać, tracąc czas.

Każda godzina poświęcona na jasne przypadki testowe oszczędza wiele godzin w dniach testowych: mniej pytań, mniej zgłoszeń, które okazują się nieporozumieniami, i wyniki, którym można zaufać na go/no-go.

Z user stories i procesów

Przypadki testowe mają dwa źródła i potrzebne są oba.

User stories i ich kryteria akceptacji

User story mówi, co ktoś chce zrobić i dlaczego: Jako handlowiec chcę przekonwertować zakwalifikowanego leada, aby otrzymać konto, kontakt i szansę sprzedaży. Jej kryteria akceptacji mówią, kiedy jest gotowa. Każde kryterium akceptacji to kandydat na krok lub przypadek testowy.

Należy sprawdzić pokrycie: każda user story w zakresie potrzebuje co najmniej jednego przypadku testowego. Story bez niego to luka, a luki wychodzą na jaw na produkcji.

Procesy biznesowe, od początku do końca

User stories są dzielone na małe części dla programistów. Biznes pracuje w procesach, które obejmują wiele stories: od leada do płatności, od oferty do zamówienia, obsługa spraw od e-maila do rozwiązania. Story może przejść sama w sobie, a proces i tak się psuje przy przekazaniu między dwoma zespołami.

Dlatego warto dodać przypadki testowe end-to-end, które prowadzą proces od początku do końca, przez różne role: handlowiec przygotowuje ofertę, kierownik ją zatwierdza, zamówienie trafia do działu finansów. Często to właśnie te przypadki testowe są dla biznesu najważniejsze.

W UAT StudioUser stories można wczytać z Jira lub Azure DevOps na karcie User stories, a zaznaczenie Only stories without test cases pokazuje luki. Z modułem AI test design AI proponuje przypadki testowe na podstawie Państwa stories lub opisu procesu, także na własnym modelu firmy. Nic nie staje się przypadkiem testowym, dopóki go Państwo nie zatwierdzą. Bez modułu Prepare with your own AI daje prompt do wklejenia w firmowe AI; kroki oznaczone [CHECK] to założenia do sprawdzenia.

Jeden cel na przypadek testowy

Przypadek testowy testuje jeden scenariusz biznesowy, z jednym celem. Jego tytuł mówi, co tester osiąga, słowami biznesu:

• Konwersja leada z istniejącym kontem
• Zatwierdzenie oferty z rabatem powyżej 20%
• Przekierowanie e-maila od znanego klienta do właściwej kolejki

Nie Test obiektu Lead ani nie Leady, szanse sprzedaży i oferty. Gdy przypadek testowy ma kilka celów, jeden błąd blokuje je wszystkie, a wynik niewiele mówi: co nie działa, a co nadal działa?

Jak duży jest jeden przypadek testowy?

Co do zasady przypadek testowy ma od trzech do piętnastu kroków i zajmuje testerowi od pięciu do dwudziestu minut. Jeśli jest znacznie dłuższy, prawdopodobnie ma więcej niż jeden cel: należy go podzielić. Jeśli jest znacznie krótszy, może pasować do sąsiedniego.

Przypadki testowe end-to-end są wyjątkiem. Obejmują cały proces i mogą być dłuższe. Warto je zachować, ale zadbać o to, by każda część procesu miała też własny, krótszy przypadek testowy, aby łatwo było ustalić, gdzie wystąpił błąd.

Kroki z oczekiwanym wynikiem

Każdy krok ma dwie części: czynność (co robi tester) i oczekiwany wynik (co powinno się stać). To oczekiwany wynik sprawia, że krok da się przetestować. Bez niego tester sam decyduje, co jest wystarczająco dobre, a dwóch testerów decyduje różnie.

Zapisanie czynności

• Jedna czynność na krok. Otwórz leada i kliknij Convert jest w porządku; pięć kliknięć w jednym kroku już nie.
• Zaczynać od czasownika: otwórz, kliknij, wypełnij, wybierz, zapisz.
• Używać etykiet tak, jak są na ekranie, pogrubionych lub w cudzysłowie.
• Pisać, co zrobić, a nie jak system działa w środku. Zapisz ofertę, a nie uruchom przepływ zatwierdzania.

Zapisanie oczekiwanego wyniku

• Opisać, co widzi tester: komunikat, wartość w polu, nowy rekord, status.
• Pisać konkretnie. Szansa sprzedaży jest na etapie Qualification, a nie działa.
• Wskazać, co nie powinno się stać, gdy to ważne: Nie powstaje drugie konto.
• Przy działaniach, które system wykonuje sam, wskazać, gdzie patrzeć: Sprawa pojawia się w kolejce Benelux Support w ciągu minuty.

Dane testowe i role

Dane testowe

Testerzy tracą więcej czasu na szukanie danych niż na jakąkolwiek inną część UAT. Dane należy umieścić w przypadku testowym wszędzie, gdzie mają znaczenie: który klient, który produkt, który cennik lub price book, jaka kwota. Te dane trzeba przygotować w środowisku testowym przed pierwszym dniem testowym.

• Używać nazw, które wyraźnie wskazują na dane testowe, np. Jansen Logistics (test).
• Dać każdemu testerowi własne rekordy, gdy zmienia dane, aby dwie osoby nie edytowały tej samej szansy sprzedaży.
• Dodać wartości graniczne: rabat tuż poniżej i tuż powyżej limitu, puste pole obowiązkowe.
• Nie używać prawdziwych danych osobowych klientów, jeśli można tego uniknąć.

Role

W CRM to, co użytkownik widzi i może zrobić, zależy od jego roli: profilu i zestawów uprawnień w Salesforce, ról zabezpieczeń i jednostki biznesowej w Dynamics 365. UAT dowodzi, że każda rola może wykonywać swoją pracę i tylko swoją pracę. Dlatego każdy przypadek testowy mówi, która rola go testuje, a tester loguje się użytkownikiem testowym, który ma dokładnie tę rolę.

Nigdy nie testować jako administrator. Administrator widzi wszystko i może wszystko, więc problemy, które UAT powinien wykryć, pozostają ukryte.

W UAT StudioKażdy krok ma czynność, oczekiwany wynik i opcjonalnie dane testowe. Każdy tester dostaje Test role i Test account, widoczne nad jego testami jako Log in as …, a rola jest pokazywana obok jego nazwiska przy każdym zgłoszeniu, które rejestruje.

Priorytet i ryzyko

Nigdy nie ma czasu, by przetestować wszystko równie dobrze. Każdy przypadek testowy należy oznaczyć tak, aby najważniejsze były testowane jako pierwsze i kończone nawet wtedy, gdy brakuje czasu.

Obok należy dodać ryzyko: ile kosztuje błąd w tym miejscu po go-live. Błędna cena na fakturze to wysokie ryzyko; błędna etykieta w raporcie to niskie. W ramach tego samego priorytetu testerzy zaczynają od wysokiego ryzyka.

Należy być rygorystycznym z Must. Gdy połowa przypadków testowych to Must, etykieta nic nie znaczy: trzeba ją zachować dla tego, bez czego biznes się nie obejdzie. Priorytety należy uzgodnić z właścicielami procesów: oni decydują też na go/no-go, gdzie najbardziej liczą się przypadki testowe Must, które nie przeszły.

W UAT StudioPriority (Must, Should, Could) i Risk (High, Medium, Low) ustawia się w edytorze lub w kolumnie przy imporcie. Odczytywane są też wartości z innych narzędzi: Critical i High stają się Must, Medium i Normal Should, Low Could. Testerzy widzą swoje przypadki testowe Must jako pierwsze, a w ramach każdego priorytetu najpierw te z wysokim ryzykiem.

Przykład

Przypadek testowy 12: Zatwierdzenie oferty z rabatem powyżej 20%

Priorytet Must, ryzyko High. User story CRM-118. Rola: handlowiec (kroki 1–3) i kierownik sprzedaży (kroki 4 i 5).

Warto zwrócić uwagę, co sprawia, że to działa: jeden cel w tytule, jedna czynność na krok, oczekiwany wynik, który tester może sprawdzić, wskazane dane i rola oraz ścieżka negatywna w kroku 3. Warto dodać drugi przypadek testowy dla rabatu poniżej limitu, który nie powinien wymagać zatwierdzenia.

Najczęstsze błędy

• Brak oczekiwanego wyniku albo działa zgodnie z oczekiwaniami. Tester musi zgadywać, czego oczekiwano.
• Język techniczny. Nazwy pól z bazy danych, nazwy obiektów albo sprawdź, czy trigger się uruchamia. Należy używać słów z ekranu.
• Zbyt wiele celów w jednym przypadku testowym. Jeden błąd blokuje resztę, a wynik niewiele mówi.
• Tylko ścieżka pozytywna. Warto dodać puste pole obowiązkowe, wartość powyżej limitu, użytkownika, który nie powinien widzieć rekordu.
• Brak danych testowych. Otwórz szansę sprzedaży: którą? Na jakim etapie, z jakimi produktami?
• Brak roli. Tester korzysta z konta, które akurat ma, często z nadmiernymi uprawnieniami.
• Skopiowane z testu systemowego. Napisane dla programistów, z krokami, których testerzy biznesowi nie są w stanie wykonać.
• Wszystko jest Must. Wtedy nic nie jest, a ważne testy nie są wykonywane jako pierwsze.
• Napisane raz, nigdy nie przeczytane. Scenariusze, których nikt nie sprawdził przed dniami testowymi, są pełne starych etykiet i błędnych menu.

Poprosić kluczowego użytkownika o przegląd

Przed dniami testowymi warto poprosić kluczowego użytkownika z biznesu, by przeczytał przypadki testowe i wypróbował dwa lub trzy z nich w środowisku testowym. Znajdzie to, czego autor nie widzi: krok, który zakłada wiedzę, etykietę, która się zmieniła, proces, który w innym kraju przebiega inaczej.

Jednocześnie należy sprawdzić, czy każda user story w zakresie ma przypadek testowy, czy każda rola w zakresie coś testuje i czy dane testowe istnieją. Po go-live przypadki testowe warto zachować: to Państwa test regresyjny na kolejne wydanie CRM.

W UAT StudioPrzypadki testowe można zaimportować z Excela, Azure DevOps, Jira z Xray lub Zephyr Scale albo z TestRail lub napisać je w edytorze. Biblioteka szablonów, dodatek do każdego płatnego planu, zawiera gotowe scenariusze dla Salesforce i Dynamics 365 do dostosowania do własnej konfiguracji.

Do bezpłatnego użytku

Wszystko inne, co trzeba załatwić przed UAT, w trakcie i po, opisuje checklista UAT na go-live CRM, także jako bezpłatny plik Excel.