REQUIREMENTS
Wymaganie musi być testowalne
„Bot ma obsługiwać rezerwacje” nie wystarcza. Zamieniam wymagania na obserwowalne kryteria: preconditions, akcję, oczekiwany stan i zachowanie po błędzie.
Independent AI Acceptance Testing · Voice · Chat · Agents
Niezależne testy odbiorcze AI, zanim zaakceptujecie wdrożenie.
Demo dostawcy pokazuje, że happy path działa. Test odbiorczy odpowiada na trudniejsze pytanie: czy system naprawdę spełnia Wasze wymagania biznesowe, poprawnie korzysta z integracji i zachowuje się właściwie, gdy coś pójdzie nie tak.
niezależna walidacjabusiness rules + integrationsGO / FIX / NO-GO
ACCEPTANCE CASE · DEMO
AT-014 · ATOMIC_RESCHEDULE
REQUIREMENTNowy slot niedostępny → stara wizyta pozostajeDEFINED
VENDOR DEMOPrzełożenie wizyty · happy pathPASS
EDGE CASESlot znika tuż przed zapisemFAIL
CRITICAL FINDING
NEW SLOT409 SLOT_TAKEN
OLD APPOINTMENTDELETED
EXPECTEDold appointment kept
ACTUALuser has no appointment
ACCEPTANCE DECISIONNO-GO · FIX REQUIRED
Poza happy pathem
System może wyglądać na gotowy i nadal nie być gotowy do odbioru.
W systemach AI poprawna odpowiedź jest tylko jedną warstwą. Przy odbiorze sprawdzam również kryteria biznesowe, stan rozmowy, wiedzę, tool calle, API i to, co faktycznie wydarzyło się w systemie po zakończeniu procesu.
INDEPENDENCE
Demo dostawcy nie jest testem odbiorczym
Sprawdzam scenariusze niezależnie od przygotowanego demo, również poza happy pathem i z warunkami, które mogą odsłonić błędy integracji lub logiki.
BUSINESS OUTCOME
Liczy się finalny stan procesu
Jeśli bot mówi „gotowe”, ale backend operacji nie wykonał, wynik jest FAIL. Odbieramy zachowanie systemu, nie tylko jakość tekstu.
EVIDENCE
Decyzja powinna mieć dowody
Każdy istotny finding opisuje wejście, oczekiwanie, wynik, evidence i severity, dzięki czemu wiadomo, co poprawić przed akceptacją.
Jak wygląda odbiór
Od wymagań do decyzji GO / FIX / NO-GO.
01
Ustalam kryteria akceptacji
Zbieramy najważniejsze procesy, warunki biznesowe, integracje oraz sytuacje, których system nie może obsłużyć błędnie. Kryteria mogą być binarne albo progowe, jeśli zachowanie systemu jest stochastyczne. Zaczynam od procesów o najwyższym ryzyku.
02
Projektuję scenariusze ryzyka
Poza happy pathem: korekty multi-turn, niepełne dane, konflikt reguł, brak wyniku w RAG, timeout API, retry, utrata kontekstu, wyścig o zasób i inne failure modes istotne dla Waszego procesu.
03
Uruchamiam niezależne testy
Black-box przez UI, numer telefonu lub API, a jeśli dostęp pozwala, również z logami i stanem backendu. Zapisuję też wersję systemu i istotne warunki środowiska testowego. Dla voice dochodzą m.in. ASR, barge-in i krytyczne sloty.
04
Zbieram evidence i severity
PASS / FAIL nie jest opinią. Do findingu dokładam dane potrzebne do reprodukcji oraz wagę biznesową, żeby krytyczny blocker nie zginął obok drobnego problemu językowego.
05
Przekazuję rekomendację
Raport pokazuje, które kryteria przeszły, które wymagają poprawy i czy badany zakres jest gotowy do akceptacji. Rekomendacja GO / FIX / NO-GO wspiera Waszą decyzję, ale nie zastępuje formalnych zapisów umowy.
Przykład findingu
Najgroźniejsze błędy często pojawiają się dopiero między rozmową a backendem.
Wymaganie · atomic reschedule
Nie wolno usunąć starej wizyty, dopóki nowy termin nie zostanie zarezerwowany.
Happy path działa, więc funkcja wygląda na gotową. W teście odbiorczym nowy slot znika między wyszukaniem a zapisem. Implementacja najpierw kasuje starą wizytę, a dopiero potem próbuje utworzyć nową.
To nie jest „gorsza odpowiedź LLM”. To złamanie reguły biznesowej i utrata istniejącej rezerwacji.
CRITERIONold appointment remains on failure
DELETE OLD200 OK · too early
BOOK NEW409 SLOT_TAKEN
FINAL STATE0 appointments
SEVERITYCRITICAL
DECISIONNO-GO · FIX REQUIRED
Co dostajecie
Materiał do podjęcia decyzji, a nie tylko lista luźnych uwag.
CRITERIA MATRIX
Macierz kryteriów
Najważniejsze wymagania i scenariusze z jednoznacznym wynikiem PASS / FAIL / NOT TESTED.
FINDINGS
Lista błędów
Opis problemu, preconditions, kroki, expected vs actual oraz wpływ na proces biznesowy.
EVIDENCE
Dowody
Fragment rozmowy, response API, tool call, log lub stan systemu potrzebny do potwierdzenia findingu.
SEVERITY
Priorytet napraw
CRITICAL / HIGH / MEDIUM, żeby odróżnić blocker odbioru od kosmetycznego problemu.
TRACEABILITY
Powiązanie z wymaganiami
Tam, gdzie jest to możliwe, finding wskazuje kryterium lub proces, którego system nie spełnił.
DECISION
GO / FIX / NO-GO
Czytelna rekomendacja dla badanego zakresu wraz z blockerami wymagającymi zamknięcia przed akceptacją.
Dla kogo
Najwięcej sensu ma wtedy, gdy to Wy macie powiedzieć: „odbieramy”.
DOBRY FIT
- firma odbiera voicebota, chatbota lub agenta od zewnętrznego dostawcy
- system obsługuje proces z realnym skutkiem biznesowym
- potrzebujecie niezależnej warstwy przed go-live
- integracje z CRM, kalendarzem, HIS/ERP lub API są częścią rozwiązania
- happy path działa, ale nie macie pewności co do edge case'ów i failure recovery
Może działać jako niezależny checkpoint obok QA dostawcy, a nie zamiast niego.
MNIEJ SENSU NA TYM ETAPIE
- produkt jest jeszcze bardzo wczesnym prototypem bez stabilnych procesów
- nie ma żadnych kryteriów poprawnego wyniku biznesowego
- celem jest wyłącznie porównanie modeli na jednym ogólnym score
- nie ma bezpiecznego środowiska lub zgody na wykonanie testów
W takim przypadku lepszy może być najpierw AI Agent Audit albo Free AI Quality Check.
Kto odpowiada za testy
Adam Stankiewicz · AI Quality Engineer
Na co dzień pracuję hands-on z ewaluacją produkcyjnych voicebotów i chatbotów. Wcześniej przez ponad 3 lata testowałem systemy rynku energii, gdzie błędy miały realne konsekwencje biznesowe.
FAQ
Najczęstsze pytania
Czy testy odbiorcze AI wymagają dostępu do kodu źródłowego?
Nie zawsze. Dużą część testów można wykonać black-box przez interfejs, numer telefonu lub API. Dostęp do logów pomaga przy diagnozie integracji, tool calli i finalnego stanu backendu.
Czy można niezależnie przetestować system dostarczony przez zewnętrznego vendora?
Tak. Celem jest niezależna weryfikacja uzgodnionych procesów i kryteriów akceptacji na środowisku, do którego macie legalny i bezpieczny dostęp. Nie trzeba opierać decyzji wyłącznie na demo dostawcy.
Czy acceptance testing zastępuje QA dostawcy?
Nie. QA dostawcy i niezależne testy odbiorcze pełnią różne role. Dostawca sprawdza własny produkt, a niezależna walidacja odpowiada na pytanie, czy rozwiązanie spełnia Wasze wymagania biznesowe i czy można je bezpiecznie odebrać lub wdrożyć.
Jaki jest wynik testów odbiorczych?
Dostajecie raport z macierzą kryteriów, wynikami PASS/FAIL, evidence, severity oraz rekomendacją GO / FIX / NO-GO dla badanego zakresu. Raport wspiera decyzję odbiorową, ale nie jest formalnym ani prawnym certyfikatem odbioru.
Czy testy odbiorcze obejmują voiceboty?
Tak. W voicebotach można dodatkowo sprawdzić m.in. ASR, barge-in, turn-taking, endpointing, krytyczne sloty, potwierdzenia i zachowanie po błędnym rozpoznaniu.
Zacznij od jednego procesu
Sprawdźmy jeden krytyczny proces przed odbiorem systemu.
W bezpłatnym Quality Checku wybiorę 5 celowanych scenariuszy i pokażę, czy system tylko brzmi poprawnie, czy faktycznie wykonuje proces tak, jak powinien.