Syllabus ISTQB Test Manager

Un challenge universel de la Gestion des Tests est la bonne sélection, allocation et priorisation des tests. C’est à dire que, à partir d’un nombre pratiquement infini de conditions de test et de combinaisons de conditions qui devraient être couvertes, l’équipe de test doit sélectionner un ensemble fini de conditions, déterminer la quantité appropriée d’effort à affecter de façon à couvrir chaque condition avec des cas de tests, et ordonner les cas de test résultant selon un ordre de priorisation qui optimise l’efficacité et la rentabilité du travail de test à faire. L’identification et l’analyse des risques, ainsi que d’autres facteurs, peuvent être utilisées par le Test Manager pour aider à résoudre ce problème, bien que de nombreuses contraintes interagissent et que des variables puissent nécessiter une solution de compromis.

2.3.1    Test Basé sur les Risques (K2)

Le risque est la possibilité d’un événement négatif ou non désiré. Les risques existent chaque fois qu’un quelconque problème peut survenir et dégrader la perception de qualité du produit ou le succès du projet pour un client, un utilisateur ou une autre partie prenante. Lorsque l’effet initial d’un problème potentiel est sur la qualité du produit, alors on parle de risques qualité, de risque produit, ou de risque qualité du produit. Lorsque l’effet initial d’un problème potentiel impacte le succès du projet, on parle de risque projet ou de risque de planning.

Dans le test basé sur les risques, les risques qualité sont identifiés et évalués lors d’une analyse des risques qualité du produit avec les parties prenantes. Ensuite, l’équipe de test conçoit, implémente et exécute les tests pour mitiger les risques qualité. La qualité inclut la totalité des fonctionnalités, comportements, caractéristiques et attributs affectant les clients, les utilisateurs et la satisfaction des parties prenantes. Ainsi, un risque qualité est une situation potentielle où des problèmes qualité pourraient exister dans un produit. Des exemples de risques qualité pour un système incluent, des erreurs de calcul dans des rapports (un risque fonctionnel lié à la précision), des temps de réponse lents suite à une saisie utilisateur (un risque non-fonctionnel lié à l’efficacité et au temps de réponse), et une difficulté à comprendre des écrans ou des champs de saisie (un risque non fonctionnel lié à l’utilisabilité et à la facilité de compréhension). Quand des tests découvrent des défauts, les tests auront réduit les risques qualité en les découvrant et en permettant de les traiter avant la livraison. Si les tests ne découvrent pas de défauts, le test aura mitigé les risques qualité en assurant que, dans les conditions du test, le système fonctionne correctement.

Le test basé sur les risques utilise les risques qualité pour sélectionner les conditions de test, allouer l’effort de test pour ces conditions, et prioriser les cas de test correspondants. Différentes techniques existent pour le test basé sur les risques, avec des différences significatives à la fois dans le type et le niveau de documentation collectée et dans le niveau de formalisme appliqué. Que ce soit de façon explicite ou de façon implicite, le test basé sur les risques a pour objectif d’utiliser les tests pour réduire le niveau de risque qualité global, et plus précisément, de réduire ce niveau de risque jusqu’à un niveau acceptable.

Les tests basés sur les risques consistent en quatre activités principales :

• L’identification des risques
• L’évaluation des risques
• La mitigation des risques
• La gestion des risques

Ces activités se recouvrent. Les sous-sections suivantes décriront chacune d’elles.

Pour être le plus efficace, l’identification et l’évaluation des risques devraient impliquer des représentants de tous les groupes de parties prenantes du projet et du produit, cependant parfois les réalités du projet font que certaines parties prenantes agissent comme substitut d’autres parties prenantes. Par exemple, dans un développement logiciel grand public, un petit échantillon de clients potentiels peut se voir demander d’identifier des défauts potentiels qui impacteraient le plus leur utilisation du logiciel ; dans ce cas, l’échantillon de clients potentiels sert de substitut à l’ensemble de la base clients. Du fait de leur expertise particulière avec les risques qualité du produit et les défaillances, les testeurs devraient être activement impliqués dans le processus d’identification et évaluation des risques.

2.3.1.1  Identification des Risques

Les parties prenantes peuvent identifier les risques via une ou plusieurs des techniques suivantes :

• Entretiens avec des experts
• Évaluations indépendantes
• Utilisation de templates de risque
• Rétrospectives de projets
• Groupe de travail sur les risques
• Brainstorming
• Check-lists
• Rappel d’expérience passées

En impliquant un échantillon le plus large possible de parties prenantes, le processus d’identification des risques aura le plus de chance de trouver les risques qualité de produit les plus significatifs.

L’identification des risques produit souvent d’autres livrables, p.ex., l’identification de problèmes qui ne sont pas des risques qualité de produit. Cela peut inclure des questions générales ou des soucis sur le produit ou le projet, ou des problèmes dans les documents référencés comme les exigences ou les spécifications de conception. Des risques projet sont aussi souvent identifiés lors de l’identification des risques qualité mais ne sont pas l’objet principal des tests basés sur les risques. Cependant, la gestion des risques projet est importante pour tout le test, pas seulement pour les tests basés sur les risques, et ceci est discuté plus avant dans la Section 2.4.

2.3.1.2  Evaluation des Risques

Une fois les risques identifiés, l’évaluation des risques, qui correspond à l’étude de ces risques, peut commencer. Spécifiquement, l’analyse des risques implique la catégorisation de chaque risque et la détermination de sa probabilité et de son impact. L’évaluation des risques peut aussi impliquer l’évaluation ou l’affectation de différentes propriétés à chaque risque, comme le propriétaire du risque.

La catégorisation des risques signifie affecter à chaque risque un type approprié tel que performances, fiabilité, fonctionnalité et ainsi de suite. Certaines organisations utilisent les caractéristiques qualité du standard ISO 9126 [ISO9126] (qui est en cours de remplacement par le standard [ISO25000]), mais beaucoup d’organisations utilisent d’autres schémas de catégorisation. La check-list d’identification des risques est souvent utilisée pour catégoriser ces risques. Il existe des check-lists génériques pour les risques qualité et beaucoup d’organisations les adaptent. Lorsque des check-lists sont utilisées comme base pour identifier les risques, la catégorisation intervient souvent durant l’identification.

Déterminer le niveau de risque implique généralement l’évaluation, pour chacun des risques, de la probabilité d’occurrence et de l’impact lié à l’occurrence. La probabilité d’occurrence est la probabilité que le problème potentiel existe dans le système en cours de test. En d’autres termes, la probabilité est l’évaluation du niveau du risque technique. On peut citer comme facteurs influençant la probabilité pour les risques produit et projet :

