Comment tester en « mode agile » ?

18 05 2009

Comme promis aux nombreux lecteurs m’ayant fais la demande, je vous présente cet article traitant des tests en mode agile. Il s’agit d’une vulgarisation et je tente de vous présenter les principes et points importants à prendre en compte.

SCRUM, XT programming et autres acronymes du même acabit sont légions depuis quelques années et sont très en vogue parmi les développeurs. En fait il s’agit de développer le plus rapidement possible quelques fonctionnalités et de mettre tout aussi rapidement en production (d’où le terme de sprint que nous verrons plus tard) !

Et le test me direz-vous ?

Les activités de tests sont bien entendu réduits à au maximum… mais… il faut savoir qu’il y a une méthodologie spécifique concernant les activités de tests et qui s’insère naturellement et simplement en mode agile.

En premier lieu je passe en revue les deux méthodes de développements les plus connues dans le mode agile. En effet, elles représentent la majorité des projets de ce type (nos chers développeurs les préfèrent aussi). Il s’agit du SCRUM et de l’eXtreme Programing.

Méthode SCRUM :
La définition du mode agile est en partie basée sur la remarque suivante : « … L’approche course de relais pour le développement de produits…peut être en conflit avec les objectifs de vitesse et de flexibilité maximum. A l’inverse, une approche holistique comme au rugby— quand une équipe essaie d’avancer en restant unie, en se passant le ballon de main en main— peut mieux servir les exigences de compétitivité d’aujourd’hui ». Hirotaka Takeuchi et Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, Janvier 1986.

Ainsi le SCRUM est un processus agile qui permet de produire la plus « grande valeur métier » dans la durée la plus courte. Du code est produit à chaque sprint (toutes les 2 à 4 semaines).

Le métier (les utilisateurs par exemple) définit les priorités. L’équipe de développeur s’organise elle-même pour déterminer la meilleure façon de produire les exigences (ou backlog) les plus prioritaires.

Et à chaque fin de sprint, tout le monde peut voir fonctionner le produit courant et décider soit de le livrer dans l’état, soit de continuer à l’améliorer pendant un sprint supplémentaire.

Les grands principes du SCRUM :

  • Equipe responsable, en auto-organisation
  • Avancement du produit / code par une série de « sprints » de 5 jours maximum
  • Exigences définies comme des éléments d’une liste appelée « backlog du produit »
  • Pas de prescription de pratiques d’ingénierie
  • Utilisation de règles génériques permettant de créer un environnement agile pour un projet

eXtreme programming :
En 2001, aux États-Unis, dix-sept acteurs clés du développement logiciel se sont réunies pour débattre de leurs méthodes respectives, dites méthodes agiles. Les plus connus d’entre eux étaient :

  • Ward Cunningham l’inventeur du Wiki via WikiWikiWeb
  • Kent Beck, père de l’extreme programming et cofondateur de JUnit
  • Ken Schwaber et Jeff Sutherland, fondateurs de SCRUM
  • Jim Highsmith, prônant l’ASD
  • Alistair Cockburn pour la méthode Crystal clear
  • Martin Fowler et Dave Thomas
  • Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD (Développement rapide d’applications).

Ces nombreux experts réussirent à extraire de leur méthodes respectives des critères pour définir une nouvelle façon des développer des logiciels. De cette réunion devait émerger le Manifeste Agile, considéré comme la définition du développement agile et de ses principes.

Ainsi leurs conclusions furent :

Principales causes identifiées de l’échec des projets :

  • Mauvaise compréhension du besoin : 51%
  • Estimation et planification déficiente : 48%
  • Technologies mal maîtrisées : 45%

Méthodes classiques trop lourdes :

  • Manque de réactivité
  • Excès de documentation

But : produire un logiciel de qualité en respectant les délais et le budget grâce à un ensemble de pratiques efficaces poussées à l’extrême.

Dans la pratique les choses sont bien différentes… En effet, les délais et budgets sont à peine respectés (comme dans les projets en mode classique – processus en V et autres) et la qualité est inconnue de la plupart des développeurs.

