Syllabus CFTL

Retour au sommaire

Gestion des tests (K3)

5. Gestion des tests

5.1 Organisation des tests (K2)

Termes
Testeur, responsable du test, gestionnaire du test.

5.1.1 Organisation du test et indépendance (K2)
L‟efficacité de la découverte d‟anomalies par le test et les revues peut être améliorée par l‟emploi de testeurs indépendants. Les options pour l‟indépendance sont les suivantes :
o Pas de testeurs indépendants, développeurs testant leur propre code
o Testeurs indépendants incorporés à l‟équipe de développement.
o Équipe ou groupe de test indépendant au sein de l‟organisation, qui réfère au gestionnaire du projet ou aux responsables décisionnaires.
o Testeurs indépendants de l‟organisation, de la communauté des utilisateurs et de l‟Informatique.
o Spécialistes de test indépendants pour des objectifs spécifiques de test tels que des tests d‟utilisabilité, de sécurité informatique ou de certification (qui certifient un produit logiciel par rapport à des normes ou réglementations).
o Testeurs indépendants externes à l‟organisation
Pour des projets de grande taille, complexes ou présentant un niveau de sécurité critique, il est habituellement préférable d‟avoir plusieurs niveaux de tests, dont certains ou tous sont traités par des testeurs indépendants. L‟équipe de développement peut prendre part aux tests, plus spécialement aux plus bas niveaux, mais son manque d‟objectivité limite son efficacité. Les testeurs indépendants peuvent avoir l‟autorité pour exiger et définir des processus et règles, mais les testeurs ne devraient accepter ce rôle touchant aux processus qu‟en présence d‟un mandat clair du management.
Les avantages de l‟indépendance comprennent les suivants :
 Des testeurs indépendants voient des défauts différents et d‟une autre nature et sont impartiaux.
 Un testeur indépendant peut vérifier les hypothèses faites pendant la spécification et l‟implémentation du système.
Les inconvénients comprennent les suivants :
 Déconnexion vis-à-vis de l‟équipe de développement (en cas de totale indépendance).
 Les développeurs perdent le sens de la responsabilité pour la qualité.
 Des testeurs indépendants peuvent constituer un goulet d‟étranglement comme dernier point de vérification et être accusés des retards.
Les tâches de test peuvent être exécutées par des personnes jouant un rôle spécifique du test, mais aussi par quelqu‟un exerçant un autre rôle, comme le responsable de projet, le gestionnaire de la qualité, un développeur, un expert métier ou domaine, infrastructure ou exploitation de l‟informatique.

5.1.2 Tâches du responsable des tests et des testeurs (K1)
Deux fonctions sont abordées dans ce syllabus, celles du responsable du test et du testeur. Les activités et tâches accomplies par des personnes dans ces deux rôles dépendent du contexte du produit et du projet, ainsi que des personnes jouant ces rôles et de l‟organisation.

