Suivi des essais par l'analyste

Définition des types d'essais

Essais unitaires

Il s'agit d'un test d'une fonctionnalité isolée. Par exemple, si l'utilisateur inscrit du texte dans un champ de saisie numérique, on s'attend à seules les caractères numériques soient acceptés, alors que tous les autres devraient être refusés.

Essais fonctionnels ou Essais intégrés

Il s'agit d'un test interfonctionnalité. Les appellations essais intégrés ou essais fonctionnels peuvent être utilisées pour ce genre de test. Un exemple de ce type d'essais : si l'utilisateur change le nom de son client, on s'attend à ce que le nouveau nom apparaisse sur la facture de ce client.

Essais globaux ou Essais système

Il s'agit d'un test du système avec son environnement. Il peut s'agir de test intersystème et de tests en réaction à l'environnement. Par ceux-ci on entend des essais de : sécurité, performance, charge, fiabilité et portabilité.

Essais utilisateur ou Essais d'acceptation

Il s'agit d'un test dans le cycle d'affaires. Les essais à ce niveau sont des tests d'utilisation comme le ferait un vrai utilisateur dans la vraie vie. On parle souvent de tests d'acceptation, car il s'agit du dernier niveau de test avant de passer le système en production.

Essais de non-régression

Il s'agit d'un sous-ensemble des essais fonctionnels qui consiste à s'assurer que les modifications apportées au code n'ont pas eu d'effet pervers et causés une régression de la qualité du logiciel.

Définition d'un cas de test

Un cas de test est minimalement composé :

• D'un numéro : pour le repérer;
• D'une description : ce qu'il faut faire pour réaliser le test;
• D'un résultat attendu : selon ce qui a été défini dans la spécification fonctionnelle, suite à l'exécution du test;
• D'un résultat obtenu : après l'exécution du test, on indique si le test a réussi ou échoué.

Les cas de test sont souvent présentés sous forme de grille. Voici un exemple : supposons qu'un utilisateur doit répartir un pourcentage entre deux entités. La documentation précise que la somme des deux entités doit exactement être égale à 100%. Nous obtiendrons les trois cas de tests suivants :

Responsables des essais

La figure ci-dessous, très théorique, présente le flux de développement logiciel, où vers la droite le système se construit et vers la gauche (au retour) la qualité est contrôlée.

Donc, selon la théorie, chacun des acteurs fait son propre niveau d'essais. Dans la pratique, cette responsabilité est variable. En mode agile, par exemple, c'est l'équipe qui fait les essais, donc les individus qui choisissent les tâches de test. Il peut aussi arriver que les essais soient impartis à une équipe autonome de testeurs. Au final, le développement informatique est un travail d'équipe et l'important est que tous doivent contribuer à livrer un logiciel de qualité.

Préparation et réalisation des essais par un testeur

Lorsque l'analyste fonctionnel n'effectue pas lui même ses essais et qu'ils sont réalisés par un testeur, le rôle de l'analyste dans cette situation est un rôle de support. Un peu comme dans sa relation avec le programmeur , l'analyste doit échanger régulièrement avec le testeur pour les raisons suivantes :

• Donner des explications sur le fonctionnement attendu;
• Répondre à des questions et apporter des précisions;
• Aviser le testeur des traitements et processus importants;
• Faire des retouches à la documentation pour fournir des explications plus claires;
• Revenir avec les parties prenantes sur quelques cas qui auraient pu être oubliés.

Le testeur (nommé aussi analyste en contrôle qualité), va ensuite planifier et préparer ses essais. Il va lire la documentation produite par l'analyste fonctionnel. Il va ensuite discuter avec ce dernier pour s'assurer de bien comprendre le fonctionnement et être avisé de ce qui est essentiel à tester. Le testeur va ensuite planifier ses essais. Cette étape est importante pour le testeur, car dans un échéancier de projet, il doit s'assurer d'arriver à un bon niveau de qualité pour le temps prévu. Il va donc préparer ses essais pour couvrir le maximum et viser l'essentiel. Il va préparer ses grilles. Une fois que celles-ci seront complétées, il pourra vérifier ses scénarios avec l'analyste.

