Idea principale

Una funzionalità deterministica si testa confrontandola con un risultato atteso: è conforme oppure no. Una risposta prodotta da un modello non offre questo appiglio. Due formulazioni corrette non hanno lo stesso valore per l'utente, una risposta sbagliata può essere perfettamente plausibile, e l'esperienza del fallimento — ciò che il prodotto fa quando non sa — diventa parte del prodotto quanto il successo.

Valutare questo tipo di output significa quindi affrontare domande che nessuna suite di test di conformità copre: la robustezza di fronte ai casi più insidiosi, la coerenza con l'intento di prodotto, la fiducia che l'utente può ragionevolmente accordare, e il margine di errore che è disposto ad accettare nel proprio lavoro.

Per questo ridurre questa valutazione alla classica quality assurance la svuota di sostanza: la domanda non è solo «l'output è giusto?» ma «questo output è accettabile, qui, per questo uso?» — una domanda di prodotto, non di verifica.

Perché è importante

Dice a chi spetta la valutazione: non può essere delegata per intero a una funzione di controllo in fondo alla catena, perché richiede di decidere sull'intento e su ciò che l'utente è disposto a tollerare.

E rende testabile ciò che molti team rinunciano a misurare: fiducia e accettabilità si lavorano con casi di business, scenari di fallimento e criteri scritti, non con un'impressione generale di qualità.

Sfumature e limiti

L'accettabilità non esenta dalla conformità: sulle regole verificabili — un calcolo, un permesso di accesso, un formato — l'esigenza resta binaria, e l'argomento probabilistico non deve servire da scusa.

E la soglia di accettabilità non appartiene al team che produce: la si constata presso chi usa il prodotto, e varia secondo il settore, la posta in gioco e la reversibilità di ciò che l'output innesca.

Domande aperte

• Come fissare per iscritto una soglia di accettabilità, quando in gioco c'è la fiducia di un utente e non un tasso di errore osservabile?