How to make unit test?

18 05 2009

The unit test :


“Test Unit (TU) (development test): A unit test is a test conducted by the developer in development environment; it is intended to demonstrate a unit complies with the criteria defined in the technical specifications.”

In the case of a procedural language unit is « the process », and in the case of an object-oriented unit is represented by « The Class. »

Unit testing is testing the first white box-type to be charged by profile type developers.

In the case of this kind of test the important question is « What is the quality of the units developed and how to measure it?

Thus, it is for the developer to test a module, independently of the rest of the program in order to ensure that it meets the requirements (functional / technical) and it works correctly. This audit is currently an audit of code coverage, which is to ensure that the test leads to perform all (or a portion) of the instructions in the code to test.

Thus, it should be understood that the unit must conduct (or the piece of code):

  • Check the functions and roles of the Unity
  • Test the boundaries of the unit (bounds: zero, one, complete. Search an empty collection, for example)

This results in a simple way by creating a test class per class developed.

Example of basic unit tests and represented by a class of test:

  1. Invoke the method with the values passed as parameters
  2. Observe the results
  3. Check if the results are those expected

Thus we must select values for which we can determine the outcome.

As we see it may take time to perform these tests manually. Similarly, if classes are complex and that we must carry out regression tests…

To help the developer tools exist and JUnit is the most effective (see details in the section on tools).

Examples of other types of unit tests:

  • Audit code: verification step of lines of code against a standard development
  • Bound checking tool to check any entries in the memory areas
  • Documentation: reading source code automatically generating descriptions of the code
  • Memory leak detectors: these tools tests memory allocation applications
  • Static code (path) analyzer: it is identifying paths / code structure as measured McCabe, etc.

Unit testing tools:

Tools integration:

  • MAVEN: free software tool for the management and automation of production of Java software projects. It provided a way to synchronize independent projects: publication Standardized information vending module jar. In basic version, Maven can dynamically download material on storage software known. It offers the transparent synchronization of modules required.
  • ANT : idem que MAVEN
  • Continuum
  • CVS Subversion
  • JIRA

The testing Framework:

The best approach to undertake unit testing is to establish a « prepared environment » (or Framework) that is dedicated. In the case of development of Java type, the combination is the perfect synergy of tools below:

  • Java development environment integrated with Eclipse in it:
  • unit testing tools: JUnit (Tools written by the creator of the programming Xtrem Kent Beck), it allows to test the development of Java type
  • Generating doc. : JavadocC# / .Net : NUnit
  • C++ : CPPUnit / CUnit
  • Fortran : fUnit
  • Delphi : DUnit

The three basic concepts of JUnit are:

  1. Verdict: Each test can go GREEN (OK or pass) or red (fail or NOK)
  2. Test case: determining if a method produces good results for a given set of values passed as parameters:
    • Represented by a method in a class test
    • There have as many methods as you want in a class of tests
    • There is often a test class for each class to test (one to one)
  3. Test suite: it contains a set of test cases for one class

The analytical coverage tests:

  • Cobertura. It can produce:
    • The number of classes per package
    • The percentage of lines tested
    • The percentage of tested expressions
    • The list of components with the test unit is in error (list of anomalies by component / access services concerned)
  • EMMA
  • Clover

Tools Control code:

Checkstyle: This control ensures a well-defined level of quality of source code.

The reporting tools

Weekly reporting is generated and provided through the tool MAVEN.

Reports to generate 1: Unit Testing in error

This report presents a summary of all the tests and highlights the following:

  • Number of tests
  • Number of errors
  • Percentage of success

Reports to generate 2: Coverage of unit tests

Tools defects:

Each anomaly must be met up through a management tool defects. Thus, the anomalies are included in the tool as tests.

The analysis should lead to:

  • Changing the unit test to incorporate a change in the code. The change was made to replay developer testing
  • The amendment of the Code, if a regression is found. The corrected source code is up for re-replay testing and closure of the defect if the test is validated

Some tools:

  • Mantis
  • BugZilla
  • The module of Quality Center Defects (ed. HP Mercury)