• La complexité de la technologie et des équipes
• Les questions de personnel et de formation entre les analystes métier, les concepteurs et programmeurs
• Les conflits au sein de l’équipe
• Les problèmes contractuels avec les fournisseurs
• La répartition géographique d’une équipe distribuée
• Les anciens systèmes contre les nouvelles approches
• Les outils et les technologies
• Une mauvaise gestion technique ou managériale
• Des pressions liées aux délais, aux ressources et au budget
• L’absence d’assurance qualité précoce
• Un fort taux de changement
• Un taux de défauts précoces élevé
• Les questions d’interface et d’intégration

L’impact en cas d’occurrence est la sévérité de l’effet sur les utilisateurs, clients ou autres parties prenantes. Parmi les facteurs influençant les risques projet et produit, on peut citer :

• La fréquence d’utilisation de la fonctionnalité affectée
• La criticité de la caractéristique dans l’accomplissement de l’objectif métier
• La dégradation de la réputation
• La perte commerciale
• Les pertes financières, écologiques, sociales ou juridiques potentielles
• Des sanctions légales, civiles ou pénales
• La perte de licence
• L‘absence de solutions de contournement acceptables
• La visibilité de la défaillance générant une contre publicité
• La sûreté et la sécurité

Le niveau de risque peut être évalué soit quantitativement, soit qualitativement. Si probabilité et impact peuvent être évalués quantitativement, les deux valeurs peuvent être multipliées l’une par l’autre pour calculer une priorité quantitative du risque. Typiquement cependant, le niveau de risque ne peut être évalué que de façon qualitative. Cela dit, il est possible de parler de priorité très haute, haute, moyenne, faible ou très faible, mais une priorité ne peut être exprimée par un pourcentage précis ; de même, il est possible de parler d’impact très haut, haut, moyen, faible ou très faible, mais l’impact ne peut être exprimé en termes financiers de façon précise et complète. Cette évaluation qualitative des niveaux de risque ne devrait pas être considérée comme moins valable que les approches quantitatives ; en effet, si l’évaluation quantitative des niveaux de risque n’est pas utilisée de façon appropriée, les résultats tromperont les parties prenantes concernant la façon de comprendre et de gérer les risques. Les évaluations qualitatives des niveaux de risque sont souvent combinées, par des multiplications ou des additions pour créer un score de risque agrégé. Ce score de risque agrégé peut être exprimé comme un numéro de priorité du risque mais devrait être interprété comme une valeur qualitative par rapport à une échelle ordinale.

De plus, à moins que l’analyse de risque ne soit basée sur des données de risques extensives et statistiquement valides, l’analyse de risques devra se baser sur l’appréciation subjective des parties prenantes en ce qui concerne la probabilité et l’impact. Les chefs de projet, programmeurs, utilisateurs, analystes métiers, architectes et testeurs ont typiquement des perceptions différentes et ainsi probablement des options différentes sur le niveau de risque à attribuer à chaque risque. Le processus d’analyse de risque devrait inclure une manière d’atteindre un consensus ou, dans le pire des cas, d’établir un niveau de risque convenu (par ex., selon une consigne de la direction ou en prenant la moyenne, ou la médiane du niveau proposé pour le risque). De plus, les niveaux de risque devraient être vérifiés pour s’assurer d’une bonne distribution sur leur échelle de valeurs et pour assurer que les taux de risques apportent des informations utiles en termes d’ordonnancement, de priorisation et d’allocation de l’effort de test. Sinon, les niveaux de risque ne pourront pas être utilisés comme guides lors des activités de réduction des risques.

2.3.1.3  Mitigation des Risques

Le test basé sur les risques commence par une analyse des risques qualité (identification et évaluation des risques qualité du produit). Cette analyse est la base du plan de test maître et des autres plans de test. Comme indiqué dans le ou les plan(s), les tests sont conçus, implémentés et exécutés de façon à couvrir les risques. L’effort associé au développement et à l’exécution d’un test est proportionnel au niveau de risque, ce qui signifie que des techniques de test plus méticuleuses (comme le test par paires) sont utilisées pour les risques les plus élevés, alors que des techniques moins méticuleuses (telles que les partitions d’équivalence ou le test exploratoire par périodes de temps) seront utilisées pour des risques moins élevés. De plus, la priorité du développement et de l’exécution du test est basée sur le niveau de risque. Certains standards liés à la sûreté (par ex., FAA DO-178B/ED 12B, IEC 61508), prescrivent les techniques de test et le degré de couverture en fonction du niveau de risque. De plus, le niveau de risque doit influencer les décisions comme l’utilisation de revues des livrables du projet (incluant les tests), le niveau d’indépendance, le niveau d’expérience des testeurs et le degré de test de confirmation (re-test) et de test de non-régression à réaliser.

Durant le projet, l’équipe de test devrait rester attentive à toute information complémentaire pouvant modifier l’ensemble des risques qualité et/ou le niveau de risque associé aux risques qualité connus. Des ajustements périodiques de l’analyse des risques qualité, entraînant des ajustements dans les tests, devraient être effectués. Ces ajustements devraient avoir lieu au minimum lors de chaque jalon majeur du projet. Les ajustements incluent l’identification de nouveaux risques, la réévaluation du niveau des risques existants et l’évaluation de l’efficacité des activités de mitigation des risques. Pour prendre un exemple, si une session d’identification et évaluation des risques a eu lieu sur la base des spécifications d’exigences, une fois la spécification finalisée, une réévaluation des risques devrait avoir lieu. Pour prendre un autre exemple, si pendant les tests un composant est identifié comme contenant considérablement plus d’erreurs que prévu, on peut conclure que la probabilité de défauts à cet endroit a été plus élevée qu‘anticipé et par conséquent ajuster à la hausse la probabilité et le niveau de risque global. Cela pourrait résulter en un accroissement de l’effort de tests à exécuter pour ce composant.

Les risques qualité du produit peuvent aussi être mitigés avant le début de l’exécution des tests. Par exemple, si des problèmes avec les exigences sont identifiés pendant l’identification des risques, l’équipe projet peut implémenter des revues de spécifications d’exigence comme action de mitigation. Cela peut réduire le niveau de risque, ce qui pourra signifier que moins de tests seront nécessaires pour mitiger les risques qualité restants.

2.3.1.4  Gestion des Risques dans le Cycle de Vie

Idéalement, la gestion des risques à lieu tout au long du cycle de vie. Si une organisation a un document de politique de test et/ou de stratégie de test, alors ceux-ci devraient décrire le processus général de gestion des risques produit et des risques projet par le test, et montrer comment la gestion des risques est intégrée et affecte toutes les étapes du test.

