Tracking bugs

Les « BOGUES »

[Not translated yet.] Ils viennent du mot anglais "bug" qui signifie insecte parasite. L'utilisation de ce mot pour désigner une anomalie vient de l'époque des premiers ordinateurs à tubes à vide. En effet, des cafards, attirés par la chaleur dégagée par ces tubes, venaient se réfugier dans ces machines et y mouraient cuits. Leurs cadavres provoquaient des courts-circuits, d'où des pannes qui ont donc été appelées des "bug". L'Académie Française a proposé d'utiliser le mot bogue qui désigne l'enveloppe épineuse de la châtaigne, et par comparaison, des problèmes épineux.

Différents types de tests

[Not translated yet.]

• 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 d'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 domaine, permet de faciliter 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 raisonnable 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'utilisateurs 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 permettrent de définir un environnement matériel minimum pour que l'application fonctionne 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

[Not translated yet.] 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 part, et l'organisation des campagne 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 globale 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'essais 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.
  Avantage : détection des problèmes de régression en rejouant entièrement des scénarios de tests identiques à chaque version d'une application.
• 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

[Not translated yet.]

• Objectif d'un plan de tests
  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 tests 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 tests
  - 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 module 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 plate-formes, 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, campagne 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 fluxg, liste des intervenants.
  - Ressources humaines : nom et responsabilité, informations utiles.
  - Planning des tests : planning, acteurs.

Analyse du risque

[Not translated yet.] 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 disfonctionnement, l'impact de ce disfonctionnement 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 disfonctionnement. 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 tests. 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 disfonctionnement 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 disfonctionnement sur l'utilisateur ou sur l'environnement externe à l'application. De même, on pourra définir, selon l'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 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é.
• 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 :
  

  	Inévitable	Fréquent	Occasionnel	Rare
  Catastrophique	Elevée	Elevée	Elevée	Moyenne
  Grave	Elevée	Elevée	Moyenne	Basse
  Modéré	Moyenne	Moyenne	Basse	Basse
  Ennuyeux	Moyenne	Basse	Basse	Basse

  La dernière étape de l'analyse du risque est la constitution de la matrice de risque pour l'ensemble des objectifs de test. Cette matrice contient les champs suivants : objectif de test, probabilité d'usage, impact, catégorie, sujet, RISQUE.

Analyse des résultas

[Not translated yet.]

• 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ésultas 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 : 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.
  - les 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 test.
  - les 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.
  - les rapports d'anomalies: ces rapports doivent faciliter le suivi 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 test é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.

• Saturday, September 04, 2010
• ©2004 ®DB-LABS - ®TrackAno 2.5 (08/2007)
  Exec time : 0.02 (s) - (4)
  
• Not connected.