Il testing manuale dell'UI è emerso inizialmente come necessità, poiché gli strumenti automatici faticano a catturare errori legati alla percezione visiva e all'usabilità dell'interfaccia (storia). Tutti gli elementi devono essere accessibili, visualizzati correttamente e interagire secondo le aspettative dell'utente.
Il principale problema del testing UI manuale è la valutazione soggettiva: persone diverse possono percepire lo stesso interfaccia in modi diversi. Inoltre, è comune che i difetti visivi non vengano documentati o vengano ignorati (‘problema’). Per evitare la soggettività, è necessario sviluppare criteri di accettazione chiari per gli elementi visivi, utilizzare isometrici e linee guida, e documentare i problemi trovati attraverso screenshot, descrizioni chiare e confronti con i modelli originali (‘soluzione’).
Caratteristiche chiave:
È sufficiente testare l'UI solo in un browser o su un dispositivo?
No, gli elementi possono essere visualizzati in modo diverso a causa delle differenze nei motori dei browser e nelle risoluzioni dei dispositivi.
Se il tester non vede un difetto, può concludere che il bug non esiste?
No, è necessario confrontare l'interfaccia con le linee guida e i modelli, non solo fare affidamento sulla propria visione soggettiva.
Si possono ignorare i requisiti di accessibilità (accessibility) durante il testing dell'UI?
No, i requisiti di accessibilità sono importanti per gli utenti finali, inclusi quelli con disabilità.
Il tester ha verificato l'UI solo sul proprio computer e in un browser, e ha confrontato visivamente con la versione precedente, senza fare riferimento al modello. Di conseguenza, gli utenti dei dispositivi mobili hanno visto un'interfaccia rotta.
Pro:
Contro:
Il tester ha controllato l'UI su diversi dispositivi e browser, ha confrontato con il modello, e ha tenuto conto delle linee guida per l'accessibilità. Ha utilizzato checklist sui criteri visivi.
Pro:
Contro: