1.4 Processus de test fondamental

Nous avions comparé les tests à un Iceburg dont la petite partie visible à la surface de l’eau est l’activité d’exécution. D’autres activités importantes de test sont moins connues mais elles ont un impact direct sur le succès de l’exécution des tests. Le test et comme le développement, la partie la plus connue est le codage mais les autres activités sont importantes pour la réussite de la phase de codage et ces activités interviennent avant et après celui-ci. La planification du projet, l’expression de besoin, la conception de la solution, le codage, l’exécution des tests et le déploiement. Ces activités sont liées entre elles et constitues un processus, et respectent généralement l’ordre séquentiel suivant : Planification des tests et contrôle Analyse et conception des tests Implémentation et exécution des tests Evaluer les critères de sortie et informer Activités de clôture des tests

Nous allons parcourir ces activités une par une pour découvrir ce qu’elles contiennent

e processus de test débute par la planification. Le responsable des tests commence par déterminer l’objectif des tests qu’il va piloter, nous avions dit que les objectifs peuvent être de :

Trouver des défauts
Acquérir de la confiance dans le produit,
Acquérir des informations pour prendre une décision
Ou prévenir des défauts

Quand l’objectif de test est précisé, une stratégie doit être définie pour atteindre cet objectif et un planning doit organiser dans le temps les actions des activités futures.

Quand cela est fait alors, le responsable des tests a un Plan.

Contrôle des tests

L ’activité de contrôle est la tâche qui consiste de s’assurer que le projet progresse bien selon le plan initial. Grâce à l’activité de contrôle le responsable des tests détecte tout écart entre le déroulement du projet et le Plan initial et agit en conséquence pour ajuster la trajectoire tout au long de l’avancement du projet.

La planification est réalisée au début du processus.
Le contrôle se déroule tout au long du processus de test.

Analyse et conception des tests

Durant cette phase, les testeurs préparent les tests qu’ils vont exécuter plus tard. Cela permet de construire un patrimoine de test structuré et s’assurer qu’aucun test n’est oublié ou qu’un élément du logiciel est testé deux fois sans raison. Cette phase du processus démarre de l’objectif définie dans la planification, et s’appuie sur le comportement attendu de l’application décrit dans les spécifications ou tout autre documentation pour sélectionner les conditions de test et concevoir les tests correspondants. Par exemple :

Pour l’exemple d’une calculatrice.
L’objectif peut être de détecter des défauts.
Les conditions de test sont : Faire une addition, Faire une soustraction, Faire un multiplication et faire une division
Les tests pour la condition de test « Faire une addition » peuvent être :
- Faire la somme de deux entiers positifs
- Faire une addition en un entier positif et un entier négatif
- Faire la somme de deux entiers négatifs
- Faire la somme de plus de 5 valeurs … etc

Durant l’analyse et la conception des tests, le testeur peut accomplir une ou plusieurs de ces tâches :

Réviser les bases de test : les bases de test sont la documentation de référence sur laquelle se base le testeur pour juger que le comportement qu’il a constaté sur le logiciel et correct ou pas. Une base de test est un document qui décrit le comportement attendu de l’application. Le test est une comparaison entre le comportement attendu de l’application et le comportement réel constaté de l’application, s’il y a un écart entre les deux, le testeur remonte un défaut.
- - Les exigences sont une représentation atomique des spécifications, au lieu de s’appuyer sur un document texte qui peut être sujet à interprétation, les exigences permettent de représenter le comportement attendu spécifié sous forme d’une liste finie mesurable et plus facile à exploiter.
  - Un rapport d’Analyse de risque est un document qui identifie les partie du logiciels les plus critiques, cela peut amener le testeur à tester plus en profondeurs les parties les plus risquées, concevoir plus de tests pour les couvrir ou exécuter en priorité les tests correspondants pour détecter au plus vite des défauts s’il y en a pour pouvoir les corriger rapidement avant de manquer de temps quand le projet s’approchera de la deadline.
  - L’architecture est la conception technique du logiciel.
  - Les interfaces sont les passerelles et des protocoles par lesquelles des composants ou des systèmes communiquent entre eux.
Toutes les exigences ne sont pas forcément testables, quand une exigence dit que le logiciel doit être « joli » ce n’est pas une exigence exploitable, il faut une charte graphique claire, quand une exigence dit que le logiciel doit être « suffisemment rapide », ce n’est pas testable non plus. Il ne faut pas hésiter dans ce cas d’échanger avec le référent fonctionnel qui a rédigé la base de test pour expliciter l’exigence et définir par exemple le délai de réponse souhaité de l’application.
Organiser les conditions de test de façon cohérente permet de structurer les tests conçus et exécuté et générer des résultats claires et une information précise sur la progression des tests et la qualité du logiciel.
Des tests de haut niveau peuvent être conçu pour faire des tests de bout en bout qui permet de voir rapidement les faiblesses du produit logiciel.
Les tests peuvent être conçus sans préciser les données de tests dont on aura besoin pour les exécuter :
- - Dans l’exemple d’une calculatrice nous avons identifié le test « Faire une addition entre deux entier positifs »
  - Nous avons identifié le besoin en données de test : 2 entiers positifs
  - Mais à ce stade, ces entiers positifs ne sont pas précisés, ça peut petre n’importe quels entiers positifs. Ils seront précisés lors de la phase d’implémentation.
