Tâche: Définition des détails du test
Cette tâche explique comment détailler les idées de test au sein d'un contexte spécifique en fonction des éléments de test cibles.
Disciplines: Test
Objet

L'objectif de cette tâche est de :

  • Définir les conditions individuelles nécessaires à la réalisation d'une idée de test dans le cadre d'un contexte spécifique
  • Identifier les points d'observation et de contrôle potentiels du ou des élément(s) de test associé(s)
  • Identifier les oracles potentiels dans le but de faciliter les points d'observation
  • Fournir des ressources consommables de support de test
Relations
Etapes
Examiner la liste des éléments de test cibles et des idées de test associées
Objectif :  Mieux comprendre les éléments de test cible sur la base des idées de test possibles. 

En vous servant de la liste des idées de test comme contexte, examinez les informations disponibles sur l'élément de test cible. Le cas d'utilisation et les produits associés (par ex., réalisation de cas d'utilisation, storyboard et scénarios de cas d'utilisation) représentent généralement de bonnes sources de départ, ajoutées aux spécifications supplémentaires, aux règles métier et aux produits de conception.

Si les informations disponibles sont limitées, vous devrez peut-être discuter de l'élément de test cible directement avec l'équipe de développement.

Sélectionner un sous-ensemble d'idées de test à détailler
Objectif :  Déterminer un sous-ensemble gérable de tests pour définir les idées les plus avantageuses dans le contexte concerné. 

Examinez la liste des idées de test et sélectionnez certaines idées pour lesquelles vous allez concevoir des tests détaillés. Dans la plupart des cas, vous sélectionnerez un sous-ensemble d'idées de test sur la base de contraintes de temps, de l'adaptation au cycle de tests en cours, de l'état d'achèvement de l'élément de test cible, etc. En fonction du contexte spécifique de votre situation, le nombre d'idées de test aboutissant à une conception est chaque fois différent.

Il est recommandé d'éviter d'entreprendre une conception pour toutes les idées de test la première fois que vous utilisez cette liste. Il est préférable d'adopter une autre approche qui consiste à concentrer vos efforts sur les quelques idées susceptibles de fournir des informations d'évaluation utiles pour le cycle de tests concerné. Cela permet de diminuer le risque de perte de temps sur un élément de test cible, ce qui entraîne la négligence des autres éléments ; cela minimise également le risque d'effort concentré sur des idées de test qui se révéleraient être de peu d'intérêt par la suite.

Pour chaque idée de test, concevoir le test
Objectif :  Définir les caractéristiques clés de chaque test conçu à partir de la liste des idées de test. 

A l'aide des informations rassemblées, concevez le test en identifiant et en définissant les caractéristiques clés nécessaires à la réalisation du test. Notez que la conception du test peut être enregistrée de différentes façons :
  • Traditionnellement, la conception de test est enregistrée sou forme d'un Produit : jeu d'essai.
  • Le Produit : modèle d'analyse de la charge de travail est une forme plus spécialisée et plus complexe de jeu d'essai, au niveau de la conception, qui est liée en particulier au test des performances du système.
  • En fonction de la complexité du test et de la culture du projet, il peut être approprié de réaliser le test directement comme un Produit : script de test, une approche que vous devez envisager s'il est acceptable pour vous de ne pas créer d'artefacts de jeu d'essai. Si vous optez pour cette solution, expliquez vos scripts de test à l'aide d'informations utiles fournissant les éléments justificatifs de l'utilité du test. Ces commentaires peuvent être utilisés comme jeu d'essai informel.

A l'aide des informations rassemblées, examinez chacun des aspects suivants du test.

identifier les conditions d'entrée, de sortie et d'exécution

En considérant le test sous l'angle "boîte noire", identifiez les caractéristiques visibles externes clés qui définissent le test. Identifiez les entrées requises pour stimuler le test et les résultats escomptés. Enumérez également la ou les condition(s) d'exécution clé(s)- le "comment" de la condition d'exécution n'a pas à être expliqué ni compris à ce stade.

Notez que les entrées et les résultats escomptés porteront des valeurs - selon le test spécifique - allant des données simples (par ex. "A", "1") à des données multidimensionnelles complexes (par ex. un clip sonore ou un objet). Il est recommandé de définir les qualificatifs des entrées et des résultats escomptés plutôt que de spécifier uniquement des valeurs spécifiques. Cela permettra à la personne qui sera chargée de l'implémentation ou de l'exécution du test de bien comprendre le raisonnement qui accompagne les données de test ; elle pourra ainsi remplacer les valeurs pour appliquer des variantes de test lors d'une exécution spécifique.

