Procédures de test
Lorsque l'on fait un programme, il est pratique d'avoir des tests unitaires, c'est-à-dire des tests automatisés vérifiant que chaque classe ou composant fait bien son boulot. Cela permet de repérer facilement des régressions. La limite de ces tests, c'est qu'il faut les programmer ; pour une application comme `grep', c'est plutôt aisé, mais pour une application qui fait du rendu graphique comme QET, c'est plus difficile. Quelqu'un a envie de perdre du temps à maintenir un programme de vérification du rendu graphique de QET ? Je ne pense pas. Évidemment, des tests unitaires pour le reste de l'application ne feraient quand même pas de mal mais bon.
En fait, ce qui nous manque avant de faire une release de QET, c'est une liste des choses à vérifier humainement, afin de n'en oublier aucune. Il faudrait donc créer, poser par écrit et maintenir des scénarios de test de QET. Des choses du genre : « Démarrer QET, s'assurer que …, aller dans, poser tel élément, s'assurer que …, poser un autre élément et un conducteur, s'assurer que …, etc. »
Cela rejoint un peu les « Use scenarios » et « Use cases » qu'on peut trouver dans le « User Profiles » : Use Scenarios and Use Cases
Cela nous permettrait de tester QET autrement que par l'usage personnel que nous en faisons en poussant chaque testeur à faire un tour complet de l'application. Cela sert aussi bien à trouver des bugs majeurs (segfaults, dysfonctionnements, …) que des bugs mineurs (cosmétique, ergonomie, …). Cela pourrait également impliquer de maintenir des fichiers schémas/projets/éléments de test (notamment pour tester la rétro-compatibilité).
À compléter
