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.
|
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.
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.
|