Syllabus ISTQB Analyste de Test

3.1  Introduction

Les techniques de conception des tests abordées dans ce chapitre sont réparties dans les catégories suivantes:

• Basée sur les spécifications (ou basée sur le comportement ou encore boîte noire)
• Basée sur les défauts
• Basée sur l’expérience

Ces techniques sont complémentaires et peuvent être utilisées de façon adaptée à une activité de test particulière, indépendamment du niveau de test en cours.

Noter que ces trois catégories peuvent être utilisées à la fois pour le test de caractéristiques qualité fonctionnelles ou non-fonctionnelles. Le test des caractéristiques non-fonctionnelles est discuté dans le chapitre suivant.

Les techniques de conception des tests, abordées dans les sections suivantes, se concentrent sur l’identification des données de test optimales (p. ex., partitions d’équivalence) ou sur l’obtention de séquences de test (p. ex., modèles d’état). Il est fréquent de combiner ces techniques pour créer des cas de test complets.

3.2  Techniques basées sur les Spécifications

Les techniques basées sur les spécifications sont appliquées aux conditions de test pour obtenir des cas de test à partir d’une analyse des bases de test pour un composant ou système, sans référence à sa structure interne.

Les caractéristiques principales des techniques basées sur les spécifications incluent:

• Les modèles (p. . diagrammes de transition d’état et table de décisions) sont créés pendant la conception des tests selon la technique de test
• Les conditions de tests sont dérivées systématiquement de ces modèles

Certaines techniques apportent aussi des critères de couverture pouvant être utilisés pour mesurer les activités de conception des tests et d’exécution des tests. Satisfaire entièrement un critère de couverture ne signifie pas que tous les tests ont été exécutés, mais plutôt que le modèle ne requiert pas de tests supplémentaires pour augmenter la couverture sur la base de cette technique.

Les tests basés sur les spécifications s’appuient en général sur les documents d’exigences système. Comme les spécifications d’exigences devraient préciser le comportement du système, en particulier d’un point de vue fonctionnel, le test du comportement du système s’appuie souvent sur la création de cas de test à partir des exigences. Dans certains, il n’existe pas d’exigences documentées mais des exigences implicites telles le remplacement des fonctionnalités d’un système préexistant.

Il existe de nombreuses techniques de test basées sur les spécifications. Ces techniques concernent différents types de logiciels et de scénarios. Les sections suivantes présentent la mise en œuvre de chaque technique, ainsi que les limitations ou difficultés que l’Analyste de Test peut rencontrer, et la méthode par laquelle la couverture est mesurée et les différents types de défauts sont détectés.

3.2.1  Partitions d’équivalence

La technique des partitions d’équivalence est utilisée pour réduire le nombre de cas de test  nécessaire pour tester un ensemble d’entrées, de sorties, d’intervalles de valeurs ou de temps. Le découpage en partitions est utilisé pour créer des classes d’équivalence (souvent appelées partitions d’équivalence) qui sont constituées d’ensembles de valeurs qui sont traités de la même manière. En sélectionnant dans chaque partition une valeur représentative, la couverture de tous les éléments de la même partition est assurée.

Application

Cette technique est applicable à tous les niveaux de test et est adaptée lorsque tous les éléments  d’un même ensemble de valeurs sont supposés être traités de la même façon et lorsque les ensembles de valeurs utilisés par l’application n’interagissent pas. La sélection des ensembles de valeur est applicable aux partitions valides et invalides (c.à.d., partitions contenant des valeurs devant être considérées comme invalides pour le logiciel testé). Il est fortement recommandé d’utiliser cette technique en la combinant avec l’analyse des valeurs limites qui étend les valeurs de test pour inclure celles situées aux extrémités des partitions. C’est une technique fréquemment utilisé pour les tests fumigatoires (« smoke test ») sur une nouvelle version ou une nouvelle livraison afin de rapidement déterminer si les fonctionnalités de base fonctionnent.

Limitations/Difficultés

Si la supposition est incorrecte et que les valeurs dans la partition ne sont pas traitées exactement de la même façon, cette technique peut laisser passer des défauts. Il est donc important de sélectionner avec attention les partitions d’équivalence. Par exemple, un champ de saisie qui accepte des valeurs positives et des valeurs négatives devrait être testé avec deux partitions valides, l’une pour les nombres positifs, l’autre pour les nombres négatifs, car ces deux ensembles seront probablement gérés de façon différente. En fonction de la possibilité ou non d’utiliser le zéro, celui-ci peut devenir une autre partition. Il est important pour l’Analyste de Test de bien comprendre le processus sous- jacent afin de déterminer les meilleures partitions de valeurs.

Couverture

La couverture est calculée en prenant le nombre de partitions pour lesquelles une valeur a été testée et en le divisant pour le nombre de partitions définies. Utiliser plusieurs valeurs pour une même partition n’augmente pas le pourcentage de couverture.

Types de Défauts

Cette technique trouve des défauts fonctionnels dans la gestion des différentes données.

3.2.2  Analyse des Valeurs Limites

L’analyse des valeurs limites est utilisée pour tester les valeurs aux limites de partitions d’équivalence. Il y a deux façons d’aborder l’analyse des valeurs limites : prendre deux ou trois valeurs pour le test. Avec deux valeurs, la valeur limite (sur la limite) et la valeur qui est juste au-delà (par le plus petit incrément possible) sont utilisées. Par exemple, si la partition inclut les valeurs 1 à 10 avec un incrément de 0,5, les deux valeurs de test pour la limite supérieure seront 10 et 10,5. Les valeurs de test pour la limite inférieure seront 1 et 0,5. Les limites sont définies par les valeurs maximum et minimum des partitions d’équivalence.

Avec trois valeurs, les valeurs inférieure, égale et supérieure à la limite sont utilisées. Selon l’exemple précédent, les valeurs pour la limite supérieure seraient 9.5, 10 et 10.5. Les valeurs pour la limite inférieure seraient 1.5, 1 et 0.5. La décision d’utiliser deux ou trois valeurs doit se baser sur les  risques associés à l’élément à tester, sachant que trois valeurs seront utilisées pour les éléments associés aux risques les plus élevés.

Application

