Définir un périmètre de tests : la stratégie

Périmètre fonctionnel

Le présent chapitre s’attachera à définir les notions de périmètre de tests et de stratégie de recette, que celle-ci se déroule directement en sortie de développement lors d’une recette technique ou plus en aval au niveau d’une recette fonctionnelle, toujours dans le cadre d’un chantier de release.

Nous aborderons ces notions en partant d’un sujet plus large que celui du test : l’analyse de risques. Cette démarche doit normalement être menée par l’équipe MOA en charge des études avant-projet et cela, bien avant le démarrage de celui-ci, comme nous l’avions précisé dans le chapitre Généralités qui exposait des généralités sur le processus de production logicielle.

Mais cette tâche n’est pas obligatoire : l’analyse de risques n’est pas toujours réalisée. Malheureusement…

1. Parties prenantes, risques et exigences

a. Lister les parties prenantes

Par partie prenante d’un projet, nous entendons une liste des types d’acteurs du projet et/ou de la solution logicielle produite.

Nous rencontrons donc des parties prenantes spécifiques à un projet (les développeurs, les chefs de projets MOE et MOA, les équipes de recette…) et des parties prenantes concernées par le produit réalisé, les types d’utilisateurs (par exemple, un administrateur, un contributeur et un rédacteur en chef pour une application de gestion de contenus).

Une partie prenante peut d’ailleurs être concernée avant, pendant et après le projet suivant son niveau d’implication. Elle peut être dans l’entreprise qui réalise le projet, comme elle peut être un anonyme à l’autre bout de la planète.

Quoi qu’il en soit, cette étape permet d’identifier toutes les typologies de personnes interagissant à un moment ou un autre avec le projet et/ou le produit.

b. Lister les risques

Une fois les parties prenantes identifiées et réparties selon qu’elles sont impliquées avec le projet ou le produit, s’en suit une phase pendant laquelle le responsable de l’étude va identifier tous les risques dans la mesure du possible....

Périmètre disponible : gérer les dégradations

Dans un monde idéal et parfait, les périmètres des recettes fonctionnelles et techniques se déduiraient des seules analyses des exigences et des risques.

Dans ce même Eden de l’Informatique, les applications arriveraient toutes dans des environnements de tests parfaits…

Malheureusement, ce n’est jamais le cas et la plupart des personnes qui travaillent sur un projet vous diront qu’il est quasiment impossible d’avoir des conditions de test rigoureusement identiques à celle de l’environnement de production.

Nous allons voir comment prendre en compte ces contraintes dans la présente section.

1. Environnement dégradé

Par environnement, nous désignons l’ensemble des données et paramètres qui conditionne l’exécution du produit testé.

a. Des traitements en moins

Maintenir un environnement est coûteux. Et généralement, le budget alloué à celui de production est très élevé.

Aussi lorsque les besoins des équipes de test induisent l’usage d’environnements de test dédiés, cela suppose que les moyens financiers, logistiques et techniques à les maintenir soient mis en œuvre.

La réalité du terrain vous montrera rapidement que l’obtention d’un environnement de test à l’image de la production n’est pas toujours possible. Au mieux, vous aurez une image du passé qui ne sera pas synchronisée - ou éventuellement de manière occasionnelle. Au pire, une image très parcellaire.

La mise à disposition de cet environnement - qui par définition est temporaire - est aussi conditionnée par les moyens matériels et leurs coûts de maintenance. Il est ainsi fréquent que plusieurs environnements de test soient logiquement installés sur le même serveur physique, par exemple.

Bref, vous n’aurez jamais l’exacte réplique de la production.

Et parmi les écarts, les premiers à être souvent constatés sont l’absence des traitements automatiques nocturnes et l’absence de certaines applications.

Ces absences, que nous appelons "dégradation de l’environnement", introduisent...

Périmètre des configurations matérielles

Dans l’arborescence des exigences produit, nous avons mentionné sans la détailler, les exigences techniques d’un produit.

Parmi elles, nous trouvons des exigences de compatibilité entre des configurations matérielles.

Nous avons déjà évoqué les difficultés rencontrées par une équipe de développement dans ce domaine, ne serait-ce que pour reproduire une anomalie dans les mêmes conditions que sa détection.

Dans le cadre des recettes qui suivent les développements, cette dimension prend une importance notable qu’il convient de maîtriser.

La présente section expose comment gérer les configurations matérielles dans les recettes techniques et fonctionnelles. Nous vous proposerons des solutions parcellaires cependant, car c’est le contexte du projet qui conduira à une réflexion sur ce sujet, donc à des adaptations de ce que nous proposons.

1. La gestion des configurations matérielles

a. En recette fonctionnelle

Théoriquement, une recette fonctionnelle n’est pas censée être la phase du projet où des exigences techniques sont testées.

Une recette fonctionnelle est censée homologuer l’application selon des critères purement métier : le respect des spécifications fonctionnelles, des règles de gestion du métier.

Toujours très théoriquement, une recette fonctionnelle serait donc censée avoir lieu dans une configuration matérielle unique, un "étalon matériel de référence".

Ainsi, les recettes réalisées par la MOA devraient s’effectuer sur une plateforme totalement normalisée, par exemple, une application web sera testée exclusivement sur une seule version d’un unique navigateur.

La réalité des projets est cependant toute autre car fonction des ressources humaines et matérielles consacrées au projet.

Qu’un projet n’ait pas de cellule de tests techniques dédiée, et c’est la MOA qui devra compenser l’effort de test. Dans une telle situation, il est bien évident qu’une recette censée être purement fonctionnelle prendra une dimension technique également....

Périmètres thématiques

Au-delà du périmètre fonctionnel et technique d’une application et du choix d’une éventuelle stratégie de test des exigences de compatibilité des configurations matérielles, il existe d’autres stratégies de test, d’autres manières de considérer un périmètre de vérification.

Nous proposons ici des approches thématiques en ciblant des exigences purement techniques en laissant de côté l’aspect fonctionnel du produit.

Ces stratégies de test très spécifiques pourront répondre à des situations indépendantes ou bien une réflexion sera conduite amenant à décider de les déployer parallèlement à un projet de recette fonctionnelle ou technique.

La dimension technologique joue évidemment un rôle dans les stratégies que nous allons aborder mais il ne faudrait pas croire que telle stratégie serait purement technique et non fonctionnelle.

Le principe est de répondre à une problématique globale pour une même application.

1. Tester l’ergonomie et le ressenti graphique global

a. Tester la navigation : les applications web

Par navigation, nous entendons exclusivement l’usage des liens hypertexte et des boutons permettant d’afficher toutes les pages d’un site web.

La navigation est l’un des aspects qui prédominent le plus dans cette technologie : elle fait donc l’objet de tests spécifiques d’autant plus qu’un plan du site est susceptible d’avoir été défini.

On pourra considérer qu’une recette technique ou fonctionnelle d’une application web (comme nous l’avons évoqué dans les sections précédentes) permet de tester chaque lien de sorte qu’une "navigation élémentaire", une transition, est réalisée dans chaque scénario de test ou fiche de test.

Ceci revient à dire que le test global de navigation est éclaté en autant de scénarios et fiches de test qu’il y a dans la recette.

L’approche que nous proposons ici est toute autre : elle consiste à envisager la navigation comme un seul concept devant être testé...