Testeur certifié ISTQB v4.

0
Résumé du Conseil international des qualifications pour les tests de
logiciels

Zied HANNACHI
1.1. Qu’est-ce que le test logiciel ?

• Le mauvais fonctionnement d’un logiciel peut entraîner de graves pertes financières, voire des risques de sécurité.

• Les tests logiciels sont un processus visant à rechercher des bogues et à améliorer la qualité d'un logiciel.

• Le processus de test vérifie non seulement si le logiciel fonctionne, mais également les besoins de
l'utilisateur.

• Les tests logiciels peuvent être dynamiques (exécution du logiciel) ou statiques (analyse et révision).

• Les testeurs utilisent non seulement des outils, mais aussi des compétences intellectuelles et
analytiques.
1.1.1. Cibles de test

• Évaluez les exigences, les conceptions et le code.

• Trouver des défauts et corriger les erreurs.

• Assurer la couverture des tests.

• Réduire le risque de ne pas répondre aux critères de qualité.

• Vérifier l'exactitude et la conformité des exigences.

• Fournir des informations précises aux parties prenantes et instaurer la confiance.

• S'assurer que le produit fonctionne complètement et selon les attentes.

Les objectifs des tests peuvent varier en fonction de facteurs tels que le produit testé, le niveau de test, les risques et le processus de développement logiciel suivi. De plus, des facteurs
commerciaux tels que la structure organisationnelle, les facteurs concurrentiels et les délais de mise sur le marché peuvent également affecter les objectifs de test.
1.1.2. Test et débogage de logiciels

• Les tests et le débogage sont des activités différentes.

• Les tests dynamiques peuvent déclencher des échecs causés par des bugs dans le
logiciel ou détecter directement des bugs.

• Le processus de débogage consiste à rechercher, analyser et éliminer les causes

des dysfonctionnements.

• Le processus de débogage consiste généralement à reproduire le défaut, à

le diagnostiquer et à corriger la cause.

• Des tests de validation sont effectués pour vérifier si les correctifs

résolvent le problème.

• Les tests de confirmation sont de préférence effectués par la même personne qui a effectué
les tests initiaux.

• Les tests statiques s'occupent du débogage lorsqu'ils trouvent un bug et trouvent directement les bugs. Aucune reconstruction
ou diagnostic requis.
1.2. Pourquoi les tests logiciels sont-ils nécessaires ?

• Le processus de test garantit la réalisation des objectifs

préalablement convenus dans les limites spécifiées en
matière de portée, de temps, de qualité et de budget.

• Ce succès ne se limite pas à l’équipe de test ; Chaque partie

prenante peut soutenir le projet en utilisant ses propres
compétences en matière de tests. Les composants de test et la
documentation associée aident à identifier les bogues dans le
logiciel.
1.2.1. Contribution des tests logiciels au succès

• Le processus de test garantit que les défauts sont détectés de manière

rentable.

• Les défauts trouvés peuvent être corrigés pour contribuer à des objets
de test de meilleure qualité.

• Le processus de test offre la possibilité d'évaluer directement la

qualité du logiciel à différentes étapes.

• Les tests contribuent aux processus décisionnels dans le cadre de la

gestion de projet.

• Les tests fournissent une représentation indirecte des utilisateurs.

• Les tests logiciels sont également nécessaires pour répondre aux exigences contractuelles ou légales.
1.2.2. Tests et assurance qualité (AQ)

• Les tests et l’assurance qualité (AQ) sont des concepts différents.

• Les tests sont une forme de contrôle qualité (CQ) et représentent une approche corrective axée sur le produit.

• Le contrôle de la qualité se concentre sur les activités qui contribuent à atteindre des niveaux de qualité appropriés.

• Les tests sont un élément important du contrôle qualité et peuvent inclure des méthodes formelles, la simulation et le prototypage.

• L’assurance qualité (AQ) est une approche préventive et axée sur les processus.

• L'assurance qualité se concentre sur la mise en œuvre et l'amélioration des processus, aboutissant à un bon produit.

• Il s'applique à la fois aux processus de développement et de test de logiciels et relève de la responsabilité de toutes les personnes participant au projet.

• Les résultats des tests sont utilisés dans les processus de contrôle qualité et d’assurance qualité.

• Bien que les résultats des tests soient utilisés pour corriger les erreurs au cours du processus de contrôle qualité, ils fournissent des informations sur les performances des

processus de développement et de test de logiciels au cours du processus d'assurance qualité.

1.2.3. Erreurs humaines, erreurs, dysfonctionnements et causes profondes

• Les gens font des erreurs, ce qui peut provoquer des bogues logiciels et éventuellement conduire à un échec.

• Des erreurs peuvent survenir pour de nombreuses raisons, notamment la pression du temps, la complexité de l'entreprise, les processus, l'infrastructure ou la communication.

• Des erreurs peuvent être trouvées dans la documentation, le code source ou le fichier de build.

• Les erreurs détectées au début des produits peuvent conduire à des produits défectueux dans les étapes ultérieures.

• Une erreur peut provoquer un comportement inattendu dans le système.

• Les erreurs humaines et logicielles ne sont pas les seules causes de dysfonctionnements ; Les conditions environnementales peuvent également l'affecter.

• La cause première est la principale raison pour laquelle un problème survient et est déterminée par l’analyse des causes profondes.

• L'élimination de la cause première garantit que des dysfonctionnements ou des erreurs similaires peuvent être évités ou réduits en
fréquence.
1.3. Principes de test

• Objectif de l'épreuve :Le but des tests est de montrer la présence de bugs dans le logiciel. Cependant, aucun test ne peut détecter tous les bugs dans
un logiciel ou prouver qu’il n’y a pas de bugs. Les tests réduisent la probabilité qu'il reste des bogues non découverts, mais ne garantissent pas une
absence totale de bogues.

• Test à 100 % impossible :Il n'est souvent pas possible de tester tous les éléments logiciels. Une plus grande efficacité peut être obtenue grâce aux tests en
utilisant des stratégies telles que des techniques de test, la priorisation des scénarios de test et une approche de test basée sur les risques.

• Tests précoces :La détection des erreurs dès les premières étapes permet d'économiser du temps et de l'argent. Les bogues détectés tôt
rendent le logiciel moins susceptible d'échouer dans les étapes ultérieures.

• Domaines où les erreurs se concentrent :Les erreurs trouvées sont généralement concentrées dans certains composants du système. Il s’agit d’un critère
important pour les tests basés sur les risques.

• Résistance aux antibiotiques:Au fur et à mesure que les mêmes tests sont répétés, l’efficacité de la recherche de nouveaux bugs diminue. Les tests et les
données de test devront peut-être être modifiés pour éviter cette situation.

• Les tests varient en fonction du contexte :Les tests varient en fonction du contexte et des conditions du projet. Il n’existe pas d’approche de test unique
universellement applicable.

• Idées fausses :Tester méticuleusement toutes les exigences et résoudre toutes les erreurs trouvées ne signifie pas que vous obtiendrez un logiciel
performant. Les tests servent uniquement à vérifier un n Cela devrait également inclure la garantie d’un bon ordre.
1.4. Activités de test, logiciels de test et rôles de test

• Le processus de test peut être personnalisé en fonction de la situation spécifique et la

planification des tests détermine quelles activités de test seront incluses, comment elles
seront mises en œuvre et quand elles seront effectuées.

• Les groupes généraux d'activités de test qui composent le processus de test augmentent la probabilité

d'atteindre les objectifs de test.

• Le processus de test est déterminé en fonction de divers facteurs, et des sources telles que la

norme ISO/IEC/IEEE 29119-2 fournissent des informations supplémentaires.

• Des aspects généraux tels que les activités et tâches de test, l'influence du contexte, le logiciel de test, la traçabilité entre la base de test et le logiciel de
test et les rôles de test sont décrits.
1.4.1. Activités et tâches de test

Le processus de test comprend généralement les principaux groupes d'activités suivants, et ces activités peuvent être répétées ou mises en œuvre en
parallèle :

