Procedure di test
Quando si crea un programma, è comodo avere delle unità di test, cioè test automatizzati per verificare che ogni classe o componente stia facendo il suo lavoro. Questo rende più facile identificare eventuali anomalie. Il limite di questi test è che devono essere programmati. Per un'applicazione come `grep', è piuttosto semplice, ma per un'applicazione grafica come QET, è più difficile. Chi vorrebbe perdere tempo nel gestire un programma di verifica della qualità grafica di QET? Io non ci penso nemmeno. Ovviamente, test unitari per il resto dell'applicazione non sono certamente una cattiva idea, anzi sono certamente utili.
In effetti, quello che ci manca prima di un rilascio di QET è un elenco di cose da controllare manualmente, per non dimenticarne nessuna. Si dovrebbero quindi creare, mettere per iscritto e verificare degli scenari tipici di test di QET. Cose come: “Avviare QET, assicurarsi che …, andare in… , inserire un certo elemento, assicurarsi che … , inserire un altro elemento e un conduttore, assicurarsi che … ecc. ”
Questo ricalca un po' gli “esempi d'uso” e i “Casi d'uso” che si possono trovare nei “Profili utente”: Scenari d'uso e casi d'uso
Questo ci permetterebbe di testare QET in modo diverso dal uso personale stiamo spingendo ogni tester a fare un giro completo dell'applicazione. Questo serve sia per trovare bug importanti (segmentation fault, malfunzionamenti, ecc) che bug minori (estetici, di ergonomia, ecc). Si potrebbe anche considerare il mantenimento dei file di programma/progetti/elementi di prova (compreso il test di retro-compatibilità).
Da completare