identifier les points d'observation possibles

Un point d'observation est un point auquel vous observez, pendant l'exécution d'un test, certains aspects de l'état de l'environnement de test. Puisque vous connaissez les conditions d'exécution, l'entrée et les résultats escomptés, identifiez les points spécifiques qui doivent être observés pendant l'exécution du test ainsi que les données à observer.

identifier les points de contrôle possibles

Au cours de l'exécution d'un test, un point de contrôle est un point auquel vous souhaitez prendre une décision à partir de plusieurs choix possibles au sujet du flux de contrôle du test. Recherchez les scénarios de test disponibles et pour chacun d'entre eux, déterminez les points auxquels le contrôle varie en fonction des différentes exécutions du test. Assemblez les différents points de contrôle et limitez la liste aux points requis pour le cycle de test actuel.

Identifier les oracles de test appropriés

Un oracle de test combine les valeurs de résultat escompté à tester et les moyens permettant d'obtenir ces données : il s'agit donc à la fois de la réponse fournie et du moyen de l'obtenir. Par exemple, pour vérifier la représentation précise des polices utilisées dans un logiciel de traitement de texte, vous pouvez utiliser l'aperçu avant impression comme moyen de vérification de la présentation des polices. L'oracle de test identifie la forme et la fonction nécessaires pour vérifier les résultats réels du test par rapport aux résultats escomptés.

Définir les sources de données, les valeurs et les plages requises
Objectif :  Définir les valeurs de données de test requises, y compris leurs sources appropriées. 

Comme mentionné précédemment, les données de test se présentent sous de nombreuses formes.

Lorsque les données sont complexes (des interdépendances existent probablement), tentez d'utiliser des experts du domaine pour spécifier les conditions applicables aux données de test. Certains outils de productivité incluent des fonctions qui facilitent la création d'ensembles de données de test.

Etablir la source de données de test consommables suffisantes
Objectif :  Etablir la source et enregistrer suffisamment de données de test valides pour fournir un support au test. 

Lors de la définition d'un test, la création ou l'assemblage des données de test appropriées constitue l'une des tâches les plus difficiles et les plus consommatrices de temps. Cela se vérifie tout particulièrement lorsqu'un niveau intensif de données est impliqué.

Nous recommandons d'enregistrer les données de test dans Microsoft® Excel® ou dans un autre produit doté d'une interface de gestion de données tabulaire, comme par exemple Microsoft® Access®.

Gérer les relations de traçabilité
Objectif :  Permettre un compte-rendu de l'analyse et de l'évaluation de l'impact sur les éléments contrôlés. 

Utilisez les exigences de traçabilité mentionnées dans le plan de test pour mettre à jour les relations de traçabilité.

Evaluer et vérifier vos résultats
Objectif :  Vérifier que la tâche a été correctement réalisée et que les produits en résultant sont acceptables. 

Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur et que vous n'avez pas simplement consommé de grandes quantités de papier. Vous devez évaluer si votre travail est d'une qualité correcte et qu'il est assez complet pour être utile aux membres de l'équipe qui en feront un usage ultérieur comme entrée pour leur propre travail. Si possible, utilisez les listes de contrôle fournies dans RUP pour vérifier que la qualité et l'exhaustivité sont "satisfaisantes".

Faites en sorte que les personnes qui effectuent les tâches en aval, et qui se basent sur votre travail comme entrée, prennent part à la revue de votre travail intermédiaire. Effectuez cette revue pendant que vous avez encore du temps disponible pour prendre les mesures qui répondent à leurs préoccupations. Vous devez également évaluer votre travail par rapport aux produits d'entrée clés pour vous assurer que vous les avez précisément et suffisamment représentés. Il peut être utile que l'auteur du produit d'entrée revoie votre travail sur cette base.

Essayez de vous rappeler que le RUP est un processus de livraison itératif et que dans de nombreux cas, les produits évoluent au fil du temps. A ce titre, il n'est généralement pas nécessaire - et c'est même souvent contre-productif - de former complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans l'immédiat. Ceci parce qu'il y a une grande probabilité pour que la situation qui entoure le produit change - et que les hypothèses émises lors de la création du produit s'avèrent incorrectes - avant même l'utilisation du produit, occasionnant ainsi une perte d'efforts et une coûteuse reprise. Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du contenu. Dans les environnements de projet où la présentation a une importance et une valeur économique en tant que résultat d'un projet, vous pouvez envisager d'utiliser une ressource administrative pour réaliser les tâches de présentation.



Plus d'informations