Reminder of good practice in unit tests:

  • Use a framework absolutely
  • Interface with the framework tools
  • Write tests before code
  • A class = test
  • To test the classes in the same package (same directory) that the classes related
  • Code unit tests must change with the application and must be maintained
  • The name of the classes of tests must necessarily include the word TEST (to distinguish them easily and Junit 3 and found her classes)
  • As for automated functional testing make sure to put the system in the same condition as before the tests (this « rehabilitation » may be part of the actions of your Selenium test scripts for example)
  • How to reduce test time:
  • Isolate the unit tests identified as greedy time (DB access, competition …) and run less frequently than every compilation, for example: before each filing of source code in the common code base
  • Do the unit tests on the assembly that has been modified and not the entire

To write this article I helped my experiences but also the return of developer and sites such as (whom I thank for their very informative articles):

I advise you to report for more details on the subject.

Comment mettre en oeuvre des tests unitaires ?

18 05 2009

Définition :

« Test Unitaire (TU) (ou test de développement) : un test unitaire est un test mené par le développeur en environnement de développement, il a pour but de démontrer qu’une unité respecte bien les critères définis dans les spécifications techniques ».

Dans le cas d’un langage procédural l’unité est « la procédure », et dans le cas d’un contexte orienté objet l’unité est représentée par « La classe ».

Les tests unitaires sont les premiers tests de type boite blanche devant être pratiqués par des profils de type développeurs.

Dans le cas de ce type de tests la question importante est « Quel est la qualité des unités développés et comment le mesurer ? ».

Ainsi, il s’agit pour le développeur de tester un module, indépendamment du reste du programme, ceci afin de s’assurer qu’il répond aux spécifications (fonctionnelles / techniques) et qu’il fonctionne correctement. Cette vérification s’accompagne couramment d’une vérification de la couverture de code, qui consiste à s’assurer que le test conduit à exécuter l’ensemble (ou une fraction déterminée) des instructions présentes dans le code à tester. ».

Ainsi, il faut comprendre ce que l’unité doit effectuer (ou la parcelle de code) :

  • Vérifier les tâches et rôles de l’unité
  • Tester les frontières de l’unité (bornes : zéro, un, complet. Chercher une collection vide par exemple)

Cela se traduit de manière simple par la création d’une classe de test par classe développée.

Exemple de tests unitaires de base et représenté par une classe de test :

  1. Invoquer la méthode avec des valeurs passées en paramètres
  2. Observer les résultats
  3. Vérifier si les résultats sont ceux attendus

Ainsi il faut sélectionner des valeurs pour lesquelles on peut déterminer les résultats attendus.

Comme on le voit cela peut prendre du temps d’effectuer ces tests de manière manuelle. De même si les classes sont complexes et que l’on doit procéder à tests de non régressions…

Pour aider le développeur des outils existent et Junit est le plus efficace (voir détails dans le paragraphe sur les outils).

Exemples d’autres types de tests unitaires :

  • Audit de code : vérification pas à pas des lignes de codes vis-à-vis d’un standard de développement
  • Bound checking : Outil permettant de vérifier d’éventuelles écritures dans les zones mémoires
  • Documentation : lecture de code source générant automatiquement les descriptions du code
  • Memory leak detectors : ces outils tests l’allocation en mémoire des applications
  • Static code (path) analyzer : il s’agit d’identifier les chemins / structure de code selon les mesures McCabe, etc.

Outillages des tests unitaires :

Outils d’intégration continue :

  • MAVEN : outil logiciel libre pour la gestion et l’automatisation de production des projets logiciels Java. Il fourni un moyen de synchroniser des projets indépendants : publication standardisée d’information, distribution automatique de modules jar. En version de base, MAVEN peut dynamiquement télécharger du matériel sur des entrepôts logiciels connus. Il propose ainsi la synchronisation transparente des modules nécessaires.
  • ANT : idem que MAVEN
  • Continuum
  • CVS Subversion
  • JIRA

Les Framework de tests :

