Automatyzacja słabo zdefiniowanego procesu biznesowego zwykle przenosi jego niejednoznaczności do oprogramowania. Test akceptacyjny pozwala sprawdzić wspólnie z osobami odpowiedzialnymi za proces, czy proponowane działanie odzwierciedla zasady operacyjne, zanim zacznie się na nim polegać w środowisku produkcyjnym. Nie zastępuje projektowania wymagań ani testów technicznych: łączy uzgodnione zasady z obserwowalnymi wynikami.
Co weryfikuje test akceptacyjny procesu biznesowego
Test akceptacyjny sprawdza, czy rozwiązanie lub proces przynosi wynik potrzebny firmie w konkretnej sytuacji. Na przykład, czy zgłoszenie spełniające określone kryteria przechodzi do właściwego stanu, tworzy wymagany rekord i pozostawia zadanie przypisane osobie, która powinna podjąć działanie.
Różni się od innych, pokrewnych działań:
- Nieformalny przegląd procesu: rozmowa lub przejście przez proces może ujawnić problemy, ale nie zawsze określa warunki i wyniki, które da się zweryfikować.
- Test techniczny: sprawdza takie aspekty jak odpowiedź API, funkcja, integracja lub obsługa błędów. Może zakończyć się powodzeniem, nawet jeśli zaimplementowana reguła biznesowa jest nieprawidłowa.
- Test akceptacyjny: weryfikuje działanie z perspektywy uzgodnionych zasad operacyjnych, przy użyciu scenariuszy i kryteriów, które mogą ocenić osoby odpowiedzialne.
Celem nie jest ponowne opisanie każdego wymagania innymi słowami ani zdefiniowanie całej strategii testowania kodu. Chodzi o uzgodnienie zestawu możliwych do opanowania sytuacji, który pozwoli odpowiedzieć na pytanie: czy użytkownicy uznaliby takie działanie za prawidłowe w tym procesie?
Wybór scenariuszy odzwierciedlających rzeczywistą pracę
Zacznij od rozrysowania głównej ścieżki: co uruchamia proces, jakie decyzje są podejmowane, kto bierze w nim udział i jak się kończy. Następnie wskaż wyjątki, które mogą zmienić decyzję lub wymagać interwencji. Nie trzeba wymieniać wszystkich możliwych kombinacji; warto jednak uwzględnić warianty wpływające na wynik, ryzyko lub obciążenie operacyjne.
Przydatny zestaw początkowy zwykle obejmuje:
- Typową ścieżkę: prawidłowe dane wejściowe, które zgodnie z najczęściej stosowanymi regułami prowadzą do zakończenia procesu.
- Istotny wyjątek: brakujące informacje, niespełnione kryterium lub konieczność weryfikacji, które zmieniają ścieżkę.
- Granicę decyzji: wartość dokładnie na progu oraz, jeśli to przydatne, po jednej wartości bezpośrednio poniżej i powyżej. Pozwala to ustalić, czy warunek obejmuje wartość graniczną, i zapobiega rozbieżnym interpretacjom.
- Ponowną próbę lub duplikat: powtórzone dane wejściowe, ponownie wykonywane działanie lub opóźnioną odpowiedź — jeśli proces może napotkać takie sytuacje.
- Interwencję człowieka: przypadek, który należy zatrzymać, eskalować lub przypisać konkretnej osobie zamiast rozwiązywać automatycznie.
Ustal priorytety scenariuszy na podstawie konsekwencji błędu, częstotliwości operacyjnej i trudności wykrycia usterki. Jeśli dwa przypadki sprawdzają tę samą regułę i dają ten sam wynik, prawdopodobnie wystarczy jeden. Jeśli wyjątek zmienia osobę podejmującą decyzję lub rodzaj przyjmowanego zobowiązania, należy rozpatrzyć go osobno.
Przygotowanie powtarzalnych danych wejściowych i stanu początkowego
Każdy scenariusz powinien opisywać, jakie informacje są dostępne przed rozpoczęciem testu. Uwzględnij pola wpływające na reguły, wcześniejszy stan sprawy oraz, w razie potrzeby, uprawnienia lub oczekujące zadania. Polecenie „przetestuj niekompletne zgłoszenie” jest niewystarczające, jeśli nie określa, jakiej informacji brakuje i jakie pozostałe dane są dostępne.
Gdy pozwalają ocenić działanie, używaj danych syntetycznych lub zanonimizowanych. Nie kopiuj prawdziwych danych osobowych dla wygody: oprócz ograniczenia ujawnienia danych, kontrolowane dane ułatwiają ponowne przeprowadzenie przypadku bez uzależnienia od zmian w rekordach operacyjnych. Jeśli bierze udział zewnętrzna integracja, opisz oczekiwaną odpowiedź oraz sposób jej symulowania lub kontrolowania podczas weryfikacji.
Zapisz także warunki wstępne, na przykład czy przypadek dotyczy nowej sprawy, czy sprawy już zweryfikowanej. Bez wspólnego stanu początkowego rozbieżność może wynikać z poprzedniego testu, pozostałych danych albo sprawdzanej reguły.
Określanie obserwowalnych wyników zamiast intencji
Dla każdego scenariusza opisz oczekiwany wynik za pomocą sygnałów, które można sprawdzić. Stwierdzenia „proces działa prawidłowo” nie da się zweryfikować. Zamiast tego wskaż, co się zmienia, a co powinno pozostać bez zmian.
- Stan: stan końcowy sprawy oraz przejścia, które powinny lub nie powinny nastąpić.
- Dane: tworzone lub aktualizowane rekordy, pola lub identyfikatory, a także istotne wartości.
- Komunikacja: wysyłane powiadomienia, ich odbiorcy i warunki wysłania.
- Oczekujące zadania: zadanie, osoba odpowiedzialna, termin lub odnotowany powód eskalacji.
- Zakazane działania: na przykład nie zamykać sprawy wymagającej weryfikacji ani nie tworzyć duplikatu rekordu przy ponownej próbie.
Warto oddzielić obserwowalny wynik od wewnętrznej decyzji implementacyjnej. Akceptacja nie powinna zależeć od tego, czy system korzysta z kolejki, tabeli czy konkretnej usługi, chyba że taki wybór jest częścią uzgodnionego ograniczenia. Dzięki temu kryterium pozostaje aktualne także po zmianie architektury.
Rozwiązywanie rozbieżności bez ukrywania nieuzgodnionych zasad
Gdy zaobserwowany wynik nie odpowiada oczekiwanemu, zapisz przypadek, dane wejściowe, stan początkowy, rzeczywiste działanie i oczekiwany wynik. Dodaj informację, kto potwierdził regułę i jaka decyzja pozostaje do podjęcia. Rozbieżność nie zawsze oznacza usterkę techniczną: może ujawnić niejednoznaczność reguły, niekompletne kryterium akceptacji albo niezgodność systemu z uzgodnieniami.
Przed podjęciem decyzji o poprawce sklasyfikuj problem:
- Niejednoznaczna lub sprzeczna reguła: wstrzymaj akceptację danego przypadku, dopóki osoba odpowiedzialna nie określi prawidłowego działania.
- Działanie niezgodne z uzgodnioną regułą: zarejestruj defekt, jego wpływ i warunki ponownego testu.
- Nieaktualny oczekiwany wynik: zweryfikuj i zatwierdź zmianę; nie modyfikuj kryterium wyłącznie po to, by test zakończył się powodzeniem.
- Problem z danymi lub środowiskiem: popraw przygotowanie i powtórz test, zachowując dowody wyjaśniające, dlaczego poprzednia próba nie była rozstrzygająca.
Przypisz rozbieżnościom osoby odpowiedzialne i statusy. Lista uwag bez decyzji i dalszych działań staje się źródłem nieporozumień, a nie dowodem akceptacji.
Ponowne wykonywanie scenariuszy po zmianach i decyzja o automatyzacji
Zaakceptowane scenariusze można ponownie wykorzystywać po zmianach reguł, formularzy, integracji lub kroków operacyjnych. Powtórz przypadki, których zmiany dotyczą, oraz główne ścieżki, na które mogły wpłynąć skutki uboczne. Zautomatyzowane testy oprogramowania mogą szybko wykonywać kontrole techniczne; weryfikacja biznesowa nadal wymaga potwierdzenia, że wyniki mają sens z punktu widzenia operacji, szczególnie gdy zmieniają się zasady lub zakresy odpowiedzialności.
Przed automatyzacją sprawdź, czy każdy scenariusz ma powtarzalne dane wejściowe, weryfikowalny wynik i osobę uprawnioną do rozstrzygania wątpliwości. Jeśli w zależności od zespołu, kanału lub rodzaju sprawy obowiązują różne reguły, należy jasno określić te granice. Przechowuj wersje lub odnośniki do aktualnych zasad, aby było wiadomo, jakie działanie zaakceptowano i kiedy.
Lista kontrolna przed automatyzacją
- Czy określono początek i koniec procesu oraz osoby odpowiedzialne za każdą decyzję?
- Czy uwzględniono typową ścieżkę, istotne wyjątki i granice stosowania reguł?
- Czy każdy przypadek określa dane wejściowe, stan początkowy i bezpieczne dane umożliwiające jego powtórzenie?
- Czy oczekiwane wyniki opisano jako obserwowalne zmiany stanu, danych, powiadomień lub zadań?
- Czy wiadomo, jak postąpić w razie rozbieżności i kto może zatwierdzić regułę?
- Czy odróżnia się defekt implementacji od nieuzgodnionej reguły lub problemu z przygotowaniem?
- Czy określono kryteria ponownej weryfikacji po zmianie procesu?
Jeśli na kilka pytań odpowiedź brzmi „nie”, proces wymaga doprecyzowania przed automatyzacją. Jeśli odpowiedź brzmi „tak”, testy akceptacyjne procesów biznesowych stanowią wspólną podstawę weryfikacji działania bez mylenia akceptacji operacyjnej z pokryciem testami technicznymi. Efektem jest możliwe do sprawdzenia uzgodnienie tego, co powinno się wydarzyć, także wtedy, gdy przypadek odbiega od typowej ścieżki.
