Chapitre 5 : Gestion des tests

5.1 Organisation des tests

5.1.1 Indépendance des tests

Les degrés d'indépendance dans les tests:

• Pas de testeurs indépendants
• Des développeurs ou des testeurs indépendants au sein des équipes de développement oude l'équipe de
projet
• Des testeurs indépendants appartenant à l’organisation métier ou à la communautéd’utilisateurs, ou
spécialisés dans des types de tests spécifiques
• Des testeurs indépendants externes à l'organisation et qui travaillant soit sur site, soit horssite
➢ Les avantages de l'indépendance des tests:
• Les testeurs indépendants sont susceptibles de détecter des types de défaillances différents par rapport aux
développeurs en raison de leurs connaissances propres, de leursapproches techniques et de biais différents
• Un testeur indépendant peut vérifier, contester ou réfuter les hypothèses formulées par lesparties prenantes
au cours de la spécification et de l'implémentation du système
➢ Les inconvénients de l'indépendance des tests:
• Les testeurs peuvent être isolés de l'équipe de développement, ce qui entraîne un manque de collaboration,
des retards dans la communication des retours d'information àl'équipe de développement ou une relation
conflictuelle avec l'équipe de développement
• Les développeurs peuvent perdre le sens des responsabilités vis-à-vis de la qualité
• Les testeurs indépendants peuvent être considérés comme un goulot d'étranglement ou être rendus
responsables des retards dans la sortie de la version
• Les testeurs indépendants peuvent ne pas disposer de certaines informationsimportantes
5.1.2 Tâches d’un Test Manager et d’un testeur
➢ Les tâches du Test Manager :
• Lancer l'analyse, la conception, l'implémentation et l'exécution des tests, suivrel'avancement
et les résultats des tests, et vérifier le statut des critères de sortie
• Préparer et fournir des rapports d'avancement des tests et des rapports de synthèse destests à partir des
informations recueillies pendant le test
• Adapter la planification en fonction des résultats et de l’avancement des tests et prendretoutes les mesures
nécessaires au contrôle des tests
• Aider la mise en place du système de gestion des défauts et à la gestion adéquate de laconfiguration des
testware
• Introduire les métriques appropriées pour mesurer l’avancement des tests et évaluer laqualité des tests
et du produit
• Accompagner la sélection et la mise en œuvre des outils pour soutenir le processus de test, y compris
recommander le budget pour la sélection des outils, consacrer du temps et des ressources pour des projets
pilotes et apporter un accompagnement continu à l'utilisation du ou des outils
• Décider de l'implémentation du ou des environnements de test
• Développer les compétences et les carrières des testeurs
➢ Les tâches des testeurs :
• Revoir et contribuer aux plans de test
• Analyser, revoir et évaluer les exigences, les User Stories et les critères d'acceptation, les spécifications
et les modèles vis à vis de leur testabilité
• Identifier et documenter les conditions de test, et saisir la traçabilité entre les cas de test,les conditions de
test et les bases de test
• Concevoir, configurer et vérifier le ou les environnement(s) de test
• Exécuter des tests, évaluer les résultats et documenter les écarts par rapport aux résultatsattendus
• Automatiser les tests selon les besoins
• Évaluer les caractéristiques non-fonctionnelles
• Revoir des tests développés par d'autres

5.2 Planification et estimation des tests

5.2.1 Objet et contenu d'un plan de test

Les activités de planification des tests peuvent comprendre :

• Déterminer le périmètre, les objectifs et les risques des tests
• Définir l'approche générale des tests, y compris la définition des niveaux de test ainsi quecelle des critères
d’entrée et de sortie.
• Intégrer et coordonner les activités de test dans les activités du cycle de vie du logiciel
• Prendre des décisions sur ce qu'il faut tester, les personnes et les autres ressourcesnécessaires
• Planifier les activités d'analyse, de conception, d'implémentation, d'exécution etd'évaluation des
tests
• Sélectionner les métriques pour le pilotage et le contrôle des tests
• Budgéter les activités de test
• Déterminer le niveau de détail pour les procédures de test de façon à fournir suffisammentde détails pour
permettre une préparation et une exécution reproductibles des tests
5.2.2 Stratégie de test, Approche de test
➢ Les types de stratégies de test :
➢ Analytique : Stratégie de test est basé sur l'analyse d'un facteur. Le test basé sur lesrisques est
un exemple d'approche analytique
➢ Basée sur des modèles : Les tests sont conçus à partir d'un modèle d'un aspect requis duproduit, comme
une fonction, un processus métier, une structure interne ou une caractéristique non-fonctionnelle.
➢ Méthodique : Stratégie de test repose sur l'utilisation systématique d'un ensemble prédéfini de tests ou
de conditions de test, comme le test basé sur les erreurs (y comprisl’estimation d’erreurs et l’attaque par
faute)
➯ Conforme à un processus (ou conforme à une norme) : Stratégie de test implique
l'analyse, la conception et l'implémentation de tests basés sur des règles et normesexternes.
Dirigée (ou consultative) : Stratégie de test est dicté par les recommandations, les conseils ou les
instructions des parties prenantes, des experts du domaine métier ou desexperts techniques.
➢ Anti-régressions : Stratégie de test est motivé par le désir d'éviter la régression au niveau des
fonctionnalités existantes.
➢ Réactive : Les tests sont conçus et implémentés, et peuvent être exécutés en réponse aux informations
obtenues à partir des résultats de tests antérieurs.
5.2.3 Critères d'entrée et de sortie
Les critères d'entrée :
• Disponibilité d'exigences testables, de User Stories ou de modèles
• Disponibilité d'éléments de test qui ont satisfait aux critères de sortie pour tous les niveauxde test précédents
• Disponibilité de l'environnement de test
• Disponibilité des outils de test nécessaires
• Disponibilité des données de test et autres ressources nécessaires
Les critères de sortie habituels incluent :
• Les tests planifiés ont été exécutés
• Un niveau défini de couverture a été atteint
• Le nombre de défauts non résolus est limité à ce qui a été défini
• Le nombre estimé de défauts restants est suffisamment faible
Les niveaux évalués de fiabilité, de performance, d'utilisabilité, de sécurité et autrescaractéristiques
qualité pertinentes sont suffisants
5.2.4 Calendrier d'exécution des tests

