Testowanie automatyzacji: checklista przed startem i po zmianach
Scenariusz przeszedł test na jednym zamówieniu, więc poszedł na produkcję. Tydzień później okazało się, że klienci bez numeru telefonu nie dostają faktur, a firmy z NIP-em dostają paragon. Jeden test sprawdził tylko jeden przypadek. Pokazuję, kiedy testować automatyzacje, jakie pięć przypadków sprawdzić, jak przygotować dane testowe w Make, BaseLinkerze, ManyChat, MailerLite i Setmore, jak testować faktury bez wysyłki do KSeF i jak zapisać wynik, żeby za pół roku wiedzieć, co było sprawdzone.
Autor: Mateusz Matuszczak · Aktualizacja:
Jak przetestować automatyzację przed startem?
Zapisz oczekiwany wynik, przygotuj dane testowe oznaczone „TEST” z własnym e-mailem, przejdź pięć przypadków (typowy, nietypowe dane, odrzucony przez filtr, wymuszony błąd, duplikat), sprawdź efekt w docelowym narzędziu, posprzątaj dane testowe i zapisz wynik w rejestrze automatyzacji.
🧪 Zobacz przypadki →Czym jest testowanie automatyzacji?
Test to nie formalność przed startem, tylko jedyny sposób, żeby wiedzieć, a nie zakładać, że proces działa. Jak wpisuje się w cały projekt: wdrożenie automatyzacji krok po kroku.
Testowanie automatyzacji to sprawdzenie na danych testowych, czy scenariusz daje oczekiwany wynik w docelowym narzędziu, i to nie tylko w typowym przypadku, ale też przy nietypowych danych, przypadkach odrzucanych przez filtr, błędzie i duplikacie. Test powtarza się po każdej zmianie w scenariuszu lub w podłączonych narzędziach.
Kiedy testować automatyzację?
Nie tylko przed startem. Większość awarii pojawia się po zmianach, często w zupełnie innym narzędziu.
W skrócie: testuj przed startem, po każdej zmianie w scenariuszu, po zmianie pól, statusów lub szablonów w podłączonych narzędziach, po ponownym połączeniu konta lub zmianie planu oraz okresowo: procesy krytyczne raz w miesiącu, pozostałe raz na kwartał.
| Moment | Przykład | Zakres testu |
|---|---|---|
| Przed startem | Nowy scenariusz faktur po wizycie | Pełny: wszystkie 5 przypadków |
| Zmiana w scenariuszu | Nowy filtr, dodatkowy moduł, zmiana mapowania | Przypadek typowy + przypadek, którego dotyczy zmiana |
| Zmiana w podłączonym narzędziu | Nowy status w BaseLinkerze, nowe pole w formularzu, nowa usługa w Setmore | Przypadek typowy dla każdej automatyzacji, która korzysta z tego pola lub statusu |
| Ponowne połączenie konta, zmiana planu | Nowy token Meta, powrót na ManyChat Pro, nowa karta płatnicza | Przypadek typowy na końcu łańcucha |
| Okresowo | Przegląd miesięczny lub kwartalny | Krytyczne: co miesiąc; pozostałe: co kwartał |
| Przed szczytem sprzedaży | Black Friday, święta, Dzień Kobiet | Pełny dla procesów zamówień, faktur i powiadomień |
Najczęstsza przyczyna awarii „bez powodu” to zmiana wprowadzona przez kogoś z zespołu w polu lub statusie, z którego korzysta scenariusz. Dlatego zasada „najpierw zgłoś, potem zmień” idzie w parze z testem po zmianie. Więcej: BaseLinker a praca zespołu.
Jakie przypadki testowe sprawdzić? 5 obowiązkowych
Jeden test na „ładnych” danych sprawdza tylko jeden z pięciu scenariuszy, które spotkasz w praktyce.
W skrócie: każdy scenariusz testuj na pięciu przypadkach: typowym, z nietypowymi danymi, takim, który filtr ma odrzucić, z wymuszonym błędem oraz z tym samym zdarzeniem dwa razy. Ostatnie dwa wykrywają awarie, które w codziennej pracy pojawiają się najrzadziej, ale kosztują najwięcej.
| Przypadek | Przykład danych | Co sprawdzasz |
|---|---|---|
| 1. Typowy | Opłacone zamówienie klienta prywatnego z kompletem danych | Czy cały łańcuch daje oczekiwany wynik |
| 2. Nietypowe dane | Brak telefonu, nazwisko z „ł” i „ż”, bardzo długi adres, NIP firmy, kod pocztowy bez myślnika | Czy scenariusz nie przerywa się i nie zniekształca danych; pomaga walidacja adresu i telefonu |
| 3. Odrzucony przez filtr | Zamówienie nieopłacone, klient bez zgody marketingowej, voucher zamiast produktu | Czy nic się nie dzieje, gdy nic nie powinno |
| 4. Wymuszony błąd | Niepoprawny NIP, nieistniejący e-mail, odłączone konto | Czy przychodzi alert, czy wykonanie da się ponowić i czy scenariusz pozostaje włączony (obsługa błędów w Make) |
| 5. Duplikat | To samo zamówienie lub zdarzenie wysłane dwa razy, ponowienie wykonania | Czy nie powstaje druga faktura, druga wiadomość, drugi kontakt |
Przy scenariuszach z rozgałęzieniami (np. osobna ścieżka dla firm i osób prywatnych) przypadek typowy przejdź osobno dla każdej ścieżki.
Jak przetestować automatyzację? 6 kroków
Ta sama procedura sprawdza się w Make, BaseLinkerze, ManyChat i MailerLite.
W skrócie: 1) zapisz oczekiwany wynik, 2) przygotuj dane testowe oznaczone „TEST”, 3) przejdź pięć przypadków, 4) sprawdź efekt na końcu łańcucha, 5) posprzątaj dane testowe, 6) zapisz wynik w rejestrze.
-
1
Zapisz oczekiwany wynik
Dla każdego przypadku jedno zdanie: „Klient dostaje e-mail z fakturą na firmę z NIP-em, zamówienie ma status Wysłane”. Bez tego test kończy się na „chyba działa”.→ Oczekiwane wyniki trafiają do karty testu. -
2
Przygotuj dane testowe
Testowe zamówienia, wizyty i kontakty oznacz słowem „TEST” w nazwisku lub notatce i podaj własny e-mail i telefon. W scenariuszu możesz dodać filtr, który dla danych testowych pomija wysyłkę do klientów lub do KSeF.→ Jak przygotować dane w konkretnych narzędziach: dane testowe w narzędziach. -
3
Przejdź pięć przypadków
Typowy, nietypowe dane, odrzucony przez filtr, wymuszony błąd, duplikat. W Make każdy przypadek uruchamiasz przez Run once, w BaseLinkerze tworząc ręcznie zamówienie testowe, w ManyChat przechodząc ścieżkę z konta testowego.→ Szczegóły w tabeli przypadków. -
4
Sprawdź efekt na końcu łańcucha
Otwórz skrzynkę, program do faktur, listę w MailerLite, kalendarz. Sprawdź treść, a nie tylko istnienie: kwotę, dane nabywcy, grupę, tagi, polskie znaki, link w wiadomości.→ Zielony znacznik w Make to dopiero połowa testu. -
5
Posprzątaj dane testowe
Usuń testowe kontakty z MailerLite i ManyChat, przenieś testowe zamówienia do osobnego statusu, odwołaj testowe wizyty. Inaczej zafałszują raporty i statystyki, a testowy adres dostanie kampanię.→ Dane testowe z prawdziwymi danymi osobowymi też podlegają RODO: RODO w automatyzacjach. -
6
Zapisz wynik w rejestrze
Data, zakres testu (pełny czy po zmianie), wynik i kto testował. Wpis trafia do kolumny „Ostatni test” w rejestrze automatyzacji.→ Za pół roku będziesz wiedzieć, co było sprawdzone, a nie zgadywać.
Jak przygotować dane testowe w Make, BaseLinkerze, ManyChat, MailerLite i Setmore?
Każde narzędzie wymaga trochę innego podejścia, żeby test nie dotknął prawdziwych klientów.
Make
BaseLinker
ManyChat i MailerLite
Setmore
* Linki partnerskie — jeśli założysz konto przez te linki, mogę otrzymać wynagrodzenie, a Twoje warunki się nie zmieniają. Polecam tylko narzędzia, które sam wdrażam i utrzymuję u klientów: narzędzia, które polecam.
Jak testować automatyczne faktury bez wysyłki do KSeF?
Faktura wystawiona w teście to prawdziwy dokument. Jeśli trafi do KSeF, trzeba ją skorygować.
W skrócie: najpierw sprawdź, czy Twój program do faktur ma tryb testowy lub dostęp do środowiska testowego KSeF. Jeśli nie, testuj scenariusz etapami: najpierw z danymi zapisywanymi do arkusza zamiast do programu, potem jedna kontrolowana faktura na Twoje dane i dopiero wtedy włączenie dla klientów.
sucho
Bez programu do faktur
tryb testowy
Środowisko testowe
kontrolnie
Jedna prawdziwa faktura
start
Włączenie dla klientów
Przykłady scenariuszy faktur, które warto testować w ten sposób: faktura po wizycie Setmore + inFakt i BaseLinker + inFakt. Czy i jak inFakt* lub inny program pozwala wystawiać dokumenty testowe, sprawdź w jego pomocy przed testem.
Karta testu automatyzacji: przykład do skopiowania
Przykład dla scenariusza „Faktura po opłaconej wizycie: Setmore → Make → inFakt”.
W skrócie: karta testu to tabela z pięcioma kolumnami: przypadek, dane wejściowe, oczekiwany wynik, faktyczny wynik i status. Wypełniona karta jest dowodem, że test się odbył, i podstawą do retestu po zmianach.
| Przypadek | Dane wejściowe | Oczekiwany wynik | Faktyczny wynik | Status |
|---|---|---|---|---|
| 1. Typowy | Wizyta opłacona, klient prywatny, komplet danych | Faktura na osobę prywatną, e-mail z PDF do klienta | … | OK / błąd |
| 2a. Firma | Wizyta opłacona, podany NIP i nazwa firmy | Faktura na firmę z NIP-em | … | OK / błąd |
| 2b. Nietypowe dane | Nazwisko z polskimi znakami, brak telefonu | Faktura z poprawnymi znakami, brak błędu przez pusty telefon | … | OK / błąd |
| 3. Odrzucony | Wizyta zarezerwowana, nieopłacona | Brak faktury, brak e-maila | … | OK / błąd |
| 4. Błąd | Niepoprawny NIP | Alert do właściciela procesu, wykonanie w niedokończonych, scenariusz włączony | … | OK / błąd |
| 5. Duplikat | Ponowienie wykonania tej samej wizyty | Brak drugiej faktury | … | OK / błąd |
Nad tabelą wpisz datę, nazwę scenariusza, zakres testu (pełny lub po zmianie) i osobę testującą. Kartę trzymaj obok rejestru automatyzacji, np. jako osobną zakładkę tego samego arkusza. Dobrze pasuje też do systemu kontroli jakości.
Testowanie automatyzacji: co działa, a co nie?
Najczęstsze skróty, które później kosztują najwięcej.
Konsultacja: testy i przegląd automatyzacji
Przetestuję Twoje automatyzacje na pięciu przypadkach, zapiszę wyniki i wskażę, co poprawić. Zobacz też jak pomagam w automatyzacji i systemach.
Najczęstsze pytania o testowanie automatyzacji
Jak przetestować automatyzację, żeby nie wysłać nic do klienta?
Jak testować automatyczne faktury bez wysyłania do KSeF?
Kiedy trzeba ponownie testować automatyzację?
Jakie przypadki testowe sprawdzić?
Czy zielony wynik w Make oznacza, że automatyzacja działa?
Gdzie zapisywać wyniki testów automatyzacji?
Jak testować automatyzacje w ManyChat?
Budowa → test → utrzymanie
Automatyzacja działa wtedy, gdy ktoś to sprawdził.
Harmonogram testów, pięć przypadków testowych, procedura w 6 krokach, dane testowe w pięciu narzędziach, faktury bez KSeF i karta testu do skopiowania. Chcesz, żebym przetestował Twoje automatyzacje? Umów konsultację.
Zakres testów zależy od liczby i ważności automatyzacji.