Cette technique est applicable à tous les niveaux de test et peut être utilisée quand des partitions d’équivalence ordonnées existent. L’ordre est important à cause des concepts consistant à être sur un limite ou au-dessus. Par exemple, une plage de nombres est une partition ordonnée. Une partition correspondant à tous les objets rectangulaires ne serait pas une partition ordonnée et ne pourrait pas avoir de valeurs limites. En plus des plages de nombres, l’analyse des valeurs limites peut être appliquée aux cas suivants :

• Ensembles de variables non-numériques (p. ex., longueur)
• Boucles, y compris dans les cas d’utilisation
• Structures de données enregistrées
• Objets physiques (y compris la mémoire)
• Activités limitées en temps

Limitations/Difficultés

Comme la précision de cette technique dépend de la justesse de l’identification des partitions d’équivalence, elle est sujette aux mêmes limitations et difficultés. L’Analyste de Test devrait ainsi comprendre les incréments des partitions valides et invalides pour être capable de déterminer précisément les valeurs à tester. Seules des partitions ordonnées peuvent être utilisées pour l‘analyse des valeurs limites mais cela ne se limite pas à un ensemble d’entrées valides. Par exemple, lors du test du nombre de cellules gérées par une feuille de calcul, il y aura une partition contenant le nombre de cellules jusqu’à un maximum inclus dans la partition (sur la limite) et une autre partition commençant avec une cellule au-dessus du maximum (au-delà de la limite).

Couverture

La couverture est déterminée en prenant le nombre de limites testées et en divisant par le nombre de limites identifiées (en utilisant la méthode des deux ou des trois valeurs). Cela donnera un pourcentage de couverture pour le test des limites.

Types de Défauts

L’analyse des valeurs limites permet de trouver des déplacements ou des omissions de limites, et peut détecter des cas de dépassement des limites. Cette technique trouve des défauts relatifs à la gestion des valeurs limites, en particulier des erreurs dues à trop peu ou trop de logique (c.à.d., déplacement). Elle peut aussi être utilisée pour trouver des défauts non-fonctionnels, par exemple de tolérance ou de limites de charge (p. ex., le système gère 10,000 utilisateurs simultanés).

3.2.3  Tables de Décision

Les tables de décision sont utilisées pour tester les interactions entre des combinaisons de conditions. Les tables de décision apportent une méthode claire pour vérifier les tests de toutes les combinaisons de conditions possibles et pour vérifier que toutes les combinaisons possibles sont gérées par le logiciel testé. Le but du test par table de décision est d’assurer que toutes les combinaisons de conditions sont testées. En essayant de tester toutes les combinaisons possibles, les tables de décisions peuvent devenir très grandes. Une méthode appelée « test par table de décision réduite » consiste à réduire intelligemment les nombre de combinaisons à partir de toutes celles possibles vers celles qui sont « intéressantes ». Avec cette technique, les combinaisons sont réduites à celles produisant des sorties différentes, et tous les tests redondants ou irréalistes sont supprimés. La décision d’utiliser des tables de décision entières ou réduites est en général basée sur les risques.

Application

Cette technique est en général appliquée aux niveaux de test intégration, système et acceptation. En fonction du code, elle peut aussi être appliquée au test de composant, lorsqu’un composant est chargé d’un ensemble de décisions logiques. Cette technique est particulièrement utile quand les exigences sont représentées sous la forme de diagrammes de flux ou de tables de règles métier. Les tables de décision sont également une technique de définition des exigences et certaines spécifications d’exigences peuvent être faites directement dans ce format. Même lorsque les exigences ne sont pas représentées sous forme de tableau ou de diagrammes de flux, des combinaisons de conditions sont en général présentes dans le texte. Lors de la création des tables de décision, il est important de prendre en compte les combinaisons de conditions définies mais aussi celles qui ne sont pas expressément définies mais qui existeront. Pour concevoir une table de décision valide, le testeur doit être capable de dériver toutes les sorties attendues pour toutes les combinaisons de conditions à partir de la spécification ou de l’oracle de test. C’est seulement lorsque toutes les conditions d’interactions sont prises en compte que la table de décision constituera un bon outil de conception des tests.

Limitations/Difficultés

Trouver toutes les conditions d’interaction peur s’avérer difficile, en particulier lorsque les exigences sont mal formulées ou n’existent pas. Il n’est pas inhabituel de s’apercevoir, lors de la préparation d’un ensemble de conditions que le résultat attendu est inconnu.

Couverture

La couverture minimale pour une table de décision est d’avoir un cas de test pour chaque colonne. Cela suppose qu’il n’y a pas de conditions composées et que toutes les combinaisons de conditions possibles ont été saisies dans une colonne. Lors de la définition de test à partir d’une table de décision, il est aussi important de considérer toutes les conditions aux limites devant être testées. Ces conditions aux limites peuvent entraîner une augmentation du nombre de cas de tests nécessaires pour tester le logiciel de façon adéquate. L’ analyse des valeurs limites et les partitions d’équivalence sont complémentaires à la technique des tables de décision.

Types de Défauts

Des défauts typiques peuvent être un traitement incorrect pour des combinaisons de conditions particulières générant des résultats inattendus. Pendant la création d’une table de décisions, des défauts peuvent être trouvés dans le document de spécification. Les types de défauts les plus communs sont des omissions (aucune information sur ce qui doit réellement se passer dans une situation précise). Le test peut également trouver des problèmes avec des combinaisons de  conditions non gérées ou mal gérées.

3.2.4  Graphes de Cause à Effet

Les graphes de cause à effet peuvent être obtenus à partir de toute source décrivant la logique fonctionnelle (c.à.d., les “règles”) d’un programme, telle que les « user stories » ou les diagrammes de flux. Ils peuvent être utiles pour obtenir une vision globale graphique de la structure logique d’un programme et sont notamment utilisés pour créer les tables de décision. Documenter des décisions sous forme de graphes de cause à effet et/ou table de décisions permet d’atteindre une couverture de test systématique de la logique du programme.

Application

Les graphes de cause à effet s’appliquent dans les mêmes situations que les tables de décisions et s’appliquent aux mêmes niveaux de test. En particulier, un graphe de cause à effet montrera des combinaisons de conditions aboutissant à des résultats (causalité), des combinaisons de conditions excluant des résultats (not), des conditions multiples devant obligatoirement être vraies pour causer certains résultats (and) et des conditions alternatives pouvant être vraies pour causer un résultat particulier (or). Ces relations, sont en général plus faciles à voir avec un graphe de cause à effet qu’avec une description textuelle.