Dans une organisation mature où la sensibilisation aux risques imprègne l’équipe de projet, la gestion des risques est présente à différents niveaux et pas seulement pendant le test. Les risques importants ne sont pas seulement traités plus tôt lors d’un niveau de test particulier, mais aussi lors de niveaux de test précédents (Par exemple, si les performances sont perçues comme un fort risque qualité, les tests de performance apparaîtront au début des tests système mais des tests de performance seront exécutés pendant les tests unitaires et les tests d’intégration). Les organisations matures non seulement identifient les risques, mais aussi les sources de risques et les conséquences de ces risques s’ils devaient se produire. Pour les défauts qui apparaissent, une analyse des causes racines est utilisée pour mieux comprendre les sources de risques et implémenter des améliorations de processus qui préviendront l’apparition des défauts. La mitigation existe tout au long du cycle de développement logiciel. L’analyse de risque est complètement informée, prenant en compte le travail associé, l’analyse du comportement du système, l’évaluation des risques basée sur les coûts, l’analyse des risques produit, l’analyse des risques des utilisateurs finaux et l’analyse des responsabilités. L’analyse des risques transcende le test, avec l’équipe de test participant à et influençant une analyse de risque au niveau du programme.

La plupart des méthodes du test basé sur les risques comprennent aussi des techniques pour utiliser le niveau de risque pour ordonnancer et prioriser le test, assurant ainsi une couverture précoce des zones les plus importantes et une découverte des défauts les plus importants pendant l’exécution des tests. Dans certains cas, tous les tests correspondant à un risque de haut niveau sont exécutés avant les tests couvrant des niveaux de risques plus faibles, et les tests sont exécutés strictement dans l’ordre du niveau de risque (souvent appelé “parcours en profondeur”); dans d’autres cas, une méthode d’échantillonnage est utilisée pour sélectionner un échantillon de tests parmi tous ceux identifiés en utilisant les risques pour pondérer la sélection tout en s’assurant en même temps que chaque élément de risque est couvert au moins une fois (souvent appelé “parcours en largeur”).

Que le test basé sur les risques effectue un parcours en profondeur ou un parcours en largeur, il est possible que le temps alloué au test soit épuisé avant que tous les tests soient exécutés. Le test basé sur les risques permet aux testeurs d’informer leur hiérarchie en termes de niveau de risque résiduel à ce moment, et permet à la hiérarchie de décider de prolonger le test ou de transférer les risques restants aux utilisateurs, clients, équipes de support/soutien technique et/ou opérationnelles.

Pendant l’exécution des tests, les techniques de test basé sur les risques les plus sophistiquées — qui n’ont pas besoin d’être les plus formelles ou les plus lourdes — permettent aux participants du projet, aux responsables projet et produit, à la hiérarchie, aux responsables seniors et aux parties prenantes du projet, de mesurer et contrôler le cycle de développement logiciel, en prenant les décisions de livraison sur la base du niveau de risque résiduel. Cela demande que le Test Manager communique les résultats des tests en termes de risques de façon compréhensible par chacune des parties prenantes.

La documentation est souvent produite dans le cadre des activités de Gestion des tests. Même si les noms précis des documents de Gestion des Tests et le périmètre de chacun des documents ont tendance à varier, les types de documents suivants sont en général trouvés dans les organisations et les projets :

• Politique de test – décrit les objectifs et les finalités du test pour l’organisation
• Stratégie de test – décrit les méthodes de test générales et indépendantes des projets au sein de l’organisation
• Plan de test maître (ou plan de test projet) – décrit l’implémentation de la stratégie de test sur un projet particulier
• Plan de test de niveau (ou plan de test de phase) – décrit les activités précises à mettre en œuvre pour chaque niveau de test

L’organisation physique de ces différents types de documents peut varier d’un contexte à un autre. Dans certaines organisations et sur certains projets, ils peuvent être combinés en un seul document ; dans d’autres, on peut trouver des documents séparés ; et dans certains cas leur contenu peut s’avérer intuitif, non documenté, ou correspondre à une méthodologie traditionnelle de test. Des organisations et projets plus grands et plus formels tendent à avoir tous ces types de livrables sous forme de livrables écrits, alors que des organisations et projets plus petits et moins formels tendent à avoir en général moins de livrables documentés ainsi. Ce syllabus décrit séparément chacun de ces types de documents, cependant en pratique le contexte de l’organisation ou du projet détermine la bonne utilisation de chacun.

2.4.1    Politique de Test (K4)

Le politique de test décrit pourquoi l’organisation teste. Cela définit les objectifs généraux que l’organisation veut atteindre pour le test. Cette politique devrait être développée par une personne expérimentée (senior) en Gestion des Tests au sein de l’organisation, en collaboration avec des responsables seniors appartenant aux différentes parties prenantes impliquées.

Dans certains cas, la politique de test viendra compléter ou fera partie d’une politique qualité plus large. Cette politique qualité décrit les valeurs et objectifs de la hiérarchie associés à la qualité.

Quand une politique de test écrite existe, il peut s’agir d’un document court, de haut niveau qui:

• Résume la valeur que l’organisation dégage du test
• Définit les objectifs du test, tels qu’acquérir de la confiance dans le logiciel, détecter des défauts dans le logiciel, et réduire le niveau de risque qualité (voir Section 3.1)
• Décrit comment évaluer l’efficacité et la rentabilité des tests pour atteindre ces objectifs
• Décrit le processus de test typique, éventuellement en utilisant comme base les processus de test fondamentaux de l’ISTQB
• Spécifie comment l’organisation améliorera ses processus de test (voir Chapitre 5)

La politique de test devrait s’appliquer aux activités de test pour un nouveau développement comme pour les activités de maintenance. Elle peut aussi se référer à des standards internes et/ou externes pour les livrables du test et la terminologie à utiliser dans l’organisation.

2.4.2    Stratégie de Test (K4)

La stratégie de test décrit la méthodologie générale de l’organisation. Cela inclut la façon d’utiliser le test pour gérer les risques produit et les risques projet, la séparation en niveaux de test et les activités de haut niveau associées au test. (Une même organisation peut avoir différentes stratégies pour différentes situations, telles que différents cycles de développement logiciel, différents niveaux de risques, ou différentes exigences réglementaires). La stratégie de test, et les processus et activités qu’elle décrit, devraient être en accord avec la politique de test. Elle devrait fournir les critères d’entrée et de sortie génériques pour l’organisation ou pour un ou plusieurs programmes.

Comme indiqué ci-dessus, les stratégies de test décrivent des méthodologies de test habituelles qui incluent typiquement :

