Risposta.

Il testing non funzionale è la verifica di un sistema non solo dal punto di vista delle funzioni di business, ma anche in base a parametri di usabilità (usability), prestazioni, sicurezza, adattabilità e accessibilità (accessibility).

Storia della questione: All'inizio dello sviluppo del testing, l'attenzione era rivolta esclusivamente a "funziona/non funziona". Con l'aumento della concorrenza e delle esigenze di qualità del prodotto, ci si è cominciati a concentrare anche su parametri accessori — facilità d'uso, velocità di lavoro, accessibilità per le persone con disabilità. Questo ha influenzato lo sviluppo del testing non funzionale.

Problema: Spesso i tester non sanno come formalizzare e valutare i parametri non funzionali manualmente. Si verifica soggettività: ciò che è comodo per un utente non lo è per un altro. L'assenza di checklist chiare e criteri aggrava solo la situazione.

Soluzione: Il tester dovrebbe:

Utilizzare standard e raccomandazioni, come WCAG per l'accessibilità o ISO 9241 per l'usabilità.
Applicare strumenti speciali (ad esempio, analizzatore di colori per controllare il contrasto tra testo e sfondo, simulatore di screen-reader per testare l'accessibilità).
Sviluppare checklist per verificare l'esperienza utente, la navigazione, la leggibilità degli elementi, ecc.
Coinvolgere utenti reali con esperienze diverse per il user-testing.

Caratteristiche chiave:

Lavorare con "scenari utente reali", non solo con test-case predefiniti.
Necessità di documentare i problemi non funzionali trovati in modo il più specifico possibile.
Capacità di utilizzare strumenti esterni per l'analisi (ad esempio, Lighthouse, Axe, NVDA, JAWS, Color Contrast Analyzer).

Domande insidiose.

Si può fare a meno del testing manuale per l'usabilità se si utilizzano test automatizzati?

No. L'esperienza utente è molto soggettiva, e molti aspetti possono essere identificati solo mediante analisi manuale o coinvolgendo utenti reali.

È sufficiente controllare l'accessibilità solo con scanner automatici?

No. I controlli automatici identificano generalmente solo il 20-30% dei problemi. Gli altri possono essere rilevati solo attraverso interazioni manuali: controlli con navigazione da tastiera, lettura tramite screen-reader, ecc.

Devo testare l'accessibilità se tra i clienti non ci sono persone con disabilità?

Sì. Legislazione, standard di qualità e prospettive di sviluppo del prodotto richiedono alta accessibilità. Inoltre, alcuni utenti potrebbero avere limitazioni temporanee (ad esempio, infortuni).

Errori comuni e anti-pattern

Negligere i requisiti non funzionali a causa di una sottovalutazione del loro impatto.
Documentare i risultati senza riferimenti agli standard.
Descrivere bug con frasi come "scomodo" o "non comodo" senza specificità.

Esempio dalla vita

Caso negativo

Il tester non ha prestato attenzione al basso contrasto della didascalia del pulsante: gli utenti con problemi di percezione dei colori non vedevano il testo.

Pro:

Risparmio di tempo sul testing.

Contro:

Gli utenti si sono lamentati, è aumentato il numero di richieste al supporto, perdite reputazionali.

Caso positivo

Il tester ha utilizzato un'utility gratuita per controllare il contrasto e ha redatto una checklist per l'accessibilità.