Risposta

Storia della domanda:

Il testing degli aspetti non funzionali è emerso quando è diventato chiaro che anche una funzionalità che funziona perfettamente in termini logici può essere scomoda, lenta o inaccessibile per una parte degli utenti. Questi difetti sono difficili da rilevare automaticamente, quindi i tester manuali svolgono un ruolo chiave in questo contesto.

Problema:

I tester spesso si concentrano solo sulle funzionalità, ignorando prestazioni, usabilità e accessibilità. I difetti non funzionali sono difficili da formalizzare e spiegare, la loro soggettività impedisce di ottenere una valutazione univoca.

Soluzione:

Quando si esegue il testing, è importante dedicare consapevolmente del tempo ai controlli non funzionali. Per le prestazioni, misurare il tempo di risposta (ad esempio, con un cronometro); per l'usabilità, descrivere le difficoltà e fornire esempi; per l'accessibilità, utilizzare checklist o strumenti (ad esempio, attivare uno screen reader).

Caratteristiche principali:

Richiedono una chiara definizione dei criteri di accettazione.
I risultati della valutazione sono spesso soggettivi, quindi è importante che i report siano ben motivati.
Non tutti questi difetti possono essere tollerati prima del rilascio — alcuni sono critici.

Domande insidiose.

Tutti i difetti non funzionali devono essere registrati con un bug report dal tester?

Non sempre. Se il problema è soggettivo, a volte è sufficiente discuterlo con il team e registrarlo come miglioramento (richiesta di funzionalità).

Il tester deve impostare le metriche di prestazione?

Solo se non sono specificate nei requisiti o nel documento di specifica, altrimenti ci si dovrebbe basare su di esse.

È obbligatorio avere software o strumenti specializzati per il testing non funzionale?

No, i controlli di base possono essere effettuati manualmente (ad esempio, misurare il tempo manualmente, analizzare l'accessibilità con una checklist).

Errori tipici e antipattern

Ignorare i criteri non funzionali.
Report soggettivi senza prove misurabili.
Titoli e descrizioni di bug troppo generici o vaghi.

Esempio dalla vita reale

Caso negativo

Il tester ha notato che la pagina del catalogo carica in più di 10 secondi, ma non ha segnalato il bug, pensando che “sia così per tutti”.

Vantaggi:

Non ha sommerso il team con ticket controversi.

Svantaggi:

Diminuzione dell'esperienza utente, i clienti sono delusi, la direzione ha appreso del problema tramite lamentele.

Caso positivo

Il tester ha documentato dettagliatamente che la pagina del catalogo impiega 12 secondi a caricarsi al primo accesso, allegando uno screenshot del cronometro e proponendo possibili ottimizzazioni.