Parfois, le responsable de test est appelé gestionnaire de test ou coordinateur de test. Ce rôle peut être rempli par un chef de projet, un responsable de développement, un responsable de la qualité ou un responsable d‟un groupe de test. Typiquement, le responsable de test planifie, surveille et contrôle les activités et tâches de test définies dans la section 1.4.
Les tâches habituelles du responsable de test peuvent comprendre les suivantes :
o Coordonner la stratégie et le plan du test avec le chef de projet et d‟autres acteurs.
o Établir ou réviser une stratégie de test pour le projet ainsi qu‟une politique de test pour l‟organisation.
o Apporter le point de vue du test aux autres activités du projet, comme la planification de l‟intégration.
o Planifier les tests – en considérant le contexte et en comprenant les objectifs et les risques – y compris la sélection des approches de test, l‟estimation du temps, de l‟effort et des coûts du test, l‟acquisition des ressources, la définition des niveaux de test, les cycles, l‟approche et les objectifs ainsi que la planification de la gestion d‟incidents;
o Démarrer la spécification, la préparation, l‟implémentation et l‟exécution des tests ainsi que surveiller et contrôler l‟exécution.
o Adapter le planning en fonction des résultats et de l‟avancement du test (parfois documenté dans un rapport d‟état d‟avancement) et entreprendre les actions nécessaires pour résoudre les problèmes
o Mettre en place une gestion de configuration adéquate du logiciel de test à des fins de traçabilité.
o Introduire des mesures appropriées pour mesurer l‟avancement du test et évaluer la qualité du test et du produit
o Décider ce qui devrait être automatisé, à quel degré et comment.
o Sélectionner les outils pour aider le test et organiser la formation des testeurs à l‟usage des outils.
o Décider de la mise en oeuvre de l‟environnement de test.
o Établir des rapports de synthèse de test à partir des informations recueillies pendant le test.
Les tâches habituelles des testeurs peuvent comprendre les suivantes :
o Passer en revue les plans du test et y contribuer.
o Analyser, passer en revue et évaluer, quant à leur testabilité, les exigences utilisateurs, les spécifications et les modèles.
o Créer des spécifications de test.
o Mettre en place l‟environnement de test (souvent en coordination avec l‟administration système et la gestion de réseau).
o Préparer et obtenir les données de test.
o Implémenter des tests à tous les niveaux, exécuter et consigner les tests, évaluer les résultats et documenter les écarts vis-à-vis des résultats attendus.
o Employer les outils d‟administration ou de gestion des tests et les outils de surveillance des tests en fonction du besoin.
o Automatiser les tests (éventuellement avec l‟aide d‟un développeur ou d‟un expert en automatisation de test).
o Mesurer les performances des composants et systèmes (si pertinent).
o Passer en revue les tests développés par d‟autres.
Les personnes travaillant sur l‟analyse, la conception des tests, sur des types de tests spécifiques ou l‟automatisation des tests peuvent être des spécialistes de ces rôles. Selon le niveau de test et les risques du projet ainsi que ceux du produit, des personnes différentes peuvent jouer le rôle de testeur, en gardant un certain niveau d‟indépendance. Typiquement, les testeurs au niveau du test de composants et d‟intégration seront des développeurs, ceux du test d‟acceptation seront des experts métier et des utilisateurs et ceux pour l‟acceptation opérationnelle seront des opérateurs.

5.2 Estimation et planification des tests (K3)

Termes
Approche de test, stratégie de test

5.2.1 Planification des tests (K2)
Cette section couvre l‟objectif de la planification du test dans des projets de développement et d‟implémentation ainsi que pour des activités de maintenance. La planification peut être documentée dans un plan de projet ou un plan de test maître ainsi que dans des plans de test séparés pour les niveaux de test, tels que le test système ou le test d‟acceptation. Le schéma des documents de planification de test est défini dans le guide « Standard for Software Test Documentation » (IEEE Std 829-1998).
La planification est influencée par la politique de test de l‟organisation, la portée du test, les objectifs, les risques, les contraintes, la criticité, la testabilité et la disponibilité des ressources. Au fur et à mesure de l‟avancement du projet et de la planification des tests, davantage d‟informations seront disponibles et davantage de détails pourront être inclus dans le plan.
La planification du test est une activité continue et est effectuée tout au long des processus et activités du cycle de développement. Le retour issu des activités de test est employé pour constater l‟évolution des risques et modifier alors la planification.

5.2.2 Activités de planification des tests (K3)
Les activités de la planification des tests pour un système ou pour une partie de celui-ci peuvent être:
o Définir le périmètre du test, les risques et identifier les objectifs du test
o Définir l‟approche générale du test (stratégie de test), y compris la définition des niveaux de test ainsi que celle des critères d‟entrée et de sortie.
o Intégrer et coordonner des activités de test dans les activités du cycle de développement : acquisition, fourniture, développement, exploitation et maintenance.
o Prendre des décisions quant à ce qui doit être testé, quels rôles vont exercer quelles activités, quand et comment ces activités doivent être exercées, comment évaluer les résultats des tests et quand arrêter les tests (critères de sortie).
o Planifier les activités d‟analyse et de conception des tests
o Planifier les activités de conception, d‟exécution et d‟évaluation des tests
o Assigner les ressources aux différentes tâches définies.
o Définir le volume, le niveau de détail, la structure et les modèles pour la documentation du test.
o Sélectionner des mesures pour suivre et contrôler la préparation et l‟exécution des tests, l‟élimination des défauts et la résolution des problèmes relatifs aux risques.
o Déterminer le niveau de détail pour les procédures de test de façon à fournir suffisamment de détails pour permettre une préparation et une exécution reproductibles des tests.

