Instructions: Décisions importantes en termes de test
Ces instructions décrivent des éléments importants à prendre en compte lors de la personnalisation des aspects de test du processus.
Relations
Description principale

Détermination de l'utilisation des produits

Décidez quels produits  utiliser et comment les utiliser.  En plus d'identifier les produits à utiliser, il est également important de personnaliser chaque produit afin qu'il soit adapté aux besoins du projet. 

Le tableau ci-dessous précise les produits de test qui sont recommandés et ceux qui sont considérés comme facultatifs (qui peuvent être utilisés uniquement dans certains cas). Pour des questions relatives à la personnalisation, voir la section s'y rapportant dans la page de description du produit.

Produit Objet Personnalisation (facultatif, recommandé)
Récapitulatif de l'évaluation du test Résume les résultats du test, principalement pour utilisation par l'équipe de gestion et les autres parties prenantes externes à l'équipe de test. Recommandé pour la plupart des projets.

Lorsque la teneur du projet consiste surtout en des informations, il peut s'avérer judicieux d'enregistrer les résultats du test et de ne de pas créer de récapitulatifs formels d'évaluation. Dans d'autres cas, les récapitulatifs d'évaluation du test peuvent être intégrés à une section d'autres produits d'évaluation, comme Evaluation d'itération ou Compte-rendu de revue.
Résultats du test Ce produit est le résultat analysé et déterminé à partir des données brutes dans un ou plusieurs journaux de test. Recommandé. La plupart des équipes de test conservent une forme d'enregistrement assez détaillée des résultats du test. Les résultats des tests manuels sont généralement enregistrés directement ici et associés aux journaux détaillés des tests automatisés.

Il arrive que les équipes de test se reportent directement aux journaux de test pour établir le récapitulatif de l'évaluation du test.
Journal de test

La sortie des données brutes lors de l'exécution du test, généralement produite par des tests automatisés.

Facultatif.

La plupart des projets exécutant des tests automatisés possèdent un journal de test. En revanche, pour certains projets, les journaux de test sont conservés après la détermination des résultats de test, alors que pour d'autres projets, ils sont supprimés.

Vous pouvez conserver des journaux de test en vue de répondre à des exigences d'audit, d'analyser les changements des données brutes de sortie du test avec le temps ou en cas de doute sur les analyses requises.

Suite de tests Sert à regrouper des tests individuels liés entre eux (scripts de test) dans des sous-ensembles pertinents. Recommandé pour la plupart des projets.

Egalement requise pour définir des séquences d'exécution de scripts de test nécessaires au bon déroulement des tests.
Liste d'idées de test Il s'agit d'une énumération d'idées de test, souvent partiellement formulées et à considérer comme aussi utiles que les tests à effectuer. Recommandé pour la plupart des projets.

Dans certains cas, ces listes sont définies et éliminées de façon informelle une fois les scripts de test ou les cas de test correspondants déterminés.
Stratégie de test Définit le plan stratégique pour le déroulement des activités de test par rapport à divers aspects du système cible. Recommandé pour la plupart des projets.

Une seule stratégie de test par projet ou par phase de projet est généralement recommandée. Vous pouvez éventuellement réutiliser des stratégies existantes si elles sont appropriées ou diviser les stratégies de test en fonction du type de test réalisé.
Plan de test Définit pour le test des objectifs, des motivations, une approche, des ressources, un calendrier et des produits de précision accrue et déterminant une itération. Recommandé pour la plupart des projets.

Un plan de test distinct par itération est recommandé pour définir la stratégie de test spécifique et détaillée. Vous pouvez éventuellement inclure le plan de test comme section dans le plan d'itération.
Plan de test Définit pour le test des objectifs, une approche, des ressources, un calendrier et des produits de haut niveau et déterminant une phase ou l'ensemble du cycle de vie. Facultatif. Utile pour la plupart des projets.

Un plan de test maître définit la stratégie de haut niveau pour l'effort de test sur de longues périodes du cycle de vie de développement du logiciel. Vous pouvez éventuellement inclure le plan de test comme section dans le plan de développement logiciel.

Décidez si vous voulez conserver un plan de test maître en plus des plans de test d'itération. Le plan de test maître couvre notamment les informations sur l'application des processus et de la logistique, lesquelles sont en général associées à l'ensemble du cycle de vie d'un projet et ne risquent pas de changer entre des itérations.
Script de test, Données de test Les scripts et les données de test incarnent la réalisation ou l'implémentation du test : les scripts sont les aspects liés aux procédures et les données les caractéristiques propres. Recommandé pour la plupart des projets.

