Testowanie automatyzacji procesów – jak bezpiecznie uruchomić workflow na produkcji?
Sprawdź, jak testować automatyzację procesów przed wdrożeniem: scenariusze, dane testowe, wyjątki, integracje i bezpieczne uruchomienie produkcyjne.
Autor: Kamil Rudnicki
Automatyczny proces może działać poprawnie podczas prostej prezentacji, a mimo to zawieść po kontakcie z rzeczywistymi danymi. Puste pola, duplikaty, niedostępne API, nietypowy format daty czy ponowne wysłanie tego samego formularza to sytuacje, których często nie widać w podstawowym scenariuszu.
Testowanie automatyzacji procesów powinno więc obejmować nie tylko odpowiedź na pytanie „czy workflow się uruchamia?”, lecz także sprawdzenie, jak zachowuje się w przypadku błędów, opóźnień i niepełnych danych. Dobrze przygotowane testy ograniczają ryzyko, że automatyzacja wyśle klientowi niewłaściwą wiadomość, utworzy kilka takich samych rekordów albo zatrzyma się bez powiadomienia operatora.
Co należy ustalić przed rozpoczęciem testów?
Punktem wyjścia jest opis oczekiwanego działania procesu. Jeżeli reguły biznesowe istnieją wyłącznie w głowie jednej osoby, trudno jednoznacznie ocenić wynik testu. Warto wcześniej określić:
- zdarzenie uruchamiające workflow,
- wymagane dane wejściowe,
- reguły podejmowania decyzji,
- systemy uczestniczące w procesie,
- oczekiwany rezultat każdego kroku,
- możliwe wyjątki i sposób ich obsługi,
- osobę odpowiedzialną za reakcję na błąd.
Pomocne jest wcześniejsze mapowanie procesu biznesowego, zwłaszcza gdy workflow obejmuje kilka działów lub aplikacji. Schemat procesu pozwala zamienić poszczególne ścieżki w konkretne przypadki testowe.
Trzeba też ustalić kryteria akceptacji. Przykładowo zapis „system przetwarza formularz” jest zbyt ogólny. Precyzyjniejsze kryterium może wskazywać, że poprawne zgłoszenie tworzy jeden rekord w CRM, przypisuje właściwego opiekuna, zapisuje źródło kontaktu i wysyła potwierdzenie na adres podany przez użytkownika.
Środowisko testowe czy produkcyjne?
Jeśli to możliwe, automatyzację należy najpierw uruchamiać w środowisku oddzielonym od produkcji. Może to być testowe konto aplikacji, osobna baza, kopia workflow albo tryb sandbox udostępniony przez dostawcę systemu. Takie rozwiązanie zmniejsza ryzyko przypadkowego wysłania wiadomości do klientów lub nadpisania prawdziwych rekordów.
Nie każda aplikacja oferuje pełne środowisko testowe. Wówczas można zastosować dodatkowe zabezpieczenia, takie jak:
- testowa lista odbiorców wiadomości,
- osobny pipeline lub oznaczenie rekordów w CRM,
- ograniczenie workflow do wskazanych identyfikatorów,
- wyłączenie operacji usuwania i masowej aktualizacji,
- zapis wyniku do pliku lub dziennika zamiast wykonania działania,
- ręczne zatwierdzenie przed krokiem powodującym nieodwracalną zmianę.
Dane testowe nie powinny zawierać informacji prawdziwych klientów, jeśli nie jest to konieczne. Powinny jednak odzwierciedlać strukturę danych produkcyjnych: długość pól, dostępne statusy, format numerów telefonu, kodowanie znaków oraz relacje między rekordami.
Jakie scenariusze testowe przygotować?
Scenariusz podstawowy
Najpierw sprawdza się typową, poprawną ścieżkę. Wszystkie wymagane pola są uzupełnione, systemy odpowiadają, a rekord nie istnieje jeszcze w bazie. Taki test potwierdza, że główna logika procesu została połączona zgodnie z założeniami.
Nie należy jednak na nim kończyć. Rzeczywiste problemy najczęściej pojawiają się poza ścieżką podstawową.
Dane niepełne lub niepoprawne
Warto przetestować brak adresu e-mail, błędny numer telefonu, pusty załącznik, nieznany status czy tekst wpisany w polu liczbowym. Dla każdego przypadku trzeba ustalić, czy proces ma odrzucić dane, uzupełnić wartość domyślną, poprosić o korektę czy przekazać sprawę człowiekowi.
Jeżeli źródłowe bazy zawierają niespójności, przed wdrożeniem przydatne może być porządkowanie danych w firmie. Automatyzacja nie powinna bez kontroli powielać błędów występujących w systemie źródłowym.
Duplikaty i ponowne uruchomienie
Ten sam webhook może zostać dostarczony więcej niż raz, użytkownik może ponownie wysłać formularz, a operator może ręcznie wznowić nieudane wykonanie. Test powinien pokazać, czy workflow w takiej sytuacji utworzy kolejny rekord albo ponownie wyśle wiadomość.
Proces odporny na powtórzenia rozpoznaje wcześniej obsłużone zdarzenie, na przykład na podstawie identyfikatora zamówienia, zgłoszenia lub transakcji. Nie zawsze oznacza to całkowite pominięcie operacji. Czasem właściwym zachowaniem jest aktualizacja istniejącego rekordu zamiast tworzenia nowego.
Niedostępność systemu zewnętrznego
Integracja może otrzymać błąd API, przekroczyć limit zapytań lub nie dostać odpowiedzi w wyznaczonym czasie. Należy sprawdzić, czy workflow:
- zapisuje informacje potrzebne do diagnozy,
- nie traci danych wejściowych,
- ponawia operację tylko wtedy, gdy jest to bezpieczne,
- po określonych niepowodzeniach powiadamia odpowiednią osobę,
- pozwala wznowić proces bez wykonywania wcześniejszych kroków drugi raz.
Sposób wymiany danych i ograniczenia poszczególnych mechanizmów szerzej opisuje artykuł o integracji systemów przez API i webhooki.
Graniczne wartości i nietypowa kolejność zdarzeń
Do testów warto dodać bardzo długi tekst, plik o niedozwolonym formacie, datę na przełomie miesiąca, brak wyników oraz dużą liczbę pozycji w jednym zamówieniu. Istotna może być także kolejność: anulowanie zamówienia może dotrzeć przed potwierdzeniem płatności, jeśli różne systemy przetwarzają zdarzenia z innym opóźnieniem.
Jak dokumentować wyniki testów?
Lista przypadków testowych nie musi być rozbudowanym dokumentem. Powinna jednak umożliwiać odtworzenie próby i jednoznaczną ocenę wyniku. Dla każdego scenariusza warto zapisać:
- nazwę i cel testu,
- dane wejściowe,
- warunki początkowe,
- oczekiwany rezultat,
- rezultat faktyczny,
- identyfikator wykonania lub wpisu w logach,
- status testu i opis wykrytego problemu.
Po poprawieniu błędu należy powtórzyć nie tylko scenariusz, który go ujawnił. Zmiana warunku w jednym miejscu może wpłynąć na inne ścieżki, dlatego potrzebne są również testy regresji, czyli ponowne sprawdzenie wcześniej działających funkcji.
Bezpieczne uruchomienie automatyzacji na produkcji
Po zakończeniu testów technicznych warto przeprowadzić odbiór z udziałem osoby znającej proces biznesowy. To ona może zauważyć, że poprawna technicznie aktualizacja statusu nie odpowiada faktycznym zasadom pracy działu.
Start produkcyjny nie musi od razu obejmować całej organizacji. Bezpieczniejszym rozwiązaniem bywa stopniowe uruchomienie dla jednego zespołu, typu sprawy, źródła danych lub niewielkiej grupy rekordów. W pierwszym okresie można pozostawić ręczną kontrolę wyniku przed wykonaniem wrażliwej operacji.
Należy również przygotować plan wycofania zmiany. Powinien określać, jak zatrzymać workflow, które operacje można odwrócić, gdzie znajdują się dane oczekujące i jak obsłużyć zadania ręcznie podczas przerwy. Samo wyłączenie automatyzacji nie naprawi rekordów, które zostały już błędnie zmienione.
Testy nie zastępują późniejszego nadzoru
Nawet szeroki zestaw scenariuszy nie przewidzi każdej zmiany po stronie zewnętrznego systemu, danych lub procesu biznesowego. Po wdrożeniu potrzebny jest monitoring automatyzacji, obejmujący alerty, historię wykonań i kontrolę rezultatów.
Testy warto powtarzać po zmianie API, formularza, struktury danych, reguł przypisywania lub konfiguracji kont. Dzięki temu automatyzacja pozostaje zgodna z procesem, który z czasem może wyglądać inaczej niż w dniu pierwszego uruchomienia.
Dobrze przetestowany workflow nie jest po prostu procesem, który wykonał się raz bez błędu. To rozwiązanie ze sprawdzoną ścieżką podstawową, obsługą wyjątków, ochroną przed duplikatami oraz przygotowanym sposobem reakcji na awarię.