5.2.3 Critères d‟entrée (K2)
Les critères d‟entrée définissent quand démarrent les tests (par exemple quand débute un niveau de test, quand un jeu de test est prêt à être exécuté)
Typiquement, les critères d‟entrée peuvent couvrir:
o Disponibilité et préparation de l‟environnement de test
o Préparation des outils de tests dans l‟environnement de test
o Disponibilité de code testable
o Disponibilité des jeux de données

5.2.4 Critères de sortie (K2)
L‟objectif des critères de sortie est de définir quand arrêter le test, par exemple, à la fin d‟un niveau de test ou lorsqu‟une série de tests a atteint un objectif donné.
Typiquement, les critères de sortie peuvent comprendre les suivants :
o Des mesures d‟exhaustivité, comme la couverture de code, de fonctionnalités ou de risques.
o L‟estimation de la densité des anomalies ou des mesures de fiabilité.
o Le coût.
o Les risques résiduels, comme les anomalies non corrigées ou le manque de couverture du test dans certaines parties.
o Un calendrier, par exemple, basé sur la date de mise sur le marché.

5.2.5 Estimation des tests (K2)
Deux approches pour l‟estimation de l‟effort de test sont couvertes par le présent syllabus :
o Estimation de l‟effort de test basée sur des mesures issues de projets antérieurs ou similaires ou basée sur des valeurs typiques.
o L‟approche experte : estimation des tâches par le détenteur de ces tâches ou par des experts.
Une fois que l‟effort de test a été estimé, il est possible d‟identifier les ressources nécessaires et d‟établir un échéancier.
L‟effort de test peut dépendre d‟un certain nombre de facteurs, dont les suivants :
o Les caractéristiques du produit : la qualité des exigences et autres informations utilisées pour les modèles de test (c‟est-à-dire la base de test), la taille du produit, la complexité du domaine, les exigences de fiabilité et de sécurité ainsi que celles de la documentation.
o Les caractéristiques du processus de développement : la stabilité de l‟organisation, les outils employés, le processus de test, le savoir-faire des personnes impliquées et les contraintes de temps.
o Les résultats du tests : le nombre de défauts et le volume des reprises exigées.

5.2.6 Stratégie de test, Approche de test (K2)
L‟approche de test est la mise en oeuvre d‟une stratégie de test pour un projet spécifique. Elle est définie et affinée dans les plans et scénarii de test. Elle comprend typiquement les décisions basées sur le projet (de test), ses buts ainsi qu‟une analyse des risques. Elle constitue le point de départ pour la planification du processus de test, pour sélectionner les types et techniques de test qui seront appliqués ainsi que pour définir les critères d‟entrée et de sortie.
L‟approche sélectionnée dépend du contexte et peut prendre en considération les risques, la sécurité et les dangers, les ressources disponibles et leur niveau d‟expertise, la technologie et la nature du système (par exemple spécifique ou générique (COTS)), les objectifs, les normes et règlements en vigueur.
Les approches typiques peuvent comprendre:
o Une approche analytique, comme le test basé sur les risques où le test est focalisé sur les parties à plus haut risque.
o Les approches basées sur les modèles, comme le test stochastique qui utilise des informations statistiques sur les taux d‟erreurs (comme les modèles de croissance de fiabilité) ou sur l‟utilisation (comme les profils opérationnels).
o Les approches méthodiques, comme le test basé sur les erreurs (y compris l‟estimation d‟erreurs et l‟attaque par faute), basées sur des listes de vérification et sur des caractéristiques de la qualité.
o Des approches basées sur la conformité aux processus et normes, tels que ceux spécifiés par des normes industrielles spécifiques ou les diverses méthodes agiles.
o Les approches dynamiques et heuristiques, comme le test exploratoire où le test est plutôt réactif aux événements que planifié, et où l‟exécution et l‟évaluation sont des tâches parallèles.
o Les approches consultatives, comme celles où la couverture de test est principalement définie par les avis et le guidage d‟experts métier ou en technologie étrangers à l‟équipe de test.
o Les approches basées régression, comme celles qui comportent le réemploi de matériel de test existant, une automatisation extensive du test de régression fonctionnel et des suites de tests standard.
Différentes approches peuvent être combinées, par exemple, une approche dynamique basée sur les risques.