• Les stratégies analytiques, telles que le test basé sur les risques, où l’équipe de test analyse la base de test pour identifier les conditions de test à couvrir. Par exemple, avec le test basé sur les exigences, l’analyse des tests dérive les conditions de test à partir des exigences, des tests sont alors conçus et implémentés pour couvrir ces conditions. Les tests sont ensuite exécutés, en utilisant souvent la priorité des exigences couvertes par chaque test pour déterminer l’ordre d’exécution des tests. Les résultats de test sont rapportés en termes de statut des exigences, p.ex., exigences testées avec succès, exigences testées en échec, exigences partiellement testées, exigences dont le test est bloqué, etc.
• Les stratégies basées sur les modèles, comme le profiling opérationnel, où l’équipe de test développe un modèle (basé sur des situations réelles ou anticipées) de l’environnement dans lequel le système existe, des entrées et conditions auxquelles le système est soumis, et comment le système devrait se comporter. Par exemple, pour du test de performances basé sur des modèles d’une application mobile grandissant rapidement, on pourrait développer des modèles de trafic réseau entrant et sortant, d’utilisateurs actifs ou inactifs, et des charges de traitement associées, basées sur l’utilisation actuelle et la croissance du projet dans le temps. De plus, des modèles pourraient être développés en considérant l’environnement de production matériel et logiciel actuel, ses données, son réseau et son infrastructure. Des modèles peuvent aussi être développés pour des taux de transmission, des temps de réponses et des allocations de ressources, idéaux, attendus ou minimum.
• Les stratégies méthodiques, telles que celles basées sur les caractéristiques qualité, où l’équipe de test utilise un ensemble prédéterminé de conditions de test, comme un standard qualité (p. ex., ISO 25000 [ISO25000] qui est en train de remplacer l’ISO 9126 [ISO9126]), une check-list ou une collection de conditions de test logiques pouvant correspondre à un domaine particulier, à une application particulière ou à un type de test particulier (p. ex., test de sécurité), et qui utilise cet ensemble de conditions de test d’une itération à la suivante ou d’une release à la suivante. Par exemple, dans du test de maintenance d’un site de e- commerce stable, les testeurs pourraient utiliser une check-list identifiant les fonctions principales, les attributs et les liens pour chaque page. Les testeurs couvriraient chaque élément pertinent de cette check-list pour chaque modification faite sur le site.
• Les stratégies basées sur un processus ou un standard, telles que pour des systèmes médicaux soumis aux standards de la “Food and Drug Administration” américaine, où l’équipe de test suit un ensemble de processus définis par un comité de standardisation ou un autre panel d’experts, où les processus traitent la documentation, la bonne identification et utilisation de la base de test et des oracles de test, ainsi que l’organisation de l’équipe de test. Par exemple, avec des projets suivant les techniques de management Scrum de l’approche agile, à chaque itération les testeurs analysent les user stories décrivant des fonctionnalités particulières, estiment l’effort de test pour chaque fonctionnalité lors du processus de planification de l’itération, identifient pour chaque user story les conditions de test (souvent appelées critères d’acceptation), exécutent les tests couvrant ces conditions, et documentent le statut de chaque user story (non testée, en échec, passée) pendant l’exécution des tests.
• Les stratégies réactives, telles que les attaques basées sur des défauts, où l’équipe de test attend la livraison du logiciel avant de commencer à concevoir et implémenter les tests, réagissant au système réellement en cours de test. Par exemple, en utilisant du test exploratoire sur une application à base de menus, un ensemble de chartes ou agréments peuvent être développés, correspondant aux particularités, aux sélections dans le menu, et aux différents écrans. Chaque testeur se voit affecté un ensemble de chartes de test lesquelles sont utilisées ensuite pour structurer leurs sessions de test exploratoire. Les testeurs rapportent régulièrement les résultats de leurs sessions de test au Test Manager, qui peut ajuster les chartes de test en conséquence.
• Les stratégies consultatives, telles que du test dirigé par les utilisateurs, où l’équipe de test s’appuie sur les entrées d’une ou de plusieurs des principales parties prenantes pour déterminer les conditions de test à couvrir. Par exemple, lors du test, sous-traité, de compatibilité pour une application web, une société peut donner au sous-traitant en charge du test externalisé une liste priorisée de versions de navigateurs, d’ anti-virus, de systèmes d’exploitation, de types de connexion, et autres options de configuration à évaluer pour son application. Le fournisseur de service de test peut alors utiliser des techniques telles que le test par paires (pour les options les plus prioritaires) et les partitions d’équivalence (pour les options les moins prioritaires) pour générer des tests.
• Les stratégies anti-régression, telles que l’automatisation extensive, où l’équipe de test utilise différentes techniques pour gérer le risque de régression, en particulier l’automatisation de tests de non-régression fonctionnelle et/ou non-fonctionnelle à un ou plusieurs niveaux. Par exemple, pour le test de non-régression d’une application web, les testeurs peuvent utiliser un outil d’automatisation basé sur l’interface utilisateur pour automatiser les principaux cas d’utilisation typiques et les cas d’utilisation en exception pour l’application. Ces tests sont alors exécutés à chaque fois que l’application est modifiée.

Diverses stratégies peuvent être combinées. Les stratégies choisies devraient être appropriées pour les besoins et moyens de l’organisation, et les organisations peuvent adapter leurs stratégies pour correspondre à des opérations ou projets particuliers.

La stratégie de test peut décrire les niveaux de test à mettre en œuvre. Elle doit alors préciser les critères d’entrée et sortie à chaque niveau et les relations entre ces niveaux (par ex., la répartition des objectifs de couverture de test).

La stratégie de test peut aussi décrire les points suivants :

• Procédures d’intégration
• Techniques de spécification des tests
• Indépendance du test (qui peut varier selon le niveau)
• Standards obligatoires ou optionnels
• Environnements de test
• Automatisation des tests
• Outils de test
• Réutilisabilité des livrables de développement et des livrables de test
• Test de confirmation (re-test) et test de non-régression
• Contrôle des tests et reporting
• Mesure du test et métriques
• Gestion des défauts
• Approche de gestion en configuration des articles de test
• Rôles et responsabilités

Des stratégies de test différentes peuvent être nécessaires pour le court terme et pour le long terme. Différentes stratégies de test sont nécessaires selon les organisations et les projets. Par exemple, lorsque des applications critiques au niveau de la sécurité et de la sureté sont impliquées, une stratégie plus intensive peut être mieux adaptée que dans d’autres cas. De plus, la stratégie de test diffère aussi selon les modèles de développements.

L’estimation, en tant qu’activité de gestion, est la création d’une cible approximative pour les coûts et dates de réalisation associés à un projet particulier ou à une opération particulière. Les meilleures estimations :

• Représentent la sagesse collective d’un ensemble de praticiens expérimentés et ont le soutien des participants impliqués
• Fournissent un catalogue spécifique et détaillé des coûts, ressources, tâches et personnes impliquées
• Présentent, pour chaque activité évaluée, les valeurs les plus probables pour le coût, l’effort et la durée

L’estimation de l’ingénierie logicielle et système a longtemps été connue pour être semée d’embûches, à la fois techniques et politiques, même si les bonnes pratiques d’estimation de projet sont établies. L’estimation des tests est l’application de ces bonnes pratiques aux activités de test associées à un projet ou une opération.

L’estimation des tests devrait couvrir toutes les activités impliquées dans le processus de test comme décrit au Chapitre 1. L’estimation du coût, de l’effort et spécialement de la durée d’exécution des tests est généralement d’un grand intérêt pour le management, car l’exécution des tests est typiquement sur le chemin critique du projet. Cependant, les estimations d’exécution de tests tendent à être difficiles à produire et peu fiables quand la qualité globale du logiciel est basse ou inconnue. De plus, la familiarisation et l’expérience avec le système affecteront en général la qualité des estimations.  Une pratique commune consiste à estimer le nombre de cas de test devant être exécutés, mais ceci ne fonctionne que si l’on peut supposer que le nombre de défauts dans le logiciel à tester est faible. Les suppositions faites devraient toujours être documentées et faire partie de l’estimation.

