Excelent document about tests design on a project. It's in french, i will translate it sooner as possible.

Source: http://www-igm.univ-mlv.fr/~dr/XPOSE/TesTs/

 

Organiser des Tests dans un Projet

 

 

« Tester consiste à exécuter un programme dans le but de faire apparaître des anomalies enfuies. »

 

   Différents types de test

   Mise en œuvre d'un plan de test

   Préparation

   Planification

   Analyse du risque

   Concevoir des jeux d'essai

   Analyse des résultats

 

 

Le test appartient à l'activité de Vérification et de Validation d'une application, qui consiste à déterminer si cette dernière a été développée correctement en fonction des exigences.

 

Les tâches liées à l'activité de Vérification et de Validation démarrent avec le projet et s'adaptent à chaque phase de développement.

 

Toutefois on peut se demander pourquoi chercher des anomalies si on suit une démarche organisée.

 

Les réponses sont nombreuses :

   Des erreurs ont peut-être été commises au cours du développement,

   Les possibilités d'utilisation sont très nombreuses,

   Le logiciel n'a peut-être pas été correctement conçu.

 

Ainsi, une démarche organisée de la phase de test permettra de mettre en évidence la qualité de l'application développée.

 

 

Différents types de tests

 

           Tests unitaires

           Tests d’intégration

           Tests fonctionnels

           Tests de non-régression

           Tests IHM

           Tests de configuration

           Tests de performance

           Tests d’installation

 

 

Les tests unitaires

Les tests unitaires consistent à tester individuellement les composants de l’application. On pourra ainsi valider la qualité du code et les performances d'un module.

 

Les tests d'intégration

Ces tests sont exécutés pour valider l'intégration des différents modules entre eux et dans leur environnement exploitation définitif.

Ils permettront de mettre en évidence des problèmes d'interfaces entre différents programmes.

Les tests fonctionnels

Ces tests ont pour but de vérifier la conformité de l'application développée avec le cahier des charges initial. Ils sont donc basés sur les spécifications fonctionnelles et techniques.

 

Les tests de non-régression

Les tests de non-régression permettent de vérifier que des modifications n'ont pas altérées le fonctionnent de l'application.

L'utilisation d'outils de tests, dans ce dommaine, permet de facilité la mise en place de ce type de tests.

 

Les tests IHM

Les tests IHM ont pour but de vérifier que  la charte graphique a été respectée tout au long du développement.

 

Cela consiste à contrôler :

 la présentation visuelle : les menus, les paramètres d'affichages, les propriétés des fenêtres, les barres d'icônes, la résolution des écrans, les effets de bord,…

 la navigation : les moyens de navigations, les raccourcis, le résultat d'un déplacement dans un écran,…

 

Les tests de configuration

Une application doit pouvoir s'adapter au renouvellement de plus en plus fréquent des ordinateurs. Il s'avère donc indispensable d'étudier l'impact des environnements d'exploitation sur son fonctionnement.

 

Voici quelques sources de problèmes qui peuvent surgir lorsque l'on migre une application vers un environnement différent :

   L’application développée en 16 bits migre sur un environnement 32 bits,

   Les DLL sont incompatibles,

   Les formats de fichiers sont différents,

   Les drivers de périphériques changent,

   Les interfaces ne sont pas gérées de la même manière...

 

Ainsi, pour faire des tests efficaces dans ce contexte, il est nécessaire de fixer certains paramètres comme par exemple :

   la même résolution graphique,

   le même nombre de couleurs à l'écran,

   une imprimante identique,

   les mêmes paramètres pour le réseau...

 

Les tests de performance

Le but principal des tests de performance est de valider la capacité qu'ont les serveurs et les réseaux à supporter des charges d'accès importantes.

 

On doit notamment vérifier que les temps de réponse restent raisonnables lorsqu'un nombre important d'utilisateurs sont simultanément connectés à la base de données de l'application.