5.3 Suivi et contrôle du déroulement des tests (K2)

Termes
Densité de défauts, taux de défaillance, contrôle des tests, suivi des tests, rapport de test

5.3.1 Suivi de l‟avancement des tests (K1)
L‟objectif du suivi du test est de fournir un retour et une visibilité sur les activités de test. Les informations à suivre peuvent être recueillies manuellement ou automatiquement et peuvent être utilisées pour évaluer les critères de sortie, comme la couverture. Des mesures peuvent aussi être utilisées pour évaluer l‟avancement par rapport au calendrier et au budget planifiés. Les mesures de test habituelles sont:
o Le pourcentage du travail consacré à la préparation des cas de test (ou pourcentage des cas de test planifiés et préparés).
o Pourcentage du travail consacré à la préparation de l‟environnement de test.
o L‟exécution de cas de test (par exemple, nombre de cas de test exécutés ou non et nombre de cas de test réussis ou échoués).
o Les informations sur les défauts (par exemple, densité des défauts, défauts trouvés et corrigés, taux des défaillances et résultats du re-test).
o Couverture par le test des exigences, des risques ou du code.
o Confiance subjective des testeurs dans le produit.
o Dates des jalons du test.
o Coût du test, y compris le coût de l‟avantage de trouver le prochain défaut comparé à celui de l‟exécution du test suivant.

5.3.2 Reporting des tests (K2)
Le reporting des tests consiste à résumer les informations relatives à l‟entreprise du test ; il comprend les activités suivantes :
o Ce qui s‟est passé pendant une phase de test, comme les dates où les critères de sortie ont été atteints.
o Les informations et mesures analysées pour étayer les recommandations et décisions pour de futures actions, comme une évaluation des défauts restants, les avantages économiques de tests prolongés, les risques non couverts et le niveau de confiance dans le logiciel testé.
Le descriptif d‟un rapport de synthèse de test se trouve dans le guide « Standard for Software Test Documentation » (IEEE Std 829-1998).
Des mesures devraient être recueillies pendant et à la fin d‟un niveau de test dans le but d‟évaluer :
o L‟adéquation des objectifs du test avec ce niveau de test.
o L‟adéquation des approches du test empruntées.
o L‟efficacité du test par rapport à ses objectifs.

5.3.3 Contrôle des tests (K2)
Le contrôle du test décrit les actions d‟orientation et de correction entreprises comme résultat des informations et mesures recueillies et consignées. Ces actions peuvent couvrir toute activité de test et influencer toute autre activité ou tâche du cycle de vie logiciel.
Exemples d‟actions de contrôle des tests :
o Prendre des décisions sur la base des informations recueillies lors du suivi des tests
o Une nouvelle affectation de priorités aux tests en cas de mise en évidence d‟un risque identifié (par exemple, retard de livraison du logiciel).
o Une modification du calendrier de test en raison de la disponibilité d‟un environnement de test.
o Définition d‟un critère d‟entrée exigeant que des corrections soient testées par le développeur avant de les accepter dans une version.

5.4 Gestion de configuration (K2)