L’estimation des tests devrait intégrer tous les facteurs pouvant influencer le coût, l’effort et la durée des activités de test. Parmi ces facteurs, on peut citer (liste non limitative) :

• Le niveau de qualité requis du système
• La taille du système à tester
• Des données historiques sur le test de projets précédents, qui peuvent être complétées par des données ou benchmark de l’industrie ou d’autres organisations
• Des facteurs liés au processus, comme la stratégie de test, le cycle de développement ou de maintenance, la maturité des processus ainsi que l’exactitude des estimations du projet
• Des facteurs matériels, incluant l’automatisation des tests et les outils, le ou les environnement(s) de test, les données de test, le ou les environnement(s) de développement, la documentation du projet (par ex., exigences, conceptions, etc.), et des livrables de test réutilisables
• Des facteurs humains, incluant les managers et responsables techniques, les engagements et les attentes de la direction exécutive et de la hiérarchie, les compétences, expériences et comportements dans l’équipe projet, la stabilité de l’équipe projet, les relations au sein de l’équipe, le support affecté à l’environnement de test et au débogage, la disponibilité de sous- traitants ou consultants compétents, et la connaissance du domaine
• La complexité du processus, de la technologie, de l’organisation, du nombre de parties prenantes du test, la composition et la localisation des sous-équipes
• Les besoins de prise de connaissance, de formations et d’orientations
• L’assimilation ou le développement de nouveaux outils, de nouvelles technologies, de nouveaux processus, de nouvelles techniques, de matériel spécifique, ou d’une grande quantité d’articles de test
• Les exigences pour un haut niveau d’informations détaillées pour la spécification des tests, spécialement pour satisfaire à standard de documentation non familier
• Un séquencement complexe dans l’arrivée des composants, spécialement pour les tests d’intégration et le développement des tests
• Des données de test fragiles (par ex., des données sensibles au temps)

La qualité du logiciel livré au test est aussi un facteur déterminant que les Test Managers devraient prendre en compte dans leurs estimations. Par exemple, si les développeurs ont adopté de bonnes pratiques comme le test unitaire automatisé et l’intégration continue, alors jusqu’à 50% des défauts seront supprimés avant la livraison du code à l’équipe de test. (Voir [Jones11] pour en savoir plus sur l’efficacité de la suppression des défauts avec ces pratiques). Certains auteurs ont indiqué que les méthodologies Agile, incluant le développement piloté par les tests, résultent en un niveau encore supérieur de qualité de ce qui est livré au test.

L’estimation peut se faire de bas en haut ou de haut en bas. Les techniques suivantes peuvent être utilisées pour l’estimation de test :

• Intuition, supposition et expérience passée
• Structure de la répartition du travail (WBS Work-breakdown-structure)
• Sessions d’estimation en équipe (par ex., Delphi à Large Bande)
• Règles et normes de la société
• Pourcentages de l’effort pour l’ensemble du projet ou du niveau des effectifs (par exemple, les ratios testeurs / développeurs)
• Historique et métriques de l’organisation, y compris les modèles dérivés de métriques qui estiment le nombre de défauts, le nombre de cycles de test, le nombre de cas de test, l’effort moyen estimé de chaque test, et le nombre de cycles de non-régression impliqués
• Des moyennes issues de l’industrie et des modèles prédictifs tels que les points de fonction, les lignes de code, l’effort de développement estimé, ou d’autres paramètres du projet.

Dans la plupart des cas, l’estimation, une fois établie, doit être fournie à la direction, avec des justificatifs (voir Section 2.7). Fréquemment, certaines négociations s’en suivent, résultant souvent en une refonte de l’estimation. Idéalement, l’estimation finale de la charge des tests représente l’équilibre optimal possible entre les objectifs du projet et ceux de l’organisation dans les domaines de la qualité, des délais, du budget, et des caractéristiques.

Il est important de se souvenir que toute estimation est basée sur l’information disponible au moment de sa préparation. Au début du projet, l’information peut être fort limitée. De plus, de l’information disponible tôt dans le projet peut changer avec le temps. Afin de rester exactes, les estimations devraient être mises à jour pour refléter les informations nouvelles ou modifiées.

Un cliché de gestion dit que tout ce qui est mesuré est fait. De plus ce qui n’est pas mesuré n’est pas fait parce que ce qui n’est pas mesuré est facile à ignorer. En conséquence, il est important qu’un ensemble adapté de métriques soit défini pour toute activité, y compris le test.

Les métriques de test peuvent être classifiées comme appartenant à une ou plusieurs des catégories suivantes :

• Métriques projet, qui mesurent le progrès au regard des critères de sortie du projet, telles que les pourcentages de cas de test exécutés, passés avec succès et en échec
• Métriques produit, qui mesurent certains attributs du produit, telles que l’étendue de ce qui a été couvert par des tests ou la densité des défauts
• Métriques processus, qui mesurent la capacité des processus de développement ou de test, telles que le pourcentage de défauts découverts par le test
• Métriques liées aux personnes, qui mesurent la capacité des individus ou groupes, telles que l’implémentation des cas de test selon un planning donné

Une métrique donnée peut appartenir à deux, trois, ou même quatre catégories. Par exemple, un graphe de tendance montrant le taux de défauts détectés par jour peut être associé à un critère de sortie (aucun nouveau défaut trouvé pendant une semaine), à la qualité du produit (le test ne peut pas trouver davantage de défauts) et à la capacité du processus de test (le test trouve un grand nombre de défauts au début de la période d’exécution des tests).

Les métriques liées aux personnes sont particulièrement délicates. Les managers confondent parfois des métriques processus avec des métriques liées aux personnes, ce qui a des conséquences désastreuses lorsque les personnes agissent pour fausser les métriques d’une façon qui leur est favorable. La bonne manière de motiver et d’évaluer les personnes impliquées dans le test est discutée au chapitre 7 de ce syllabus et dans le syllabus Expert Test Manager [ISTQB ETL SYL].

Au niveau avancé, nous sommes principalement concernés par l’utilisation de métriques pour mesurer l’avancement du test, c’est à dire, des métriques projet. Certaines de ces métriques projets utilisés pour la mesure de l’avancement du test sont liées aussi au produit et au processus. Le syllabus Expert Test Manager donne plus d’information sur la façon pour un manager d’utiliser les métriques processus. Le syllabus Expert Amélioration des Processus de Test [ISTQB ITP SYL] donne plus d’information sur l’utilisation de métriques processus.