Pour faire des tests on peut avoir besoin d’un environnement spécifique, un système d’exploitation, des bouchons, des applications tierces pour communiquer avec notre produit logiciel ou des outils de comparaison pour vérifier les résultats de nos tests. Tout ces éléments peuvent être prévus dès cette phase pour commencer à les préparer avant la phase d’exécution.
La traçabilité est assurées par des liens entre la base de test comme des exigences et les cas de tests. Ça permet dans la phase de conception de vérifier qu’on a bien conçus des tests pour toutes les exigences. Et dans la phase d’exécution, pour vérifier quels sont les exigences qui sont couvertes par les tests et quels sont le niveau de validation à un instant donné.

Implémentation et exécution des tests

C’est durant cette phase que :

les procédures sont écrites pour les tests manuels et que les scripts sont programmés pour les tests automatisés.
Les tests dans l’ordre d’exécution souhaité.
Les données de tests et toutes les informations qui seraient utiles aux tests sont ajoutés aux tests
Le produit logiciel à tester est livré et installé dans l’environnement de test. Et l’exécution commence dès que tout est prêt.

Finaliser, développer et prioriser les cas de test sont les actions de conception qu’on n’a pas pu faire dans la phase précédente et qu’on peut faire maintenant, peut être par manque de temps ou parce que ce qui reste à finaliser dépend de l’environnement d’exécution.

Développer les procédures de test veut dire que les cas de tests qui ont été conçus dans la phase précédente doivent être détaillés et spécifiés dans cette phase en étapes spécifiques et claires que les testeurs exécuteront facilement.

Celui qui a conçu les tests n’est pas forcément celui qui va les exécuter. Chaque test est détaillé en étapes qui décrivent clairement l’action à faire sur l’application et le résultat attendu.

Prenons encore l’exemple de la calculatrice.

Nous avions identifié les cas de tests dans la phase d’analyse et de conception.

Dans la phase d’implémentation et d’exécution, ces cas de tests seront implémentés et étapes de test.

Par exemple le test : Faire une addition entre 2 entiers positifs

Sera détaillé en des étapes claires comme :

Action : Allumer la calculatrice => Résultat attendu : la calculatrice est allumée et affiche un 0
Action : Renseigner la valeur 9 => Résultat attendu : La valeur 9 s’affiche sur l’écran
Action : Appuyer sur le bouton « + » => Résultat attendu : La valeur 9 s’affiche toujours sur l’écran
Action : Renseigner la valeur 11 => Résultat attendu : La valeur 11 s’affiche sur l’écran
Action : Appuyer sur le bouton « = » => Résultat attendu : La valeur 20 s’affiche sur l’écran

Créer des suites de tests à partir des procédures de test pour une exécution rentable des tests

Les suites de test permettent de rassembler plusieurs tests et de les exécuter dans un ordre qui a un sens fonctionnel. Cela permet de rendre les tests plus efficaces et en rendant par exemple possible que chaque test prépare les prérequis nécessaires pour exécuter le test suivant.

Vérifier que les environnements de tests ont été mis en place correctement

Vérifier que les différents composants du logiciel ainsi que la base de données ont été bien installés pour commencer l’exécution dans de bonnes conditions.

Vérifier et mettre à jour la traçabilité bi-directionnelle entre les bases de test et les cas de test

Ce sont les liens dont nous avions parlé précédemment entre les exigences et les cas de test, pour structurer les tests et permettre de s’assurer qu’on a pas oublié de concevoir des tests pour une exigences.

Exécuter les procédures de test soit manuellement soit en utilisant des outils d’exécution de tests, en suivant la séquence planifiée

C’est la phase d’exécution concrète des tests en suivant l’ordre prévu soit manuellement en utilisant des logiciels bureautique ou en utilisant un outil spécial de gestion des tests comme HP ALM, SQUASH, TESTLINK, XSTUDIO et autres…

Consigner les résultats de l’exécution des tests et enregistrer les identités et versions des logiciels en test, outils de test et testware

Quand les tests sont exécutés il faut rapporter les résultats en veillant à décrire les conditions dans lesquelles les tests ont été déroulés comme le système d’exploitation MAC, Windows, Android ou IOS pour que le développeur puisse une vision la plus complète possible de l’origine des défauts s’il y en a.