Pour cela, il faut d'abord relever les temps de réponse en utilisation normale, puis les comparer aux résultats obtenus dans des conditions extrêmes d’utilisation.

 

Une solution est de simuler un nombre important d'utilisateur en exécutant l'application à partir d'un même poste et en analysant le trafic généré.

 

Le deuxième objectif de ces tests est de valider le comportement de l'application, toujours dans des conditions extrêmes. Ces tests doivent permettent de définir un environnement matériel minimum pour que l'application fonctionnement correctement.

 

Les tests d'installation

Une fois l'application validée, il est nécessaire de contrôler les aspects liés à la documentation et à l'installation.

 

Les procédures d'installation doivent être testées intégralement car elles garantissent la fiabilité de l'application dans la phase de démarrage.

Bien sûr, il faudra aussi vérifier que les supports d'installation ne contiennent pas de virus.

 

 

Préparer des tests

 

 

 

   Définir les ressources humaines

   Choisir une plate-forme de test

   Choisir un outil de test

   Définir une politique pour le suivi des anomalies

 

On organise la phase de test de la même manière qu’on organise un projet.

 

Ainsi, le premier travail consiste à définir toute la partie ressources, d’une parte, et l’organisation des campagnes de tests, d’autre part.

 

Définir les ressources humaines

On se pose souvent la question de savoir qui doit participer aux tests.

 

S’il n’y a pas de réponse tranchée à cette question (cela dépend du projet), on peut tout de même définir les rôles suivants :

 

   Le chef des tests

Tout comme un chef de projet, le chef des tests a pour mission d’assurer la bonne réussite des tests. C’est pourquoi on choisira la personne qui a la vue la plus global du projet.

 

  Le concepteur des jeux d'essais

On prendra de préférence un programmeur ayant une grande expérience de l’environnement d’exploitation et de l’application.

Pour préparer les jeux d’essai ce concepteur devra s’appuyer sur les spécifications techniques et le cahier des charges.

 

   Les testeurs

Ce peut être toutes personnes impliquées dans le développement et le déploiement de l’application.

Le profil idéal du testeur est un utilisateur expérimenté et motivé, ayant une bonne connaissance du logiciel. Toutefois, on évitera de faire participer les développeurs eux-mêmes.

Choisir une plate-forme de test

Afin d’éviter tout problème lié à une différence entre l’environnement de tests et d’exploitation réel, une méthode est de fixer dans le cahier des charges la configuration matérielle minimale.

Ainsi, les tests seront effectués sur plusieurs plates-formes, dont la configuration minimum.

Choisir un outil de test

Les outils de test ont pour vocation de rejouer des scénarios de tests pour mettre en évidence des problèmes de régression ou de dégradation des performances. Cependant, comme tous les logiciels, ils présentent des avantages et des inconvénients :

 

   Avantage

Détection des problèmes de régression en rejouant entièrement des scénarios de tests identiques à chaque version d’une application.

 

   Inconvénient

Temps d’apprentissage et de mise en œuvre

Investissement

 

Définir une politique pour le suivi des anomalies

La façon dont va circuler les anomalies doit être définie dès cette phase. Il s’agit de se mettre d’accord sur la façon dont seront réalisées les corrections et par qui.

 

De plus, les anomalies déclarées suite aux tests seront consignées sur des formulaires avec l’état de progression de la correction.

 

 

Planifier des tests

 

 

   Objectif d’un plan de test

   Structure d’un plan de test

 

 

Objectif d’un plan de test

L’activité de planification est productrice d’idées et d’organisation. Elle exige une grande imagination, car elle nécessite de formaliser des processus qui sont en général menés de manière intuitive.

 

Le plan de test recense les objectifs et les moyens pour réaliser les tests. Il permet l’organisation technique des tests, il planifie leur déroulement dans le temps et définit les points de repère, en particulier les conditions d’arrêt. Il sert aussi de document de validation de la qualité finale du logiciel et fait partie des documents contractuels du projet, au même titre que les spécifications techniques ou les besoins fonctionnels. Il est conçu par le responsable des tests et validé par le chef de projet.

 