Limitations/Difficultés

Les graphes de cause à effet demandent, en comparaison avec d’autres techniques de conception des tests, du temps et un effort supplémentaires pour leur apprentissage. Ils nécessitent également le soutien d’un outil. Les graphes de cause à effet ont leur propre notation qui doit être comprise par le créateur et par le lecteur du graphe.

Couverture

Chaque branche de cause à effet doit être testée, y compris les conditions de combinaisons, pour atteindre la couverture minimale. Les graphes de cause à effet fournissent un moyen de définir des contraintes sur les données et des contraintes dans un flux logique.

Types de Défauts

Ces graphes trouvent les mêmes types de défauts combinatoires que les tables de décisions. De plus, la création des graphes aide à définir le bon niveau de détail dans les bases de test, et par conséquent, aide à améliorer le détail et la qualité de ces bases de test, et aide le testeur à identifier des exigences manquantes.

3.2.5  Test de Transition d’Etat

Le test de transition d’état permet de tester la capacité d’un système à entrer dans des états définis et à en sortir par des transitions valides et invalides. Des événements particuliers font passer le système d’un état à un autre et déclenchent certaines actions. Les événements peuvent être associés à des conditions qui influencent le chemin de transition à prendre. Par exemple, l’évènement correspondant à une connexion avec un nom d’utilisateur et un mot de passe valides donnera lieu à une transition différente de celle déclenchée par une connexion avec un mauvais mot de passe.

Les transitions d’état sont suivies soit dans un diagramme de transition d’état montrant toutes les transitions valides entre les états, de façon graphique ; soit avec une table d’états montrant toutes les transitions possibles, valides ou invalides.

Application

Le test de transition d’état peut s’appliquer à tout logiciel ayant des états définis et étant sensible à des événements qui déclencheront des transitions entre ces états (p. ex., un changement d’écrans). Le test de transition d’état peut être utilisé à tous les niveaux de test. Les logiciels embarqués, les logiciels web, et tout type de logiciels transactionnels sont de bons candidats à ce type de test. Les systèmes de contrôle, (c.à.d., les contrôleurs de feux de circulation), sont aussi de bons candidats pour ce type de test.

Limitations/Difficultés

La détermination des états est souvent la chose la plus difficile dans la définition des tables ou diagrammes d’état. Lorsque le logiciel dispose d’une interface utilisateur, les différents écrans affichés sont souvent utilisés pour définir les états. Pour les logiciels embarqués, les états peuvent dépendre des états que le matériel prendra.