En fin de compte les problèmes concernant les tests sont les mêmes sur tout les projets. Le principal étant la non connaissance des bonnes pratiques de tests par les chefs de projets (ou scrumMaster) et les développeurs (ou CoWboyZ).

Ainsi le mode agile possède aussi quelques bonnes pratiques à mettre en œuvre et faire respecter par les ScrumMaster et autres chefs de projet. Voici celles que j’ai apprises et optimisées lors de mes missions.

Ci-dessous le processus de développement logiciel en mode agile :

image1_agile

On constate que le processus fonctionne un peu comme un sous-marin, avec des compartiments devant rester étanches, sous peine de ne plus respecter le processus…

  • Ainsi, les métiers définissent leurs besoins et exigences, ils les communiquent au chef de produit
  • Le chef de produit en fais une synthèse et en propose une priorisation au chef de projet (ou ScrumMaster)
  • Ensuite, le chef de projet les prends en compte et détermine les exigences (ou backlogs) qui seront développés par son / ses équipes « agiles ».
  • Sachant que les users métiers ne doivent parler qu’uniquement au chef de produit et que celui-ci est le seul à parler avec le chef de projet
  • Enfin, les développeurs et testeurs ne peuvent pas parler avec les users ni les chefs de produit

Ce mode de « communication en mode étanche » a été préconisé à l’époque afin d’assurer la tranquillité de l’équipe de développement et s’assurer que ceux-ci ne seraient pas dérangés. Ainsi, les créateurs du mode agile crurent assurer en partie par ce biais le respect des délais et des budgets.

Mais, les effets pervers de ce mode étanche sont :

  • Pas ou peu de cahier des charges / spécifications en entrée des développements
  • Les besoins et exigences des utilisateurs sont filtrés et surtout réinterprétés par trois personnes différentes ayant chacun des priorités et objectifs différents
  • Pas de traçabilité des exigences
  • Des effets de ralentissements ou « d’à peu près » car quand un développeur a une question sur une fonctionnalité à coder, il ne peut la poser qu’au chef de projet qui demandera au chef de produit qui demander aux utilisateurs. La réponse (si la question a bien été posée) prendra le chemin en sens inverse…
  • Les testeurs non presque pas de documentation et doivent souvent attendre la fin du  deuxième sprint pour avoir une certaine visibilité sur ce qu’il y aura à tester

Finissons cette description du processus logiciel en mode agile par la communication au sein de l’équipe agile.

  • En début de chaque sprint (tous les lundis donc car un sprint = 5 jours) il y a une réunion de démarrage qui doit aborder le planning, les outils, etc.
  • Pendant les sprints il y a une réunion quotidienne ne devant pas avoir lieu dans une salle (ceci reste un mystère pour moi j’avoue) mais plutôt dans un lieu incongru et très bruyant comme la salle à café ou équivalent. Cette réunion ne doit pas dépasser 15 minutes (avec des questions comme : les problèmes rencontrés, etc.)
  • Le reste de la communication est assurée par les « Instant Messenger » comme MSN et équivalent (même si les développeurs et testeurs sont dans le même bureau, ce qui est hallucinant à vivre je vous l’avoue !)

Synthèse des fondamentaux de l’agile :

  • Sprint et itérations très courts
  • Une équipe ne communiquant que par son scrumMaster
  • Spécifications « rédigées » pendant les sprints
  • Pas de plan de tests – scripts « one shot »

Ci-dessous le séquencement d’un projet agile :

image2_agile

Au sein d’un projet il y a plusieurs releases. Chaque release est composé de plusieurs sprint. Tous les 3 ou 4 sprints une release / package est construite par les développeurs (en 1 journée grand maximum). Puis, le package doit-être mis en production. Si vous avez lus mes articles précédents vous constaterez bien vite qu’il manque une étape importante avant la mise en production… (Roulement de tambour… suspens…), il s’agit des tests avant la mise en production. Comme :

  • Les tests de performance
  • Les tests d’exploitabilité
  • Les tests d’installations
  • Les tests de MEP à blanc, etc.