Structure d’un plan de test

 

Introduction

L’introduction présente les informations générales du plan :

 

   Présentation de l’application

   Contexte de réalisation

   Choix technologiques

   Coordonnées du responsable des tests

 

Projet à tester

Il s'agit ici de décrire précisément le projet

 

   Liste des modules et/ou des lots

   Date de livraison

 

Documents joints

   Documents généraux

   Documents techniques

   Documentation

 

Environnement de test

Ce paragraphe présentera une description la plus précise possible des plateformes, en indiquant si elles sont représentative des plates formes utilisateurs.

 

   Sites de test

   Configurations matérielles

   Outils de test

   Bases de test

   Données de test

   Coordonnées de l’administrateurs de la bases de données

   Coordonnées du responsable du parc micro

 

Tests à réaliser

   Listes des modules à tester

   Objectif des tests

   Exigences

   Analyse du risque

   Matrice Exigences/Risques pour définir les priorités

   Jeux d’essais

   Estimation de la charge

 

Stratégie de tests

On décrira dans ce paragraphe la démarche mise en œuvre pour réaliser les tests

 

   Description de l’approche générale

   Phase de tests

   Champagne de test

   Ordre d’exécution des tests

 

Condition d’arrêt

   Critères retenus et pourquoi

 

Gestion des fiches d’anomalies

   Modèles des fiches d’anomalie

   Actions et états

   Gestion des flux

   Liste des intervenants

 

Ressources humaines

   Nom et responsabilité

   Informations utiles

 

Planning des tests

   Planning

   Acteurs

 

 

Analyse du risque

 

 

   Les facteurs de risque

   Priorité du risque

 

 

Une fois les objectifs de test recensés, il faut définir les objectifs les plus importants et ceux qui présentent le plus grand risque.

 

Comme les tests ne pourront pas éliminer toutes les anomalies de l'application, on sera toujours amené à faire des choix mais on ne voudra pas éliminer des tests les plus importants. A cet effet, on définira pour chaque objectif de test une priorité qui dérivera directement du facteur de risque.

 

On peut définir le facteur de risque comme étant la combinaison de :

   La probabilité d'apparition d'un dysfonctionnement,

   L’impact de ce dysfonctionnement sur les utilisateurs ou sur l'environnement.

 

En fait, cela consiste à prendre chaque objectif de test, donc chaque fonction principale de l'application, et à définir si la fonction est souvent utilisée et quel sera impact d'un éventuel dysfonctionnement.

 

Le résultat de cette analyse du risque conduit à attribuer une priorité à chaque objectif de test qui fera l'objet d'un paragraphe séparé du plan de test.

 

Le risque s'applique à des catégories particulières qui peuvent être :

   Fonctionnalité la fonction testée ne correspond pas aux besoins.

   performance- les temps de réponse sont inacceptables,

   Instabilité les fonctions ne sont pas reproductibles,

   Coût financier - le coût du dysfonctionnement est important,

   Planning- la correction de l'anomalie induira un retard important de la livraison,

   Fiabilité -le nombre constaté d'anomalies et leur sévérité pose problème.

 

 

Le dernier maillon de la chaîne lié au risque est le sujet, c'est-à-dire les personnes qui seront directement influencée par ce facteur risque. On distingue :

   L’utilisateur du logiciel,

   Le concepteur,

   L’exploitant.

 

Les facteurs de risque

Probabilités d'apparition