Les projets se distinguent par la formalité du traitement des produits. Dans certains cas, ils sont informels et passagers, et l'équipe de test est évaluée en fonction d'autres critères. Dans d'autres cas en revanche, notamment avec des tests automatisés, les scripts de test et les données de test associées (ou un sous-ensemble de ces données) sont pris comme des livrables clés de l'effort de test.
Cas de test

Définit un ensemble spécifique d'entrées de test, de conditions d'exécution et de résultats attendus.

Le fait de documenter les cas de test permet leur revue pour vérifier qu'ils sont complets et corrects, ainsi que leur prise en compte avant de planifier et d'étendre l'effort d'implémentation.

Ceci est plus utile lorsque les entrées, les conditions d'exécution et les résultats attendus sont particulièrement complexes.

Cette démarche est recommandée pour la plupart des projets : que les conditions requises pour mener un test spécifique soient complexes ou extensives, vous devez définir des cas de test. Vous devrez également documenter des cas de test quand un livrable est requis de façon contractuelle.

Nous recommandons le plus souvent de conserver la liste d'idées de test et les scripts de test implémentés au lieu des cas de test détaillés.

Certains projets décrivent simplement les cas de test à un niveau élevé et laissent les détails aux scripts de test. Les informations sur les cas de test sont aussi souvent documentées en tant que commentaires dans les scripts de test.

Modèle d'analyse de la charge de travail

Un type spécialisé de cas de test. Sert à définir une charge de travail représentative pour permettre l'évaluation des risques de qualité associés au système s'exécutant sous cette charge.

Recommandé pour la plupart des systèmes, notamment quand les performances système sous la charge doivent être évaluées ou qu'il existe d'autres risques importants de qualité associés aux opérations sous la charge.

Généralement pas requis pour des systèmes qui seront déployés sur un système cible autonome.

Classes de testabilité dans le modèle de conception

Eléments de testabilité dans le modèle d'implémentation

Si le projet doit développer un autre comportement spécialisé pour adapter et prendre en charge les tests, cet aspect est symbolisé par l'insertion de classes de testabilité dans le modèle de conception et d'éléments de testabilité dans le modèle d'implémentation.

Quand cela est nécessaire.

Les modules de remplacement sont une catégorie courante de classe de test et de composant de test.

Architecture d'automatisation des tests

Fournit une vue d'ensemble de l'architecture du système d'automatisation des tests, avec plusieurs vues d'architecture illustrant les divers aspects du système.

Facultatif.

Recommandé pour des projets dont l'architecture de test est relativement complexe, avec un grand nombre d'employés participant à l'élaboration des tests automatisés, ou quand le système d'automatisation des tests doit être géré sur une longue période.

Dans certains cas, il peut simplement s'agir d'un diagramme de tableau blanc enregistré de façon centralisée pour sa consultation par les parties intéressées.

Spécification de l'interface de test

Définit un ensemble de comportements requis par un classificateur (plus précisément, une classe, un sous-système ou un composant) en vue du test (testabilité). Parmi les types courants figurent l'accès au test, le comportement modulaire, la consignation du diagnostic et les oracles de test.

Facultatif.

Pour de nombreux projets, l'accessibilité au test est suffisante dans les opérations visibles sur des classes, des interfaces utilisateur, etc.