- Une fois que les différents cas de test et procédures de test sont produits et assemblés en
suites de test, les suites de test peuvent être organisées selon un calendrier d'exécution destests qui définit l'ordre
dans lequel elles doivent être exécutées.
- Idéalement, les cas de test devraient être exécutés en fonction de leur niveau de priorité,généralement en
exécutant en premier les cas de test ayant la priorité la plus élevée.
- Si un cas de test avec une priorité plus élevée dépend d'un cas de test avec une priorité plusfaible, le cas de
test de priorité plus faible doit être exécuté en premier.
5.2.5 Facteurs influençant l'effort de test
Les facteurs qui influencent l'effort de test:.
➢ Caractéristiques du produit
• Les risques associés au produit
• La qualité des bases de test
• La taille du produit
• La complexité du domaine métier du produit
• Les exigences relatives aux caractéristiques de qualité
• Le niveau de détail requis pour la documentation des tests
• Les exigences en matière de conformité juridique et réglementaire
➢ Caractéristiques du processus de développement
• La stabilité et la maturité de l'organisation
• Le modèle de développement utilisé
• L'approche de test
• Les outils utilisés
• Le processus de test
• La pression des délais
➢ Caractéristiques liées aux personnes
• Les compétences et l'expérience des personnes impliquées, en particulier avec des projetset des produits
similaires
• La cohésion et le leadership de l'équipe
➢ Résultats des tests
• Le nombre et la sévérité des défauts trouvés
• La quantité nécessaire de travail à refaire
5.2.6 Techniques d'estimation des tests

➢ Les techniques sont:

➢ La technique basée sur les métriques : estimer l'effort de test sur la base de métriquesd'anciens projets
similaires ou sur la base de valeurs représentatives
➢ La technique basée sur l'expertise : estimation de l'effort de test sur la base del'expérience des
responsables des tâches de test ou par des experts
5.3 Pilotage et contrôle des tests

- Le but du pilotage des tests est de recueillir des informations et de fournir un retour et de
la visibilité sur les activités de test.
- Le contrôle des tests décrit toutes les mesures correctives ou d'orientation prises à la suitede l'information
et des métriques recueillies et rapportées.
- Les actions peuvent couvrir toutes les activités de test et peuvent affecter toute autreactivité du cycle
de vie du logiciel.
➢ Exemples d'actions de contrôle des tests :
• Re-prioriser les tests lorsqu'un risque identifié se produit
• Modifier le calendrier des tests en raison de la disponibilité ou de l'indisponibilité d'unenvironnement
de test ou d'autres ressources
• Réévaluer si un élément de test répond à un critère d'entrée ou de sortie à cause d'unemodification
5.3.1 Métriques utilisées pour les tests
➢ Les métriques de test les plus courantes:
• Pourcentage du temps de travail prévu réalisé pour la préparation des cas de test
• Pourcentage du travail prévu réalisé pour la préparation de l'environnement de test
• Exécution des cas de test
• Informations sur les défauts
• Couverture des exigences, des User Stories, des critères d'acceptation, des risques ou ducode par les tests
• Degré d'achèvement des tâches, affectation et utilisation des ressources, et temps passé
5.3.2 Buts, contenu et destinataires des rapports de test