L’utilisation de métriques permet aux testeurs de rapporter des résultats de façon consistante et permet un suivi cohérent de l’avancement dans le temps. Il est souvent demandé aux Test Managers de présenter des métriques à diverses réunions auxquelles peuvent participer plusieurs niveaux de parties prenantes, allant de l’équipe technique à la direction générale. Parce que les métriques sont souvent utilisées pour déterminer le succès global d’un projet, une grande attention devrait être portée sur ce qu’il faut mesurer, la fréquence à laquelle communiquer, et la méthode utilisée pour présenter l’information. Un Test Manager doit notamment considérer les points suivants :

• Définition des métriques. Un ensemble limité de métriques utiles devrait être défini. Les métriques devraient être définies sur la base d’objectifs spécifiques au projet, au processus et/ou au produit. Les métriques devraient être définies de façon équilibrée, une unique métrique pouvant induire une mauvaise interprétation d’un statut ou de tendances. Une fois ces métriques définies, l’interprétation doit être acceptée par toutes les parties prenantes afin d’éviter toute confusion quand les mesures seront discutées. On a souvent tendance à définir trop de métriques au lieu de se concentrer sur les plus pertinentes.
• Suivi des métriques. Le suivi et la consolidation des métriques devraient être aussi automatisés que possible pour réduire le temps passé à prendre et à traiter des mesures. Des variations dans le temps pour une métrique spécifique, peuvent refléter une information différente de l’interprétation prévue initialement. Le Test Manager devrait être préparé à analyser soigneusement les divergences possibles entre ce qui est mesuré et ce qui était attendu, et les raisons de ces divergences.
• Reporting des métriques. L’objectif est de fournir une compréhension immédiate de l’information pour les besoins de gestion. Des présentations peuvent montrer un aperçu des métriques à un instant t ou montrer leur évolution dans le temps pour évaluer des tendances.
• Validité des métriques. Un Test Manager doit aussi vérifier l’information qui est rapportée. Les mesures d’une métrique peuvent ne pas refléter le statut réel d’un projet ou peuvent fournir une tendance trop positive ou négative. Avant toute présentation de résultat, le Test Manager doit les revoir attentivement, à la fois en termes d’exactitude et des messages qui sont susceptibles d’être transmis.

L’avancement est principalement mesuré selon cinq dimensions :

• Risques produit (qualité)
• Défauts
• Tests
• Couverture
• Confiance

Les risques produit, les défauts, les tests et la couverture peuvent être et sont souvent rapportés de façon spécifique au long du projet ou de l’opération. Si ces mesures sont liées à des critères de sortie définis dans le plan de test, elles peuvent fournir un standard objectif par lequel juger la complétude de l’effort de test. La confiance est mesurable par des sondages ou en utilisant la couverture comme métrique de substitution, cependant, la confiance est souvent aussi rapportée de façon subjective.

Les métriques liées au risque produit incluent :

• Pourcentage de risques entièrement couverts par des tests passés avec succès
• Pourcentage de risques pour lesquels certains ou tous les tests sont en échec
• Pourcentage de risques n’étant pas encore complètement testés
• Pourcentage des risques couverts, triés par catégories de risques
• Pourcentage des risques identifiés après l’analyse de risque qualité initiale

Les métriques liées aux défauts incluent :

• Nombre cumulé de défauts rapportés (trouvés) versus nombre total de défauts résolus (corrigés)
• Temps moyen entre les défaillances ou taux de nouvelles défaillances
• Répartition du nombre ou du pourcentage de défauts classés par :
  • Élément ou composant de test particulier
  • Causes racines
  • Source du défaut (par ex., spécification d’exigences, nouvelle fonctionnalité, régression, etc.)
  • Version de livraison en test
  • Phase d’introduction, de détection et de résolution du défaut
  • Priorité/sévérité
  • Rapports d’anomalie rejetés ou en doublon
• Tendances en termes de durée moyenne entre découverte et résolution des défauts
• Nombre de défauts corrigés ayant introduit de nouveaux défauts (parfois appelés défauts dépendants)

Les métriques liées aux tests incluent :

• Nombre total de tests planifiés, spécifiés (implémentés), exécutés, passés avec succès, en échec, bloqués, et sautés
• Statut des tests de non-régression et de confirmation, y compris les tendances et les volumétries relatives aux défaillances lors des tests de non-régression et de confirmation
• Nombre d’heures de test prévues par jour versus nombre d’heures réellement passées à tester
• Disponibilité de l’environnement de test (pourcentage d’heures de disponibilité de l’environnement de test pour l’équipe de test)

Les métriques liées à la couverture incluent :

• Couverture des exigences et des éléments de conception
• Couverture du risque
• Couverture des environnements et des configurations
• Couverture du code

Il est important que les Test Managers comprennent comment interpréter et utiliser les métriques de couverture de manière à comprendre et informer sur le statut des tests. Pour les niveaux plus élevés de test, tels que le test des systèmes, l’intégration des systèmes, et les tests d’acceptation, les bases de test initiales sont souvent des livrables tels que des spécifications d’exigences, des spécifications de conception, des cas d’utilisation, des user stories, des risques produit, les environnements et configurations supportés. Les métriques de couverture de la structure du code s’appliquent plus à des niveaux de test inférieurs (p.ex. couverture des instructions et des branches) et l’intégration des composants (p.ex. couverture des interfaces). Bien que les Test Managers puissent utiliser les métriques de couverture de code pour mesurer le niveau atteint de couverture des structures du système en cours de test, le reporting de résultats de tests de plus haut niveau ne devrait typiquement pas inclure des métriques de couverture de code. De plus, les Test Managers devraient comprendre que, même si le test unitaire et le test d’intégration des composants atteignent 100% de leurs objectifs de couverture structurelle, des défauts et des risques qualité restent à traiter dans des niveaux de test supérieurs.

Les métriques peuvent aussi être liées aux activités des processus de test fondamentaux (décrits dans le syllabus niveau fondation et dans ce syllabus). De cette façon, les métriques peuvent être utilisées tout au long du processus de test pour mesurer le processus lui-même ainsi que l’avancement par rapport aux objectifs du projet.

Les métriques pour mesurer la planification et le suivi des tests peuvent inclure :

• La couverture des risques, des exigences et des autres éléments de la base de test
• La découverte de défauts
• Le nombre d’heures prévues versus passées pour développer le testware et exécuter les cas de test

Les métriques pour mesurer les activités d’analyse de test peuvent inclure :

• Le nombre de conditions de test identifiées
• Le nombre de défauts trouvés lors de l’analyse des tests (par ex., en identifiant les risques ou les autres conditions de test en utilisant la base de test)

Les métriques pour mesurer les activités de conception de tests peuvent inclure :

• Pourcentage des conditions de test couvertes par des cas de tests
• Nombre de défauts trouvés lors de la conception des tests (par ex., en développant des tests à partir de la base de test)

Les métriques pour mesurer les activités d’implémentation des tests peuvent inclure :

• Pourcentage d’environnements de test configurés
• Pourcentage de données de test chargées
• Pourcentage de cas de tests automatisés