Termes
Gestion de configuration, contrôle de versions
Contexte
L‟objectif de la gestion de configuration est d‟établir et de maintenir l‟intégrité des produits (composants, données et documentation) du logiciel ou du système durant le cycle de vie du projet et du produit.
Pour le test, la gestion de configuration peut permettre d‟assurer que :
o Tous les éléments faisant partie du testware sont identifiés, sous contrôle de versions, que les changements sont identifiés et re-traçables, reliés les uns aux autres et aux éléments de développement (objets de test), de sorte que la traçabilité peut être maintenue pendant tout le processus du test.
o Tous les documents identifiés et les éléments du logiciel sont référencés de manière non ambiguë dans la documentation de test.
La gestion de configuration aide le testeur à identifier de manière unique (et à reproduire) l‟élément testé, les documents de test, les tests et le harnais de test.
Pendant la planification du test, les procédures et l‟infrastructure (outils) de la gestion de configuration devraient être choisis, documentés et implémentés.

5.5 Test et risques (K2)

Termes
Risques liés au produit, risques liés au projet, risques, test basé sur les risques
Contexte
Un risque peut être défini comme la probabilité qu‟un événement, un danger, une menace ou une situation arrive, et que les conséquences indésirables qui en découlent constituent un problème potentiel. Le niveau de risque sera déterminé par la probabilité qu‟un événement adverse arrive et par l‟impact de ce dernier (les dommages résultant de cet événement).

5.5.1 Risques liés au projet (K2)
Les risques liés au projet sont les risques menaçant la capacité de ce dernier à atteindre ses objectifs, tels que :
o Facteurs organisationnels :
 Manque de compétence et de formation du personnel ;
 Problèmes de personnel;
 Problèmes politiques, tels que
 problèmes dus au fait que des testeurs ne communiquent pas leurs besoins et les résultats du test ;
 incapacité à suivre les informations recueillies pendant le test et les revues (par exemple, ne pas améliorer les pratiques de développement et de test).
 Attitude ou attentes inappropriées vis-à-vis du test (par exemple, ne pas apprécier la valeur de la découverte de défauts durant le test).
o Problèmes techniques :
 Problèmes pour définir des exigences correctes ;
 La mesure selon laquelle les exigences seront satisfaites en fonction de contraintes existantes ;
 Environnement de test indisponible
 Conversion des données tardive ; planning de migration et de développement ; conversion des données de test / outils de migration
 Qualité de la conception, du code et des tests
o Problèmes d‟acquisition :
 Défaillance d‟une tierce partie ;
 Problèmes contractuels.
Pour analyser, gérer et diminuer ces risques, le gestionnaire de test suivra les principes bien établis de la gestion de projet. Le guide « Standard for Software Test Documentation » (IEEE Std 829-1998) pour le plan de test exige que les risques et contingences soient documentés..

5.5.2 Risques liés au produit (K2)
Les défaillances potentielles (événements futurs indésirables ou dangers) des parties du logiciel ou du système sont définies comme des risques liés au produit, puisqu‟elles représentent un risque pour la qualité du produit, comme :
o Livraison d‟un logiciel défectueux.
o Possibilité qu‟un logiciel ou système entraîne des dommages à des personnes ou à des entreprises.
o Caractéristiques logicielles de moindre qualité (par exemple, fonctionnalité, sécurité, fiabilité, utilisabilté et performances).
o Intégrité et qualité des données de faible qualité (par exemple en raison de problèmes liés à leur migration, à leur conversion, à leur transport, à un non respect des standards)
o Logiciel n‟offrant pas les fonctionnalités voulues.
Les risques sont employés pour décider quand commencer à tester et où tester davantage ; le test est utilisé pour réduire le risque qu‟un événement indésirable ne survienne ou pour réduire l‟impact de ce dernier.
Les risques relatifs au produit sont un type particulier de risque pour le succès d‟un projet. Le test, comme activité de contrôle des risques fournit un retour quant aux risques restants par la mesure de l‟efficacité de l‟élimination des défauts critiques et des plans de contingence.
Une approche des tests basée sur les risques fournit des possibilités proactives de réduire le niveau des risques relatifs au produit, en partant des premières étapes d‟un projet. Elle comprend l‟identification des risques liés au produit et de leur emploi comme guide pour la planification du test, la spécification, la préparation et l‟exécution des tests. Dans une approche basée sur les risques, les risques identifiés peuvent être utilisés pour :
o déterminer les techniques de test à employer,
o déterminer le volume du test à effectuer.
o définir les priorités à affecter aux tests dans le but de trouver les défauts critiques le plus tôt possible.
o déterminer si des activités ne faisant pas partie du test pourraient aider à réduire les risques (par exemple, une formation fournie aux développeurs inexpérimentés).
Le test basé sur les risques repose sur les connaissances et la compréhension collectives des acteurs d‟un projet pour déterminer les risques et les niveaux de test nécessaires pour couvrir ces derniers.
Pour s‟assurer que la probabilité de défaillance d‟un produit est minimisée, les activités de gestion des risques fournissent une approche disciplinée pour :
o estimer (et re-estimer régulièrement) ce qui peut faillir (les risques),
o déterminer quels sont les risques importants à couvrir,
o entreprendre des actions pour couvrir ces risques.
De plus, le test peut aider à identifier de nouveaux risques, à déterminer quels risques doivent être minimisés et à réduire l‟incertitude relative aux risques.