Bonnes pratiques :

  • Mettre en place une machine d’intégration continue qui assurera la « récolte » des développements, leurs sauvegardes et leurs versions
  • Prévoir, définir et mettre en œuvre les tests devant valider les packages :
  • Souvent cette étape se résume à un combat pour l’imposer auprès des chefs de projet qui trouve que les tests ne font pas partie du mode agile et ralentissent le processus. Ces mêmes chefs de projet qui subitement changent d’avis après des mises en production sans tests préalable… C’est ce que l’on appel l’expérience par l’échec.

image3_agile
Détaillons les activités de tests dans le mode agile en prenant un exemple concret :

Dans le schéma ci-dessus j’ai modélisé une release comportant uniquement deux sprints, une étape de packaging et la mise en production (MEP).

Itération 1 – Planning du sprint 1 (ou S1) :

  • Lundi 2 février au matin : réunion de démarrage (1 heure maximum – A). Le scrumMaster explique aux 3 développeurs et au testeur unique les backlogs (B) devant être développés et testés
  • Lundi 2 au vendredi 6 février matin les développeurs on les tâches suivantes :
  • Prise de connaissance des backlogs fourni par le scrumMaster
  • Développements (codage en Java – C) des backlogs (et des classes de tests bien entendu) :
  • + Tests unitaires (D) en utilisant Junit et Javadoc au sein du framework Eclipse
  • Chaque les développeurs « commit » leurs bouts de code. Ce code est pris en charge dans le processus d’intégration continue (E)
  • Lundi 2 au vendredi 6 février matin le testeur a les tâches suivantes :
  • Prise de connaissance des backlogs
  • Lecture des rapports de tests générés par Junit
  • Création des scripts de tests (sous Selenium – F)
  • Vendredi 6 février après-midi :
  • Le scrumMaster décide lors de la réunion matinale quotidienne de mettre fin au sprint 1 (S1) ce vendredi en fin de journée car il estime que les objectifs ont été atteints. Il envoi un mail pour en prévenir le chef de produit.

Planning du sprint 2 (S2) :

  • Lundi 9 au 13 février matin : réunion de démarrage (1 heure maximum). Le scrumMaster explique aux 3 développeurs et au testeur unique les backlogs devant être développés et testés
  • Lundi 9 au 13 février matin les développeurs on les tâches suivantes :
  • Prise de connaissance des backlogs fourni par le scrumMaster
    Développements (codage en Java) des backlogs (et des classes de tests bien entendu) :
    + Tests unitaires en utilisant Junit et Javadoc au sein du framework Eclipse
    Chaque les développeurs « commit » leurs bouts de code. Ce code est pris en charge dans le processus d’intégration continue
  • Lundi 9 au vendredi 13 février matin le testeur a les tâches suivantes :
    Prise de connaissance des backlogs S2
    Lecture des rapports de tests générés par Junit du S2
    Création des scripts de tests (sous Selenium) pour le S2
    + Le testeur doit aussi faire en parallèle (dès le lundi après la réunion) :
    Lancement et surveillance des scripts du S1 (H)
    Remontée des anomalies sur les backlog du S1 au scrumMaster (uniquement à lui – qui est juge et partie sur la décision de corriger ou pas les anomalies remontées par le testeur – G)
  • Vendredi 13 février après-midi :
    Le scrumMaster décide lors de la réunion matinale quotidienne de mettre fin au sprint 2 (S2) ce vendredi en fin de journée car il estime que les objectifs ont été atteints. Il envoi un mail pour en prévenir le chef de produit et indique qu’une mise en production est possible sans problème
    La MEP est effectué par un des développeurs. Juste avant de partir en week-end il lance l’installation en étant sur à 100% que tout se déroulera bien (I)

Fin de l’itération 1

J

Voici donc le fonctionnement typique d’une équipe agile classique. Suivant vos expériences, vous vous apercevrez qu’il y a de nombreuses erreurs de jugement et de très importants manques aux niveaux des tests !

Je vais lister ci-dessous les bonnes pratiques pouvant être mises en œuvre dans un projet agile. Sachant que ces bonnes pratiques devront être présentées et défendues auprès du scrumMaster, par le testeur.

L’intervention des bonnes pratiques est signalées par une lettre dans le planning ci-dessus et expliquées en détails ci-dessous :

image4_agile

