Al hacer un programa, es conveniente contar con las pruebas unitarias, es decir, en las pruebas automatizadas verificar que cada clase o componente haga su trabajo. Esto permite identificar fácilmente las regresiones. El límite de estas pruebas es que los programas; para una aplicación como `grep ', es bastante fácil, pero, para una aplicación que hace la representación de gráficos en QET es más difícil. Alguien quiere perder el tiempo en mantener un programa de representación de gráficos de QET ?No creo. Por supuesto, las pruebas unitarias para el resto de la aplicación no harían daño, sino bien.

De hecho, lo que necesitamos antes de hacer una lanzamiento de QET, es una lista de cosas que debe comprobar humanamente sin olvidar ninguna. Por lo tanto, debe crear, instalar y mantener una prueba escrita de QET . Cosas como la clase: « Comenzar QET, asegúrese de que …, vaya, pregunte tal elemento, asegúrese de que …, colocar otro elemento y un conductor, asegúrese de que …, etc. »

Esto va un poco más « Escenarios de uso » y « Casos de uso » que se puede encontrar en el « User Profiles » (Perfiles de Usuario): Escenerios de uso y Casos de uso

Esto nos permitirá poner a prueba QET distinto del uso personal que que hacemos pulsando cada prueba de hacer una vuelta completa de la aplicación. Esto sirve tanto para encontrar errores importantes (segmentación, mal funcionamiento, …) como los bugs de menor importancia (estética, ergonomía, …). También podría involucrar el mantenimiento de archivos esquemas/proyectos/elementos de prueba (Por ejemplo, para probar la compatibilidad de versiones anteriores).

• Instalación de paquetes
• Editor de esquemas
• Editor de elementos
• Gestión de elementos
• Opciones de la línea de comandos y el Mode Daemon
• Características de la bandeja del sistema
• Completo.