5.6 Gestion des incidents (K3)

Termes
Consignation d‟incidents, gestion des incidents, rapport d‟incidents
Contexte
Comme l‟un des objectifs du test est de découvrir des défauts, les différences entre les résultats attendus et les résultats effectifs doivent être consignées en tant qu‟incidents. Un incident doit être analysé et peut par la suite devenir un défaut. Des actions adéquates doivent être définies afin de traiter les incidents et les défauts. Les incidents et les défauts doivent être suivis depuis leur découverte et classification jusqu‟à leur correction et la confirmation de leur résolution. Pour pouvoir gérer tous les incidents jusqu‟à la fin d‟un projet, une organisation devrait établir un processus de gestion des incidents et des règles pour leur classification.
Les incidents peuvent survenir pendant le développement, les revues, le test ou l‟utilisation d‟un produit logiciel. Ils peuvent survenir en raison de problèmes dans le code, dans le système opérationnel ou dans tout type de documentation, notamment les documents de développement, les documents de test ou les informations destinées à l‟utilisateur tels que le manuel d‟utilisation ou le manuel d‟installation.
Les rapports d‟incidents peuvent avoir les objectifs suivants :
o Fournir aux développeurs et aux autres parties un retour sur le problème concerné pour en permettre l‟identification, la localisation et la correction nécessaires.
o Fournir aux responsables du test le moyen de suivre la qualité d‟un système sous test et l‟avancement du test.
o Fournir des idées pour l‟amélioration du processus de test.
Les détails du rapport d‟incident peuvent inclure:
o Date de l‟incident, organisation faisant part de l‟incident, auteur
o Résultats attendus et effectifs.
o Identification ou élément de configuration du logiciel ou système.
o Processus du cycle de vie du logiciel ou du système au cours duquel l‟incident a été observé
o Description de l‟anomalie pour permettre son élimination, y compris les traces, extraits de la base de données ou captures d‟écrans
o Degré de l‟impact sur les intérêts des détenteurs d‟enjeux.
o Sévérité de l‟impact sur le système.
o Urgence ou priorité de la correction.
o Etat de l‟incident (par exemple, ouvert, soumis, doublon, en attente de correction, corrigé en attente de test de confirmation, clôturé).
o Conclusions et recommandations.
o Problèmes globaux, comme d‟autres parties pouvant être impactées par une modification résultant de l‟incident.
o Historique des modifications, telles que la séquence des actions entreprises par des membres de l‟équipe du projet afin de localiser l‟incident, de corriger et d‟en confirmer la correction.
o Références, incluant l‟identité du cas de test ou la spécification qui a permis d‟identifier le problème
La structure d‟un rapport d‟incident est couverte par le guide « Standard for Software Test Documentation » (IEEE Std 829-1998).