1. Planification des tests: Détermination des cibles de test et choix du meilleur mode de transport.

2. Surveillance et contrôle des tests: Surveiller toutes les activités de test et comparer ce qui était prévu avec ce qui s'est passé.

3. Analyse des tests: Définir les fonctionnalités testables, déterminer et prioriser les conditions de tests.

4. Conception des tests: Détaillant les conditions de test sous forme de scénarios de test et d'autres logiciels de test.

5. Tester l'adaptation: Créer ou obtenir le logiciel de test nécessaire pour l'exécution du test.

6. Test du harnais: Exécution de tests selon le calendrier d'exécution des tests, manuellement ou automatiquement.

7. Achèvement des tests: Gestion des erreurs non résolues, fermeture de l'environnement de test et création d'un rapport de fin
de test.

Ces activités permettent d'adapter le processus de test à une situation spécifique et des décisions peuvent être prises dans le cadre de la
planification des tests.
1.4.2. Processus de test dans le contexte du projet

Les tests font partie intégrante des processus de développement logiciel effectués au sein de l'organisation et sont
financés par les parties prenantes du projet.

La manière dont les tests sont effectués dépend de nombreux facteurs contextuels, notamment :

1. Parties prenantes: Besoins, attentes, exigences, désir de coopération, etc.

2. Membres de l'équipe: Compétences, connaissances, niveau d’expérience, disponibilité, besoins de formation, etc.

3. Domaine d'activité de l'institution: Niveau de criticité de l'objet de test, risques identifiés, besoins du
marché, réglementations légales, etc.

4. Facteurs techniques: Type de logiciel, architecture du produit, technologie utilisée, etc.

5. Contraintes du projet: Portée, délai, budget, ressources, etc.

6. Facteurs organisationnels: Structure organisationnelle, politiques actuelles, pratiques utilisées

7. Cycle de vie du développement logiciel: Pratiques d'ingénierie, méthodes de développement, etc.

8. Outils: Commodité, convivialité, compatibilité, etc.

Ces facteurs influencent les questions liées aux tests telles que la stratégie de test, les techniques de test utilisées, le degré d'automatisation des tests, le niveau de couverture requis, le niveau
de détail de la documentation des tests, les rapports, etc.
1.4.3. Logiciel de test

• Un logiciel de test est créé dans le cadre des produits de travail résultant d’activités de test spécifiques.
• Différentes organisations peuvent utiliser différentes approches pour produire, façonner, nommer, organiser et
gérer les produits du travail.
• Une gestion appropriée de la configuration garantit la cohérence et l’intégrité des produits de travail.
• Les produits de travail peuvent inclure :
1. Planification des tests: Plan de test, calendrier des tests, registre des risques, critères d'entrée et de sortie.

2. Supervision et contrôle des tests: Rapports d'avancement des tests, documentation des directives de contrôle, informations sur les risques.

3. Analyse des tests: Conditions de test, rapport de bug.

4. Conception des tests :Cas de test, chartes de test, éléments de portée, exigences en matière de données de test, exigences en matière

d'environnement de test.
5. Adaptation des tests :Procédures de test, scripts de test automatisés, groupes de test, données de test, calendrier d'exécution des tests, éléments de

l'environnement de test.

6. Test :Journaux de tests, rapports de bugs.

7. Achèvement du test :Rapport d'achèvement des tests, éléments d'action, expériences, demandes de modification.
1.4.4. Traçabilité entre la base de test et le logiciel de test

• La traçabilité est importante pour rendre la surveillance et le contrôle des tests efficaces.

• Les éléments de base de test fournissent la relation entre le logiciel de test, les résultats des tests et les erreurs détectées.

• Il prend en charge l'évaluation de la couverture et facilite le suivi des critères de couverture mesurables.

• Par exemple, la traçabilité des scénarios de test par rapport aux exigences peut aider à vérifier dans quelle mesure les tests
répondent aux exigences.

• Une bonne traçabilité facilite l’évaluation de la couverture ainsi que l’analyse d’impact, les audits de tests et le respect des exigences de
gouvernance informatique.

• Il facilite également la compréhension des rapports d'avancement et d'achèvement des tests et aide à communiquer clairement les
aspects techniques des tests aux parties prenantes.

• La traçabilité fournit des informations importantes pour évaluer la qualité des produits, la capacité des processus et l'avancement du projet par rapport aux

objectifs commerciaux.
1.4.5. Rôles dans le processus de test

1. Deux rôles essentiels dans le programme de tests :

il Rôle de gestion des tests

il Rôle de test

2. Rôle de gestion des tests :

il Responsable de la gestion et de la supervision du processus de tests.

il En particulier la planification, la supervision et le contrôle des tests, ainsi que l'achèvement des tests.

se concentre sur ses activités.

il La manière dont elle est réalisée dépend du contexte du projet, des compétences de l’équipe et de l’organisation.

varie en fonction

3. Rôle de test :

il Responsable des aspects techniques du test.

il Il se concentre principalement sur les activités d’analyse, de conception, d’adaptation et de mise en œuvre des tests.

4. Changement de responsabilités :

il Différentes personnes peuvent assumer la responsabilité des rôles.

il La même personne peut assumer à la fois les rôles de test et de gestion des tests.
1.5. Compétences requises et bonnes pratiques dans le processus de test
1.5.1. Compétences générales requises dans le processus de test

1. Compétences importantes :

il Connaissance des tests (activité utilisant des techniques de tests) Minutie,

il attention, curiosité, souci du détail (pour trouver les erreurs difficiles)

il Bonne communication, écoute active, travail d'équipe (communication efficace avec les parties

il prenantes) Pensée analytique et critique, créativité (pour des tests efficaces)