La démarche optimale pour entreprendre les tests unitaires est de mettre en place un « environnement préparé » (ou Framework) qui soit dédié. Dans le cas de développement de type Java, la combinaison parfaite est la synergie des outils ci-dessous :

  • Java : Environnement de développement intégré : Eclipse avec en son sein :
    • Outils de tests unitaires : Junit (Outils écris par le créateur de l’Xtrem programming Kent Beck), il permet de tester les développements de type Java
    • Génération de doc. : Javadoc
  • C# / .Net : NUnit
  • C++ : CPPUnit / CUnit
  • Fortran : fUnit
  • Delphi : DUnit

Les trois concepts de bases de Junit sont :

  1. Verdict : chaque test peut passer en VERT (pass ou OK) ou en ROUGE (fail ou NOK)
  2. Cas de test : détermine si une méthode produit les bons résultats pour un ensemble donné de valeurs passées en paramètres :
    1. Représenté par une méthode dans une classe de test
    2. Il y avoir autant de méthodes que voulu dans une classe de tests
    3. Il existe souvent une class de test correspondant à chaque class à tester (one to one)
  3. Tests suite : elle contient un ensemble de cas de test pour une classe

Les outils d’analyse de couverture des tests :

· Cobertura. Il peut produire :

o Le nombre de classes par paquetage

o Le pourcentage de lignes testées

o Le pourcentage d’expressions testées

o La liste des composants dont le test unitaire est en erreur (liste des anomalies par composant / services d’accès concernés)


· Clover

Outils de contrôle de code :

Checkstyle : Ce contrôle permet d’assurer un niveau bien défini de qualité de code source.

Les outils de reporting

Un reporting hebdomadaire est prévu et généré au travers de l’outil MAVEN.

Rapports à générer 1 : Tests unitaires en erreur

Ce rapport présente une synthèse de l’ensemble des tests et fait ressortir les éléments suivants :

Nombre de tests effectués

Nombres d’erreurs

Pourcentage de réussite

Rapports à générer 2 : Couverture des tests unitaires :

Outils de gestion des anomalies

Chaque anomalie rencontrée doit être remonté au travers d’un outil de gestion des anomalies. Ainsi, les anomalies sont intégrées dans l’outil au fur et à mesure des tests. L’analyse doit conduire à :

· La modification du test unitaire afin d’intégrer une évolution du code. La modification est réalisée développeur pour rejeu des tests

· La modification du code, si une régression est constatée. Le code source corrigé est re-livré pour rejeu des tests et clôture de l’anomalie si le test est validé

Quelques outils :

  • Mantis
  • BugZilla
  • Le module Defects de Quality Center (éditeur HP Mercury)

Rappel des bonnes pratiques dans les tests unitaires :

  • Utiliser absolument un framework
  • Interfacer le framework avec les outils
  • Ecrire les tests avant le code
  • Une classe = un test
  • Mettre les classes de tests dans le même package (et même répertoire) que les classes s’y rapportant
  • Le code des tests unitaires doit évoluer avec l’application et doit donc être maintenu
  • Le nom des classes de tests doivent comporter obligatoirement le mot TEST (pour les différencier facilement et Junit 3 retrouve ses classes ainsi)
  • Comme pour les tests fonctionnels automatisés pensez bien à remettre le système dans le même état que celui d’avant les tests (cette « remise en état » peut faire partie des actions de vos scripts de tests Selenium par exemple)
  • Comment réduire les temps de test :
    • Isoler les tests unitaires identifiés comme gourmand en temps (accès DB, concurrence…) et les exécuter moins souvent qu’à chaque compilation, exemple : avant chaque archivage du code source dans la base de code commune
    • N’exécuter que les tests unitaires concernant l’assemblage qui a été modifié et non pas l’intégralité

Pour rédiger cet article je me suis aidé de mes expériences mais aussi du retour de développeur et de certains sites comme (que je remercie pour leurs articles fort instructifs) :

Je vous conseil de vous y rapporter pour plus de détails sur le sujet.

Dis tonton… comment on script avec un automate de tests et si tu pouvais aussi me donner quelques bonnes pratiques steuplé ?

1 12 2008

Hum… et tu ne veux pas non plus 100 euros et un Mars ? Bref, je te sens piaffer d’impatience alors écoute donc…

Je vais tenter de vous exposer comment les automates de tests fonctionnent. Je vais parler des QuickTests Pro (QTP) et autre Sélénium. Des automates utilisés pour les tests fonctionnels, les scénarios de tests utilisateurs, etc.

