Test non funzionali: ciò che definisce se il sistema è buono oltre a funzionare

Un sistema può superare tutti i test funzionali ed essere comunque un fallimento.

Fa esattamente quello che le specifiche richiedono. Ogni pulsante funziona, ogni calcolo è corretto, ogni flusso si completa da solo. E anche così è lento fino all'irritazione, si blocca quando molte persone lo usano, perde dati al primo tentativo di attacco ed è così intricato che nessuno può cambiarlo senza rompere altre tre cose. Funziona ed è brutto.

Questa differenza tra "fa quello che dovrebbe" e "lo fa abbastanza bene da essere effettivamente utilizzato" è esattamente il territorio dei test non funzionali. Sono, a mio avviso, l'elemento di qualità che più distingue i prodotti professionali dai prototipi camuffati.

Funzionale e non funzionale

La distinzione è semplice da formulare e profonda nelle sue conseguenze.

I test funzionali verificano cosa fa il sistema: dato un input, produce l'output corretto? La registrazione viene salvata? Il pagamento viene elaborato? Il rapporto fornisce i numeri giusti? Queste sono domande sul comportamento e sulla correzione.

I test non funzionali verificano le prestazioni del sistema: quanto velocemente, quanto è sicuro, quanto è affidabile, quanto è scalabile, quanto è facile da usare e mantenere. Non si chiedono “funziona?”, ma piuttosto “funziona bene?”. Velocità, sicurezza, stabilità sotto carico, accessibilità, sono tutte cose non funzionali.

La trappola è che la funzionalità è facile da specificare e da pagare, quindi riceve quasi tutta l'attenzione. Il non funzionale è diffuso, facile da rimandare, e quindi solitamente trascurato, fino a diventare la ragione per cui il sistema fallisce nella produzione.

Le dimensioni che contano

"Non funzionale" è un grande ombrello. Vale la pena conoscere le dimensioni principali, perché ognuna rappresenta un modo diverso in cui il sistema può deludere anche quando funziona.

Le prestazioni sono le più visibili: tempi di risposta, velocità di utilizzo. Un sistema corretto ma lento perde silenziosamente utenti. Scalabilità e capacità dipendono dalla capacità di gestire la crescita e i picchi di domanda, piuttosto che funzionare solo quando poche persone lo utilizzano.

Affidabilità e disponibilità riguardano la continuità: il sistema regge nel tempo, si riprende dai guasti e non corrompono i dati? La sicurezza controlla se resiste a un uso dannoso, ed è qui che risiede la categoria dei difetti più costosi, perché una falla di sicurezza non frustra l'utente, lo espone.

Usabilità e accessibilità chiedono se persone reali, con capacità e contesti diversi, possano effettivamente utilizzarlo. E la manutenibilità, la più invisibile di tutte, chiede se il team può far evolvere il sistema senza che ogni cambiamento diventi un campo minato.

Perché il non funzionale viene rinviato (e perché è un bug)

C'è una ragione strutturale per cui il non funzionale viene trascurato: non appare nella dimostrazione.

Quando mostri il sistema a un cliente o a un manager, mostri la funzionalità. "Guarda, fai questo, fai quello." Nessuno dimostra "guarda come resiste a diecimila utenti" o "guarda come resiste a un attacco". Queste qualità sono invisibili fino al giorno in cui vengono a mancare, e allora appaiono come una crisi.

Il risultato è una falsa economia. Il test di carico, sicurezza, accessibilità è rinviato, perché "prima deve funzionare". Quindi il sistema entra in produzione, si blocca al primo picco, perde dati o esclude parte degli utenti e il costo della correzione tardiva è molte volte superiore a quello che sarebbe stato testare in tempo.

Nel settore pubblico ciò è particolarmente grave. Un sistema di servizi al cittadino che funziona ma è lento, insicuro o inaccessibile non serve a chi ne ha più bisogno. E quando si tratta di dati personali, la falla di sicurezza non funzionale si scontra direttamente con la LGPD, smette di essere un problema tecnico e diventa un problema legale.

Testare ciò che non funziona richiede una mentalità diversa

Testare la funzionalità è relativamente semplice: definire gli input, controllare gli output. Testare ciò che non funziona è più difficile perché richiede di definire cosa è "abbastanza buono", e questa è una decisione, non un dato di fatto.

Quanto velocemente è abbastanza veloce? Quanti utenti simultanei può "gestire"? Quale livello di disponibilità è accettabile? Queste domande non hanno una risposta universale; dipendono dal contesto dell’azienda e degli utenti. Il primo compito dei test non funzionali è, quindi, trasformare qualità vaghe in obiettivi misurabili. "Veloce" non è testato; Viene testato "rispondere al di sotto di tale tempo per il 95% dei casi".

La conseguenza pratica è che i requisiti non funzionali devono essere definiti precocemente, insieme a quelli funzionali. Trattarli come un ripensamento significa garantire che verranno testati troppo tardi o mai più.

Gli errori che rendono inutile lo sforzo

Il primo errore è non fissare obiettivi. Senza un obiettivo, "testare le prestazioni" significa raccogliere numeri senza sapere se sono buoni o cattivi. L'obiettivo deve arrivare prima della prova.

Il secondo è testare in un ambiente non realistico. Misurare le prestazioni su una macchina diversa da quella di produzione o la sicurezza senza scenari di attacco realistici genera risultati fuorvianti. Il non funzionale è particolarmente sensibile all'ambiente, i numeri valgono solo se le condizioni somigliano alla realtà.

Il terzo è trattarlo come un unico evento. Prestazioni, sicurezza e affidabilità si riducono nel tempo, con ogni modifica al sistema. Un test di sicurezza effettuato al momento del lancio dice poco sulla sicurezza sei mesi e cinquanta rilasci successivi. La ricorrenza dei bisogni non funzionali.

La qualità è ciò che rimane quando la funzionalità è data per scontata

C'è un momento nella maturità di un prodotto, e di un'organizzazione, in cui "funziona" smette di essere un risultato e diventa un punto di partenza. Da allora in poi la vera qualità si definisce non funzionale: è veloce, è sicura, regge, resiste, è accessibile, è possibile evolvere.

I team delle startup celebrano “funziona”. Le squadre mature sanno che questa è solo la base. Ciò che distingue un sistema professionale da uno amatoriale è raramente quello che fa, è quanto bene lo fa, sotto pressione, nel tempo, per tutti. Questo "quanto bene" è proprio ciò che proteggono i test non funzionali.

Ignorarli non risparmia fatica. Si limita a trasferire il costo nel momento peggiore possibile: la produzione, con la presenza dell'utente.

Se il tuo prodotto "funziona" ma non hai mai misurato quanto sia veloce, sicuro o resistente, probabilmente c'è un rischio non funzionale in attesa di emergere. Ho altri articoli sul blog su prestazioni, sicurezza, affidabilità e qualità del software che affrontano ciascuna di queste dimensioni.