Certaines raisons courantes motivant la création de spécifications de l'interface de test incluent les extensions de l'interface graphique (pour les interactions avec l'outil) et les routines de consignation des messages de diagnostic, notamment pour les traitements par lots.



Déterminer comment réviser des produits

Cette section vous fournit des instructions pour décider comment réviser les produits de test. Pour des informations générales, voir Instructions : Niveaux de revue.

Incidents

Le traitement des revues d'incidents dépend grandement du contexte ; elles sont cependant généralement traitées comme informelles, formelles-internes ou formelles-externes. Ce processus de revue est souvent appliqué ou du moins assisté par la gestion des enchaînements d'activités dans un système de suivi des incidents. Généralement, le niveau de formalité des revues est souvent lié à la gravité perçue ou à l'impact de l'incident. Toutefois, des facteurs comme la teneur du projet et le niveau de formalisme ont une incidence sur la manière de gérer des revues.

Dans certains cas, vous devez envisager de séparer la gestion des incidents (également appelés symptômes ou échecs) de celle des fautes, c'est-à-dire la véritable source de l'erreur. Pour de petits projets, vous pouvez généralement assurer la gestion en faisant uniquement le suivi des incidents et gérer implicitement les fautes. Cependant, si le système gagne en complexité, il peut s'avérer utile de séparer la gestion des incidents de celle des fautes. Par exemple, plusieurs incidents peuvent être dus à la même faute. Par conséquent, si une faute est corrigée, il est nécessaire de rechercher les incidents signalés et d'avertir les utilisateurs ayant soumis les incidents. Ceci est uniquement possible si incidents et fautes peuvent être identifiés séparément.

Plan de test et stratégie de test

Si un projet implique des tests compliqués, il vous faut un plan ou une stratégie de test. En général, vous aurez besoin d'un plan de test pour chaque itération et un type de stratégie de test pour l'ensemble. Vous pouvez éventuellement créer et conserver un plan de test maître. Souvent, ces produits sont considérés comme informels : ils sont révisés mais pas formellement approuvés. Lorsque la visibilité du test est importante pour les parties prenantes externes à l'équipe de test, elle doit être traitée comme formelle-interne, voire formelle-externe.

Scripts de test

Les scripts de test sont généralement traités comme informels : il sont approuvés par une personne membre de l'équipe de test. Si les scripts de test sont employés par de nombreux testeurs, ainsi que partagés ou réutilisés pour divers tests, ils doivent être traités comme formels-internes.

Cas de test

Les cas de test sont créés par l'équipe de test et, en fonction du contexte, généralement révisés à l'aide d'un processus informel ou simplement pas du tout révisés. Le cas échéant, les cas de test peuvent être approuvés par d'autres membres de l'équipe, auquel cas ils peuvent être traités comme formels-internes, ou par des parties prenantes externes, auquel cas ils sont formels-externes.

Nous vous conseillons de ne réviser formellement que les cas de test qui l'exigent, ce qui concerne normalement un petit sous-ensemble illustrant les cas de test les plus importants. Par exemple, lorsqu'un client souhaite valider un produit avant de le lancer, un sous-ensemble de cas de test peut être sélectionné comme base de validation. Ces cas de test doivent alors être traités comme formels-externes.

Produits de test pour la conception et l'implémentation

Les classes de testabilité se trouvent dans le modèle de conception et les éléments de testabilité dans le modèle d'implémentation. Il existe également deux autres produits relatifs (bien que non spécifiques au test) : les packages, dans le modèle de conception, et les sous-systèmes, dans le modèle d'implémentation.

Ces produits concernent la conception et l'implémentation ; ils sont toutefois créés en vue de prendre en charge la fonctionnalité de test dans le logiciel. L'emplacement logique pour les stocker est avec les produits de conception et d'implémentation. Pensez à leur donner un nom ou un intitulé de façon à les distinguer clairement de la conception et de l'implémentation du système principal. Révisez ces produits en suivant les procédures de revue pour les produits de conception et d'implémentation.

Choisir les critères d'approbation d'itération

Au moment d'entrer chaque itération, efforcez-vous de définir clairement selon quels critères l'effort de test sera jugé suffisant et comment ce jugement sera évalué. Pour ce faire, concertez-vous avec la personne ou le groupe en charge de prendre la décision d'approbation.

Les exemples suivants illustrent des façons de gérer l'approbation d'une itération :

  • L'équipe de gestion de projet approuve l'itération et évalue l'effort de test en révisant les récapitulatifs de l'évaluation du test.
  • Le client approuve l'itération en révisant les récapitulatifs de l'évaluation du test.
  • Le client approuve l'itération en fonction des résultats d'une démonstration impliquant un sous-ensemble des tests. Ce sous-ensemble doit être défini et approuvé auparavant, de préférence au début de l'itération. Ces tests sont traités comme formels-externes et souvent qualifiés de tests de réception.
  • Le client approuve la qualité du système en menant ses propres tests. Là encore, la nature de ces tests est clairement définie et approuvée à l'avance, de préférence au début de l'itération. Ces tests sont traités comme formels-externes et souvent qualifiés de tests de réception.

Il s'agit d'une décision importante, car vous ne pouvez pas atteindre un objectif sans l'avoir d'abord défini.