IEEE 829

Les documents sont définis en huit étapes de test logiciel, et chaque étape peut potentiellement produire son propre type de document. Le standard IEEE 829-2008 spécifie le format de ces documents. Par contre, il ne stipule pas s’ils doivent être réalisés, et n’incluent pas non plus de critère pour s’assurer de leur contenu. Ces questions n'entrent pas dans le champ du standard. Les huit documents sont les suivants :

• Planning de test. Ce document de planification de management montre : comment sera effectuée la campagne de test, qui la fera, ce qui sera testé, combien de temps cela prendra, quelle sera la couverture de test.
• Spécifications techniques de test. Ce document détaille les conditions de test et les résultats attendus.
• Spécifications de cas tests. Ce document spécifie les données de test pour l’exécution des conditions de tests définies dans le document précédent.
• Spécifications de procédure de test. Ce document détaille comment chaque test est exécuté, notamment les pré-conditions de configuration et les scénarios de test.
• Rapport de transmission de cas tests. Ce document rapporte le passage d'une étape à une autre d'un scénario de test.
• Journal de test. Ce document enregistre les cas tests exécutés, leur auteur, leur ordre d’exécution, et le résultat du cas test.
• Rapport d’incidents de test. Ce document détaille pour chaque test non validé, les résultats attendus et obtenus, ainsi que des informations pour comprendre la raison du décalage. Ce document s’appelle bien un rapport d’incidents et non de fautes. En effet, les raisons du décalage entre le résultat attendu et le résultat obtenu ne sont pas toujours le fait d’une faute du système. Il est par contre exclu que le résultat de test soit obtenu du fait d’une mauvaise exécution du test ou d’exigences testables équivoques. Ce rapport entre dans le détail des incidents de tests : quand l’incident survient, quelles remarques peuvent aider à sa résolution. Si possible, le rapport inclut aussi une évaluation de l’impact de l’incident sur la suite de la campagne de test.
• Rapport de test (ou PV de recette). Ce document de management fournit les informations importantes mises au jour par la campagne de tests exécutée : une évaluation de la qualité de l’effort de test, de la qualité du système testé, des statistiques du rapport d’incidents de test. Le rapport comporte aussi la durée des différents tests menés, et comment améliorer une prochaine campagne de test. Ce document final indique si le système testé est approuvé ou pas, et selon quels critères.

Voici d'autres standard IEEE associés au IEEE 829-2008 :

• IEEE 1008, un standard pour le test unitaire
• IEEE 1012, un standard pour la validation et la vérification d’un système
• IEEE 1028, un standard pour l'inspection d’un système
• IEEE 1044, un standard pour la classification des anomalies d’un système
• IEEE 1044-1, un guide de la classification des anomalies d’un système
• IEEE 830, un guide pour développer des spécifications d’exigences pour un système.
• IEEE 730, un standard pour les plans d’assurance de qualité d'un système
• IEEE 1061, un standard pour la méthodologie et la mesure de la qualité d’un système
• IEEE 12207, un standard pour les processus de cycles de vie d’un système
• BS 7925-1, un glossaire des termes utilisés dans le test logiciel
• BS 7925-2, un standard pour le test des composants d'un système

Ce standard fait partie du programme d’entraînement de la fondation ISEB et de la certification pour le test logiciel de la société britannique d’informatique. L’ISTQB après avoir adopté son propre langage fondé sur l’ISEB et l’ASQF allemande, a aussi adopté le standard IEEE 829 comme document de référence pour le test logiciel.

• - IEEE standard 829-1998 (venant de l’IEEE)
• - IEEE standard 829-2008 (venant de l’IEEE)