Pendant la préparation des essais, le testeur va aussi discuter avec le programmeur. Celui-ci a déjà fait des essais unitaires et il sait aussi quel est le niveau de confiance qu'il peut attribuer à son code. Ces informations sont utiles au testeur pour déceler où pourraient se trouver d'éventuelles failles.

Le testeur effectue, seul ou en équipe, les tests selon les cas définis dans les grilles de tests. Lorsqu'un comportement anormal est détecté, une anomalie est soulevée et le programmeur la corrige.

Lors des essais, il peut survenir des comportements non désirés ou incohérents, car il n'y avait pas de spécification fonctionnelle pour le cas survenu. Il s'agit de situation imprévue par l'analyste, non décelé par le programmeur, et non planifié par le testeur. Ces anomalies surprises peuvent coûter cher, car le travail doit être repris au début de la chaîne. Une approche d'analyse par scénario (cas d'utilisation) ou une approche d'analyse par prototype peut être utile pour réduire, voir éviter ce genre de problèmes.

Redondance entre les spécifications et les cas de test

L'élaboration de grille de test est une bonne pratique. Ces grilles permettent d'indiquer ce qui a été testé et peuvent être réutilisées pour des essais de non-régression. Elles peuvent être exécutées par des personnes qui connaissent peu le système informatique à tester. De plus, l'écriture des cas d'essais permet à son auteur de prendre un moment pour réfléchir à d'autres cas. Cet exercice permet d'être plus précis et d'atteindre un meilleur niveau de qualité.

Les grilles de test ont cependant un défaut, elles peuvent finir par devenir monstrueusement longues avec des centaines et des milliers de cas. Lorsque le système est en évolution, ces grilles deviennent difficiles à maintenir.

Lorsque les essais fonctionnels et intégrés sont réalisés par des analystes (et non pas des testeurs) ceux-ci ont commencé à signaler, lors de rétrospectives, que le maintien des grilles de test était fastidieux et apportait peu de valeur. Souvent avec raison.

L'analyste rédige une spécification dans son dossier fonctionnel. Ensuite, il va dans la grille de tests et rédige un petit nombre de cas pour couvrir toutes les situations liées à cette spécification. Contrairement au testeur qui n'a pas fait l'analyse, l'analyste, lui connait son dossier. Et s'il est moindrement expérimenté, il sait ce qu'il a à tester sans avoir besoin de l'écrire. Produire des grilles de tests devient pour lui une sorte de réécriture, dans un autre format, de ce qu'il a déjà écrit.

Pour régler ce problème, les équipes de développement informatique utilisent différentes approches.

Simplifier la préparation des essais

Dans cette approche, les grilles de tests classiques ne sont plus utilisées. L'analyste fonctionnel qui termine son dossier prend quelques heures à préparer ses essais sous forme de liste de vérification (Check list). Il réfléchit à ce qu'il est important de tester et important de ne pas oublier et le note dans sa liste. Il pense aussi aux données nécessaires pour réaliser ses cas. Pour réaliser les essais, il descend simplement sa liste en se référant continuellement à son dossier fonctionnel où le comportement attendu y est inscrit.

Utiliser l'approche TDD (Test driven development)

Dans l'approche TDD, on pense au cas de test avant de coder. Ceux-ci deviennent alors les spécifications et l'analyste n'a plus besoin de faire de dossier fonctionnel. Il ne rédige que le cas de test. Le programmeur écrit le code en ayant pour objectif que le cas s'exécute avec succès. Cette approche s'applique bien en Agile, où il faut analyser et préparer les essais dans un court laps de temps (sprint).

Générer les cas de test à l'aide d'un outil

La documentation fonctionnelle est souvent écrite dans un éditeur de texte (ex.: Microsoft Word) ou dans un wiki (ex.: Confluence). Cependant, il existe des outils pour rédiger des spécifications fonctionnelles qui permettent de générer des cas de test à partir de celles-ci (ex.: InteGREAT avec TFS).