C'est la première étape de l'analyse du risque. On parcourt l'ensemble des objectifs et on définit le degré d'utilisation de chaque fonction. On peut, par exemple, définir les degrés suivants :

   Inévitable - Une partie de l'application que tous les utilisateurs rencontreront nécessairement. Exemple : écran d'accueil.

   Fréquent - Une partie de l'application utilisée par les utilisateurs, mais pas dans toutes les sessions. Exemple : impression d'un document.

   Occasionnel - Une partie de l'application qu'un utilisateur moyen n'utilisera pas, mais qui peut être utilisée par un utilisateur expérimenté en cas de besoin. Exemple : paramétrage des options.

   Rare - Une partie de l'application qui n'apparaît que dans certains cas, dans le cadre d'opérations complexes. La majorité des utilisateurs ne l'utilisent pas, mais elle joue un rôle dans certaines situations. Exemple : modifications de barres d'outils.

 

Cette analyse des probabilités d'apparition s'effectuera au niveau de chaque objectif de test. Elle guidera les testeurs vers les fonctionnalités les plus utilisées.

 

Impact

Une fois les zones importantes identifiées, il faut analyser l'impact d'un dysfonctionnement sur l'utilisateur ou sur l'environnement externe à l'application.

 

De même, on pourra définir, selon impact des anomalies, les niveaux suivants :

   Catastrophique. Exemple : la machine s'arrête, le logiciel dans son ensemble ne fonctionne plus, on ne peut pas sauvegarder, etc.

   Grave - Si cette fonction ne marche pas, l'application peut continuer, mais le risque de perdre des données ou d'utiliser des données corrompues est important. Il est nécessaire de relancer l'ordinateur pour résoudre le problème. Exemple : la communication vers l'ordinateur hôte s'interrompt, et les données ne sont plus mises à jour.

   Modéré - Le problème rencontré perturbe l'utilisateur, mais ce dernier peut le contourner en effectuant des actions complémentaires. Exemple : la disquette de sauvegarde est pleine, l'utilisateur doit passer par le disque dur pour finir la sauvegarde.

   Ennuyeux - Si cette fonction ne marche pas, on peut continuer à utiliser l'application, mais elle peut poser des problèmes ultérieurement. Exemple : on veut entrer un nom de fichier de dix caractères, mais l'application ne permet pas d'en entrer que cinq.

 

Le fait de combiner les probabilités d'usage avec les impacts sur les utilisateurs va permettre de classer les objectifs de tests par priorités.

Priorité du risque

La priorité servira à valoriser l'importance que l'on accorde à chaque objectif de test.

Une priorité élevée définira les problèmes qui doivent impérativement être résolus,

une priorité moyenne les problèmes qui pourront être résolus ultérieurement, mais qu'il ne faut pas négliger, et en fin une priorité basse les problèmes dont la solution peut attendre et qui seront traités en dernier.

 

L'action suivante est d'assigner ces priorités aux objectifs de test. Cette démarche s'effectue en deux étapes : définir une table de risque, puis assigner des priorités en fonction de cette table, comme le décrit le tableau ci-dessous :

 

 

La dernière étape de l'analyse du risque est la constitution de la matrice de risque pour l'ensemble des objectifs de tests. Cette matrice contient les champs suivants :

   Objectif de test

   Probabilité d'usage

   Impact

   Catégorie

   Sujet

   RISQUE

 

Concevoir des jeux d’essai

   Validation d’un champ

   Graphe de cause à effet et tables de décision

   Plan d’un jeu d’essai

« Un jeux d’essai est une description d’une suite d’action et de résultats attendus, ayant pour objectif la validation d’une fonctionnalité de l’application. »

 

On créera donc des jeux d’essai qui décrivent une situation possible, plausible ou bien probable d’utilisation.

Validation d’un champ

 

   Les champs numériques

Lors des tests de champs numériques, on veillera tout particulièrement à ceux que seul le format décrit dans les spécifications soit acceptée. Par exemple, si un champ n’accepte que les valeurs numériques positives, on validera les cas suivants :

 

	Résultats
Chiffres uniquement	Cas normal
Lettres uniquement	Non accepter
Nombre négatif	Non accepter
Nombre positif incluant une virgule	Cas normal

 

  Les abréviations

