W skrócie
Testy trwają 3-5 dni i sprawdzają Studio RMA.net po konfiguracji i integracji z ERP, zanim firma zarejestruje pierwszą prawdziwą reklamację. Testerzy z działów prowadzą przez program sprawy z ostatnich miesięcy, których wynik firma zna, od formularza klienta do zamknięcia. Sprawdzamy kierowanie do działu, terminy, wiadomości do klienta i wydruki, a uwagi zbieramy w jednym miejscu. Właściciel procesu rozstrzyga, co jest błędem konfiguracji, a co zmianą zasad z analizy, i na koniec podejmuje decyzję o dniu uruchomienia.
Testy w harmonogramie wdrożenia
Testy zaczynają się po konfiguracji programu i integracji z ERP, a kończą decyzją o dniu uruchomienia. W standardowym harmonogramie trwają 3-5 dni, a po nich przez 2-3 dni szkolimy pracowników. Program ma już wtedy docelowe statusy i role, a kartoteki pochodzą z ERP firmy. Testujemy więc to, na czym dział będzie pracować od pierwszego dnia, a nie standardową konfigurację z demo. Miejsce testów wśród pozostałych etapów opisujemy przy etapach wdrożenia systemu reklamacyjnego.
Test ma sens tylko wtedy, gdy przed jego rozpoczęciem wiadomo, co jest poprawnym wynikiem. Dlatego oczekiwane wyniki bierzemy z zatwierdzonego opisu ścieżki reklamacyjnej, powstałego w analizie przedwdrożeniowej systemu reklamacji. Zakres sprawdzeń zestawiamy w tabeli:
| Obszar | Co sprawdzamy | Gdzie widać wynik |
|---|---|---|
| Rejestracja | Formularz, pola obowiązkowe i numery sprawy | Lista Oczekujące RMA i karta reklamacji |
| Kierowanie | Czy sprawa trafia do właściwego działu | Listy spraw działu |
| Terminy | Termin rozpatrzenia i wartości w kolumnie Dni | Listy spraw i karta reklamacji |
| Wiadomości | SMS i e-mail przy zmianie statusu | Menu Historia, pozycje Wysłane e-mail i Wysłane SMSy |
| Wydruki | Dane na dokumentach dla klienta | Menu Wydruk i podgląd PDF |
| Uprawnienia | Listy i przyciski dostępne dla każdej roli | Logowanie kontami testerów |
| Dane z ERP | Kartoteki i powiązanie z dokumentami sprzedaży | Formularz zgłoszenia i karta reklamacji |
| Raporty | Sprawy testowe w zestawieniach | Menu Informacje, Raporty i Zestawienia |
Sprawy testowe z praktyki firmy
Sprawy do testów firma wybiera spośród reklamacji z ostatnich miesięcy, których wynik już zna. Znany wynik pozwala ocenić, czy program poprowadzi sprawę tak jak dział. Zestaw powinien obejmować różne drogi przez firmę, np. cztery rodzaje spraw:
- Typowa naprawa - najczęstsza droga, na której dział pracuje codziennie.
- Reklamacja nieuznana - sprawa z odmową, w której liczy się treść wiadomości do klienta.
- Sprawa z rzeczoznawcą - dłuższa droga ze statusem Rzeczoznawca i ryzykiem przekroczenia terminu.
- Zgłoszenie od partnera B2B - sprawa z terminem z umowy, a nie z przepisów.
Z prawdziwych spraw bierzemy przebieg i wynik, a dane osobowe reklamujących zastępujemy danymi testowymi. Do testów nie są potrzebne nazwiska ani telefony klientów, a ich kopiowanie do sprawy testowej tworzy niepotrzebny zbiór danych. Kartoteki asortymentu i kontrahentów pochodzą już z ERP firmy, więc testujemy na prawdziwych artykułach. Sprawy testowe oznaczamy tak, żeby dało się je odróżnić, np. słowem TEST w polu Uwagi.
Testerów wskazuje firma spośród osób, które będą pracować w programie po starcie. Każdy tester prowadzi sprawy swojej roli, np. pracownik przyjęć rejestruje zgłoszenia, a serwisant zapisuje usługi. Zadania firmy przed testami opisujemy przy przygotowaniu firmy do wdrożenia systemu reklamacji.
Od formularza klienta do listy pracownika
Każdą sprawę testową zaczynamy tam, gdzie zaczyna ją klient. Konsument wypełnia formularz na stronie firmy, a partner B2B zgłasza sprawę z konta w portalu. Tester sprawdza, czy formularz przyjmuje dane z prawdziwej sprawy i czy pola obowiązkowe wymuszają to, czego dział potrzebuje. W nowym interfejsie zgłoszenie z formularza trafia na listę Oczekujące RMA z numerem RMA i numerem dokumentu.
Numer RMA ma 12 znaków szesnastkowych w trzech grupach, a numer dokumentu postać rok-miesiąc-numer, np. 2026-08-0051. Tester sprawdza, czy numeracja dokumentów odpowiada ustaleniom z konfiguracji i czy po zapisie klient dostał potwierdzenie e-mailem. Budowę obu numerów opisujemy przy numeracji dokumentów i formacie numeru RMA. Program kieruje nowe zgłoszenie do właściwego działu, więc tester działu sprawdza, czy sprawa pojawiła się na jego liście.
Zgłoszenia z e-maila albo telefonu rejestruje pracownik przyciskiem Dopisz, więc tę drogę testujemy osobno. Tester sprawdza przy tym wybór asortymentu i kontrahenta z kartotek zamiast ręcznego wpisu. Dane wybrane z kartotek trafiają potem do raportów, więc błąd na tym etapie widać dopiero w zestawieniach.
Zmiany statusu i terminy w trakcie sprawy
Tester prowadzi każdą sprawę przez kolejne statusy w oknie Status. Okno ma osobne listy Status i Stan, więc tester sprawdza obie wartości po każdej zmianie. Kolejność statusów porównujemy z opisem ścieżki z analizy, a nazwy z tym, jak dział mówi o sprawach. Statusy i stany opisujemy przy statusach reklamacji w systemie RMA.
Tester sprawdza, czy termin rozpatrzenia wynika z reguły ustalonej dla typu sprawy, np. 14 dni od przyjęcia reklamacji konsumenta. W demo termin rozpatrzenia to data przyjęcia plus 14 dni, a kolumna Dni pokazuje, ile dni zostało do terminu. Jeśli firma ustaliła liczenie terminu z dniami wolnymi, tester sprawdza sprawę z terminem wypadającym w sobotę albo w święto. Zasady wyliczania terminu opisujemy przy terminie rozpatrzenia reklamacji w programie.
Na liście W realizacji tester serwisu zapisuje wykonane usługi przyciskiem Usługi. Po zamknięciu sprawy sprawdza na liście Zamknięte kolumnę Wartość usług. Lista Zamknięte nie ma na pasku przycisku Edycja, więc test pokazuje też, czy dział poprawia dane przed zamknięciem sprawy.
Wiadomości do klienta i wydruki
Przy każdej zmianie statusu tester sprawdza, czy klient dostał wiadomość wybranym kanałem i czy jej treść pasuje do sprawy. Klient B2C dostaje e-mail przy każdej zmianie statusu, więc w teście liczy się każda wiadomość, a nie tylko pierwsza i ostatnia. Do testów potrzebne są adresy e-mail i numery telefonów testerów, a nie klientów. Każdą wysłaną wiadomość tester odnajduje w menu Historia w pozycji Wysłane e-mail albo Wysłane SMSy.
Wydruki tester porównuje z dokumentami, które firma wysyła dziś klientom. Menu Wydruk w nowym interfejsie ma pozycje Oświadczenie dla klienta i Szczegóły reklamacji, a wydruk PDF zawiera m.in. kod kreskowy i sekcję Żądanie reklamującego. Na każdym wydruku sprawdzamy dwie rzeczy:
- Dane firmy - nazwa, adres, telefon i NIP, które według starszej dokumentacji pochodzą z parametrów programu.
- Dane sprawy - numer dokumentu, artykuł, dane reklamującego i żądanie zgodne z kartą reklamacji.
Wydruk z błędnymi danymi firmy trafia do klienta razem z każdą sprawą, więc poprawiamy go przed startem, a nie po pierwszej reklamacji. Treść szablonów zatwierdza dział obsługi klienta, a tester sprawdza tylko, czy do klienta trafił właściwy szablon. Wysyłanie wiadomości z programu opisujemy przy wysyłaniu e-maili z programu do reklamacji.
Uprawnienia i dane z ERP w testach
Każdy tester loguje się własnym kontem z docelową rolą, a nie kontem administratora. Tylko wtedy test pokazuje listy i przyciski, które pracownik zobaczy po starcie. Przy logowaniu przez Active Directory tester używa danych z sieci firmowej, więc test obejmuje też konta w domenie. Zakres widoczności spraw dla ról i oddziałów sprawdzamy na kontach z różnych działów. Ustawienia, które testujemy, opisujemy przy konfiguracji programu do reklamacji przy wdrożeniu.
Dane z ERP tester sprawdza na sprawach, które powstały z dokumentów sprzedaży. Przy integracji z ERP zgłoszenie jest powiązane z dokumentami sprzedaży i historią zamówień klienta, więc tester porównuje je z zapisem w ERP. Przy wymianie plikowej sprawdzamy, czy artykuły z importu mają indeks, numer katalogowy, producenta i czas gwarancji. Błąd w danych z ERP poprawia osoba znająca ERP w systemie źródłowym, żeby nie wrócił przy kolejnej wymianie.
Na koniec tester sprawdza, czy sprawy testowe pojawiły się w raportach, np. Reklamacje wg statusów i Zgłoszenia wg pracowników. Raport z pustymi kolumnami wskazuje pole, którego dział nie wypełnił w formularzu. Tester zapisuje też jeden raport do XLS, żeby sprawdzić eksport na komputerze działu.
Uwagi z testów i decyzja o starcie
Uwagi z testów zbieramy w jednym miejscu razem z numerem sprawy testowej i oczekiwanym wynikiem. Każdą uwagę ocenia właściciel procesu i przypisuje ją do jednej z dwóch grup:
- Błąd konfiguracji - program działa inaczej, niż ustaliła analiza, więc poprawiamy ustawienia w ramach testów.
- Zmiana zasad - firma chce inaczej, niż ustaliła analiza, więc zmiana wraca do etapu konfiguracji.
Po poprawkach tester powtarza tę samą sprawę od początku, a nie tylko krok, w którym wystąpił błąd. Poprawka statusu zmienia często także wiadomość do klienta albo wydruk. Testy wydłuża zmiana zasad ustalonych w analizie, bo wraca wtedy etap konfiguracji.
Tylko zmiana zasad wydłuża testy, bo cofa wdrożenie do konfiguracji.
Przed startem sprawom testowym nadajemy stan Anulowana, żeby nie mieszały się z prawdziwymi reklamacjami. W zestawieniach sprawdzamy, czy anulowane sprawy nie zawyżają wyników działu. Decyzję o dniu uruchomienia podejmuje właściciel procesu, gdy wszystkie sprawy testowe przeszły bez otwartych uwag.
Po testach przez 2-3 dni szkolimy pracowników na tym samym, sprawdzonym programie. Przebieg szkoleń opisujemy przy szkoleniu pracowników z programu do reklamacji. Sprawy przeprowadzone w testach stają się gotowym materiałem szkoleniowym, bo pokazują pracownikom ich własne sprawy w nowym programie.