Le but du rapport de test est de synthétiser et de communiquer les informations sur l’activité de test, à la fois,
pendant et à la fin d'une activité de test
➢ Les rapports de test peuvent inclure :
Le rapport de test préparé pendant une activité de test peut être appelé rapport
d’avancement de test, tandis qu'un rapport de test préparé à la fin d'une activité de testpeut être appelé rapport
de synthèse de test.
➯ Les rapports d'avancement de test peuvent inclure :
• Le statut des activités de test et l’avancement par rapport au plan de test
• Les facteurs qui freinent l'avancement
• Les tests prévus pour la prochaine période de suivi
• La qualité de l'objet de test
Lorsque les critères de sortie sont atteints, le Test Manager fournit le rapport de synthèse detest. Ce rapport
fournit un résumé des tests réalisés, sur la base du dernier rapport d’avancement de test et de toute autre
information pertinente.
5.4 Gestion de configuration
Le but de la gestion de la configuration est d'établir et de maintenir l'intégrité du composant
ou du système, du testware et de leurs relations mutuelles tout au long du cycle de vie duprojet et du produit
➢ Pour supporter correctement les tests, la gestion de la configuration peut impliquer de s'assurer de
:
- Tous les éléments de test sont identifiés de façon unique, versionnés, suivis pour leschangements
et reliés les uns aux autres
- Tous les éléments du testware sont identifiés de manière unique, versionnés, suivis pour leschangements,
liés les uns aux autres et liés aux versions des éléments de test afin que la traçabilité puisse être maintenue
tout au long du processus de test
- Tous les documents et logiciels identifiés sont référencés sans ambiguïté dans ladocumentation
de test
5.5 Risques et tests

5.5.1 Définition du risque

- Le risque implique la possibilité d'un événement futur qui a des conséquences négatives.
- Le niveau de risque est déterminé par la probabilité de l’événement et son impact
5.5.2 Risques produit et risques projet

Risques liés au produit

- Le risque produit implique la possibilité qu'un produit d’activités puisse ne pas satisfaire lesbesoins de ses
utilisateurs ou parties prenantes.
- Lorsque les risques produits sont associés à des caractéristiques de qualité spécifiques d'unproduit.
➢ exemples de risques produit
• Le logiciel peut ne pas remplir les fonctions attendues selon la spécification ou les besoinsde l'utilisateur,
du client et/ou des parties prenantes
• Une architecture système peut ne pas répondre de manière adéquate à certainesexigences non-
fonctionnelles
• Un traitement particulier peut être effectué de manière incorrecte dans certainescirconstances
• Une structure de contrôle de boucle peut être mal codée
• Les délais de réponse peuvent être insatisfaisants pour un système de traitement destransactions à
haut niveau de performance
• L'expérience utilisateur pourrait ne pas satisfaire les attentes pour le produit
Risques liés au projet
- Le risque projet implique des situations qui, si elles se produisent, peuvent avoir un effet négatif sur la
capacité d'un projet à atteindre ses objectifs
➢ exemples de risques projet
❖ Problèmes liés au projet :
• Des retards peuvent se produire dans la livraison, l'achèvement des tâches ou lasatisfaction des
critères de sortie ou de la définition du terminé
• Des estimations erronées, la réaffectation de ressources à des projets plus prioritaires ouune réduction
générale des coûts dans l'ensemble de l'organisation peuvent entraîner unfinancement inadéquat
• Des changements tardifs peuvent entraîner un travail supplémentaire important
❖ Problèmes organisationnels :
• Les compétences, la formation et le nombre de personnes peuvent ne pas être suffisants
• Les problèmes personnels peuvent causer des conflits et des problèmes
• Les utilisateurs, les personnes du métier ou les experts du domaine peuvent ne pas êtredisponibles en
raison de priorités contradictoires
❖ Problèmes politiques :
• Les testeurs peuvent ne pas communiquer leurs besoins ou les résultats des tests demanière adéquate
• Les développeurs ou les testeurs peuvent ne pas assurer le suivi des informations trouvéesdans les tests et
les revues
• Il peut y avoir une attitude ou des attentes erronées vis-à-vis des tests
❖ Questions techniques :
• Les exigences peuvent ne pas être suffisamment bien définies
• Les exigences peuvent ne pas être satisfaites, compte tenu des contraintes existantes
• L'environnement de test peut ne pas être prêt à temps
• La conversion des données, la planification de la migration et leur outillage peuvent êtreen retard
• Les faiblesses dans le processus de développement peuvent avoir un impact sur lacohérence ou la
qualité des produits d’activités du projet
• Une mauvaise gestion des défauts et des problèmes similaires peut entraîner uneaccumulation de
défauts et d'autres dettes techniques
❖ Problèmes liés aux fournisseurs :
• Ne pas livrer un produit ou un service nécessaire
• Des problèmes contractuels peuvent causer des difficultés au projet
5.6 Gestion des défauts
➢ Les rapports de défauts ont les objectifs :
• Fournir aux développeurs et aux autres intervenants de l'information sur tout événement indésirable
survenu
• Fournir aux Test Managers un moyen de suivre la qualité du produit d’activités testé etl'impact sur les
tests
• Fournir des idées pour le développement et l'amélioration du processus de test
➢ Un rapport de défaut comprend:
• Un identifiant
• Un titre et un bref résumé du défaut signalé
• La date du rapport de défaut, l'organisation émettrice et l'auteur
• L'identification de l'élément de test et de l'environnement
• La ou les phases du cycle de développement au cours desquelles le défaut a été observé
• Une description du défaut pour permettre la reproduction et la résolution
• Les résultats attendus et obtenus
• La portée ou le degré d'impact du défaut pour les parties prenantes concernées
• Urgence/priorité de la correction
• L'état du rapport de défaut
• Les conclusions, recommandations et approbations
• L'historique des modifications
• Les références