Test odbiorczy podpisu musi pokazać poprawny przypadek i kontrolowaną porażkę
Prezentacja jednego dokumentu zakończona zielonym komunikatem sprawdza tylko wąską ścieżkę. Odbiór ma wykazać zachowanie całego przepływu dla wejść poprawnych, granicznych i błędnych. Każdy przypadek łączy wymaganie, dane, kroki, oczekiwany wynik, obserwację i zachowany artefakt.
Przygotuj bezpieczne dane i znane oczekiwania
Użyj dokumentów testowych bez rzeczywistych danych osobowych, które pozwalają rozpoznać zmianę strony, załącznika, kwoty, znaku i kolejności. Przygotuj kontrolowane certyfikaty oraz środowisko uzgodnione z dostawcą. Nie próbuj wywoływać unieważnienia lub awarii na cudzej usłudze bez zgody; część stanów może wymagać symulatora albo dostarczonego zestawu referencyjnego.
Przed testem zamroź wersję aplikacji, biblioteki, konfiguracji, źródła zaufania i polityki walidacji. W przeciwnym razie dwa wyniki mogą dotyczyć różnych warunków, choć dokument wejściowy był ten sam.
Sprawdź zgodność podglądu z podpisanym obiektem
Porównaj dokument pokazany przed autoryzacją z pobranym wynikiem. Zmień treść po podglądzie, przerwij sesję, wróć do starej karty przeglądarki i spróbuj użyć wcześniejszego żądania. System powinien wykrywać zmianę albo wymagać nowego, świadomego rozpoczęcia; dokładne zachowanie wynika z projektu.
Przetestuj pusty dokument, wiele plików, brak załącznika, zbyt duży plik, nieobsługiwany format i treść z aktywnymi elementami. Odrzucenie powinno być czytelne, zapisane i powiązane z zadaniem, ale nie może ujawniać w logu całej poufnej treści.
Autoryzacja musi dotyczyć właściwej osoby i operacji
Sprawdź prawidłową osobę, błędne konto, wygaśniętą sesję, anulowanie, wielokrotne kliknięcie oraz utratę odpowiedzi po autoryzacji. Użytkownik musi widzieć, ile obiektów podpisuje i w jakiej sprawie. Kod, PIN lub potwierdzenie nie mogą być przejmowane przez operatora procesu.
Niepewny finał potrzebuje własnego stanu
Jeśli dostawca wykonał operację, ale integracja nie odebrała odpowiedzi, ślepe ponowienie może utworzyć kolejny podpis. System powinien najpierw sprawdzić stan pierwotnego zadania albo skierować je do kontrolowanego wyjaśnienia. „Błąd” nie może automatycznie znaczyć „nic się nie wydarzyło”.
Walidację badaj na macierzy wyników
Przygotuj poprawny podpis, dokument zmieniony po podpisie, brak powiązanych danych dla podpisu odłączonego, certyfikat o innym statusie, brak części danych walidacyjnych, nieobsługiwany format i wiele podpisów o różnych wynikach. Oczekiwany rezultat powinien wynikać z polityki i materiału referencyjnego, nie z koloru, który pokaże testowany produkt.
Raport musi wskazywać status każdego składnika, czas oceny, źródło zaufania, politykę i przyczynę. Sprawdź, czy status nieokreślony nie jest mapowany na ważny, a błąd pobrania danych nie znika pod ogólnym komunikatem.
Wiele podpisów nie może niszczyć wcześniejszych
Podpisz tę samą wersję w ustalonej kolejności i sprawdź wszystkie podpisy po każdym kroku. Przetestuj próbę dodania podpisu do innej wersji, zmianę załącznika, odrzucenie jednej osoby i wycofanie procesu. Nie zakładaj, że dwa oddzielnie podpisane pliki da się połączyć przez kopiowanie stron.
Jeżeli system stosuje pieczęć automatyczną, przetestuj ją jako osobny artefakt z własnym uprawnieniem, certyfikatem i logiem. Interfejs nie powinien sugerować, że pieczęć jest podpisem człowieka.
Odbierz przekazanie, retencję i eksport
Wyślij wynik do kontrolowanego punktu odbiorcy i sprawdź format, komplet, identyfikator oraz potwierdzenie. Następnie odtwórz pakiet z repozytorium: dokument, załączniki, podpisy, raport, dowody czasu, źródło umocowania i dowód przekazania. Osoba spoza projektu powinna zrozumieć relacje bez prezentacji wykonawcy.
Przetestuj role, odebranie dostępu, log, retencję i kontrolowany eksport. Wyeksportowane dane mają nadawać się do walidacji poza panelem, w zakresie uzgodnionym w wymaganiu. Plan wyjścia sprawdza się przed uruchomieniem, bo po zakończeniu umowy może być za późno na dodanie brakujących artefaktów.
Protokół opisuje również granice dowodu
Wpisz wersję, wynik, plik dowodowy, odchylenie, ryzyko, właściciela i decyzję. Jeżeli scenariusza nie dało się wykonać, nie oznaczaj go jako zaliczony na podstawie deklaracji. Ustal test zastępczy albo jawnie pozostaw warunek otwarty.
Po zmianie biblioteki, interfejsu, polityki, listy zaufania lub sposobu generowania dokumentu uruchom właściwy zestaw regresji. Odbiór jest początkiem kontrolowanego utrzymania, nie ostatnim testem systemu.