En plus des états en eux-mêmes, l’unité de base d’un test de transition d’état est la transition seule, aussi appelé aiguillage-0 (0-switch). Le simple test de toutes les transitions trouvera certains défauts de transition d’état, mais davantage de défauts seront trouvés par les tests de séquences de transactions. Une séquence de deux transactions successives sera appelée aiguillage-1, une séquence de trois transactions successives sera appelée aiguillage-2, et ainsi de suite (ces  aiguillages sont parfois appelés aiguillages N-1 , où N représente le nombre de transactions qui seront traversées. Une simple transaction, par exemple un aiguillage-0, est désignée par application de la formule aiguillage 1-1.

Couverture

Comme avec d’autres techniques de test, il y a une hiérarchie des niveaux de couverture de test. Le degré minimum de couverture acceptable est d’avoir visité chaque état et traversé chaque transition. Une couverture des transitions à 100% (aussi appelée 100% de couverture d’aiguillage-0 ou 100% de couverture logique des branches) garantira que chaque état est visité et chaque transition traversée, à moins que la conception du système ou le modèle de transition d’état (diagramme ou table) soit incorrect. En fonction des relations entre les états et les transitions, il peut être nécessaire  de traverser certaines transitions plusieurs fois afin d’exécuter d’autres transitions au moins une fois.

Le terme “aiguillage-n ” correspond au nombre de transitions couvertes. Par exemple, atteindre 100% de couverture d’aiguillage-1 demande à ce que toute séquence valide de deux transitions successives soit testée au moins une fois. Ce test pourrait faire apparaître certains types d’ erreur de couverture que 100% d’aiguillage-0 manquerait.

Une “couverture Aller-Retour” correspond aux situations dans lesquelles les séquences de transitions forment des boucles. 100% de « couverture Aller-Retour » est obtenu lorsque toutes les boucles partant d’un état et revenant vers ce même état ont été testées. Cela doit être testé pour tous les états inclus dans des boucles.

Pour chacune de ces approches, un degré de couverture encore plus important pourra être atteint en essayant d’inclure toutes les transitions invalides. La couverture des exigences et la couverture des différents jeux pour le test de transition d’état doit identifier si les transitions invalides sont incluses.

Types de Défauts

Les principaux défauts trouvés peuvent être des traitements incorrects dans l’état courant à cause des traitements faits dans un état précédent, des transitions incorrectes ou non supportées, des états qui n’ont pas de sortie et le besoin d’états ou de transitions supplémentaires. Pendant la création du modèle de machine à états, des défauts peuvent être trouvés dans le document de spécification. Les types de défauts fréquents sont les omissions (aucune information sur ce qui doit réellement se passer dans une certaine situation) et les contradictions.

3.2.6  Techniques de Test Combinatoire

Le test combinatoire est utilisé lors du test de logiciel avec plusieurs paramètres, chacun avec plusieurs valeurs, ce qui aboutit à davantage de combinaisons que ce qui est faisable dans le temps imparti. Les paramètres doivent être indépendants et compatibles dans la mesure où il doit être possible de combiner toute option d’un facteur avec n’importe quelle fonction d’un autre facteur. La classification arborescente permet à certaines combinaisons d’être exclues, si certaines options ne sont pas compatibles. Cela ne veut pas dire que les facteurs combinés ne s’influenceront pas, au contraire, mais qu’ils s’influenceront de façon acceptable.

Le test combinatoire offre une façon d’identifier un sous-ensemble adéquat de ces combinaisons pour atteindre un certain niveau de couverture. Le nombre d’éléments à inclure dans les combinaisons peut être sélectionné par l’Analyste de Test, y compris des éléments seuls, des paires, des ensembles de trois éléments et plus. Différents outils existent pour aider l’Analyste de Test dans cette tâche (voir www.pairwise.org pour des exemples). Ces outils demandent à ce que les paramètres et leurs valeurs soient listés (test par paires et tests par tableaux orthogonaux) ou graphiquement représentés (classification arborescentes). Le test par paires est une méthode appliquée pour tester des paires de variables combinées. Les tableaux orthogonaux sont  des tableaux prédéfinis, mathématiquement justes qui permettent à l’Analyste de Test de remplacer les éléments à tester pour les variables dans un tableau, en produisant un ensemble de combinaisons qui atteindront un certain niveau de couverture lors du test. Des outils de classification arborescente permettent à l’Analyste de Test de définir la taille des combinaisons à tester (c.à.d., combinaison de deux valeurs, trois valeurs, etc.).

Application

Le problème d’un nombre de combinaisons trop important se manifeste dans au moins deux situations liées au test. Certains cas de test contiennent plusieurs paramètres, chacun avec plusieurs valeurs possibles, par exemple un écran avec plusieurs champs de saisie. Dans ce cas, les combinaisons de valeurs constituent les données d’entrée pour les cas de test. De plus, certains systèmes se configurent selon un nombre important de dimensions, ce qui donne un très grand nombre de configurations possibles. Dans ces deux situations, le test combinatoire peut être utilisé pour identifier un sous-ensemble de combinaisons de taille raisonnable.

Pour les paramètres ayant un grand nombre de valeurs, les partitions de classes d’équivalence, ou un autre mécanisme de sélection, peuvent être appliqués en premier lieu, à chaque paramètre individuellement, pour réduire le nombre de valeur pour chaque paramètre, avant que le test combinatoire ne soit appliqué pour réduire l’ensemble des combinaisons obtenues.

Ces techniques sont en général appliquées aux niveaux de test intégration, système et intégration système.

Limitations/Difficultés

La principale limitation avec ces techniques est l’hypothèse que les résultats de quelques tests seront représentatifs de tous les tests et que ces quelques tests représentent l’utilisation cible. Si une interaction inattendue entre certaines variables se produit, elle ne sera pas forcément détectée par ce type de test, si cette combinaison particulière n’est pas testée. Ces techniques peuvent être difficiles à expliquer à un public non technique pour qui la réduction logique des tests pourra être difficile à comprendre.

Il est parfois difficile d’identifier les paramètres et leurs valeurs respectives. Il est difficile d’obtenir à la main le plus petit ensemble possible permettant d’atteindre un certain niveau de couverture. En général des outils sont utilisés pour trouver cet ensemble minimal de combinaisons. Certains outils permettent de forcer l’inclusion ou l’exclusion de (sous-) combinaisons dans la sélection finale. Cette possibilité peut être utile à l’Analyste de Test pour accentuer ou réduire certains facteurs selon la connaissance du domaine ou les informations sur l’usage du produit.

Couverture

Il y a différents niveaux de couverture. Le plus bas niveau de couverture est appelé « 1-wise » ou couverture de singleton. Il demande à ce que chaque valeur de chaque paramètre soit présente dans au moins l’une des combinaisons choisies. Le niveau de couverture suivant est appelé « 2-wise » couverture de paires. Il demande à ce que chaque paire de valeurs possible soit incluse dans au moins une combinaison. Cette idée peut être généralisée à la couverture « n-wise », qui demandera à ce que toute combinaison de valeurs possible pour n paramètres soit incluse dans l’ensemble de combinaisons sélectionnées. Plus le n est élevé, plus le nombre de combinaisons nécessaires pour atteindre 100% de couverture est important. La couverture minimale avec des techniques est d’avoir un cas de test pour chaque combinaison produite par l’outil.

Types de Défauts

Les défauts les plus communs trouvés avec ce type de test sont les défauts liés aux combinaisons de valeurs avec plusieurs paramètres.

3.2.7 Test de Cas d’Utilisation

Le test de cas d’utilisation fournit des tests de transactions basés sur les scénarios qui simulent l’usage du système. Des cas d’usage sont définis en termes d’interactions entre les acteurs et le système qui effectue des actions. Les acteurs peuvent être des utilisateurs ou des systèmes extérieurs.

Application

Le test des cas d’utilisation est en général appliqué aux niveaux de test système et acceptation. Il peut être utilisé pour le test d’intégration en fonction du niveau d’intégration et même au niveau composant en fonction du comportement du composant. Les cas d’utilisation servent souvent de base au test de performance parce qu’ils représentent un usage réaliste du système. Les scénarios décrits dans les cas d’utilisation peuvent être affectés à des utilisateurs virtuels pour créer une charge réaliste sur le système.

Limitations/Difficultés

Pour être valides, les cas d’utilisation doivent représenter des transactions réalistes avec l’utilisateur. L’information doit provenir d’un utilisateur ou d’un représentant des utilisateurs. La valeur d’un cas d’utilisation est diminuée si celui-ci ne représente pas les activités d’un utilisateur réel. Pour que la couverture de test puisse être rigoureuse, il est important de disposer d’une description précise des différents chemins (flux) possibles. Les cas d’utilisation doivent être considérés comme un guide, mais pas comme une définition exhaustive de ce qui doit être testé car ils ne fournissent pas systématiquement une définition claire de l’ensemble des exigences. Il peut également être intéressant de créer d’autres modèles, tels que des diagrammes de flux, à partir de la description des cas d’utilisation, pour améliorer la précision du test et pour vérifier le cas d’utilisation lui-même.

Couverture

La couverture minimale d’un cas d’utilisation consiste à avoir au moins un cas de test pour le principal chemin possible, et un cas de test pour chaque chemin ou flux alternatif. Les chemins alternatifs incluent les chemins concernant les exceptions et les défaillances. Les chemins alternatifs sont parfois considérés comme des extensions du chemin principal. Le pourcentage de couverture est déterminé en prenant le nombre de chemins testés et en divisant par le nombre total de chemins principaux et alternatifs.

Types de Défauts

Les défauts pourront être la mauvaise gestion de scénarios définis, l’absence de prise en compte de chemins alternatifs, le mauvais traitement de certaines conditions et une gestion des erreurs  imprécise ou incorrecte.

3.2.8  Test de «User Story»

Dans certaines méthodes Agile , telles que Scrum, les exigences sont préparées sous la forme de

« user stories » décrivant des petites unités fonctionnelles pouvant être conçues, testées et montrées dans une même itération [Cohn04]. Ces « user stories » comprennent une description de la fonctionnalité à développer, d’éventuels critères non-fonctionnels, et aussi des critères d’acceptation devant être satisfaits pour que la « »user story» » soit considérée terminée.

Application

Les « user stories » sont d’abord utilisées en environnement Agile et dans tout autre environnement itératif et incrémental du même type. Elles sont utilisées à la fois pour les tests fonctionnels et pour les tests non-fonctionnels. Les «user stories» sont utilisées à tous les niveaux de test avec comme attente, la démonstration par le développeur de la fonctionnalité développée pour la «user story» avant la remise du code aux membres de l’équipe en charge des tâches de test des niveaux suivants. (p. ex., intégration, performance).

Limitations/Difficultés

Comme les «user stories» sont de petits incréments de fonctionnalité, il peut être nécessaire de développer des pilotes et des bouchons pour réellement tester la partie de fonctionnalité qui est délivrée. Cela nécessite en général de la programmation et l’utilisation d’outils qui aideront à tester, comme des outils de test d’ IHM (Interface Homme Machine). La création de « drivers » et de bouchons est en général sous la responsabilité du développeur, même si un Analyste Technique de Test peut aussi être impliqué dans la production de code et l’utilisation d’outils de test d’ IHM. Si un modèle d’intégration continue est utilisé, comme dans le cas de la plupart des projets Agiles, les besoins de pilotes et bouchons sont réduits.

Couverture

La couverture minimale d’une «user story» consiste à vérifier que chacun des critères d’acceptation spécifiés a été satisfait.

Types de Défauts

Les défauts sont en général fonctionnels lorsque le logiciel ne parvient pas à fournir la fonctionnalité spécifiée. D’ autres défauts trouvés sont des problèmes d’intégration de la fonctionnalité de la nouvelle «user story» avec la fonctionnalité déjà existante. Comme les «user stories» peuvent être développées indépendamment, des défauts de performance, d’interface et de gestion des erreurs peuvent être trouvées. Il est important pour l’Analyste de Test de réaliser non seulement le test de la fonctionnalité  livrée  individuellement mais  aussi le  test d’intégration  à chaque fois  qu’une nouvelle «user story» est testée.

3.2.9  Analyse par Domaine 

Un domaine est un ensemble défini de valeurs. Ce domaine peut être défini comme une plage de valeur pour une simple variable (un domaine à une dimension, p. ex., “les hommes âgés de 24 à 66 ans”), ou comme plusieurs plages de valeurs pour des variables associées (un domaine à plusieurs dimensions, p. ex., “les hommes âgés de 24 à 66 ans ET ayant un poids compris entre 69 et 90 kg “). Pour un domaine à plusieurs dimensions, chaque cas de test doit inclure les valeurs nécessaires pour chaque variable concernée.

L’analyse par domaine pour un domaine à une dimension utilise en général les partitions d’équivalence et l’ analyse des valeurs limites. Une fois les partitions définies, l’Analyste de Test sélectionne pour chaque partition des valeurs correspondant à une valeur qui est dans la  partition (IN), une valeur à l’extérieur de la partition (OUT), une valeur sur la limite de la partition (ON) et une valeur juste sous la limite de la partition (OFF). Avec ces valeurs, chaque partition est testée avec ses conditions aux limites.

Avec des domaines à plusieurs dimensions, le nombre de cas de test générés par ces méthodes augmente de façon exponentielle avec le nombre de variables concernées, alors qu’une approche par domaine débouche en théorie sur une croissance linéaire. De plus, comme l’approche formelle intègre une théorie sur les défauts (un modèle de fautes), qui manque aux partitions d’équivalence et à l’analyse des valeurs limites, cet ensemble de tests réduit pourra trouver des défauts dans des domaines à plusieurs dimensions, que les plus grands ensembles de test heuristique ne trouveraient pas forcément. Avec des domaines à plusieurs dimensions, le modèle de test peut être construit comme une table de décision (ou “matrice de domaine”). L’identification des valeurs des cas de test pour des domaines à plusieurs dimensions nécessitera en général un support outillé.

Application

L’analyse par domaine combine les techniques utilisées pour les tables de décisions, les partitions d’équivalence et l’analyse des valeurs limites pour créer un ensemble réduit de tests qui couvre néanmoins les domaines importants et les domaines sujets aux défaillances. Elle est souvent appliquée dans les cas où les tables de décisions seraient inappropriées à cause du trop grand nombre de variables pouvant interagir. L’analyse par domaine peut être utilisée à tous les niveaux de test mais est le plus souvent utilisée aux niveaux intégration et système.

Limitations/Difficultés

Réaliser une analyse par domaine demande une bonne compréhension du logiciel afin de pouvoir identifier les différents domaines et les interactions possibles entre les domaines. Si un domaine est oublié, il manquera des tests, mais il est probable que le domaine soit détecté parce que des variables OFF et OUT pourraient se trouver dans le domaine non détecté. L’analyse par domaine est une technique puissante à utiliser lors du travail de définition des domaines de test avec le développeur.

Couverture

La couverture minimale pour l’analyse par domaine est d’avoir un test pour chaque valeur IN, OUT, ON et OFF dans chaque domaine. Lorsqu’il y a un chevauchement de valeurs (par exemple, la valeur OUT d’un domaine est la valeur IN d’un autre domaine), il n’est pas utile de dupliquer les tests. Grâce à cela, les tests réellement nécessaires sont souvent moins de quatre par domaine.

Types de Défauts

Les défauts peuvent être des problèmes fonctionnels au sein du domaine, la gestion des valeurs limites, des problèmes d’interaction de variables et de gestion d’ erreur (en particulier pour les valeurs n’appartenant pas à un domaine valide).

3.2.10  Combiner les Techniques

Il arrive que des techniques soient combinées pour créer des cas de test. Par exemple, les conditions identifiées dans une table de décision peuvent donner lieu à des partitions d’équivalence pour découvrir différentes façon de satisfaire une condition. Les cas de test couvriront alors non seulement toutes les combinaisons de conditions, mais aussi, pour les conditions qui auront donné lieu à des partitions, les partitions d’équivalence couvertes par les cas de tests supplémentaires. Lors de la sélection de la technique particulière à appliquer, l’Analyste de Test devrait se demander si la technique est applicable, quelles sont les limitations et difficultés, et quels sont les objectifs du test en termes de couverture et de défauts à détecter. Il n’y aura pas forcément « LA » technique pour une situation donnée. Une combinaison de technique offrira souvent la couverture la plus large à condition qu’il y ait suffisamment de temps et les bonnes compétences pour correctement appliquer les techniques.

3.3 Techniques basées sur les défauts

3.3.1    Utiliser les Techniques Basées sur les Défauts (K2)

Une technique de conception des tests basée sur les défauts utilise le type de défaut recherché comme base pour la conception des tests, avec des tests dérivés systématiquement de ce que l’on sait des types de défauts. A la différence du test basé sur les spécifications, qui dérive ses tests des spécifications, le test basé sur les défauts dérive les tests de taxonomies de défauts (c.à.d., des listes par catégorie) pouvant être totalement indépendantes du logiciel testé. Les taxonomies peuvent inclure des listes de types de défauts, de causes racines, de symptôme de défaillances et de toute autre donnée relative à des défauts. Le test basé sur les défauts peut aussi utiliser, pour cibler le test, des listes de risques identifiés et de scénario de risque. Cette technique de test permet que testeur de cibler un type spécifique de défaut ou de travailler de façon systématique avec une taxonomie de défauts regroupant les défauts connus et répandus d’un type particulier. L’Analyste de Test utilise des données de taxonomie pour déterminer l’objectif du test, qui est de trouver un type de défaut spécifique. A partir de ces éléments, l’Analyste de Test pourra créer les cas de test et conditions de test provoquant le défaut, s’il existe.

Application

Le test basé sur les défauts peut être appliqué à tous les niveaux de test mais est en général utilisé lors du test système. Des taxonomies standard existent pour les différents types de logiciels. Ce type de test indépendant du produit aide à améliorer la connaissance des standards industriels utilisés pour dériver des cas de test. En suivant des taxonomies spécifiques à l’industrie, des métriques relatives à l’occurrence des défauts peuvent être suivies tout au long des projets et même au sein des organisations.

Limitations/Difficultés

Il existe de nombreuses taxonomies des défauts spécifiques à un type de test particulier, l’utilisabilité par exemple. Il est important de choisir la taxonomie applicable au logiciel testé, si elle existe. Par exemple, il n’y aura pas forcément de taxonomie propre au logiciel innovant. Certaines organisations pourront avoir compilé leurs propres taxonomies pour le logiciel innovant. Certaines organisations pourront avoir compilé leurs propres taxonomies de défauts probables ou fréquemment rencontrés. Quelle que soit la taxonomie utilisée, il est important de définir la couverture attendue avant de commencer à tester.

Couverture

Cette technique apporte des critères de couverture qui sont utilisés pour déterminer à quel moment tous les cas de test utiles auront été définis. En pratique, le critère de couverture pour une technique basée sur les défauts aura tendance à être moins systématique que pour une technique basée sur les spécifications puisque seules des règles générales de couverture sont données et puisque l’appréciation du degré de couverture nécessaire reste personnel. Comme avec d’autres techniques, le critère de couverture ne signifie pas que tous les tests ont été exécutés, mais plutôt que les défauts étudiés ne permettent plus de créer des tests supplémentaires utiles avec cette technique.

Types de Défauts

Les types de défauts découverts dépendent en général de la taxonomie utilisée. Si une taxonomie propre aux IHM est utilisée, la majeure partie des défauts trouvés portera sur l ’IHM, mais d’autres défauts peuvent être découverts comme résultats de cette technique de test.

3.3.2 Taxonomie de Défauts (K4)

Les taxonomies de défauts sont des listes de types de défauts organisées par catégories. Ces listes peuvent être très générales et utilisées pour servir de directives à haut niveau ou peuvent être très spécifiques. Par exemple, une taxonomie utilisée pour des IHM pourrait contenir des termes généraux comme : fonctionnalité, gestion des erreurs, affichage graphique et performance. Une taxonomie détaillée pourrait inclure la liste de tous les objets graphiques possibles (en particulier pour une interface graphique utilisateur) et pourrait décrire une mauvaise gestion de ces objets comme :

• Zone de texte
  • Une donnée valide n’est pas acceptée
  • Une donnée valide est acceptée
  • La longueur d’une entrée n’est pas vérifiée
  • Des caractères spéciaux ne sont pas détectés
  • Des messages d’erreur pour les utilisateurs ne sont pas clairs
  • L’utilisateur ne peut pas corriger une erreur de saisie
  • Aucune règle n’est appliquée
• Champ de saisie de la date
  • Des dates valides ne sont pas acceptées
  • Des dates invalides ne sont pas rejetées
  • Les plages de dates ne sont pas vérifiées
  • La précision des données n’est pas gérée correctement (p. ex.., hh:mm:ss)
  • L’utilisateur ne peut pas corriger une donnée erronée
  • Aucune règle n’est appliquée (p. ex.., la date de fin doit être supérieure à la date de début)

Il existe beaucoup de taxonomies de défauts, allant de taxonomies formelles, pouvant être achetées, à des taxonomies sur mesure, faites pour les besoins spécifiques d’une organisation. Des taxonomies de défauts développées en interne peuvent aussi être utilisées pour cibler des défauts spécifiques

trouvés dans l’organisation. Lors de la création d’une nouvelle taxonomie de défauts ou lors de l’adaptation d’une existante, il est important de définir les buts et objectifs de la taxonomie. Par exemple, le but peut être d’identifier des problèmes d’interface utilisateur ayant été découverts sur des systèmes en production ou d’identifier des problèmes relatifs à la gestion des champs de saisie d’entrées.

Pour créer une taxonomie:

1. Créer un but et définir le niveau de détail désiré
2. Sélectionner une taxonomie existante pour l’utiliser comme base
3. Définir les valeurs et les défauts le plus souvent rencontrés dans l’organisation et/ou dans des pratiques extérieures

Plus la taxonomie est détaillée, plus elle sera longue à développer et à maintenir, mais cela doit permettre d’augmenter la productivité dans les résultats de test. Des taxonomies détaillées peuvent être redondantes mais elles permettent à l’équipe de test de se répartir le test sans perte d’information ou de couverture.

Une fois que la taxonomie la plus adaptée a été sélectionnée, elle peut être utilisée pour créer des conditions de test et des cas de test. Une taxonomie basée sur les risques peut aider le test à se concentrer sur un domaine spécifique. Des taxonomies peuvent également être utilisées pour des domaines non fonctionnels tels que l’utilisabilité, la performance, etc. Des listes de taxonomies sont offertes par différentes publications de l’IEEE, et sur Internet.

3.4 – Techniques basées sur l’expérience

Les tests basés sur l’expérience utilisent les compétences et l’intuition des testeurs, avec leur expérience sur des applications ou technologies similaires. Ces tests permettent de trouver des défauts mais ne sont pas aussi appropriés que d’autres techniques pour atteindre certains niveaux de couverture de test, ou pour produire des procédures de test réutilisables. Lorsque la documentation  du système est pauvre, que le temps consacré au test est très réduit ou que l’équipe de test a une forte expertise dans le système à tester, le test basé sur l’expérience peut être une bonne alternative  à des approches plus structurées. Le test basé sur l’expérience peut être inadapté à des systèmes demandant une documentation de test détaillée, une parfaite répétabilité ou la capacité à mesurer précisément la couverture de test.

En utilisant des approches dynamiques ou heuristiques, les testeurs s’appuient normalement sur les tests basés sur l’expérience, et le test est plus réactif aux événements que des approches de test planifiées à l’avance. De plus l’exécution et l’évaluation sont des tâches concurrentes. Certaines approches structurées des tests basés sur l’expérience ne sont pas entièrement dynamiques, (c.à.d., que les tests ne sont pas entièrement créés au moment où le testeur exécute les tests).

Même si certaines notions de couverture sont présentées pour les techniques discutées, les techniques basées sur l’expérience n’ont pas de critères de couverture formels.

3.4.1  Estimation d’Erreur (K2)

Avec la technique de l’estimation d’erreur, l’Analyste de Test utilise l’expérience pour deviner les erreurs potentielles pouvant avoir été faites lors de la conception et du développement du code. Une fois les erreurs attendues identifiées, l’Analyste de Test détermine les meilleures méthodes à utiliser pour découvrir les défauts associés. Par exemple, si l’Analyste de Test prévoit des erreurs du logiciel lors de l’introduction d’un mot de passe invalide, des tests seront conçus pour entrer un nombre important de valeurs différentes dans le champ mot de passe afin de voir si l’erreur a réellement été faite et a produit une défaillance visible lors de l’exécution des tests.

En plus de son utilisation comme technique de test, l’estimation d’erreur est aussi utile lors de l’analyse de risque pour identifier les différents modes de défaillance possibles.

Application

L’estimation d’erreur est utilisée principalement lors des tests d’intégration et des tests système, mais peut être utilisée à tous les niveaux de test. Cette technique est souvent utilisée conjointement à d’autres techniques et permet d’élargir le périmètre des tests existant. L’estimation d’erreur peut aussi être utilisée efficacement lors du test de la nouvelle version d’un logiciel, afin de commencer à tester les défauts et erreurs les plus fréquents avant de commencer des tests plus rigoureux et sous formes de script. Des check-lists et taxonomies peuvent aider à guider le test.

Limitations/Difficultés

La couverture est difficile à évaluer et varie beaucoup en fonction des capacités et de l’expérience de l’Analyste de Test. Elle sera plus efficace avec un testeur expérimenté habitué aux différents types de défauts les plus souvent introduits dans le code testé. L’estimation d’erreur est souvent utilisée mais rarement documentée et, par conséquent, peut être moins reproductible que d’autres formes de test.

Couverture

Lorsque l’on utilise une taxonomie, la couverture est déterminée selon les erreurs de données et les types de défauts correspondants. Sans taxonomie, la couverture est limitée par l’expérience et la connaissance du testeur, ainsi que par le temps disponible. L’intérêt de cette technique sera variable et fonction de la capacité du testeur à bien cibler les domaines problématiques.

Types de Défauts

Les principaux défauts sont en général ceux issus de la taxonomie retenue, ou “devinés” par l’Analyste de Test, et qui n’ont pas été trouvés par les tests basés sur les spécifications.

3.4.2 Test basé sur les check-lists (K3)

Avec la technique du test basé sur les check-lists, l’Analyste de Test expérimenté, utilise une liste de haut niveau d’éléments à noter, à vérifier, à mémoriser, ou un ensemble de règles et critères par rapport auxquels un produit doit être vérifié. Ces check-lists sont construites sur la base d’un ensemble de standards, de l’expérience et d’autres considérations. On peut citer comme exemple de test basé sur les check-lists, une check-list relative aux interfaces graphiques utilisée comme base pour les tests.

Application

Le test basé sur les check-lists est le plus efficace dans les projets disposant d’une équipe de test expérimentée, connaissant bien le logiciel à tester ou le domaine couvert par la check-list (p. ex., pour appliquer efficacement une check-list portant sur l’interface utilisateur, l’Analyste de Test peut être habitué au test d’interface utilisateur, mais pas spécifiquement au logiciel testé). Comme les check- lists sont en général de haut niveau et ne fournissent habituellement pas les étapes détaillées que l’on trouve dans les cas de test et les procédures de test, la connaissance du testeur est utilisée pour combler les manques. Sans étapes détaillées, les check-lists sont faciles à maintenir et peuvent être appliquées à de nombreuses livraisons du même type. Les check-lists peuvent être utilisées à tous les niveaux de test. Elles sont également utilisées pour le test de régression et le test fumigatoire.

Limitations/Difficultés

Le caractère de haut niveau des check-lists peut limiter la possibilité de reproduire les résultats de test. Des testeurs différents pourront interpréter différemment une même check-list et suivre des approches différentes pour satisfaire les éléments de la check-list. Cela peut entraîner des résultats différents, malgré l’utilisation d’une même check-list. Cela peut aboutir à une couverture plus large, mais parfois au détriment de la possibilité de reproduire les résultats de test. Les check-lists peuvent aussi conduire à une confiance excessive par rapport au niveau de couverture atteint, puisque le test

reste à l’appréciation du testeur. Les check-lists peuvent être dérivées de cas de tests ou de listes détaillées et ont tendance à grossir avec le temps. Leur maintenance est nécessaire pour assurer qu’elles couvrent les principaux aspects du logiciel testé.

Couverture

La couverture dépend de la check-list mais, compte-tenu de la nature de haut niveau des check-lists, les résultats seront différents en fonction de l’Analyste de Test qui appliquera la check-list.

Types de Défauts

Les principaux défauts trouvés avec cette technique seront des défaillances dues à une variation des données, de l’ordre des étapes ou du workflow général lors du test. L’utilisation de check-lists peut aider à garder un test renouvelé puisque de nouvelles combinaisons de données et de processus sont possibles durant le test.

3.4.3  Test Exploratoire (K4)

Le Test Exploratoire se caractérise par la réalisation simultanée par le testeur de la découverte du produit et de ses défauts, de la planification du travail de test à faire, de la conception et de l’exécution des tests, et du reporting des résultats. Le testeur ajuste dynamiquement les objectifs de test lors de l’exécution et ne conçoit qu’une documentation réduite.

Application

Un bon test exploratoire est géré, interactif et créatif. Il demande peu de documentation sur le  système à tester et est souvent utilisé lorsque la documentation n’est pas disponible ou n’est pas adaptée à d’autres techniques de test. Le test exploratoire est souvent utilisé pour compléter d’autres techniques de test et pour servir de base au développement de cas de test supplémentaires.

Limitations/Difficultés

Le test exploratoire peut être difficile à gérer et à programmer. Sa couverture est sporadique et il est difficile à reproduire. L’une des méthodes utilisée pour gérer le test exploratoire est d’utiliser des chartes pour identifier les domaines à couvrir lors d’une session de test, et de limiter le temps pour préciser celui à consacrer au test. A la fin d’une session ou d’un ensemble de sessions de test, le Test Manager peut organiser une réunion de “débriefing” pour collecter les résultats des tests et définir des chartes pour les sessions futures. Les réunions de “débriefing” sont difficiles à organiser pour les grandes équipes ou les grands projets.

Une autre difficulté avec les sessions de test exploratoire est de les suivre précisément dans un système de gestion des tests. Cela se fait parfois en créant des cas de test qui sont en fait des sessions de test exploratoire. Cela permet de suivre le temps alloué au test exploratoire, ainsi que la couverture prévue, avec les autres efforts de test.

Le test exploratoire étant peu reproductible, des problèmes peuvent survenir lorsqu’il faut se souvenir des étapes nécessaires pour reproduire une défaillance. Certaines organisations utilisent les fonctionnalités de capture/rejeu d’un outil d’automatisation des tests pour enregistrer les étapes suivies par le testeur. Cela apporte un enregistrement complet de toutes les activités suivies lors de la session de test exploratoire (ou lors de toute autre session de test basé sur l’expérience). Rechercher dans les petits détails pour trouver la cause réelle d’une défaillance peut être fastidieux mais il y a au moins un enregistrement de toutes les étapes suivies.

Couverture

Des chartes peuvent être créées pour spécifier les tâches, les objectifs et les livrables. Des sessions exploratoires sont alors planifiées pour atteindre ces objectifs. La charte peut aussi préciser à quel endroit doit être concentré l’effort de test, ce qui fait ou ne fait pas partie de la session de test, et quelles ressources devraient être engagées pour accomplir les tests prévus. Une session peut aussi se concentrer sur un type particulier de défauts et sur d’autres domaines pouvant être sources de problèmes et que l’on peut traiter sans utiliser des scripts formels de test.

Types de Défauts

Les principaux types de défauts trouvés avec le test exploratoire sont liés à des problèmes de scénario non détectés lors des tests fonctionnels basés sur des scripts, à des problèmes se produisant entre des valeurs limites, et à des problèmes liés à des « workflows ». Des problèmes de performance et de sécurité sont aussi parfois découverts lors du test exploratoire.

3.4.4  Appliquer la meilleure technique

Les techniques basées sur les défauts et sur l’expérience nécessitent la mise en œuvre d’une connaissance des défauts et d’une expérience dans le domaine du test pour cibler le test afin d’augmenter le taux de détection des défauts. Elles vont du « test rapide » dans lequel le testeur n’a pas formellement préparé les activités à réaliser, aux sessions documentées, en passant par des activités simplement planifiées. En général, elles sont toujours utiles, en particulier dans les contextes suivants:

• Aucune spécification disponible
• Le système sous test est très peu documenté
• Manque de temps consacré à la conception et à la création de tests détaillés
• Testeurs disposant d’une forte expérience dans le domaine et/ou la technologie
• Objectif de maximiser la couverture des tests avec des tests complémentaires aux tests documentés
• Nécessité d’analyser des défaillances opérationnelles

Les techniques basées sur les défauts et sur l’expérience sont également utiles lorsqu’elles sont utilisées avec des techniques basées sur les spécifications, car elles couvrent les trous dans la couverture de test dus aux faiblesses typiques de ces techniques. Comme avec les techniques basées sur les spécifications, il n’existe pas une seule technique parfaite pour toutes les situations. Il est important pour l’Analyste de Test de comprendre les avantages et les inconvénients de chaque technique et d’être capable de sélectionner la meilleure technique ou la meilleure combinaison de techniques pour une situation donnée, en prenant en compte le type de projet, le planning, l’accès à l’information, les compétences du testeur et tout autre facteur pouvant influencer la sélection.

Les tests basés sur l’expérience utilisent les compétences et l’intuition des testeurs, avec leur expérience sur des applications ou technologies similaires. Ces tests permettent de trouver des défauts mais ne sont pas aussi appropriés que d’autres techniques pour atteindre certains niveaux de couverture de test, ou pour produire des procédures de test réutilisables. Lorsque la documentation  du système est pauvre, que le temps consacré au test est très réduit ou que l’équipe de