Comparer les résultats actuels et les résultats attendus.

Et vérifier s’il y a un écart, si oui => Anomalie et on crée une fiche pour la décrire au développeur sinon on exécute le test suivant

Signaler les divergences comme des incidents et les analyser de façon à établir leur cause (p.ex. défaut dans le code, dans les données de test, dans la documentation de test, ou méprise dans la manière d’exécuter le test)

Répéter les activités de test en réponse aux actions prises pour chaque divergence. Par exemple, réexécution d’un test qui était préalablement défaillant de façon à valider une correction (test de confirmation), exécution d’un test corrigé et/ou exécution de tests de façon à s’assurer que des défauts n’ont pas été introduits dans des secteurs non modifiés du logiciel ou que le défaut corrigé n’a pas découvert d’autres défauts (test de régression)

Ce dernier points abordes deux types de test qu’il ne faut pas oublier de réaliser :Les tests de confirmation et les tests de régression.

Quand une anomalie est détéctée elle est signalée par le testeur au développeur à l’aide d’une fiche d’anomalie. Le développeur reçoit la fiche et corrige l’anomalie. Une fois corrigée le testeur rafait un test pour vérifier et confirmer que la correction a été bonne. C’est le test de confirmation.

Et ce n’est pas fini, pour corriger l’anomalie, le développeur a du modifier le code de l’application, ce qui peut impacter des endroits de l’application qui fonctionnait bien avant et qui ne fonctionne plus maintenant que c’est modifié. C’est ce que l’on appelle des régréssions. Les testeurs sont amenés à refaire des tests sur des fonctionnalités déjà vérifiés : c’est ce que l’on appelle des tests de régression.

Evaluer les critères de sortie

Evaluer les critères de sortie est l‟activité où l‟exécution des tests est évaluée en fonction des objectifs définis. Ceci devrait être fait pour chacun des niveaux de test.

Evaluer les critères de sortie est ce qui permet de décider d’arrêter les tests ou pas. On arrête les tests quand on a atteints les objectifs initiaux qu’on a défini. Chaque niveau de test a ses propres objectifs. Nous verrons ce que sont les « niveaux de test » dans les sections suivantes.

Comment on réalise cette activité ?

Vérifier les registres de tests en fonction des critères de sortie spécifiés dans la planification des tests

En comparant au cours de l’exécution les résultats de test avec les critères de sortie définis lors de la phase de planification.

Evaluer si des tests supplémentaires sont requis ou si les critères de sortie doivent être changés

Si les critères de sorties ne sont pas encore atteint, alors soit on décide de continuer l’exécution des tests, soit on décide de redéfinir les critères de sortie si on juge qu’il ne correspondent plus à la réalité du projet.

Ecrire un rapport de synthèse des tests pour les parties prenantes

A la fin de l’exécution, le responsable fournit un rapport de synthèse des tests pour rendre compte aux parties prenantes de l’avancement final du projet, de la qualité atteinte et éventuellement des risques restants.

Activités de clôture des tests

Cette activité est une phase de prise de recul ou on rassemble tous ce qui a été produit lors de la campagne qui vient de se terminer pour le réutiliser dans les prochaines campagnes et revenir sur l’expérience acquise pour mieux faire la prochaine fois. En vérifiant que tout ce qui devait être livré par l’équipe de test a été bien livré. En archivant les fiches des anomalies qui ont été rapportés et corrigés. Et quant aux anomalies qui n’ont pas été corrigé et qui sont toujours dans le produit logiciel, on peut transformer ces fiches d’anomalies en demandes d’évolution pour devenir une base de test pour le prochain cycle de développement. Tracer les résultats des tests d’acceptation dans un compte rendu. Et archiver tous les cas de test conçus, les données de test, les outils de comparaisons, les écrans.. etc pour les réutiliser à nouveau. Si une autre équipe prendra en charge les travaux sur la qualité du produit c’est durant cette phase que l’équipe sortante leur fournira tout ce qui a été produit durant les tests. L’équipe peut se réunir pour reparler à tête reposée de ce qui s’est passé durant ce projet pour identifier ce qui s’est bien passé pour le reproduire et les erreurs et les points à améliorer.

Les tests fournissent des informations sur la qualité du produit testé mais pas que, les tests peuvent aussi donner une idée sur l’efficacité du processus de développement. Si beaucoup d’anomalies sont dues à des mauvaises interprétations de la base de test, c’est qu’il y a un problème dans la spécification du comportement attendu ou la communication entre les référents fonctionnels qui écrivent la documentation et les développeurs. Si beaucoup d’anomalies sont des erreurs de codage alors il faut renforcer les tests statiques sur le code et multiplier les tests unitaires par exemple. C’est ainsi qu’une équipe peut améliorer la maturité de ses tests grâce à l’expérience passée et les informations collectées.