Définir les critères d'achèvement des tests d'un logiciel

Vous ne pouvez pas tester partiellement un logiciel. Par conséquent, tout projet qui a été testé devrait avoir des critères bien définis pour indiquer si les tests ont été correctement menés.

Chaque test devrait avoir des objectifs quantifiables spécifiques.

Par exemple, "100% des scripts d'une nouvelle fonctionnalité doivent être exécuté durant les tests d'intégration du système". Ceci est un objectif. Il devrait y avoir un objectif pour les scripts de régression également. Vous pouvez aussi avoir des objectifs qui soient spécifiques pour tester certains types de fonctionnalités si pour une raison ou une autre vous n'avez pas de scripts de test.

Maintenant, voici une chose à considérer: est ce que les tests sont terminés lorsque tous les tests ont été exécutés, ou bien le sont-ils lorsque tous les scripts se sont correctement exécutés?

Voyez-vous la différence? Vous pouvez avoir 100 scripts avec 100 exécutions mais obtenir 10 erreurs. Est ce que cela veut dire que le test est terminé? ou bien est ce que ces 10 erreurs ont besoin d'être corrigées avant d'affirmer que les tests soient terminés?

Cette question est quelque chose qui doit être discuté avec votre équipe qualité si vous n'avez pas encore définit de standard. Vous pouvez faire cela de différentes manières:

• Vous pouvez fixer comme critère que tout vos scripts doivent se terminer correctement - c'est à dire qu'aucun script doit être en erreur pour valider totalement les tests.
• Vous pouvez fixer des critères qui définissent le nombre d'erreurs et la priorité de ceux-ci afin d'affirmer que les tests soient terminés. Vous pouvez définir un seuil acceptable d'erreurs à partir duquel vous pouvez passer l'application en production. Par exemple, vous pouvez dire que "les tests sont validés lorsque 95% des scripts se sont exécutés correctement et qu'il n'y a pas d'erreur majeure non résolue".

Je dis cela tout le temps et ça continue d'être une bonne leçon. "Avoir un processus bien définit n'est pas aussi important qu'en avoir un et de le suivre".

Soyez certain d'avoir un processus standardisé afin de savoir lorsque vos tests sont validés et que l'équipe de développement avec laquelle vous travaillez sache quelles sont les attentes.Cela est inestimable dans votre relation et votre communication avec les développeurs.

source originale: the analyst coach