Il y a deux façons de scripter dans QTP, il y a la bonne et… la bonne !

Je m’explique car vous pourriez penser que je ne veuille faire qu’un rapide et stérile clin d’œil au sketch des Inconnus (à l’attention de nos amis anglophone : Inconnus = groupe de comique français des années 90).

Mais avant de passer en revue les façons de scripter demandons nous à quoi peuvent servir ces fameux automates qui pourraient être la solution miracle aux tests (ou pas…).

Théorie des automates de tests :

Sur un site Web (par exemple) QTP enregistre vos actions (enregistrement du mouvement de la souris, des clics de souris, etc.) et les rejoue à volonté. Vous pourrez ainsi exécuter à l’infini les scénarios de tests tout les soirs et, au matin, après votre café, compulser dans la tranquillité les rapports d’exécution.

Cette définition est un mythe urbain répandu par les éditeurs il y a quelques années lorsque les automates de tests étaient peu connus des clients. Depuis et jusqu’à ce jour, hélas, c’est toujours ce que pensent la plupart des clients…

Autres grands principes des automates de tests :

  • Les automates de tests fonctionnent par reconnaissance des objets des IHM (boutons, listes déroulantes, etc.) qu’il stocke dans un répertoire nommé parfois « repository »
  • En mode enregistrement, ils capturent les interactions réalisées sur des objets nécessaires lors du déroulement du scénario de test. Il génère un script en VB (pour QTP)
  • En mode exécution, ils rejouent le scénario de test à partir du script

Les automates de tests dans la vraie vie :

La seule partie vraie dans la définition théorique est « QTP enregistre vos actions et les rejoue à volonté » !

Le reste n’est possible que chez très peu de client ayant un niveau de maturité important dans l’automatisation des tests. Bref, il y a deux manières de scripter :

Le scripting par enregistrement et reworking :
– Le testeur dispose des IHM et scripte directement
– Il lance le script, relève les erreurs et les corrige
– Une fois son script terminée il doit le faire valider par un autre testeur et ainsi procéder à un cross-checking (notion très importante pour finaliser les scripts)

Le scripting en mode « programmation descriptive » et reworking :
– Le testeur ne dispose pas des IHM et doit donc travailler à partir de spécifications techniques et fonctionnelles. Mais cela est très rare chez les clients. De plus cela impliquerai que les spécifications sont déjà exhaustives, validées et stables… (il est bon de rire parfois ;- )
– Il lance le script, relève les erreurs et les corrige
– Cross-checking

Points importants à prendre en compte :
Principe : On automatise que sur une application STABLE et MATURE ! Sinon, c’est de la perte de temps et de l’onanisme pour Mammouth !
– Principe : 100% des tests manuels ne pas automatisable :

  • Il faut savoir prioriser, faire des choix intelligents, utilisation de la loi de Paretto
  • Étudier l’intérêt d’automatiser, etc.

– Principe : mener une étude de faisabilité pour déterminer l’intérêt d’automatiser les tests et la faisabilité technique (voir article sur le sujet)
– Retour sur investissement : des campagnes de tests automatisées ne sont rentables qu’à partir de trois, voir quatre itérations de campagne de tests automatiques (à partir d’une courbe de ROI sur trois ans)
– Création des scripts :

  • la charge de création des scripts est plus importante que la création des tests manuels
  • la difficulté n’est pas dans la capture du script mais dans le choix du critère et du moyen de contrôle du résultat attendu
  • il faut mettre des points de synchronisation ou d’attente entre deux actions pour éviter les times out sur l’apparition de résultat attendu
  • bonne pratique pour un scénario isolé (meilleure robustesse du scénario = se remettre dans les mêmes conditions que lors de l’enregistrement du script) :

– Préparation des environnements et application
– Génération des JDDT
– Tests de l’application
– Nettoyage des environnements et application

– Jeux De Données de Tests (JDDT) :

  • penser à générer les JDDT par l’automate avant l’exécution des scénarios