Lien vers l’article traitant des tests unitaires.

Publicités




How to make unit test?

18 05 2009

The unit test :

Definition:

“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.





Preview: new versions of Quality Center and QuickTest Pro V 10.00!

5 02 2009

I attended the presentations of new versions of Quality Center (QC) and QuickTest Pro (QTP) in the version 10.00. This HP in Issy les Moulineaux (Near to Paris – France) a rainy morning. And so, in the TGV (a very fast railway for the English) brings me back, I type this article to share with you the information provided by HP in their basement …
The celebration program was:

  • New QC 10.00
  • New BPT 10.00
  • New QTP 10.00
  • Method of pricing (on the licensing policy – a subject not treated here)
  • Demos

(Does the use of figures 10.00 warns that there will be many patch and it is expected to version 10.94 Only time will tell).
HP has reported that all the information and risk are subject to because not included in versions 10.00 in February. Yet I take the bet that if. This warning of HP is probably the only legal title.
I need not address in this article from Business Process T. (BPT) for the moment because it’s uncommon among French customers and above all a desire / wishes for HP to sell full containers (first desire of any software publisher after all).

Quality Center (QC) 10.00:
Regarding what Quality Center is, I refer you to my articles on tools for testing repositories / management as well as those on QC. The release date is scheduled for 31 January 09 and three packs will be distributed:

  • QC Starter Edition: Designed for a team of 5 single-project
  • Enterprise Edition QC: QC 9.2 equivalent current (TD for Quality Center)
  • First Edition: Designed for a team with needs such as advanced multi-project, high availability platform supporting QC, etc.

I will detail here only the Enterprise Edition / First of QC because it is where the real changes / new features.
QC Enterprise Edition / First, the modules present:

  • Requirements management
  • Test plan
  • Lab Tests
  • Risk based testing
  • Release management
  • Defect management
  • QA Lab Manager

The sentence shock input presentation by HP was « Mastering the chaos version requirements, tests and components”! Rather ambitious and shock, but see news (grouped by topic below).

Reporting:
Centralizing these unlike the current dashboard (9.2)

  • New module replacing the dashboard
  • Centralized reporting
  • All panels are centralized in the module
  • Creation of public view and private
  • Report possible multi-project
  • Take this version of reporting as the V1 from the old … Finalized dashboard module so.

Possibility to define a more complete test:

  • Risks and technical occupations ==> assigned to a functional complex – calculation of risk

Versioning: this module is not useful for a small project
Version Management requirements, tests (test sheets for example) and components:

  • Check-in and check-out
  • Comparison between the
  • Ability to return to a previous version
  • Can be activated at a project through the hotel (the new business administrator, therefore)
  • The versioning is of course to be taken into account before the project starts (part of best practices dear to CMMi and other ITIL)
  • Establishment of baselines (creating a picture of a set of project components), to mark / identify the milestones of the project. Example: requirements validated V1: establishing a baseline. It also allows you to freeze a configuration of testing association with a test campaign.
  • Guarantees to run the correct version vis-à-vis a test campaign
  • Comparison of baseline possible ==> identifying the elements that have changed

QC Requirements Management:

  • It would be a direct competitor tools like Doors, Req Pro and other Caliber
  • HP cites a 2008 report issued by Forrester and noting that the new management module requirements of HP is the first before all others. Hmm … I just think this kind of premature conclusion since the version that comes out in February and that results can be obtained after a few months of intense use in the real customers. A monitor then.

Other: template:

  • It is now (finally?) possible to define a project template and especially to use it and share it between many projects. The major fact is the possibility to update the template and distribute the update on the entire project implementing it. You should know that the current version 9.2 is only possible through internal development of each client.
  • Ability to setup and maintenance of centralized template
  • Broadcast « automatic » updates
  • Maintenance of template by administrators
  • Please note that this feature also joined the concepts of best practices advocated by CMMI and ITIL

Functional testing:

  • Output January 31
  • WinRunner is no longer included in this pack

Contained in the pack Functional testing:

  • Resource Management QTP:
  • Versioning
  • Tools Comparison