il Connaissances techniques et du domaine (pour l'efficacité des tests)

2. Importance des compétences en communication :

il Il ne faut pas oublier que les résultats des tests peuvent être perçus comme une critique du produit.

il Les compétences en communication facilitent l’acceptation des résultats des tests et évitent les biais de confirmation. Les erreurs et les

il dysfonctionnements doivent être communiqués de manière constructive et il convient de souligner qu'ils contribuent au projet et au produit.
1.5.2. Approche d’équipe entière

• Compétence en travail d'équipe :

il L’une des compétences clés des testeurs est la capacité à travailler efficacement en équipe
et à contribuer positivement aux objectifs de l’équipe.

il L'approche globale de l'équipe, issue de la méthodologie Extreme Programming, met l'accent sur cette

compétence.

• Approche d’équipe entière :

il Dans cette approche, tous les membres de l’équipe possèdent les connaissances et compétences nécessaires et chacun est

responsable de la qualité.

il L'espace de coworking facilite la communication, augmente la communication d'équipe et permet à différents

ensembles de compétences de créer une synergie.

• Rôle des testeurs :

il Les testeurs visent à atteindre les niveaux de qualité souhaités en travaillant en étroite collaboration avec les autres membres de l'équipe.

il Ils effectuent des tâches telles que la création de tests d'acceptation avec les unités commerciales et la détermination de la stratégie de test et des méthodologies d'automatisation avec les développeurs de logiciels. Les

il testeurs jouent un rôle important en transférant leurs connaissances aux autres membres de l’équipe et en contribuant au développement des produits.

• Adaptabilité au contexte :
il Une approche d’équipe globale n’est pas toujours appropriée ; En particulier dans certaines situations sensibles pour la sécurité, un degré élevé d'indépendance des tests peut être requis.
1.5.3. Indépendance des tests

• L'indépendance permet aux testeurs d'être efficaces dans la recherche de bogues, mais elle ne remplace pas la familiarité.

• Les produits de l’étude peuvent être testés par des personnes ayant différents niveaux d’indépendance.

• Les testeurs indépendants sont plus à même de trouver divers bugs en raison de leurs différentes expériences et perspectives.

• Cependant, il peut également y avoir des inconvénients tels que des comportements différents et des problèmes de communication.
2. Tests tout au long du cycle de vie du développement logiciel
2.1. Tests dans le contexte du cycle de vie du développement logiciel

• Le cycle de vie du développement logiciel (DDD) est considéré comme une représentation générale du processus de développement logiciel.

• Les modèles YGYD montrent les relations logiques et chronologiques entre les différentes étapes de développement et types d'activités.

• Des exemples de modèles YGYD sont : modèle en cascade, modèle en V, modèle en spirale, prototypage, processus unifié.

• Les activités du processus de développement logiciel peuvent être définies avec des méthodes de développement logiciel et des pratiques Agile

plus détaillées.

• Exemples : développement logiciel basé sur les tests d'acceptation (ATDD), développement logiciel basé sur le comportement (BDD), conception basée sur

le domaine (DDD), programmation extrême (XP), développement basé sur les fonctionnalités (FDD), Kanban, Lean IT, Scrum, et le développement piloté par

les tests (TDD).

2.1.1. Impact du cycle de vie du développement logiciel sur les tests

• Pour que les tests réussissent, ils doivent être adaptés à YGYD. YGYD

il Portée et calendrier des activités de test Niveau de

il détail de la documentation de test Sélection des

il techniques et de l'approche de test Portée de

il l'automatisation des tests

il Rôles et responsabilités du testeur

• Dans les modèles de développement logiciel séquentiel, les testeurs e, tester

Participe à l’analyse et à la conception des tests. Les tests dynamiques sont généralement effectués à des étapes ultérieures.

• Dans certains modèles de développement itératif et incrémentiel, chaque cycle fournit un prototype fonctionnel ou une fonctionnalité de produit. Cela
signifie que des tests statiques et dynamiques peuvent être effectués à chaque cycle.

• Dans le développement de logiciels agiles, il est préférable d’alléger la documentation des produits de travail et d’utiliser une automatisation poussée des tests.

Les tests manuels sont effectués à l'aide de techniques de test basées sur l'expérience et ne nécessitent pas d'analyse ni de conception de tests préalables

approfondies.
2.1.2. Cycle de vie du développement logiciel et bonnes pratiques de test

• Chaque activité de développement logiciel est accompagnée d'une activité de test, de sorte que l'ensemble du processus de développement soit soumis à un contrôle

qualité.

• Différents niveaux de tests ont des objectifs de test spécifiques et différents, évitant ainsi les duplications inutiles lors de la réalisation de tests

complets.

• L'analyse et la conception des tests commencent au stade de développement correspondant du YGYD pour un niveau de test spécifique, de sorte que les tests soient

effectués conformément au principe des tests précoces.

• Les testeurs sont impliqués dans l'examen des produits de travail dès que les ébauches de la documentation sont prêtes, soutenant ainsi
la stratégie « shift-left » de tests précoces et de détection des bogues.
2.1.3. Les tests comme facteur de développement logiciel

• TDD (développement logiciel piloté par les tests) :

il Les scénarios de test déterminent le codage ; les tests sont écrits en premier, pas le code en

il premier. Les tests sont écrits, puis le code est écrit et enfin les tests et le code sont édités.

• ATDD (développement logiciel piloté par les tests d'acceptation) :

il À partir des critères d'acceptation, des tests sont dérivés et effectués dans le cadre de la conception du système. Les

il tests sont d’abord écrits, puis le codage est effectué.

• BDD (développement logiciel piloté par le comportement) :

il Le comportement souhaité de l’application est exprimé dans des cas de tests simples en langage naturel.

il Les scénarios de tests sont automatiquement convertis en tests exécutables.

Dans toutes ces approches, les tests restent des tests automatisés pour garantir la qualité du code dans les futurs processus
d'adaptation et de refactorisation.
2.1.4. DevOps et tests

• DevOps vise à permettre aux équipes de développement logiciel et d'exploitation de travailler ensemble.

• Cela nécessite un changement organisationnel et prend en charge des éléments culturels tels que l’autonomie de l’équipe et un feedback rapide.

• Les pratiques techniques incluent l'intégration continue (CI) et la livraison continue (CD). Avantages
du point de vue des tests :

• Retour rapide et impact positif sur la qualité du code.

• Promouvoir l’approche shift-left et créer des environnements de test stables.

• Prise en charge des processus automatisés et visibilité accrue des exigences non fonctionnelles.

• Réduire le risque de régression grâce à des tests de régression

automatisés. défis:

• La nécessité de définir et d’établir un pipeline de livraison DevOps.

• Présentation et maintenance des outils CI/CD.
• L’automatisation des tests nécessite des ressources supplémentaires et est difficile à mettre en place.

Malgré un niveau élevé d'automatisation des tests, des tests manuels peuvent encore être nécessaires du point de vue de l'utilisateur.
2.1.5. Approche Shift-Gauche

• Le principe du « test précoce », met en évidence les tests effectués au début de YGYD et parfois
"shift-gauche"On l'appelle.

• Shift-left encourage les tests plus tôt, mais ne signifie pas négliger les tests
à des stades ultérieurs.
Il existe quelques bonnes pratiques pour garantir le décalage à gauche :

1. Examen de l'analyse du point de vue des tests.

2. Rédaction de scénarios de test avant d'écrire le code et d'exécuter le code dans une incubation
de test.

3. Utilisation de CI ou même de CD.

4. Achèvement de l'analyse statique du code source.

5. Effectuer des tests non fonctionnels à partir du niveau de test des composants.
• Le déplacement vers la gauche peut nécessiter une formation, des efforts et des coûts supplémentaires au début du processus, mais peut permettre d'économiser de l'argent dans les étapes ultérieures.

• Il est important que les parties prenantes soient convaincues de l’approche du virage à gauche et croient en ce concept.
2.1.6. Rétroactifs et amélioration des processus

• Éléments rétrospectifs :
il Il est traité à la fin du projet ou du cycle, au moment de la sortie ou selon les besoins.

il Son timing et son organisation dépendaient du modèle YGYD suivi.

• Contenu de la réunion :

il Les succès et les échecs sont discutés.

il Les questions sur la manière dont la durabilité et l'amélioration peuvent être réalisées sont abordées.

• Enregistrement des résultats :

il Il fait généralement partie du rapport de fin de test.

• Avantages:

il Efficacité et efficience des tests plus élevées.

il Qualité supérieure du logiciel de test.

il Création de liens d'équipe et apprentissage.

il Qualité de base de test supérieure.

il Meilleure collaboration entre le développement et les tests.

2.2. Niveaux de test et types de tests

• Niveaux de test :

il Il s'agit de groupes d'activités de test pendant les étapes de développement logiciel.

il Ce sont des exemples de processus de test effectués depuis des composants individuels jusqu'à des systèmes complets.

• Liens:
il Il est associé à d’autres activités au sein de YGYD.

il Dans les modèles YGYD séquentiels, des critères de sortie et d’entrée sont définis.

• Activités de développement:

il Peut couvrir plusieurs niveaux de tests. Cela peut se

il chevaucher au fil du temps.

• Types d'essais :

il Il s'agit de groupes d'activités de test liées aux exigences. Ils peuvent

il être effectués à n’importe quel niveau de test.

2.2.1. Niveaux de test

• Tests de composants (tests unitaires) :

il Il se concentre sur le test des composants séparément.

il Cela est généralement réalisé par les développeurs dans leurs propres environnements.

• Tests d'intégration de composants (tests d'intégration unitaires) :

il Teste les interactions entre les interfaces et les composants.
il Selon la stratégie d'intégration, des approches telles que bottom-up, top-down ou big-bang peuvent être utilisées.
• Test du système :
il Il se concentre sur le comportement global et les capacités du système.

il Il comprend des tests fonctionnels et non fonctionnels des tâches de bout en bout.
• Tests d'intégration du système :
il Il teste les interfaces du système testé avec d'autres systèmes et services externes. Cela nécessite des

il environnements de test appropriés similaires à l’environnement opérationnel.

• Test d'admission:
il Il vise à montrer que le système est prêt à être présenté à l'utilisateur.
il Elle est réalisée par les utilisateurs.
• Liste utilisée pour séparer les niveaux de test :
il objet de test
il Cibles de test
il Base de test

il Erreurs et dysfonctionnements

il Approche et responsabilités
2.2.2. Types de tests

• Tests fonctionnels :
il Il évalue les fonctions que le composant ou le système doit remplir. L'objectif

il principal est de vérifier l'intégrité fonctionnelle, l'exactitude et la conformité.

• Tests non fonctionnels :

il Évalue les fonctionnalités autres que les exigences fonctionnelles.

il L'objectif principal est de contrôler les exigences non fonctionnelles telles que les performances, la compatibilité, la convivialité, la fiabilité, la sécurité, la
maintenabilité et la portabilité.

• Tests de boîte noire :

il Il est basé sur des exigences et obtient des tests en regardant de l'extérieur.

il L’objectif principal est de contrôler le comportement du système par rapport aux exigences.

• Tests en boîte blanche :

il Il est basé sur la structure et dérive les tests de l'application ou de la structure interne.

il L’objectif principal est de garantir qu’il couvre la structure sous-jacente à un niveau acceptable.

• Bien que chaque type de test ait des objectifs différents, il peut être appliqué à tous les niveaux de test.

• Différentes techniques de test peuvent être appliquées pour chaque type de test.
2.2.3. Tests de validation et tests de régression

• Test de confirmation :

il Ceci est fait pour confirmer que l’erreur d’origine a été corrigée avec succès.

il La version corrigée du logiciel est testée de différentes manières : en exécutant des scénarios défectueux
précédents ou en ajoutant de nouveaux tests.

il Elle peut être limitée en raison de contraintes de temps ou de coût, ou se limiter à la vérification de la récurrence des

erreurs.

• Les tests de régression:

il Ceci est fait pour confirmer qu’un changement n’entraîne aucun effet négatif. Le changement

il peut affecter l'objet de test, d'autres composants et même d'autres systèmes connectés.

il C'est un bon candidat pour l'automatisation des tests et il est recommandé de le démarrer dès les premières étapes du

projet.

• Tests de validation et de régression aux niveaux de test :

il Lorsque des bogues sont corrigés ou que des modifications sont apportées, elles doivent être effectuées à tous les niveaux

il de test. Des tests de validation et/ou de régression sont requis à tous les niveaux de test.
2.3. Essais d'entretien

• Catégories d'entretien :

il La maintenance peut être corrective, adaptative ou améliorant les performances/maintenabilité. Cela

il peut inclure des versions/distributions planifiées et des versions/distributions non planifiées.

• Analyse d'impact:

il Avant d’apporter des modifications, une analyse d’impact peut être effectuée pour évaluer les conséquences possibles.

il Il est nécessaire de tester les modifications apportées au système dans un environnement réel et de vérifier les régressions.

• Portée du test de maintenance :

il Le degré de risque du changement, la taille du système existant et l'étendue du changement déterminent la portée des tests de maintenance.

• Déclencheurs de maintenance :

il Les modifications, les mises à niveau/migrations de l’environnement opérationnel et les retraits peuvent déclencher une maintenance et
des tests de maintenance.

il Les mises à niveau, les migrations et les dépréciations de l’environnement opérationnel peuvent introduire des exigences de test
particulières.
3. Tests statiques
3.1. Fondamentaux des tests statiques

• Test statique :

il Il n'est pas nécessaire d'exécuter le logiciel testé.

il Le code, les processus, l'architecture du système ou d'autres produits de travail sont évalués via une révision manuelle ou des outils.

il Les objectifs des tests incluent l’amélioration de la qualité, la détection des bogues et l’évaluation des fonctionnalités. Peut être utilisé

il pour la vérification et l’approvisionnement.

• Collaboration et révision :
il Les testeurs, les unités commerciales et les développeurs travaillent ensemble pour garantir que les user stories et les produits de travail associés
répondent aux critères.

il Des techniques de révision sont utilisées pour garantir que les user stories sont complètes, compréhensibles et contiennent des critères
d'acceptation testables.

• Analyse statique :

il Peut identifier les problèmes avant les tests dynamiques. Cela nécessite

il généralement moins d’efforts et est inclus dans le processus CI. La durabilité

il et la sécurité peuvent également être évaluées.

il Des outils tels que le correcteur orthographique et les outils de lisibilité peuvent être utilisés.
 3.1.1. Produits fonctionnels pouvant être examinés avec des tests statiques

• Exemples de tests statiques pouvant être examinés :

il Exigences
il code source
il Plans de tests
il Scénarios de tests
il Éléments du backlog produit
il Documents de la charte de test

il Documentation du projet

il Contrats
il Des modèles

• Produits d'étude éligibles pour examen :

il Ceux qui sont lisibles et compréhensibles

il Ceux dont la structure ressemble à un mécanisme de contrôle

• Produits d'étude incompatibles :
il Difficile à interpréter par les humains Ne peut
il pas être analysé avec des outils
3.1.2. Importance des tests statiques

• Rôle des tests statiques aux premiers stades :

il Il peut remplir le principe des tests précoces en détectant les erreurs précoces. Il peut

il détecter des erreurs que les tests dynamiques ne peuvent pas détecter.

• Améliorer la qualité des produits de travail :

il Il évalue la qualité et augmente le sentiment de confiance.
il Assure l’exactitude des exigences documentées.
• Renforcement de la communication :

il Cela crée une compréhension commune entre les parties prenantes concernées. Cela

il renforce la communication.

• Coût et avantage des avis :

il Les avis peuvent coûter de l’argent, mais le taux de retour est élevé. Cela permet
il d'économiser plus de temps et d'efforts dans les étapes ultérieures du projet.
• Détection des erreurs de code avec l'analyse statique :
il Les erreurs de code peuvent être détectées plus efficacement à l’aide d’une analyse statique plutôt que de tests dynamiques.

il Cela entraîne généralement moins d’erreurs de code et un effort de développement global moindre.
3.1.3. Différences entre les tests statiques et les tests dynamiques

• Différences entre les tests statiques et dynamiques :

il Les deux types de tests détectent les erreurs, mais certains types d’erreurs peuvent être détectés avec un seul. Les tests

il dynamiques identifient les bogues, tandis que les tests statiques trouvent directement les bogues.

il Les tests statiques peuvent détecter plus facilement les erreurs dans les parties de code qui ne peuvent pas être exécutées.

il Les tests statiques peuvent être utilisés pour des mesures de qualité qui ne dépendent pas de l'exécution du code, tandis que les tests dynamiques dépendent

de l'exécution du code.

• Erreurs courantes détectées avec les tests statiques :

il Erreurs dans les exigences (incohérences, ambiguïtés, contradictions) Erreurs
il de conception (structures inefficaces, mauvaise modularisation)
il Certaines erreurs de code (variables non définies, blocs de code inaccessibles) Des

il écarts par rapport aux standards (non-respect des conventions de nommage) Des

il erreurs dans les exigences d'interface (incompatibilités de paramètres) Des failles de

il sécurité (débordements de tampon)

il Lacunes ou erreurs dans le cadre des tests

 3.2. Processus de rétroaction et d’examen
3.2.1. Avantages des commentaires précoces et fréquents des parties prenantes

• Des retours précoces et fréquents permettent une détection précoce des problèmes de qualité potentiels.

• Une faible implication des parties prenantes peut empêcher le produit de répondre à la vision originale et entraîner l'échec du projet.

• Les commentaires fréquents des parties prenantes évitent les malentendus sur les exigences et garantissent une mise en œuvre rapide des changements.

• Cela donne à l’équipe de développement la possibilité de mieux comprendre ce qu’elle fait.

• Cela permet aux parties prenantes de se concentrer sur les fonctionnalités les plus précieuses et qui géreront au mieux les risques.
3.2.2. Activités du processus d'examen

• Planification:Il comprend des informations telles que la portée de l’examen, les

caractéristiques de qualité, les domaines d’intérêt et les critères de sortie.

• Début de l'examen: On s'assure que tout le monde est prêt, l'accès et les rôles
sont déterminés.

• Bilan individuel: Les examinateurs évaluent le produit du

travail et identifient les anomalies.

• Communication et analyse :Les anomalies sont analysées, des décisions sont prises et des actions
de suivi sont déterminées.

• Correction et reporting: Des rapports d'erreurs sont créés, des actions correctives sont
suivies et les résultats sont rapportés.
3.2.3. Rôles et responsabilités en revue

• Exécutif: Fournit des ressources de révision et décide ce qu’il faut réviser.

• Écrivain: Crée et corrige les produits de travail.
• modérateur: Gère les réunions d'examen, offre un environnement sûr et facilite une communication efficace.

• Greffier: Enregistre les anomalies et entreprend la tâche de documenter les décisions prises lors des réunions de revue.

• critique: La personne ou l'équipe qui examine et évalue les produits du travail.

• responsable de la revue: Assume la responsabilité globale de l’examen et gère l’organisation.
 3.2.4. Types d'avis

• Examen informel: Processus non défini, ne nécessite pas de sortie formelle, détecte les anomalies.
• ne dépasse pas: Cela se fait sous la direction de l'auteur, pour accroître la qualité et instaurer la confiance.

• Analyse technique: Géré par des personnes qualifiées, gère les problèmes techniques, évalue la qualité.
• Inspection: Le processus le plus formel et entièrement contrôlé vise à trouver le maximum d'anomalies.
3.2.5. Facteurs de réussite des avis

• Il est important de fixer des objectifs clairs et des critères de sortie mesurables.

• La sélection du type d'évaluation approprié doit être adaptée au type de produit du travail, aux participants et aux besoins du
projet.

• Il est important de diviser le processus d’évaluation en plusieurs parties pour éviter de distraire les participants.

• Les produits et les activités doivent être améliorés en fournissant des commentaires aux parties prenantes et aux auteurs.

• Les participants doivent disposer de suffisamment de temps pour se préparer.

• Obtenir le soutien de la direction renforce le processus d’examen.

• Il est important d’adopter et d’améliorer continuellement les avis dans le cadre de la culture d’entreprise.

• Tous les participants doivent être formés pour remplir leurs rôles.
• L’animation des réunions est essentielle à un processus d’examen efficace.
 4. Analyse et conception des tests
4.1. Présentation des techniques de test

• Techniques de test en boîte noire: analyse le comportement de l'objet de test et est

indépendant de la façon dont le logiciel est écrit.

• Techniques de test en boîte blanche :Il analyse la structure interne et les opérations de

l'objet de test et dépend de la façon dont le logiciel est conçu.

• Techniques de tests basées sur l’expérience :Utilise les connaissances et

l’expérience des experts en tests pour concevoir et adapter des scénarios de tests.

• Les techniques de tests basées sur l’expérience sont complémentaires aux

techniques de tests en boîte noire et en boîte blanche.

4.2. Techniques de test de la boîte noire

Les techniques de test en boîte noire couramment utilisées sont abordées dans les sections suivantes :

• Affectation en actions d'équivalence

• Analyse des valeurs limites

• Tests de table de décision

• Tests de transition d'état

4.2.1. Affectation en actions d'équivalence

• Le partitionnement d'équivalence (DPA) divise les données en partages en fonction de l'attente que tous les éléments d'un objet de test seront traités
de la même manière.

• La DPA recommande un test pour chaque partage, et les partages peuvent être continus ou discrets, ordonnés ou non, finis ou
infinis.

• Les partages ne doivent pas se chevaucher et ne doivent pas se trouver dans un cluster vide.

• L’utilisation du DPA demande de la rigueur pour comprendre le comportement de l’objet à tester.

• Les partages contenant des valeurs valides sont appelés « partages valides », tandis que ceux contenant des valeurs non valides sont appelés « partages invalides ».

• Dans DPA, les éléments du périmètre sont des parts d'équivalence et le but est d'atteindre 100% du périmètre en essayant chaque part au moins une

fois.

• Pour les objets de test contenant plusieurs groupes d'enjeux, la couverture Chaque choix est le critère de couverture le plus simple et nécessite

au moins un essai de chaque enjeu de chaque groupe d'enjeux.

4.2.2. Analyse des valeurs limites

• Analyse des valeurs limites (SDA)est une technique basée sur le test des limites des numérateurs d'équivalence et ne peut être utilisée que pour des
données ordinales.

• SDA vise à identifier les erreurs que les développeurs peuvent commettre dans les valeurs limites en testant les valeurs minimales et
maximales des actions.

• Il est disponible en deux versions : SDA à 2 valeurs et SDA à 3 valeurs.

• 2 SDA valorisés: Pour chaque valeur limite, il existe deux éléments de couverture : la valeur limite et son voisin le plus proche de la marge adjacente.

• 3 SDA valorisés: Pour chaque valeur limite, il existe trois éléments de portée : la valeur limite et les deux valeurs limites adjacentes de cette valeur limite.

Par exemple;

• Le SDA à 3 valeurs effectue une analyse plus rigoureuse que le SDA à 2 valeurs et peut détecter plus d'erreurs.

• 2 SDA valorisés :Puisque seules les valeurs limites telles que x = 10 et x = 11 seront testées, l'erreur ne peut pas être détectée car la valeur limite
est correctement définie.
• 3 SDA valorisés :Dans ce cas, l’erreur peut être détectée car les deux côtés de la frontière, y compris x = 9, seront
testés.
4.2.3. Tests de table de décision

• Utilisation des tables de décision :

il Il est utilisé pour montrer les résultats de différentes combinaisons de conditions de test et pour démontrer efficacement une logique complexe. Il

il est défini si les conditions sont remplies ou non et les actions à entreprendre en conséquence.

il Les conditions forment les lignes du tableau, tandis que chaque colonne spécifie une combinaison unique de conditions et d'actions associées.

• Structure des tables de décision :

il Dans les tableaux de décision à entrées limitées, les conditions et les actions sont souvent représentées sous forme de valeurs booléennes (vraies ou fausses).

il Dans les tables de décision d’entrée étendues, les conditions et les actions peuvent prendre plusieurs valeurs.

• Notation des conditions et des actions :

il Pour condition : « T » (vrai), « F » (faux), « - » (non pertinent), « N/A » (non

il applicable). Pour l'action : "X" (devrait arriver), espace (ne devrait pas arriver).
• Scénarios de portée et de test :

il La couverture nécessite que les cas de test atteignent une couverture de 100 % en essayant toutes les colonnes applicables.

il La couverture est mesurée comme le nombre de colonnes tentées divisé par le nombre de toutes les colonnes applicables, exprimé en pourcentage.

• Avantages :
il Il propose une approche systématique en abordant toutes les combinaisons de

il conditions. Cela aide à trouver des lacunes ou des contradictions dans les exigences.

• Défis et solutions :
il À mesure que le nombre de conditions augmente, le nombre de règles à appliquer augmente également. Dans ce cas, une table de décision réduite ou une approche basée sur les risques peuvent être utilisées.
4.2.4. Tests de transition d'état

• Diagrammes de transition d'état (DGD) et tables d'état :

il DGD montre les états possibles d'un système et les transitions entre ces états. Les tables d'état sont

il l'équivalent du DGD et contiennent les états, les événements et les conditions de protection.

• Tests de transition d’état et critères de couverture :

il Couverture toutes occasions :

▪ Pour couvrir tous les cas, les cas de test doivent examiner tous les cas.

▪ La couverture est mesurée en divisant le nombre de cas examinés par le nombre total de cas.

il Portée des transitions valides :

▪ Pour tester toutes les transitions valides, les scénarios de test doivent essayer toutes les transitions valides.

▪ La couverture est mesurée en divisant le nombre de passes valides tentées par le nombre total de passes valides.

il Couverture de toutes les transitions :

▪ Pour couvrir toutes les transitions, valides et non valides, les scénarios de test doivent tenter toutes les transitions.
▪ Cette couverture est mesurée en divisant les tentatives de passes par le nombre total de passes.

• Scénarios de couverture et de test :

il Un scénario de test est représenté par une série de changements d'état et comprend des transitions entre les états.

il La couverture est mesurée en divisant le nombre de transitions valides et invalides tentées ou tentées d'être couvertes par les scénarios de test exécutés par le nombre
total de transitions valides et invalides.
4.3. Techniques de test en boîte blanche
4.3.1. Tests de commande et pourcentage de couverture de commande

• Test de commande :

il Éléments de portée : commandes exécutables.

il Objectif : atteindre un niveau de couverture acceptable en essayant au moins une fois toutes les commandes exécutables
du code.

il Mesure de couverture : elle s'effectue en divisant le nombre de commandes tentées par les cas de test par le nombre total de
commandes exécutables, exprimé en pourcentage.

il Couverture de commandement à 100 % :

▪ Garantit que toutes les commandes exécutables sont essayées au moins une fois.

▪ Il indique si chaque commande contient des erreurs, mais il se peut qu'il ne détecte pas toutes les erreurs.

▪ Cela ne garantit pas que toute la logique de décision soit testée, car toutes les branches du code ne peuvent pas être testées.
4.3.2. Tests de succursales et couverture des succursales

• Test de branche :

il Éléments de portée : les branches sont des transferts de contrôle entre deux nœuds dans le graphe de flux de contrôle.

il Objectif : atteindre un niveau de couverture acceptable en essayant toutes les branches du code au moins une fois.

il Mesure de couverture : elle s'effectue en divisant le nombre de branches essayées par les scénarios de test par le nombre total de branches,

exprimé en pourcentage.

il Couverture des succursales à 100 % :

▪ Il garantit que toutes les branches inconditionnelles et conditionnelles sont testées par des cas de test.

▪ Les branches conditionnelles correspondent généralement à des décisions « si…alors », à des instructions de commutation/cas ou à des décisions de boucle.

▪ Tester une branche avec un scénario de test ne signifie pas que tous les bugs de cette branche seront détectés.

il Relation : La couverture des succursales comprend le pourcentage de couverture des instructions ; c'est-à-dire que l'ensemble de scénarios de test qui atteint une couverture de

branche de 100 % atteint également un pourcentage de couverture de commande de 100 %.

4.3.3. L'importance des tests en boîte blanche

• Points forts des techniques de test en boîte blanche :

il La prise en compte de l’intégralité du code lors des tests permet de détecter plus facilement les erreurs sans ignorer les ambiguïtés ou omissions de
l’analyse.

il Il peut également être utilisé dans des tests

il statiques. Domaines où il peut être utilisé :

▪ Codes qui ne sont pas encore prêts à être exploités.

▪ Codes complexes ou incorrects.

▪ Logiciel modélisé avec un organigramme de contrôle.

• Faiblesses:
il Il n'est pas possible de détecter les exigences non codées.

• Mesure et confiance :

il Le simple fait d'effectuer des tests en boîte noire ne mesure pas la couverture réelle du code. Les techniques de test en boîte

il blanche fournissent une mesure objective de la couverture et augmentent la confiance dans le code.
4.4. Techniques de test basées sur l'expérience

• Les techniques de test basées sur l’expérience couramment utilisées sont abordées dans les sections suivantes :

• Prédiction des erreurs

• tests exploratoires

• Tests basés sur une liste de contrôle

4.4.1. Prédiction des erreurs

• Estimation des erreurs :

il Il s’agit d’une technique permettant de détecter les erreurs humaines, les erreurs logicielles et les dysfonctionnements en s’appuyant sur les
connaissances du testeur.

il Sources d'informations:

▪ L'historique de l'application et son fonctionnement.

▪ Erreurs courantes commises par les développeurs et leurs conséquences.

▪ Types de dysfonctionnements dans des applications similaires.

il Types d'erreurs et de dysfonctionnements :

▪ Cela peut être lié à l'entrée, à la sortie, à la logique, au calcul, à l'interface ou aux données.

• Attaques pour détecter les failles :

il Il s'agit d'une approche méthodique pour mettre en œuvre la prédiction des erreurs.

il Le testeur identifie les erreurs et dysfonctionnements possibles et conçoit des tests pour les révéler. Des listes peuvent être créées sur la base

il de l'expérience, des données d'erreurs et de dysfonctionnements ou de connaissances générales sur les logiciels.
4.4.2. Test de découverte

• Test de découverte :

il Les tests sont conçus, exécutés et évalués simultanément pendant que le testeur découvre l'objet de test.
il Objectifs :
▪ Pour en savoir plus sur l'objet de test.
▪ Explorer l'objet de test en profondeur avec des tests ciblés.
▪ Création de tests pour les zones non testées.
il Approche basée sur les sessions :

▪ Elle est réalisée dans un certain délai.

▪ Le testeur détermine les objectifs du test à l'aide de la charte de test.
▪ Après la séance de tests, une réunion d'information est organisée avec les parties prenantes.

il Objectifs des tests :

▪ Elles sont considérées comme des conditions de test de niveau supérieur.

▪ Les éléments de portée sont définis et testés lors de la session de test.

il Avantages des tests de découverte :

▪ Cela fonctionne bien lorsque les exigences sont peu nombreuses ou insuffisantes, ou lorsque le temps presse.

▪ Il peut être utilisé pour compléter d’autres techniques de tests formels.

il Qualifications du testeur :
▪ Doit être expérimenté, avoir une connaissance du domaine, avoir des compétences analytiques, être curieux et créatif.

il Utilisation avec d'autres techniques de test :

▪ Cela peut également inclure d'autres techniques de test, telles que le partitionnement d'équivalence.
4.4.3. Tests basés sur une liste de contrôle

• Tests basés sur une liste de contrôle :

il Les testeurs conçoivent, mettent en œuvre et exécutent des tests pour couvrir les conditions de test trouvées dans une liste de contrôle. Des listes de contrôle
il peuvent être créées en fonction de l'expérience, de ce qui est important pour l'utilisateur ou de la connaissance du pourquoi et du comment du logiciel pourrait
échouer.

il Listes de contrôle :
▪ Articles pouvant être contrôlés automatiquement,
▪ Éléments éligibles comme critères d’entrée/sortie ou
▪ Il n'inclut pas les éléments trop généraux.

il Les éléments de la liste de contrôle se présentent généralement sous la forme de questions et doivent être vérifiables individuellement et directement.

il Les éléments peuvent concerner des exigences, des spécifications d'interface, des caractéristiques de qualité ou d'autres formes de conditions de test. Des

il listes de contrôle peuvent être créées pour prendre en charge différents types de tests (par exemple, 10 critères pour les tests d'utilisabilité).

il Les listes de contrôle peuvent devenir moins efficaces avec le temps et doivent être mises à jour pour refléter les erreurs nouvellement
il découvertes. La liste de contrôle peut être utilisée comme guide lorsque les scénarios de test ne sont pas détaillés.
il Il est probable qu'il y ait certaines variations dans les tests réels, ce qui pourrait conduire à une plus grande couverture mais à
une reproductibilité moindre.
4.5. Approches de tests collaboratifs
4.5.1. Rédaction collaborative de user story

• Témoignages d'utilisateurs (3 C) :
il Carte:Média qui décrit la user story, comme une fiche ou une entrée dans un presse-papiers électronique.
il Conversation:Il détermine la manière dont le logiciel sera utilisé, peut-être par le biais de la documentation ou
il verbalement. Confirmation:Définit les critères d'acceptation.
• Format de la user story :
il Le format le plus courant : « Je veux que [l’objectif soit atteint] dans [le rôle] parce que [la valeur commerciale émerge pour le rôle] ». Les

il critères d'admission suivent ce format.

• Rédaction collaborative de user story :
il Des techniques telles que le brainstorming et la cartographie mentale peuvent être utilisées.

il La collaboration permet de créer une vision commune en prenant en compte les perspectives d’analyse, de développement logiciel et de test.

• Bonnes histoires d'utilisateurs (critères INVEST) :

il Indépendant

il négociable
il Précieux

il Prévisible
il Petit
il testable
• Marque de testabilité :
il Cela montre qu’une user story est testable.
il Si une partie prenante ne sait pas comment tester une user story, il se peut que la story ne soit pas assez claire, ne reflète pas quelque chose de valeur, ou que la partie
prenante ait simplement besoin d'aide pour les tests.
4.5.2. Accepter les conditions

• Acceptez les conditions :

il Il contient les conditions qu’une user story doit remplir pour être acceptée par les parties prenantes. Les critères
il d'acceptation sont des tests qui doivent être tentés par des experts en tests.
il Cela se produit généralement à la suite d’une conversation.

• Objectifs de l'utilisation des critères d'acceptation :

il Définir la portée de la user story. Assurer le consensus
il entre les parties prenantes. Expliquer les scénarios
il positifs et négatifs. La user story sert de base aux tests
il d’acceptation. Pour garantir une planification et des
il prévisions correctes.
• Formats des critères d'acceptation :
il Orienté scénario : par exemple, Given/When/Then utilisé dans BDD
il Orienté vers des règles : par exemple, une liste de contrôle à puces ou une forme tabulaire du mappage entrées-sorties. La plupart des critères

il d'acceptation peuvent être documentés dans l'un de ces deux formats.

il Cependant, l’équipe peut également utiliser un autre format personnalisé à condition que les critères d’acceptation soient bien définis et clairs.
4.5.3. Développement de logiciels piloté par les tests d'acceptation (ATDD)

• ATDD (Développement piloté par les tests d'acceptation) :

il Il s’agit d’une approche axée sur le test d’abord.

il Des scénarios de test sont créés avant la mise en œuvre de la user story.
il Les cas de test peuvent être créés par des membres de l'équipe ayant des perspectives différentes : clients, développeurs et testeurs. Les cas de
il test peuvent être exécutés manuellement ou automatiquement.
• Processus de demande:
il La première étape est un atelier d’analyse où la user story et, si nécessaire, les critères d’acceptation sont analysés et affinés par l’équipe.
il Ensuite, des scénarios de tests sont créés. Cela peut être fait par l’équipe dans son ensemble ou par le testeur.
il Les cas de test sont basés sur des critères d'acceptation et peuvent être considérés comme des exemples du fonctionnement du logiciel. Les

il échantillons et les tests étant identiques, ces termes sont souvent utilisés de manière interchangeable.

• Scénarios de tests :
il Les premiers cas de tests sont généralement des tests positifs et confirment le comportement souhaité.

il Après des tests positifs, l’équipe réalise des tests négatifs et des tests d’exigences non fonctionnelles. Les scénarios de
il test doivent être exprimés d'une manière compréhensible pour les parties prenantes.
il Les cas de test contiennent des phrases dans un langage naturel qui contiennent les préconditions, entrées et postconditions requises. Les

il cas de test doivent aborder toutes les caractéristiques de la user story et ne doivent pas aller au-delà de la story.

• Tests d'acceptation et automatisation :

il Le code qui teste les hypothèses peut être écrit dans le cadre du processus de mise en œuvre, et ces tests se transforment en exigences exécutables.
 5. Gérer les activités de test
5.1. Planification des tests

5.1.1. Objectif et contenu du plan de test

TRégime EST :

• Spécifie les objectifs, les ressources et les processus d'un projet de test.
• Documente les outils et le programme qui permettent d'atteindre les objectifs de test.
• Il permet de répondre aux critères établis des activités de test effectuées.
• Il sert d’outil de communication avec les membres de l’équipe et les autres parties prenantes.
• Explique s'il sera conforme ou non à la politique et à la stratégie de test actuelles.

• Planification des tests :

• Il guide le testeur dans sa réflexion et le prépare aux défis futurs.

• C'est un moyen utile de calculer l'effort requis pour atteindre les objectifs du projet de test.
• Contenu typique :

• Contexte du test (portée, objectifs, contraintes, lignes directrices)

• Hypothèses et contraintes du projet de test

• Parties prenantes (rôles, responsabilités, disponibilité, besoins de formation)
• Communication (forme, fréquence, modèles de documentation)

• Registre des risques (risques produits et projets)

• Approche de test (niveaux, types, techniques, livrables, critères, mesures, exigences en matière de données et d'environnement, politique et stratégie)

• Budget et calendrier
5.1.2. Contribution du testeur à la planification du cycle et des versions

• Planification dans les YGYD cycliques :

il Deux types de planification existent : la planification des versions et la planification du cycle.

• Planification des versions :

il Planifie le lancement d'un produit. Définit

il et redéfinit le backlog produit.
il Il décompose les user stories complètes en petits groupes. Il
il sert de base à l’approche de test et au plan de test.
il Experts en tests :
▪ Participe au processus de rédaction des user stories testables et des critères d’acceptation.
▪ Participe aux analyses de risques projet et qualité.
▪ Estimation de l’effort de test associé aux user stories.
▪ Détermine l’approche de test et planifie les tests pour la version.
• Planification des cycles :
il Il prédit la fin d'un seul cycle et est lié à la liste de travail du cycle.
il Experts en tests :
▪ Participe à une analyse détaillée des risques des user stories.
▪ Détermine la testabilité des user stories.
▪ Divise les user stories en tâches (en particulier les tâches de test).
▪ Estime l’effort de test pour toutes les tâches de test.
• Identifie et améliore les éléments d'objet de test fonctionnels et non fonctionnels
5.1.3. Critères d'entrée et critères de sortie

• Critère d'entrée:
il Définit les prérequis pour une activité spécifique. Si les

il critères d’entrée ne sont pas remplis :

▪ L'activité est plus difficile,

▪ prend plus longtemps,
▪ Cela sera probablement plus coûteux et plus risqué.
il Il doit être défini pour chaque niveau de test.
il Critères d'entrée typiques :

▪ Disponibilité des ressources (personnes, outils, environnements, données de test, budget, temps),

▪ Tester la disponibilité des logiciels (base de tests, exigences testables, user stories, scénarios de tests),
▪ Niveau de qualité initial de l'objet à tester (tous les tests de fumée réussis).
• Critère de sortie:
il Il définit ce qui doit être réalisé pour comprendre qu'une activité est terminée. Critères
il de sortie typiques :
▪ Métriques d'intégrité (niveau de couverture atteint, nombre de bugs non résolus, densité de bugs, nombre de cas de test ayant échoué),
▪ Critères de réalisation (tests planifiés exécutés, tests statiques effectués, tous les bugs trouvés signalés, tous les tests de régression
automatisés).
il Le manque de temps ou d’argent peut également être considéré comme un critère de sortie valable.

il Dans le développement de logiciels agiles, les critères de publication sont souvent appelés « Définition du fait » et définissent les métriques cibles pour un élément
publiable.
il Les critères d'entrée qu'une user story doit remplir pour que les activités de développement et/ou de test puissent commencer sont appelés « Définition
prête ».
 5.1.4. Techniques d'estimation

• Estimation de l’effort de test :

• Il s'agit d'estimer la quantité de travail lié aux tests requis pour atteindre les objectifs du projet de test.
• Il convient de préciser aux parties prenantes que les prévisions sont basées sur un ensemble d'hypothèses et sont toujours sujettes à des erreurs de prévision.

• Les estimations pour les petites tâches sont généralement plus précises que les estimations pour les tâches plus importantes. Par conséquent, lors de l’estimation d’une
tâche importante, la tâche est divisée en tâches plus petites et une estimation est effectuée pour elles.
Techniques d'estimation :
1. Estimation basée sur des ratios :
il Les chiffres obtenus lors de projets antérieurs au sein de l'organisation sont utilisés.
il Les tarifs des projets précédents peuvent être utilisés pour estimer l’effort de test pour les nouveaux projets.
2. Extrapolations :
il Les premières mesures sont effectuées dans le cadre du projet actuel.

il Après une observation suffisante, l'effort requis pour le travail restant est déterminé par extrapolation.
3. Delphi à large bande :
il Les experts font des prédictions basées sur l’expérience.

il Il est demandé à chaque expert d'estimer l'effort individuel, puis les résultats sont additionnés et corrigés si nécessaire.
4. Estimation en trois points :
il Trois prévisions sont faites par les experts : la prévision la plus optimiste, la plus probable et la plus pessimiste.

il L'estimation finale est calculée comme la moyenne pondérée de ces estimations.

Autres techniques :
• La technique de planification du poker est une variante de Wideband Delphi et est fréquemment utilisée dans le développement de logiciels agiles.
5.1.5. Priorisation des scénarios de test

• La priorisation des cas de test affecte l'ordre déterminé dans le calendrier d'exécution des tests.
• Les stratégies de priorisation les plus couramment utilisées sont :
1. Priorisation basée sur les risques: Les scénarios de test présentant les risques les plus importants sont exécutés en premier. Par exemple, les
scénarios à risque le plus élevé pouvant survenir en cas de défaillance d'une fonctionnalité critique d'un logiciel sont prioritaires.

2. Priorisation basée sur la couverture: Pour augmenter la couverture des tests, les cas de test sont classés à l'aide de mesures telles
que le pourcentage de couverture des commandes. Les scénarios offrant une couverture élevée sont prioritaires.
3. Priorisation basée sur les exigences: Les scénarios de tests sont classés en fonction des priorités d'exigences déterminées par
les parties prenantes. La priorité est donnée en fonction des besoins critiques.
• Les cas de test sont triés et exécutés selon des stratégies de priorisation.
• Cependant, s’il existe des dépendances entre les cas de test ou les fonctionnalités, ces stratégies peuvent être difficiles à mettre en œuvre. Par
exemple, si un scénario de test à priorité élevée dépend d'un scénario à faible priorité, le scénario à faible priorité doit être exécuté en premier.

• Le séquençage de l'exécution des tests doit également prendre en compte l'accessibilité des ressources disponibles (par exemple, les outils de test, les

environnements, les personnes). Par exemple, si seul un certain outil de test est accessible pendant une certaine période, la planification doit être effectuée en

conséquence.
5.1.6. Pyramide de test

• La pyramide des tests est un modèle qui montre les différents niveaux de tests et comment l'automatisation des tests est prise en charge en fonction de ces
niveaux.

• Les couches pyramidales représentent des groupes de tests et des niveaux de détail des tests.

• Les couches inférieures de la pyramide sont constituées de petits tests isolés et rapides. Ces tests sont souvent appelés tests unitaires et
vérifient un petit élément de fonctionnalité.

• Le nombre de tests sur les couches inférieures peut être important car un grand nombre de tests peut être nécessaire pour fournir une couverture raisonnable.

• Les couches supérieures représentent des tests complexes, de haut niveau et de bout en bout. Ces tests sont généralement plus lents et vérifient une plus
grande partie des fonctionnalités.

• Le nombre de tests dans les couches supérieures est généralement moindre car seuls quelques tests suffisent généralement pour vérifier la couverture.

• Le nombre et le nom des couches peuvent varier. Par exemple, dans un modèle, les trois couches peuvent être appelées « tests unitaires », « tests de service » et « tests d'interface utilisateur

», tandis que dans un autre modèle, elles peuvent être appelées « tests de composants », « tests d'intégration de composants » et « tests de fin ». -des tests jusqu'à la fin."

• D’autres niveaux de tests peuvent également être inclus dans la pyramide des tests.
5.1.7. Trimestres de test

• Les quadrants de test regroupent les niveaux de test en types de tests, activités et produits de travail spécifiques.

• Le modèle est utilisé pour comprendre la relation entre les types de tests et les niveaux de tests afin de prendre en charge la gestion des tests.

• Les tests peuvent être axés sur l'entreprise ou sur la technologie et peuvent soutenir l'équipe ou critiquer le produit.

• Le modèle se compose de quatre quadrants :

1. Q1 : Axé sur la technologie et pour soutenir l'équipe (par exemple, tests de composants et d'intégration de composants).

2. Q2 : Axé sur le business et pour soutenir l'équipe (ex : tests fonctionnels, tests de user story).

3. Q3 : Orienté métier, pour critiquer le produit (par exemple, tests exploratoires, tests d'utilisabilité).

4. Q4 : Orienté technologie, pour critiquer le produit (ex. tests de fumée, tests non fonctionnels).
5.2. Gestion des risques

• La gestion des risques a des effets positifs sur la réalisation des objectifs et
l'amélioration de la qualité des produits.

• Les étapes de base de la gestion des risques comprennent l’analyse et le contrôle des risques.

• La sélection, la priorisation et la gestion des tests axées sur les risques

constituent l'approche des tests basée sur les risques.
5.2.1. Définition du risque et caractéristiques du risque

• Le risque est un événement, un danger ou une situation potentiel pouvant entraîner des conséquences négatives.

• Un risque a deux caractéristiques principales : la probabilité (la probabilité que le risque se réalise) et l'impact (les conséquences du risque).

• Le niveau de risque indique l'importance d'un risque ; Des niveaux de risque plus élevés nécessitent plus d’attention.
5.2.2. Risques du projet et risques du produit

• Il existe deux types de risques dans les tests de logiciels : les risques liés au projet et les risques liés au produit.

• Les risques du projet concernent la gestion et le contrôle du projet et incluent les problèmes d’organisation, de ressources humaines, techniques et de

fournisseurs.

• Les risques du projet peuvent avoir un impact sur le calendrier, le budget et la portée, ce qui à son tour affecte la capacité du projet à atteindre ses objectifs.

• Les risques liés aux produits sont liés aux exigences du produit et incluent des problèmes tels que des fonctionnalités manquantes, des calculs incorrects, des problèmes de

performances, etc.

• Les risques liés aux produits peuvent entraîner des conséquences négatives telles que l'insatisfaction des utilisateurs, la perte de revenus, la perte de confiance et des coûts

de maintenance élevés.
5.2.3. Analyse des risques produits

• Le but de l’analyse des risques liés aux produits est d’attirer l’attention sur les risques liés aux produits et d’orienter les efforts et les activités de test pour réduire les risques restants.

• Idéalement, l’analyse des risques produits commence dès les premiers stades de YGYD.

• L'analyse consiste en l'identification et l'évaluation des risques.

• L'identification des risques implique la création d'une liste complète des risques et des techniques telles que le brainstorming, les ateliers et les entretiens peuvent être utilisées.

• L'évaluation des risques implique de catégoriser les risques identifiés, de déterminer la probabilité, l'impact et le niveau des risques, de prioriser et de concevoir des
stratégies d'atténuation des risques.

• L'évaluation des risques peut utiliser une approche quantitative ou qualitative, ou une combinaison des deux.

• L'analyse des risques produits affecte l'intégrité et la portée des tests.

• Les résultats sont utilisés aux fins suivantes :

il Détermination de la portée des tests.

il Recommander des niveaux et des types de tests.

il Déterminer les techniques de test et la portée à utiliser.

il Estimation de l’effort de test.

il Prioriser les tests pour détecter rapidement les bugs critiques.

• Identifier des activités supplémentaires non liées aux tests pour réduire les risques
5.2.4. Contrôle des risques produits

• Le contrôle des risques produits comprend les mesures prises contre les risques produits identifiés et évalués.

• Ce contrôle comprend l'atténuation des risques et la surveillance des risques.

• L'atténuation des risques implique la mise en œuvre des actions recommandées pour réduire le niveau de risque.

• L’objectif de la surveillance des risques est de garantir l’efficacité des mesures prises et d’améliorer l’évaluation des risques.

• Il existe différentes options de réponse pour le contrôle des risques liés aux produits, notamment la réduction des risques par le biais de tests, l'acceptation des risques, le transfert

des risques et la planification d'urgence.

Les mesures qui peuvent être prises pour réduire les risques liés aux produits sont :

• Choisir des testeurs expérimentés

• Appliquer le niveau approprié d’indépendance des tests

• Effectuer des revues et des analyses statiques

• Utiliser des techniques de test et une couverture appropriée

• Appliquer les types de tests appropriés

• Réaliser des tests dynamiques, notamment des tests de régression