– Exécution des scripts : la charge d’exécution automatique est moins importante qu’une exécution manuelle
– Maintenance des scripts: la bonne méthodologie et les bonnes pratiques sont à appliquer avant le début de l’automatisation afin de minimiser les charges de maintenance des scripts (normes pour l’organisation, le nommage, la gestion des versions des scripts, etc.).
– Maintenance des scripts: il faut maintenir une compétence d’automatisation pour réaliser les adaptations, évolution des scripts en cas d’évolution de l’application

Je finirai en vous demandant de coupler TOUJOURS et autant que possible votre automate avec votre référentiel de tests ! Ce qui permettra, entre autre, de :
– Stocker la description des scénarios à automatiser
– Stocker les scripts QTP dans QC et les repository associés
– Planifier l’exécution des campagnes de tests automatiques
– Stocker les résultats des campagnes de tests

Dis tonton… comment faire une étude de faisabilité avant d’automatiser mes tests ?

1 12 2008

Principe : mener une étude de faisabilité pour déterminer l’intérêt d’automatiser les tests et la faisabilité technique. Ci-dessous le sommaire type d’une étude, avec quelques indications pour vous aider à remplir ce document.

1- En tout premier lieu il faut valider les aspects techniques de l’automatisation : vérifier que l’automate peut se prêter d’un point de vue technique à l’automatisation de l’application (sur un échantillon de scénarios du lot à automatiser)

  • Utiliser les documents de pré-requis des automates

    2- Prononcer le GO / NOGO

    3- Procéder au Prototypage :

    – Identifier des scénarios représentatifs en utilisant des scénarios existant manuels :

    • Scénario de complexité « Simple
    • Scénario de complexité « Moyenne »
    • Scénario de complexité « Complexe »

    – Mise en place des scénarios dans Quality_Center_TESTLINK_Salome et QuickTests Pro_SELENIUM :

    • Automatisation des scénarios (exemple de critères de sélections des scénarios) :
    • Périmètre : automatiser sur des fonctions stables (test de non-régression et pas de tests automatique sur les évolutions)
    • Fréquence : automatiser les tests sur des fonctions à tester régulièrement
    • Criticité : automatiser les fonctions critiques
    • Estimer la durée de l’automatisation pour chaque scénario
    • Estimer l’exécution manuelle des scénarios (pour comparer les charges)
    • Estimer le coût de maintenance des scénarios en cas de montée de version

    – Dresser les prémices du ROI :

    – Identifier les « Best Practices » à implémenter

    • Librairie de fonctions de l’application, fonctions VB réutilisables, gestion des objets, etc.
    • Se reporter à l’article sur comment automatiser et les bonnes pratiques

    – Identifier le mode de gestion des jeux de données

    – Faire des préconisations sur la gestion des versions de scripts.

    Ci-dessous un petit exemple d’un rapport de faisabilité.

    Sommaire du document :

    • Objectifs de l’étude

    Client_xxx et votre_société on convenu de mener une étude de faisabilité afin de déterminer si une automatisation des campagnes de tests est possible.

    Ce qui pourrait permettre d’obtenir des gains de temps conséquent. Ainsi qu’une réutilisabilité par des tiers autre que les équipes votre_société.

    L’objectif de cette étude est donc de savoir :

    Quels sont les différents modules / parties automatisables ?

    Avec quels moyens (logiciels, outils) automatiser ces tests ?

    Les gains obtenus sont-ils significatifs ?

    • Comment avons-nous procédé ?

    Un premier choix a tout d’abord porté sur l’automate (QuickTests Pro_SELENIUM) au vue des contraintes et besoins de Client_xxx.

    Ensuite, à partir des scénarios présents dans (Quality_Center_TESTLINK_Salome) nous avons sélectionné quelques tests semblant significatifs.

    Puis nous les avons « Enregistré et scripté » à l’aide de l’automate.

    Pour illustrer le plus clairement possible les explications : la vidéo ci après montre un exemple concret d’automatisation de test pour l’application AAA, avec l’automate yyyy (nom de la fonctionnalité).

    L’automate teste automatiquement :

      1. Pas 1
      2. Pas n

    Joindre la vidéo de l’action de l’automate (outils existant sur Internet et gratuit).

    Il est important de prendre un exemple concret sinon l’impact auprès du client en sera amoindri et moins percutant.

    • Résultats de l’étude

    L’étude de faisabilité a montrée que :

    La plupart des applications sont compatibles avec l’outil d’automatisation xxx. Cette compatibilité a été vérifiée grâce au document « ddd », fourni en annexe.

    Une grande partie des scénarios sont automatisables par Selenium :

    · Le module « mmm1 », qui consiste à vérifier le bon fonctionnement de xxx

    · Le module « mmm2 »

    Les parties non automatisables concernent les échanges de flux entre les différents modules :

    · Batchs

    · Echange (problème de détection des objets par xxx), etc.

    Bonnes pratiques des référentiels de test

    15 10 2008

    Dis tonton, tu peux me donner quelques best practices steuplé ?
    Les premières bonnes pratiques sont :

    • Bon sens,
    • Organisation,
    • Réflexions.

    Rien de magiques mais qui, bien appliquées, seront les garants de la bonne utilisation d’un référentiel de test. Je vais les exposer sous forme de question à se poser aux bons moments :
    Gestion des exigences ou requirements :

    Unicité ?

    • Cette exigence est-elle la seule concernant ce point à tester ?

    Clarté ?

    • Mener une réflexion sur l’arborescence à mettre en place,
    • Le besoin est-il exprimé suffisamment clairement et n’y a-t-il pas de zone d’ombre ou d’ambiguïtés sur la compréhension ?
    • Quelles sont les exigences implicites et non listé dans l’expression des besoins, (par exemple), mais dont on doit tout de même tenir compte ?

    Précision ?

    • L’exigence est-elle suffisamment explicite pour être mesurable et quantifiable via des objectifs de test précis ?

    Validité ?

    • Le document à l’origine de l’exigence est-il à jour et validé par le client ?

    – Testabilité ?

    • Est-il possible de créer un ou des cas pertinents pour tester efficacement l’ensemble des aspects de cette exigence ?

    Gestion du catalogue des fiches de test ou Test Plan :
    Fondamentaux :

    • Chaque fiche de test doit-être reliée à une ou plusieurs exigences sinon vous pouvez dire adieu à la couverture de test
    • Une fois la fiche de tests rédigée une astuce est de vérifier si toutes les fiches sont reliées au moins une fois à une exigence, sinon vous avez des trous dans votre raquette !
    • En fonction de la stratégie définie, le Test Plan doit-être hiérarchisé selon les critères fonctionnels, métiers ou organisationnels du client

    L’arborescence du plan de test doit :

    • Être facile à appréhender par des fonctionnels
    • Dans l’ordre des processus métier / applicatif du client (utiliser des codes numériques afin de gérer l’ordre des répertoires par exemple
    • Être déterminée au départ entre tous les acteurs
    • 4 à 5 niveaux MAXIMUM de répertoires sinon la folie vous guettera

    Apporter un soin particulier aux onglets « Details » et « Design steps » :

    • Saisir une description claire par le commun des mortels pour le but de la fiche de test

    Apporter un soin particulier à l’onglet « Design steps » :

    • Être suffisamment précis et détaillée, pour éviter toute ambiguité et autres interprétation au moment de l’exécution
    • Indiquer les données à utiliser ainsi que leurs provenances
    • Renseigner le résultat attendu (RA) de manière précise et clair car le résultat sera comparé au résultat obtenu (RO) lors de l’exécution

    Les bonnes questions :
    – Unicité ?
    o Un objectif = une fiche de test
    – Clarté ?
    o Les différentes étapes du mode opératoire sont-elles clairement identifiées, n’y a-til pas de zone d’ombre ou d’ambigüités sur la marche à suivre ?
    – Données ?
    o Toutes les données représentatives nécessaires aux tests sont-elles identifiées ?

    o Avoir des données qui soient :

    – Cohérentes
    – Précise
    – Représentatives
    – Préparées
    – Couverture ?
    o Le mode opératoire de la fiche de test est-il pertinent et complet pour l’objectif identifié ?
    – Généricité ?
    o Pas de fiche de test valorisée sauf si une valeur est en dur dans l’application à tester

    Conception et exécutions des campagnes de test ou Test Lab :
    – Disponibilités ?
    o L’environnement permettant d’effectuer les tests est-il disponible ?
    o L’application à tester est-elle installée avec la bonne version (politique de versionning du client) ?
    o Les comptes d’accès (login / mots de passes) aux applications et autres serveurs sont-ils valides ?
    – Préparation ?
    o Les fiches de test sont-elles à jour ou datent-elles d’il y a un an ?
    o Les scripts des tests automatisés sont-ils identifiées et dans les bons répertoires ?
    – Clarté ?
    o Les noms des campagnes et fiches de tests sont-ils assez explicites pour votre voisine de palier comprenne ?
    – Données ?
    o A-t’on toutes les données nécessaires pour exécuter les fiches ?
    – Couverture ?
    o L’ensemble de la campagne couvre-t’il l’objectif identifié ?

    Bonnes pratiques pendant l’exécution des fiches de test :
    – Avoir les environnements, plateformes et réseaux disponible
    – Disponibilité de la machine à café effective
    – Pendant l’exécution des steps :
    o Suivre le mode opératoire contenu dans le champ « Description » à la LETTRE !
    o Les tests hors des chemins balisés sont INTERDITS !
    o Comparer le résultat obtenu (RO) avec celui du champ « Expected Result » (ou résultat attendu (RA)).

    Gestion des anomalies ou Defects :
    Fondamentaux :
    – Avoir défini un workflow des anomalies qui soit connu, validé, partagé et clair. Ceci pour tous les acteurs
    – Si oui, est-ce que tout les acteurs sont au courant de leurs rôles et responsabilités ?
    – Si l’exécution produit un échec :
    o Vérifier que le résultat attendu spécifié est exact
    o Saisir le résultat obtenu le plus clairement possible
    o Vérifier que l’anomalie est reproductible sinon l’intégrateur vous ridiculisera et ne prendra pas en compte l’anomalie
    o Ouvrir une anomalie
    o Décrire l’anomalie le plus CLAIREMENT possible sinon votre travail ne servira à rien et vous allez perdre beaucoup de temps en explication
    o TOUJOURS associer à une fiche de test

    – Reproductibilité ?
    o L’anomalie constatée est-elle reproductible dans les mêmes conditions ?
    – Conformité ?
    o L’anomalie a-t-elle été détectée en suivant le mode opératoire inscrit dans la fiche de test ?
    o Les résultats attendus inscrits dans la fiche sont-ils à jour ?
    – Unicité ?
    o L’anomalie détectée n’est-elle pas déjà ouverte ?
    – Pour cela, questionner vos collègues et votre responsable est un bon début
    – Utiliser les filtres et champs de recherche
    o N’y a-t-il pas déjà un ticket ouvert sur un sujet quasi identique ?

    – Gravité ?
    o Quel est le niveau de gravité de l’anomalie ?
    – Critique
    – Majeure
    – Mineure

    Une dernière bonne pratique pour la route ? Faite un copier / coller des pratiques ci-dessus dans un fichier Excel, nommé ce fichier « Checklist garante de la qualité du référentiel de test. ». Il ne vous restera plus :

    • qu’à aller demander une augmentation à votre manager ;-)
    • qu’à la présenter à votre client qui aura enfin un réel exemple d’industrialisation des outils de test

    Et pour la petite histoire, sachez que mettre en pratique tout les jours ces préconisations fera de le mise en oeuvre de cet outil un niveau CMMI 3 (voir article complémentaire sur CMMI3 et QC).

    Manuel de survie sur Quality Center !

    15 10 2008

    Dans le monde du test tout le monde parle de Quality Center (QC pour son petit nom) de l’éditeur HP Mercury. Tout le monde en parle, du client à la société de service, en passant par les ingénieurs qui ne jurent que par ce fabuleux QC… Quel monde merveilleux que le notre dans lequel tout les acteurs d’un même projet partagent, échangent et utilisent le même référentiel de test et font en sorte que les exigences métier soient au cœur des priorités de chacun… Mais… La réalité est moins glamour !
    En effet, parmi ces milliers d’ingénieurs seuls une petite poignée connaissent réellement QC et l’utilisent correctement.
    Ainsi j’écris cet article afin de vous présenter les fondamentaux de l’outil et apporter quelques bonnes pratiques à mettre en œuvre lors de l’utilisation d’un référentiel de test (je ne m’étendrai pas sur la partie administration de cet outil).

    Dis tonton, qu’est-ce qu’un référentiel de test ?
    Ou « Comment à partir du minimum d’effort faire le maximum ? ». Pour la réponse reportez-vous à l’article sur le sujet.

    Dis tonton, il y a quoi dans QC ?
    Avant d’expliquer ce qu’il y a dedans précisons juste que c’est un outil partagé de gestion complète des activités de test, que son ancien nom était Test Director (ou TD).L’interface de QC est relativement « user friendly » (adapté aux utilisateurs) et pratique.

    Dans cet outil il y a 5 onglets (ou parties). Chacun de ces onglets représente une partie importante pour chaque projet de test. Mais voyons plus en détails chacun de ceux-ci.
    – Gestion des exigences ou requirements
    – Gestion du catalogue des fiches de test ou Test Plan
    – Conception des campagnes de test ou Test Lab
    – Gestion des anomalies ou Defects
    – Gestion des releases (non expliqué dans cet article car il faut savoir préserver le suspens)

    Avec pour chaque onglets les fonctionnalités communes suivantes :
    – Rapports & Graphiques
    – Bilan
    – La possibilité de joindre des captures d’écrans, des documents, etc.
    – Impression
    – Administration

    La logique d’utilisation est la suivante, tout d’abord on élabore la stratégie de test et la matrice de couverture (onglets exigences et Test Plan). Puis, on planifie les exécutions (Test Plan et Test Lab), lors des exécutions on crée les fiches d’anomalies via lesquelles on fait valider les corrections.
    Enfin, on met à jour les tests et on réitère le cycle de tests.

    Plongeons nous dans QC :
    Gestion des exigences ou requirements :
    Il s‘agit d’identifier les exigences de test (à partir des exigences métier et autres spécifications), de structurer le plan de test et spécifier les futures fiches de test.
    Petit rappel : les exigences peuvent être l’expression des besoins ou la liste des fonctionnalités à tester. Ainsi, l’ensemble des exigences de test définissent le périmètre à couvrir. Ces exigences sont aussi le point commun entre les dossiers de spécification et les tests à exécuter.
    Les prendre en compte permet d’assurer la traçabilité entre la phase de conception et celle d’exécution. Enfin, les exigences sont le support aux études d’impact des évolutions des spécifications sur les plans et fiches de test.
    Cet onglet permet également de voir tout les détails des exigences et de voir le statut des résultats des fiches de test couvrant une ou ses exigences propres.
    Enfin, on peut soit entré manuellement les exigences soit utiliser une macro d’import à utiliser sur des documents aux formats Word ou Excel. Soit sous forme d’addin ou de développement interne au client ou la société de service.

    Gestion du catalogue des fiches de test ou Test Plan :
    Il s’agit de concevoir les fiches de test, définir les scénarios et préparer le reporting (en collaboration avec le Test Lab). Il s’agit aussi de créer l’arborescence des fiches de test ainsi que les fiches et créer les liaisons entre les exigences et fiches de test.
    Le Test Plan correspond à l’ensemble des fiches de test, en cours de constitution ou opérationnelles.

    Conception et exécutions des campagnes de test ou Test Lab :
    Il s’agit de la création et de la planification des campagnes de test. L’exécution a lieu dans cet onglet, qu’elles soient automatisés ou manuel.

    Rappelons que :
    – une campagne de test est une combinaison de scénarios (composés de fiches de test)
    – une fiche de test peut faire partie de plusieurs campagnes
    – a l’issue de l’exécution des différentes épates, une fiche de test est considérée en statut PASSED, si et seulement si TOUTES les étapes la composant on ce même statut
    – si au minimum une de ces étapes est en statut FAILED ou NOT COMPLETED la fiche de test aura ce même statut

    Gestion des anomalies ou Defects :
    Après exécution des scénarios / fiches de test il s’agit de décrire les anomalies et renseigner le reporting de campagne.

    La suite de l’article concerne les bonnes pratiques