QuickTest Pro (QTP) 10.00:
Better reporting

  • Monitoring local system: this module allows RUN when scripts to monitor the implementation and some points. Specifically we can identify at what point and following the action script a problem occurs. For example, a peak CPU load generated by the action of a QTP script. This will help to strengthen links and interactions between the teams test and those in charge of performance tests. It should be noted that this function has been implemented by many customers through internal development. They will appreciate.
  • Improvement of the various GUI:
  • Tools management tasks (TODO)
  • Support for scripting
  • Export to DOC format and PDF reporting
  • Ability to attach screenshots
  • Direct access to the script from QTP reporting
  • Ability to compare two versions of scripts easily

My final impression is that QTP is transformed into CASE (Computer Aided Software Environment or AGL (Atelier de Genie Logiciel for French people)) but oriented tests. What I mean is that HP has incorporated many features to better script and more to help developers fully QTP scripts. I find it beneficial for all writers. Do not draw hasty conclusions and wait till the first returns of experience other than HP. Finally, synergy, linkages between QTP and QC seem also strengthened.

What about migration?
To migrate your versions to 10.00 you must already have version 9.0 (patch 26) and QC 9.2 (patch 12). Unable to migrate with older versions as these.
An upgrade tool is available on the HP site to help you with migration. But be careful if this works as the previous times you need to go through testing experts to help you because the migration tool from HP does not expect miracles and calls for the intervention of humans.
One last thing about the migration, if you go to QC 10.00 you should necessarily go to the 10.00 version of QTP.

WinRunner:
Do we collect on the body of this bloodless automation testing tool that was a forerunner in our industry. He well-deserved retirement. Rest In Peace WinRunner and thank you for everything.

  • It is no longer distributed with the pack functional testing
  • End 2009: End of the developments and patch
  • End 2011: The end

Goodies and “petits fours” (little cakes for corporate party in France):
And the goodies offered by HP for us to reward our time and attention? Well we had a pink plastic pen, a few blank sheets to the header of HP … and a book in English on the tests!
His name is « Optimize Quality for Business Outcomes – a practical approach to software testing » and this in its third edition. This is the first time I have heard of this book dealing with the tests. Below I list the main chapters:
1. What is the big deal about testing?
2. Testing the business requirements: start at the root of the problem
3. Test rules: build the backbone for effective testing
4. Test cases: let’s get down to the real stuff
5. Test optimization: balancing risk and effort
6. Why bother with non-functional testing?
7. Application security testing: the next frontier
8. Test sourcing: how outsourcing improves cost effective testing
9. Successful goal-driven approach KPI
10. Getting started: putting it all together
11. Appendix A – Common test techniques
12. Appendix B – HP application quality management solutions introduction and overview
13. Appendix C – Verification
14. Appendix D – Naming conventions

I try to read this book quickly and I will make my opinion, soon.

And then?
Ultimately, HP’s strategy is to play together in the editing software to expand its functional and its turnover. What is a healthy and able to provide end users with better service and services companies expanding their services (with a contribution of value added greater than today).
However, HP blithely tramples the toes of many competitors / software editor. So publishers with tools for managing requirements and configuration management / version will inevitably their market shares reduced inexorably by HP. As inexorable as desertification in Africa? Not so on this because, take for example publishers management software requirements, their products will not be dedicated more complete than that of HP. It remains to be seen more fully the choice of HP doing in this area and the effort to test them in real life!





Critères de choix d’un outil de référentiel de tests

23 01 2009

Cet article doit pouvoir vous aider pour choisir un outil de référentiel de tests dans la sérénité. Pourquoi ? Car chez certain client les choses ne sont pas aussi facile que l’on peux le croire. Exemple : un client possède déjà un outil de chez HP (QC) et en même temps utilise Entreprise Architect (EA) pour gérer ses exigences. La question est « Est-ce que l’on utilise quality center ou EA ? ». A partir de cette question il y a eu des remous sur le choix à faire. Et la politique inter-services et le frein de certains utilisateurs n’aidant pas le stand-by fut prononcé… Jusqu’à que la liste ci-dessous soit apportée.

