Livrables de l’équipe de test logiciel

Les livrables de test sont des documents transmis aux parties prenantes pendant le développement. Cette section présente les éléments suivants.

Ouvrir le schéma en taille réelle ↗

Livrables de l’équipe de test logiciel

• Stratégie de test logiciel
• Plan de test logiciel
• Scénarios et cas de test logiciel
• Indicateurs de test logiciel
• Indicateurs produit
• Indicateurs de processus
• Documentation de test logiciel
• Rapports de test logiciel
• Rapports quotidiens de suivi des tests
• Rapports d’incident
• Rapport final de clôture des tests

Stratégie de test logiciel

Une stratégie de test trace la marche à suivre pour les activités de test du projet. Répartissez le travail en processus plus petits et clairement définis. La stratégie aide l’équipe à estimer le temps, l’effort et les ressources nécessaires. Elle facilite également la planification, le pilotage et le suivi de l’avancement.

Plan de test logiciel

Un plan de test définit la stratégie générale, l’environnement et les niveaux de test. Il indique comment analyser les résultats et quels indicateurs utiliser. Il précise aussi les critères de sortie de chaque phase et les estimations de charge et de coût.

Ouvrir le schéma en taille réelle ↗

Plan de test logiciel

Scénarios et cas de test logiciel

Un scénario de test décrit une situation hypothétique qui permet d’évaluer le logiciel de façon structurée. Il peut être aussi complexe qu’un récit. Un cas de test indique directement ce qu’il faut faire, les données à saisir et le résultat attendu. Un cas de test tient généralement en une ligne, tandis qu’un scénario propose au testeur un contexte plus large à explorer.

Ouvrir le schéma en taille réelle ↗

Scénarios et cas de test logiciel

En 2003, Cem Kaner a présenté les tests par scénarios comme une façon d’explorer des situations réalistes. Les cas de test détaillés décrivent toujours les étapes, les données d’entrée et les résultats attendus. Maintenir ce niveau de détail peut demander plus d’efforts.

Les cas de test indiquent directement au testeur quoi faire et comment tester le logiciel.

Ouvrir le schéma en taille réelle ↗

Scénarios et cas de test logiciel

Indicateurs de test logiciel

Une métrique logicielle est une unité de mesure d’une caractéristique du logiciel. Les indicateurs de test évaluent la qualité et indiquent le niveau de préparation du système au fil du développement. On ne peut améliorer que ce que l’on mesure, car la mesure permet de maîtriser le résultat. Dans chaque phase, les décisions s’appuient sur les indicateurs de la phase précédente. Les indicateurs se répartissent en deux groupes.

1. Les mesures directes, ou indicateurs de base, sont les données brutes recueillies par un analyste de test pour montrer l’état du projet. Par exemple, le nombre de cas de test créés ou exécutés.
2. Les mesures indirectes, ou indicateurs calculés, transforment les données de base en informations plus utiles sur le projet. Par exemple, le pourcentage d’achèvement ou le taux de couverture des tests.

Indicateurs produit

Les indicateurs produit orientent l’amélioration de la qualité. Une évaluation régulière aide l’équipe à repérer à temps les caractéristiques du produit à corriger. Ces indicateurs mesurent les éléments suivants.

• Taille
• Complexité
• Aspects de la conception
• Performance
• Qualité

Indicateurs de processus

Les indicateurs de processus montrent comment améliorer les méthodes de travail et économiser du temps et des efforts. Pour évaluer les progrès, comparez les résultats à l’objectif du processus. Suivre les activités de test peut améliorer l’efficacité et la productivité du projet. Dans le développement logiciel, ces indicateurs couvrent les domaines suivants.

• Développement logiciel
• Maintenance logicielle
• Test logiciel

Documentation de test logiciel

La documentation consigne les activités avant ou pendant les tests. Elle comprend notamment les documents suivants.

• Plan de test
• Scénario de test
• Cas de test
• Matrice de traçabilité

Rapports de test logiciel

Les rapports suivants appuient le travail de test.

• Rapports quotidiens de suivi des tests
• Rapports d’incident
• Rapport final de clôture des tests

Rapports quotidiens de suivi des tests

Les rapports quotidiens tiennent informés l’équipe de test et les responsables du projet et du programme. Le chef de projet peut voir le nombre de défauts de la journée, les cas exécutés et le travail de chaque testeur. Répondez aux questions suivantes.

1. Combien de cas de test étaient prévus pour la journée ?
2. Combien ont été exécutés ?
3. Combien de défauts l’équipe a-t-elle signalés ?
4. Combien de défauts étaient critiques ?
5. Où trouver les rapports détaillés, dont la fiche de suivi des défauts et d’exécution des tests ?

Rapports d’incident

Les rapports d’incident coordonnent les activités de test et de développement. La gestion des incidents consigne les éléments suivants.

• La comparaison entre les résultats obtenus et les résultats attendus
• La cause de l’écart lors d’un échec de test, par exemple une automatisation défaillante, un mauvais cas de test ou une panne réelle du logiciel

Pour une défaillance réelle, rédigez un rapport d’incident qui contient les informations suivantes.

• Identification
• Quel est l’identifiant de chaque rapport ?
• Quel est l’objet du test ?
• Version de l’application testée
• Informations sur l’environnement de test, matériel et logiciel compris
• Nom du développeur chargé d’évaluer et de résoudre l’incident
• Quand la défaillance a-t-elle été observée ?
• Classification
• Statut
• Sévérité
• Priorité
• Exigence
• Cause
• Description du problème
• Description de la défaillance
• Détails du cas de test
• Commentaires du testeur
• Commentaire du développeur après la modification
• Références éventuelles

Rapport final de clôture des tests

Le responsable des tests prépare un rapport de clôture lorsque les critères de sortie sont remplis ou que les tests sont terminés. Les parties prenantes et les clients le relisent ensuite. Indiquez les cas de test exécutés avec succès et les défauts encore ouverts dont la correction est prévue après le déploiement.