Les métriques pour mesurer les activités d’exécution des tests peuvent inclure :

• Pourcentage de cas de tests exécutés, passés avec succès et en échec
• Pourcentage de conditions de test couvertes par des cas de test exécutés (et/ou passés avec succès)
• Nombre prévu versus réel de défauts trouvés/résolus
• Couverture prévue versus réalisée.

Les métriques contrôlant l’avancement du test et la complétude des activités de test incluront une correspondance (mapping) entre les jalons, les critères d’entrée, et les critères de sortie (définis et approuvés lors de la planification des tests), qui peuvent inclure les éléments suivants :

• Nombre de conditions de test, cas de tests ou spécifications de test prévus et ceux ayant été exécutés, répartis par statut (passés ou en échec)
• Nombre total de défauts, souvent classés par sévérité, priorité, état actuel, sous-système concerné, ou autre classification (voir Chapitre 4)
• Nombre de changements demandés, acceptés, implémentés et testés
• Coût prévu versus réel
• Durée prévue versus réelle
• Dates de passage des jalons de test prévues versus réelles
• Dates de passage prévues versus dates réelles pour les jalons du projet ayant un lien avec le test (par ex., fin des développements)
• Statut des risques produit (qualité), souvent classés par, risques mitigés versus non-mitigés, domaines de risques, nouveaux risques découverts après l’analyse des tests, etc.
• Pourcentage d’effort de test, de coût ou de temps perdus suite à des évènements bloquants ou des changements de planning
• Statuts des tests de confirmation et de non-régression

Les métriques pour mesurer les activités de clôture des tests peuvent inclure :

• Le pourcentage de cas de test exécutés, passés avec succès, en échec, bloqués, et sautés pendant l’exécution des tests
• Le pourcentage de cas de test identifiés comme réutilisables dans le référentiel de test
• Le pourcentage de cas de test devant être automatisés versus le pourcentage de cas de test réellement automatisés
• Le pourcentage de cas de test intégrés aux tests de non-régression
• Le pourcentage de rapports de défauts résolus/non résolus
• Le pourcentage de livrables du test identifié et archivés

De plus, les techniques de gestion de projet classiques, telles que le découpage du travail en tâches et sous-tâches (Work Breakdown Structure) sont souvent utilisées pour piloter le processus de test. Dans les équipes agiles, le test fait partie de l’avancement des user stories dans le graphe du réalisé (burn-down chart). Lorsque les techniques Lean sont utilisées, l’avancement du test, sur la base du cas par cas (story by story), est souvent piloté par le déplacement des user stories d’une colonne à une autre dans le tableau de Kanban.

Sur la base d’un ensemble donné de métriques, les mesures peuvent être rapportées de façon textuelle, avec des tableaux de chiffres ou avec des graphiques. Les mesures peuvent être utilisées avec différentes finalités, comme :

• L’analyse, pour découvrir les tendances et causes identifiables par le biais des résultats de test
• Le reporting, pour communiquer sur les découvertes des tests aux participants du projet et aux parties prenantes intéressées
• Le contrôle, pour modifier les tests ou le projet dans son ensemble et pour mesurer les résultats de ce changement d’orientation

Les bonnes manières de collecter, d’analyser et de communiquer ces mesures dépendent des besoins spécifiques en termes d’information, des objectifs et des compétences des personnes qui utiliseront ces mesures. De plus, le contenu des rapports de test devrait être adapté en fonction des destinataires.

Pour le contrôle des tests, il est essentiel que des métriques, tout au long du processus de test (une fois la planification des tests terminée) apportent au Test Manager l’information requise pour orienter l’effort de test vers l’accomplissement de la mission, des stratégies et des objectifs du test. Par conséquent, la planification des tests doit considérer ces besoins d’informations et la mesure des tests doit inclure la collecte des métriques nécessaires. Le volume d’information requis et l’effort nécessaire à cette collecte dépendent de différents facteurs du projet comme la taille, la complexité et le risque.

Le contrôle du test doit répondre à l’information générée par le test de même qu’aux changements des conditions dans lesquelles un projet ou une opération existe. Par exemple, si du test dynamique révèle des agrégats de défauts dans des domaines qui avaient été considérés comme ne devant pas contenir beaucoup de défauts, ou si la période d’exécution des tests est raccourcie à la suite d’un retard dans le démarrage des tests, l’analyse de risque et le plan devront être révisés. Cela pourrait aboutir à une re-priorisation des tests et à une réallocation de l’effort d’exécution des tests.

Si des divergences par rapport au plan de test sont découvertes par les rapports de test, le contrôle des tests devrait être réalisé. Le contrôle des tests a pour objectif de réorienter le projet et/ou le test dans une meilleure direction. Quand les résultats des tests sont utilisés pour influencer ou mesurer les efforts de contrôle d’un projet, les options suivantes devraient être envisagées :

• Révision de l’analyse des risques qualité, des priorités de test et/ou des plans de test
• Ajout des ressources ou augmenter l’effort de test ou l’effort du projet
• Retarder la date de livraison
• Assouplir ou renforcer les critères de sortie de test
• Modifier le périmètre (fonctionnel et/ou non-fonctionnel) du projet

Implémenter de telles options demande un consensus entre les parties prenantes du projet ou de l’opération et l’approbation des responsables du projet ou de l’opération.

L’information livrée dans un rapport de test devrait dépendre largement des besoins d’information de l’audience cible, par ex., responsables projet ou responsables métier. Pour un chef de projet, une information détaillée sur les défauts sera probablement utile, pour le responsable métier, le statut des risques produits pourrait être l’élément clé du rapport.

Le Test Manager doit travailler à optimiser les tests de façon à livrer la meilleure valeur ajoutée au métier. Tester de façon excessive n’apportera pas une bonne valeur métier, parce que le test imposera des délais et coûts supérieurs à ce qu’il permettrait d’économiser. Ne pas tester suffisamment, n’apportera pas une bonne valeur au métier car trop de défauts seront livrés aux utilisateurs. L’optimum se situe entre ces deux extrêmes. Le Test Manager doit aider les parties prenantes du test à comprendre cet optimum et la valeur apportée par le test.

Même si beaucoup d’organisations sont conscientes de la valeur du test, peu de managers, y compris des Test Managers, peuvent quantifier, décrire ou exprimer clairement cette valeur. De plus, beaucoup de Test Managers, responsables de test et testeurs se focalisent sur les détails tactiques du test (aspects spécifiques à une tâche ou un niveau de test), tout en ignorant les problèmes stratégiques plus larges (d’un niveau supérieur) qui importent aux autres participants, notamment les managers.

Le test fournit de la valeur à l’organisation, au projet et/ou à l’opération à la fois de façon quantitative et de façon qualitative :