Dans le cas où certains champs de l’application accepte des abréviations, il s’agira de s’assurer que seul les abréviations autorisées sont acceptées.

Graphe de cause à effet et tables de décision

On modélise souvent le fonctionnement d’une application sous la forme d’un diagramme d’état transition décrivant les transitions possibles entre deux états ou deux écrans. On associe à chaque transition des conditions à respecter pour assurer cette transition.

Les graphes de cause à effet définissent, sous forme graphique et logique, les conditions de ces transitions.

 

Exemple de diagramme état transition :

 

 

On peut passer de l’état 1 soit à l’état 2 soit à l’état 4 en fonction d’une condition.

 

Plan d’un jeu d’essai

 

Nom de l’application :

Référence de scénario de test :

Date :

 

Action	Résultats attendus
Clique sur le menu	La fenêtre d’accueil apparaît
Choisir une option	Le choix est exécuté

 

Ce plan montre qu’il est tout à fait possible de découper les tests en une suite d’actions de bases, dont on contrôlera la progression en fonction des résultats obtenus.

 

 

Analyse des résultats

 

 

   Cycle de test

   Rapport de test

   Interprétation des résultats

 

 

Cycle de test

Le cycle de test correspond à la période durant laquelle un ensemble de tests est exécuté. Ainsi à la fin de chaque cycle, un examen des résultats obtenus permettra de définir si l’on peut passer ou non au cycle suivant.

 

Organiser ces cycles dans un tableau permettra de simplifier l’analyse des résultats.

 

Si l’application développée est une version n+1 d’une application existante, on sera amené à en vérifier la non-régression. Pour cela, on pourra définir un cycle de non-régression qui consistera à rejouer des scénarios de test de la version précédente.

Rapport de test

On trouve en général cinq familles de rapport dans ce domaine :

 

   Les rapports de synthèses,

   Les rapports de couverture de test,

   Les rapports d’avancement,

   Les rapports de performance,

   Les rapports d’anomalies.

 

Rapports de couverture des tests

Ils mettent en relation les scénarios de test avec les objectifs et les règles de gestion. Toutefois, même avec l'aide de ce rapport il reste en général difficile d'affirmer que toute l'application a été testée.

 

Rapports d'avancement

Afin de pouvoir évaluer l’avancement des tests, on générera des rapports visualisant les scénarios enregistrés, ceux qui contiennent des bogues, par rapport à l’ensemble des procédures.
On pourra également lister les scénarios qui auront été exécutés sans problème.

 

Comme les rapports de couverture de test, les rapports d’avancement doivent faire référence aux objectifs de tests.

 

Rapports de performance

Les performances sont liées aux temps de réponse observés lors des tests de montée en charge ou des tests en mode dégradé.

Afin de simplifier la lecture de ces rapports, les résultats obtenus pourront être présentés sous la forme de graphiques appropriés.

 

Rapports d’anomalies

Ces rapports doivent faciliter le suivit d’une anomalie.

De plus, ils permettront de déterminer quels sont les modules les plus fiables de l’application.

Interprétation des résultats

Une fois les rapports de tests écrits, il faut se prononcer sur leur signification.

 

Le premier critère à prendre en compte est lié à la phase de test que l’on vient d’exécuter.
Si on se trouve dans des phases préliminaires, on aura la possibilité de corriger les anomalies détectées sans trop perturber la suite des tests et le développement ultérieur de l'application.

Si au contraire on se trouve dans une phase de test avancée, il est important de prendre en compte l'impact de la correction des anomalies sur les tests ultérieurs.

 

Dans tous les cas, on veillera spécialement à qualifier correctement les anomalies, surtout celles qui ont été définies comme bloquantes et on recherchera les modules provoquant le plus grand nombre d'anomalies.

 

Enfin, avant de définir les conditions de test du cycle suivant, il faudra préciser quelles sont les anomalies que l'on voudra suivre tout particulièrement pour vérifier si elles ont bien été corrigées.