Cet article décrit un processus de développement de test hautement formel.
Ce processus de test est généralement moins formel dans la réalité. Mais la compréhension du processus le plus formel permettra de comprendre plus facilement les processus les moins formels.
Le choix du niveau de formalisme à adopter dépendra du contexte du projet et de ses contraintes.
Plus les contraintes du projet sont fortes (contraintes de temps, exigence de sureté de fonctionnement ou exigences réglementaires réglementaire etc..), plus le processus aura besoin en théorie d’un niveau de formalisme élevé.
Plus les moyens dont dispose le projet sont grands (maturité des tests et des processus de développement, niveau d’expertise des personnes impliquées..etc) moins le processus a besoin en théorie d’un niveau de formalise élevé.
Le test est une comparaison entre le comportement réel d’une application, et le comportement attendu d’une application.
Le comportement réel de l’application est issu de la manipulation de l’application en exécution.
Le comportement attendu de l’application est issu quant à lui d’une documentation qu’on appelle Base de test.
Dans un article précédent, nous avions définit le processus fondamental de test qui se compose de 7 étapes
ANALYSE DE TEST
La deuxième étape du processus fondamental de test est l’Analyse de test.
Pendant cette étape le testeur lit la documentation de la base de test pour en extraire les conditions de test.
Les conditions de test sont tous les éléments qui ont besoin d’être vérifiés par des tests.
Les conditions de test est une liste de ce qui est à tester.
Une condition de test peut être :
- une fonction du système comme Trier, Calculer, Envoyer…
- Une transaction : comme le paiement en ligne, réserver une place, faire une demande sur un site.
- Caractéristique qualité : comme la facilité d’utilisation de l’application, la performance, la fiabilité, la robustesse
- Ou un élément structurel ; comme un menu, un logo, un titre, un bouton…
Les spécifications est la documentation qui décrit le comportement attendu de l’application à développer.
Les exigences sont une représentation atomique de ces spécifications. Au lieu d’avoir un document textuel difficile à manipuler on le structure sous forme d’une liste délimitée d’éléments (les exigences).
Les exigences permettent donc de représenter le comportement attendu de l’application sous forme d’une liste d’éléments à fabriquer.
Les conditions de test sont une liste des éléments à tester
Etablir la traçabilité entre les conditions de tests et les exigences, revient à établir des liens entre les éléments à fabriquer et les éléments à tester.
Une exigence peut nécessiter plusieurs vérifications.
Cela peut alors être représenté ainsi :
Analyse d’impact
La traçabilité entre les exigences et les conditions de test permet de réaliser des analyses d’impact.
Une analyse d’impact a pour objectif de mesurer les conséquences d’un changement dans les exigences.
En établissant la traçabilité, il est facile de trouver grâce aux liens, les éléments qui dépendent d’une exigence et qui seront touchée si cette exigence change.
Cette traçabilité permet aussi de détecter rapidement le niveau de couverture des exigences par les tests. Dans cet exemple (ci-dessus) on voit facilement que l’exigence 4 n’a été couverte par aucune condition de test.
« Pendant l‟analyse de conception des tests, les approches détaillées de tests sont implémentées pour sélectionner des techniques de tests basées sur, entre autres considérations, les risques identifiés «
C’est une phrase longue et compliquée pour dire que :
L’analyse de risque est une technique pour sélectionner et prioriser les tests à réaliser.
CONCEPTION DES TEST
Pendant la conception des tests, les cas de tests sont créés.
Un cas de test se compose de :
- Un objectif de test : tout test d’avoir avoir un objectif défini à atteindre comme la vérification du fonctionnement d’un élément particulier.
- Une pré-condition d’exécution : qui peut être une liste de pré-requis nécéssaires à l’exécution comme une connexion établie à internet,, être positionné sur la page donnée de l’application pour commencer le test, avoir un compte utilisateur avec des habilitations données etc..
- Le cas de test contient aussi des valeurs d’entrée : comme des actions à accomplir et des données de test à utiliser.
- Des résultats attendus : comme l’affichage d’une nouvelle page ou un message d’erreur etc..
- Des post-conditions : comme être connecté à une machine, un paiement ou une transaction réussie ou en échec…etc
Le standard IEEE 829-1998 décrit les structures des conditions de test et des cas de test.
Il n’est pas nécessaire de lire ces standards mais Il faut retenir leurs noms et les sujets qu’ils traitent car ils peuvent être demandés lors de l’examen de certification ISTQB.
Les résultats attendus sont la référence du testeur qui va exécuter le test pour décider qu’un test est en Succès ou en Echec.
Si le résultat attendu n’est pas défini alors n’importe quel comportement de l’application lors de l’exécution peut être interprété comme un Succès.
Ce qui peut empêcher de détecter un défaut.
Les résultats attendus doivent être extraits de la base de test qu’ils soient des spécifications ou des exigences.
La base de test contient les éléments sur lesquelles se base le concepteur de test pour définir des résultats attendus comme les sorties et messages affichés, les modifications des données stockés la base de données ou des changements d’états à constater comme les états connecté et non connecté.
IMPLEMENTATION ET EXECUTION DES TESTS
L’implémentation des tests est l’étape où les tests sont détaillés.
Les tests ayant été créé lors de l’étape de la conception des tests, ne sont qu’une description générale de ce qui est à vérifier.
L’implémentation des tests définit une procédure de test précise pour chaque cas de test.
La procédure de test est une séquence d’actions concrètes à réaliser lors de l’exécution et des résultats attendus intermédiaires à vérifier suite à chacune de ses actions.
Ces cas de test ainsi implémentés seront priorisés selon la stratégie de test définie par le responsable de test.
Ces cas de test seront donc exécutés selon l’ordre qui a été défini dans cette étape.
Quand le test est manuel la séquence d’actions à exécuter est appelée une procédure de test.
Quand le test est automatique la séquence d’actions à exécuter est appelée Script de test.
Le standard IEEE 829-1998 traite aussi le sujet de spécification de procédure de test.
Le planning d’exécution des tests définit l’ordre d’exécution prévu des tests.
Le planning d’exécution des tests regroupe les procédures de tests manuels et les scripts de tests automatisés.
L’ordre d’exécution est défini sur la base d’une stratégie de test qui prend en compte
- La priorité des exigences à tester : les exigences les plus importantes peuvent être testés en premier
- Les dépendances entre les tests : Les tests liés l’exigence « annuler une commande » sont à réaliser après les tests de « créer une commande ».
- Les tests de régression : on peut décider dans la stratégie de test de s’assurer que les modifications apportées au logiciel ne l’ont pas détérioré avant de vérifier les nouvelles fonctionnalités.