• Les valeurs quantitatives incluent la découverte de défauts qui sont prévenus ou corrigés avant la livraison, la découverte de défauts qui sont connus avant la livraison (non corrigés mais documentés, si possible avec des solutions de contournements), la réduction du risque par l’exécution de tests, et la fourniture d’information sur le projet, le processus, et le statut du produit
• Les valeurs qualitatives incluent l’amélioration de la réputation en termes de qualité, la maîtrise des livraisons, une confiance accrue, la protection d’un point de vue légal, et la réduction de risques de pertes de missions, voire de vies humaines

Les Test Managers devraient identifier lesquelles de ces valeurs s’appliquent à leur organisation, projet, et/ou opération, et devraient être capables de communiquer sur les tests selon ces valeurs.

Une méthode établie pour mesurer la valeur quantitative et l’efficacité des tests est appelée le coût de la qualité(ou, parfois, coût de la non-qualité). Le coût de la qualité implique la classification des coûts du projet et des opérations selon quatre catégories relatives au coût des défauts du produit.

• Coûts de prévention, par ex., formation des développeurs pour écrire un code plus facilement maintenable ou plus sécurisé
• Coûts de détection, par ex., écrire des cas de tests, configurer les environnements de test, et revoir les exigences
• Coûts internes des défaillances, par ex., correction des défauts trouvés pendant le test ou les revues, avant la livraison
• Coûts externes des défaillances, par ex., coûts du support associé à la livraison d’un logiciel défaillant aux clients

Une partie du budget de test est un coût de détection (c.à.d., argent dépensé même si les testeurs ne découvrent pas de défauts, tels que l’argent dépensé pour développer les tests) alors que le reste est un coût interne de défaillance (c.à.d., le coût associé aux défauts trouvés). La somme des coûts de détection et des coûts internes de défaillance est généralement bien inférieure au coût externe de défaillance, ce qui rend le test très rentable. En déterminant les coûts dans ces quatre catégories, le Test Manager peut créer une étude financière convaincante en faveur du test.

Dans les syllabi niveau Fondation et Avancé, de nombreux standards sont référencés. Ces standards référencés couvrent le cycle de développement logiciel, le test logiciel, les caractéristiques qualité logicielle, les revues, et la gestion des anomalies. Les Test Managers devraient être au courant des standards, de la politique de leur organisation vis à vis des standards, et si les standards sont ou non exigés ou nécessaires pour leur travail.

Il existe différentes sources de standards, telles que :

• Internationaux ou avec des objectifs internationaux
• Nationaux, comme l’application nationale de standards internationaux
• Spécifiques à un domaine, comme les standards nationaux ou internationaux adaptés à un domaine, ou développés pour des domaines particuliers

Les organismes de standardisation incluent l’ISO et l’IEEE. ISO est l’Organisation Internationale des Standards (International Standards Organization), aussi appelée IOS, l’International Organization for Standardization. Elle est composée de membres représentants, pour leur pays, le comité national le plus pertinent pour le domaine en cours de standardisation. Cet organisme international a publié un nombre de standards utiles aux testeurs de logiciels comme, ISO 9126 (en cours de remplacement par ISO 25000), ISO 12207 [ISO 12207], et ISO 15504 [ISO 15504].

L’IEEE est l’Institut des Ingénieurs en Electricité et Electronique (Institute of Electrical and Electronics Engineers), une organisation professionnelle basée aux États-Unis, mais ayant des représentants nationaux dans plus de cent pays. Cette organisation a proposé un nombre de standards utiles aux testeurs de logiciel, tels que l’IEEE 829 [IEEE829] et l’IEEE 1028.

Beaucoup de pays ont leurs propres standards nationaux. Certains de ces standards sont utiles pour le test logiciel. Un exemple est le standard anglais BS-7925-2 [BS7925-2], qui fournit des informations relatives à de nombreuses techniques de conception des tests décrites dans les syllabi avancés Analyste de Test et Analyste Technique de Test.

Certains standards sont spécifiques à des domaines particuliers, et certains parmi eux ont des implications sur le test, la qualité et le développement des logiciels. Par exemple, dans le domaine de l’aviation, le standard DO-178B de la U.S. Federal Aviation Administration (et son équivalent européen ED 12B) s’appliquent aux logiciels utilisés dans des aéronefs civils. Ce standard prescrit certains critères de niveaux de couverture structurelle selon le niveau de criticité du logiciel testé.

Un autre exemple de standard spécifique à un domaine, est présent dans le domaine médical avec la U.S. Food and Drug Administration et le document 21 CFR Part 820 [FDA21]. Ce standard recommande certaines techniques de test structurelles et fonctionnelles. Ce standard recommande aussi des stratégies de test et des principes consistants avec les syllabi ISTQB.

Dans certains cas, le test est influencé par des standards ou méthodologies largement répandus qui ne sont pas concernés initialement par le test, mais qui influencent fortement le contexte du processus logiciel dans lequel s’exécutent les tests.  Le modèle d’amélioration des processus logiciels CMMI® en est un exemple. Il contient deux domaines de processus clé, vérification et validation, qui sont souvent assimilés à des niveaux de test (comme le test système et le test d’acceptation respectivement). Il a aussi des implications en termes de stratégie de test, souvent interprétée comme nécessitant du test analytique basé sur les exigences comme partie de la stratégie de test.

Trois autres exemples importants sont le PMBOK de PMI, PRINCE2®, et ITIL®. PMI et PRINCE2 sont des référentiels de gestion de projet largement utilisés respectivement en Amérique du Nord et Europe. ITIL est un référentiel destiné à s’assurer qu’un groupe des technologies de l’information délivre des services de valeur à l’organisation à laquelle il appartient. La terminologie et les activités spécifiées dans ces référentiels diffèrent fortement des syllabi et du glossaire ISTQB. Quand il travaille dans des organisations utilisant PMBOK, PRINCE2, et/ou ITIL, le Test Manager doit comprendre les référentiels choisis, leur implémentation, et leur terminologie suffisamment pour être efficace.

Quels que soient les standards ou méthodologies adoptés, il est important de se souvenir qu’ils ont été créés par des groupes de professionnels. Les standards reflètent l’expérience et la sagesse collective, mais aussi leurs faiblesses. Le Test Manager devrait être conscient des standards qui s’appliquent à son contexte et à son environnement, qu’il s’agisse de standards formels (internationaux, nationaux ou spécifiques à un domaine) ou de standards maison et de pratiques recommandées.

En considérant l’utilisation de multiples standards, il faut garder à l’esprit que certains standards sont inconsistants, voire contradictoires, avec d’autres standards. Le Test Manager devrait déterminer l’utilité des différents standards pour le contexte particulier dans lequel se déroule le test.  L’information mentionnée dans un standard peut être utile au projet ou au contraire lui être nuisible. Cependant, les standards peuvent fournir des références à de bonnes pratiques, et fournir une base pour l’organisation du processus de test.

Dans certains cas, la conformité à des standards est requise et à des implications sur le test. Le Test Manager doit être conscient de telles exigences de respect de standards et s’assurer que la conformité nécessaire est maintenue.