Elle n’existe que pour apporter des informations FACTUELLES sur les fonctions principales devant être remplies par un outil de référentiel de tests. Comme vous pourrez peut-être le constater elle n’est pas orienté pour que Quality Center soit choisi (je tiens à dire que ce n’est pas de l’ironie).

Un référentiel de tests doit pouvoir gérer (uniquement les fonctions de bases) :

Fonctions de niveau 1
Gérer les exigences de tests :

  • Aide à la création
  • Multi-utilisateurs : Partage aisé entre tous les acteurs du projet
  • Modification aisé
  • Lien facile entre exigences > Fiches de tests > Anomalies
  • Génération d’une matrice de couverture exigences ==> campagne / scénarios
  • Analyse du taux de couverture
  • Impression facile des listes
  • Gestion des versions des exigences

Gérer les fiches et cas de tests :

  • Aide à la création
  • Modification aisé
  • Possibilité de joindre des documents
  • Multi-utilisateurs
  • Gestion des versions

Gérer les cahiers / dossiers / plan de tests :

  • Aide à la création des scénarios
  • Multi-utilisateurs
  • Gestion des versions

Aide au pilotage des tests :

  • Etat d’avancement de la conception des tests
  • Etat d’avancement de l’exécution des tests
  • Etat d’avancement global d’une campagne de test
  • Impression de rapport déjà renseigné et formaté
  • Multi-utilisateurs

Fonction de niveau 2 :
Gérer les anomalies :

  • Outils de création de worflow des anomalies
  • Création et renseignement complet d’une fiche d’anomalie
  • Possibilité de pièces jointes, captures écrans, etc.
  • Moteur de recherche intégré
  • Lien facile et direct entre une fiche / cas de tests et une anomalie
  • Notification par mail des anomalies vers les acteurs du projet
  • Multi-utilisateurs
  • Impression de rapport déjà renseigné et formaté avec chiffres et statistiques par modules / fonctions, etc.

Interfaçage et pilotage directs des :

  • Automates de tests fonctionnels
  • Automates de tests techniques (performance)
  • Anomalies (si pas intégré)




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





Liens et sites

27 09 2008




Liste de sociétés employant des testeurs

27 09 2008

Au fur et a mesure je vais rédiger des fiches par entreprises en passant en revue leurs offres sur les activités de tests.

Je listerai au fur et à mesure les sociétés ayant des activités dans le monde du test. Je tenterai également de vous faire part de mon ressenti…

Région parisienne :

GFI : SSII de grande ampleur.

Sur leur site corporate il ne font figurer qu’un PDF de 4 pages dont une seule consacrée aux tests. Ils abordent les activités de tests uniquement par la TRA ou Tierce Recette Applicative.

SOPRA : SSII de grande ampleur.

Une offre de tests existe.

VISION OPTIUM : SSII moyenne

Deux offres sont présentées, sur la TRA et le conseil.

ATOS ORIGIN : SSII de grande ampleur.

Ils ont leur méthode « TAM » et leur credo est « Sécuriser le passage du développement à la production ».

LOGICA : SSII de grande ampleur. Je connais leur offre de tests mais sur leur site je n’ai rien trouvé en rapport avec…

ALTRAN : SSII de grande ampleur. Idem que LOGICA.

AEDIAN : SSII de grande ampleur. Ils abordent le sujet en parlant de « Fiabiliser le SI« .

SOGETI : SSII de grande ampleur.ayant une offre testing qui s’appuie sur la méthodologie TMAP Next. Méthodologie existante depuis de très nombreuses années. Je rédigerai un prochain article sur ce sujet. Connaissant également leur offre il est curieux de constater les présentations sur leur site Web.

STERIA : SSII de grande ampleur.ayant plus de 300 testeurs (DP, CDP, analystes, etc.) et opérant principalement en Ile de France. Leur offre est également sur la fiabilité des SI.

Criteres Testing : SSII et éditeur du site testissimo.com (qui me semble sans activités). Leur offre est classique.

Région française :

  • Astek
  • Dalysis
  • Keepcore
  • Qualife :  SSII œuvrant surtout dans le sud de la France
  • All4test

MONDE :
Adresses en Allemagne et Chine :
http://www.industrystock.com/html/Test%20de%20logiciel/product-result-fr-38083-0.html