Quality Center et ALM 11 ?

La présentation d’ALM 11 était plutôt intéressante j’avoue. Une grande messe avec son lot de nouveautés, de discours roboratif, de partenaires avides de visibilité, le tout dans la sauce corporate habituelle.

Introduction de la communication

Mais l’impression générale est très positive pour mon ressenti. Je vous laisse donc à votre appétit gourmand de testeur et bonne lecture.

Je vous présente cela par ordre d’apparition à « l’écran »…

La chargé de communication HP monte sur la scène et « blabla… merci… blabla… ». La chose à retenir étant la présence des partenaires comme Sogeti, Stéria, Atos Origin pour les industriels des tests. Mais aussi des sociétés comme Dalisys, Open, ValidIT ou C2L2 consulting pour les challengers en devenir. Et enfin Cognizant souhaitant finir d’établir sa tête de pont testing en France.

Hélas leurs présences ne se sont réalisées que sous forme de plaquette disponible sur des présentoirs (certains partenaires ont même osés des plaquettes bricolées et imprimées surement sur des imprimantes 9 aiguilles… Qu’il est bon de rire parfois).

Introduction du DG HP France – Bruno Buffenoir

Le DG de HP France monte sur la scène et tente d’aborder le test et ALM 11 en partant de la génération Y et leurs besoins en agile, mobilité, Web 2.0, réseaux sociaux, les cycles courts, etc. Hum… pourquoi pas mais la ficelle « On trouve un sujet sexy et teasing pour introduire ALM » était trop visible et surtout sans rapport flagrant avec le sujet. Bref, HP s’est fait plaisir mais nous on patienté en attendant.

Ensuite un passage par les nouveaux enjeux pour le SI qui était cette fois dans le vif du sujet enfin. Le paradigme de HP étant d’évoquer le concept de « Supply chain IT » !

Le concept peu clair à l’oral, s’éclairci en lisant les slides (reçu récemment). En fait la supply chain IT est ce qui fait le lien et assure le support entre les utilisateurs (clients, employés, etc.) et le SI d’une entreprise (processus, applications, etc.). Concept nouveau pour moi j’avoue et qui ouvre quelques perspectives intéressantes pour le futur.

Après la supply chain IT, on arrive aux nouvelles tendances comme le mobile computing, le cloud (private ou pas), la virtualization, et l’ALM ou Application Lifecycle Management.

L’ALM est donc décrit sous la forme du processus run > plan > built > retire

L’enchainement est fait sur l’intégration de bout en bout de la qualité, de la sécurité et des performances des SI.

Enfin, la conclusion est faite en mettant en évidence l’ALM et la supply chain IT.

Présentation d’ALM par Yrieix Garnier –Directeur de produit HP

Intérêt de son intervention ? En triant dans ce qu’il a pu dire on peut remarquer les points suivants :

Implémentation d’HP ALM 11

HP ALM 11 était présenté comme la plateforme JAZZ d’IBM RATIONAL (slide presque identique que chez IBM) !

Ok, après avoir bien rigolé notons tout de même qu’autour d’HP ALM 11, présenté comme « référentiel unique, plateforme unifiée », sont intégré les applications / Fonctions suivantes :

• HP Sprinter pour les tests « manuels »
• Quality Center 11 – Functionnal Test Engineer
• ALM 11 – Project Manager (étrange ALM 11 est présenté pourtant comme la plateforme…)
• PC 11 / LoadRunner 11 – Performance Engineer
• ASC + Fortify – ASC étant l’ex-module tests de sécurité
• RM 11 + Business Process Management – Biz Analyst

En transverses du tout la tracabilité est présentée comme de bout en bout. A vérifier donc.

En support les “outils” developer MSVS, developer .NET et developer Java.

Intégration et collaboration

En plus de la plateforme ALM 11 les environnements (ou framework) comme Eclipse, MS Visual Studio et Collabnet sont intégrés. Ceci avec des accès direct aux éléments comme ALM / QC depuis l’IDE Eclipse, les exigences, le module defect, etc.

Et le tout avec la traçabilité assurée et une synchronisation bi-directionnelle.

Plus largement, le discours était très orienté « Pensons aux développeurs, à leurs besoins et tentons de les impliquer plus largement dans la qualité ».

Ce qui me semble une démarche saine et pleine de pertinence. Reste à voir le degré d’appropriation des communautés des développeurs dans quelques mois.

Présentation des avant-vente Olivier Jean, Jean-Luc Malvoisin et Mohamed Zouari

Ce fut le clou de la matinée car ils ont su nous expliquer ALM 11 avec des mots de tous les jours et sans le discours corporate classique. Merci à eux.

Quelques chiffres afin d’épater :

• 1 plateforme unifiée
• 8 nouvelles versions d’applications

o   HP ALM 11, HP Quality Center 11, HP Performance Center 11, HP Sprinter, HP Loadrunner 11, HP Functional Testing 11, Test Data Management 1.1 et HP Service Test 11

• 50 dépôts de brevets

o   Sur l’Ajax Truclient et HP Sprinter notamment

• 100 nouvelles fonctionnalités

De quoi faire saliver ;- )

Avant de rentrer dans les démonstrations, une explication sur les noms a été faite, précision utile :

• Quality Center Entreprise 10 devient => Quality Center Entreprise 11
• Quality Center Premier 10 devient => HP Application Lifecycle Management 11
• Performance Center 9.5 devient => HP Performance Center 11

S’ensuit quatre démonstrations sur les points suivants :

• Planification, suivi et rapports
• Processus métier et gestion des exigences
• Accélération de l’exécution des tests – Intégration développement
• Validation de la performance sur la plateforme unifiée ALM

Les démonstrations on eu lieu sous forme de jeu de rôle de type « (DSI parle) Mais dis moi, on me signale des soucis dans notre SI ! ». Scène totalement improbable pour un DSI mais qui a eu le mérite de mettre de la vie dans ces démonstrations en nous présentant les nouveautés. Merci les avant-vente !

Pour plus de détails vous pouvez consulter les articles sur les points suivants :

• ALM 11, les processus métiers et les exigences ?
• ALM 11 et HP Sprinter ?
• ALM 11 et les pilotages des tests ?
• ALM 11 et les tests techniques – LoadRunner ?
• Présentation d’ALM 11 / Quality Center 11.00

How to make unit test?

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):

• http://fr.wikipedia.org/ (and UK version)
• http://developpez.com (http://smeric.developpez.com/java/astuces/tests/)
• http://www.dotnetguru.org/articles/dossiers/testunitaires/UnitTest.htm
• http://www.tarpoon.org/tag/cobertura/

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

Comment mettre en oeuvre des tests unitaires ?

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)

· EMMA

· 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) :

• • http://fr.wikipedia.org/ (et la version anglaise également)
  • http://developpez.com (http://smeric.developpez.com/java/astuces/tests/)
  • http://www.dotnetguru.org/articles/dossiers/testunitaires/UnitTest.htm
  • http://www.tarpoon.org/tag/cobertura/

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

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

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!

Criteria for selecting a management testing tool (or quality management tool)

Criteria for selecting a management testing tool (or quality management tool):

This article will help you to choose a management testing tool in peace. Why? Because for some client it’s not easy as we can believe. Example: a client already has a tool from HP (Quality Center) and at the same time using Enterprise Architect (EA) to manage its requirements. The question is « Is what we use quality center or EA? ». From this question there was a stir on the choice. And inter-service policy and the brake of some users does not help the stand-by was delivered … until the list below is made.

This list exists only to provide FACTUAL information about the main functions to be performed by a management testing tool. As you may be able to see it is not oriented for Quality Center is chosen (I want to say it’s not irony).

A repository of tests should be able to manage (only basic functions):

Level 1 Functions
Manage the test requirements:
* Support for the creation
* Multi-user: easy sharing between all project stakeholders
* Easy change
* Easy link between requirements> Test Sheets > Defects
* Generating a matrix coverage requirements ==> campaign / scenarios
* Analysis of coverage
* Print friendly list
* Version management requirements

Manage the test plan to test cases:
* Support for the creation
* Easy change
* Ability to attach documents
* Multi-user
* Version management

Manage books / files / test plan:
* Support for the creation of scenarios
* Multi-user
* Version management

Help manage tests:
* Status of design tests
* Status of the test run
* Status of an overall campaign test
* Printing of reports already formatted and filled
* Multi-user

Function Level 2:
Manage defects:
* Tools for creating worflow defects
* Create and complete an information sheet defect
* Possibility of attachments, screen captures, etc.
* Integrated search engine
* Easy and direct link between a sheet / test cases and an defect
* Notification by mail to the defects involved in the project
* Multi-user
* Printing of reports already formatted and filled with figures and statistics modules / functions, etc.

Interfacing and direct steering:
* Automates functional tests
* Automates testing techniques (performance)
* Defects (if not integrated)

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

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é)

En avant-première : nouvelles versions de Quality Center et Quicktest Pro en V 10.00 !

J’ai assisté aux présentations des nouvelles versions de Quality Center (QC) et Quicktest Pro (QTP) dans leur version 10.00. Ceci chez HP à Issy les Moulineaux par un matin pluvieux. Et ainsi, dans le TGV qui me ramène, je tape cet article pour partager avec vous les informations données par HP dans leur sous-sol…
Le programme des réjouissances fut :
–    Nouveautés QC 10.00
–    Nouveautés BPT 10.00
–    Nouveautés QTP 10.00
–    Mode de pricing (politique concernant les licences – sujet non traité ici)
–    Démos

(Est-ce que le fait d’utiliser les chiffres 10.00 nous prévient qu’il y aura de nombreux patch et qu’il faut s’attendre à une version 10.94 ? Seul l’avenir nous le dira).

HP nous a signalé que toutes les informations présentées et exposées sont à prendre sous réserve car pas forcément inclus dans les versions 10.00 en février. Je prends pourtant le pari que si. Cet avertissement de HP n’est surement là qu’à titre juridique.

Je ne traiterai pas dans cet article de Business Process T. (BPT) car pour le moment c’est un produit peu répandu chez les clients français et surtout un désir / vœux de HP d’en vendre des containers entier (premier désir de tout éditeur de logiciel après tout).

Quality Center (QC) 10.00 :
Concernant ce qu’est Quality Center je vous renvoi vers mes articles concernant les outils de référentiels de tests ainsi que ceux sur QC. La date de sortie est prévue au 31 janvier 09 et trois packs seront distribués :

• Edition QC starter : Prévu pour une équipe de 5 personnes mono-projet

• Edition QC Entreprise : Equivalent de QC 9.2 actuel (TD for Quality center)
• Edition Premier : Prévu pour une équipe avec des besoins avancés comme les multi-projet, la haute disponibilité des plateformes supportant QC, etc.

Je détaillerai ici uniquement l’édition Entreprise / Premier de QC car c’est là ou se situe les vrais changements / nouveautés.

Edition QC Entreprise / Premier, les modules présent :

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

La phrase choc d’entrée de la présentation assénée par HP fut « Maitrisez le chaos en versionnant les exigences, les tests et les composants ! ». Plutôt ambitieux et choc, mais voyons voir les nouveautés (regroupé par thème ci-dessous).

Reporting :
Centralisation de ceux-ci au contraire du dashboard actuel (9.2)

• Nouveau module remplaçant le dashboard
• Centralisation du reporting
• Tous les tableaux de bords sont centralisés dans ce module
• Création de vue publique et privé
• Rapport multi-projet possible
• Il faut prendre cette version de reporting comme la V1 de l’ancien module dashboard… Finalisé donc.

Possibilité de définir une stratégie de test plus complète :

• Risques métiers et techniques ==> affecté à une complexité fonctionnelle – calcul des risques

Versionning : ce module n’est pas utile pour un petit projet
Gestion des versions des exigences, des tests (fiches de tests par exemple) et des composants :

• Check-in et check-out
• Comparaison entre les versions
• Possibilité de retour à une version antérieure
• Peut être activé à un projet via la partie administration (nouvelle activité de l’administrateur donc)
• Le versionning est bien entendu à prendre en compte avant les démarrages des projets (fais partie des best practices cher à CMMi et autre ITIL)
• Création des baselines (création d’une photo d’un ensemble d’éléments projet), pour marquer / identifier les étapes importantes du projet. Exemple : des exigences validées en V1 : création d’une baseline. Cela permet aussi de figer une configuration de tests par l’association à une campagne de tests.
• Garantit d’exécuter  la bonne version vis-à-vis d’une campagne de tests
• Comparaison de baseline possible ==> identifier les éléments qui ont changés

QC requirement management :

• Se veux comme un concurrent direct des outils comme Doors, Req Pro et autres Caliber
• HP cite un rapport 2008 émis par le Forrester et signalant que le nouveau module de gestion des exigences de HP est le premier devant tout les autres. Hum… je pense un peu prématuré ce genre de conclusion sachant la version ne sort qu’en février et que des résultats probants ne pourront être obtenus qu’après quelques mois d’intense utilisation chez des vrais clients. A surveiller donc.

Autres : les template :

• Il est désormais (enfin ?) possible de définir un projet template et surtout de l’utiliser et le partager entre de nombreux projet. LE fait majeur étant la possibilité de mettre à jour le template et de diffuser la mise à jour sur l’intégralité des projets le mettant en œuvre. Il faut savoir que sur la version 9.2 actuelle cela n’est possible que via des développements internes propres à chaque client.
• Possibilité de configuration et de maintenance centralisées des template
• Diffusion « automatiques » des mises à jour
• Maintenance des template par les administrateurs
• A signaler que cette fonctionnalité aussi rejoint les concepts de best-practices prônés par CMMi et ITIL

Fonctional testing :

• Sortie le 31 janvier
• Winrunner n’est plus inclus dans ce pack

Contenu dans le « pack » Fonctional testing :

• Gestion des ressources QTP :
• Versionning
• Outils de comparaison

Quicktest Pro 10.00 (QTP) :

• Meilleur reporting
• Monitoring système local : ce module permet lors du RUN des scripts de surveiller l’exécution et certains points. Concrètement on pourra déceler à quel moment et suite à quelle action du script un problème survient. Par exemple un pic de charge d’un CPU généré par une action d’un script QTP. Cela devrai permettre de renforcer les liens et interactions entre les équipes de tests et ceux en charge des tests de performance. Il faut signaler que cette fonction a été implémentée par de nombreux clients à l’aide de développements internes. Ils apprécieront.
• Amélioration diverses de l’IHM :
• Outils de gestion des tâches (TODO)
• Aides aux scripting
• Export au format DOC et PDF du reporting
• Possibilité de joindre des captures d’écrans
• Accès direct à la ligne de script QTP depuis le reporting
• Possibilité de comparer deux versions de scripts facilement

Mon impression finale est que QTP se transforme en AGL (Atelier de Génie Logiciel) mais orienté tests. Je veux dire par là que HP a intégré de nombreuses fonctions permettant de mieux scripter et d’aider plus complètement les développeurs de scripts QTP. Je trouve cela bénéfique pour tous les scripteurs. Ne tirons pas de conclusion hâtives et attendons les premiers retours d’expériences autres que ceux de HP. Enfin, la synergie, les liens entre QTP et QC semblent renforcés également.

Quid des migrations ?
Pour pouvoir migrer vos versions vers la 10.00 il vous faut avoir déjà les versions 9.0 (patch 26) et 9.2 de QC (patch 12). Impossible de migrer avec des versions plus vieilles que celles-ci.
Un outil d’upgrade sera disponible sur le site support de HP pour vous aider dans les migrations. Mais attention si cela se déroule comme les précédentes fois il vous faudra passer obligatoirement par des experts testing pour vous aider dans la manœuvre car l’outil de migration de HP ne fait pas de miracle et demande l’intervention d’humains.
Une dernière chose sur la migration, si vous passez à QC 10.00 il vous faut obligatoirement passez à la version 10.00 de QTP.

Winrunner :
Recueillons-nous sur la dépouille exsangue de cet automate qui fut un des précurseurs dans notre métier. Il a, ma foi, bien mérité sa retraite. RIP Winrunner et merci pour tout.

• Il n’est plus distribué avec le pack fonctional testing
• Fin 2009 : fin des développements et patch
• Fin 2011 : fin de l’automate

Goodies and petits fours :
Et les goodies offert par HP pour nous récompenser de notre temps et notre attention ? Et bien nous avons eu droit à un stylo en plastique rose, quelques feuilles vierges à l’entête de HP et… à un livre en anglais sur les tests !
Son nom est « Optimize Quality for Business Outcomes – a practical approach to software testing» et ceci dans sa troisième édition. C’est la première fois que j’entends parler de ce livre traitant des tests. Ci-dessous je liste les chapitres principaux :
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-fonctional testing?
7.    Application security testing: the next frontier
8.    Test sourcing: how outsourcing improves cost effective testing
9.    Successful goal-driven KPI approach
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

Je tente de lire ce livre rapidement et je vous en ferai une « critique ».

Et alors ?
Au final, la stratégie de HP est de jouer des coudes dans l’édition logiciels pour agrandir son périmètre fonctionnel et ainsi son chiffre d’affaire. Ce qui est une démarche saine et pouvant apporter aux utilisateurs finaux un meilleur service et aux sociétés de services / conseils un élargissement de leurs prestations (avec un apport de valeur ajouté plus important qu’à ce jour).
Cependant, en « jouant des coudes » HP piétine allégrement les orteils de nombreux concurrents. Ainsi les éditeurs avec des outils gérant les exigences ou les gestions de configurations / versions verront immanquablement leurs parts de marché grignotées inexorablement par HP. Aussi inexorable que la désertification en Afrique ? Pas si sur que cela, car, pour prendre l’exemple des éditeurs de solutions de gestion des exigences, leurs produits dédiés seront forcément plus complet que celui de HP. Reste à savoir plus complètement les choix fais par HP en la matière et les mettre en œuvre pour les tester dans la vrai vie !

Best practices and test repository

Say Uncle, you can give me some best practices pleaaaaaaaaaaase?
The first good practices are:
– Good sense
– Organization,
– Reflections.

Nothing but magic, properly implemented, will guarantee the proper use of a benchmark test. I will expose them as a question to ask the good moments:
Management requirements or requirements:
– Uniqueness?
o This is the only item on this test?

– Clarity?
o Reflect on the tree to establish,
o The need is expressed clearly enough and is there no gray area or ambiguities on the understanding?
o What are the requirements implicit and not listed in the expression of needs (for example), but we must still consider?
– Accuracy?
o The requirement is it enough to be measurable and quantifiable targets via specific test?
– Validity?
o The document led to the requirement is updated and validated by the customer?
– Testability?
o Is it possible to create one or more relevant cases to effectively test all aspects of this requirement?

Managing the card catalog test or the Test Plan:
Fundamental:
– Each sheet test should be linked to one or more requirements or you can say goodbye to the test coverage
– Once the test sheet drafted a trick is to check if all the cards are connected at least once a requirement, otherwise you have holes in your racket!
– Depending on the strategy, the Test Plan should be prioritized according to the functional, organizational or business customer
– The tree test plan must:
o Be easy to understand by functional
o In order of business process / application client (use numerical codes to manage the directory eg
o be determined at the outset between all actors
o 4 to 5 levels MAXIMUM directories otherwise you watch the madness
– Provide care tabs « Details » and « Design steps:
o Enter a clear description of the common people for the purpose of the test card
– Provide care to the tab Design steps:
o Be sufficiently precise and detailed to avoid any ambiguity and interpretation at runtime
o Display data to be used and their origins
o = A STEP ONE ACTION
o Inform the expected outcome (RA) so precise and clear because the result will be compared to the result (RO) during execution
—

Good questions:
– Uniqueness?
o A target = sheet test
– Clarity?
o The stages of the procedure are clearly identified, no-til no gray area or ambiguities on the way forward?
– Data?
o All representative data needed for testing are they identified?
o Have data that are:
consistent
Clarifies
Representative
Prepared
– Coverage?
o The modus operandi of the sheet test is relevant and complete the objective identified?
– Generic?
o No test sheet valued unless a value is hard in the test

Design and execution of test campaigns or Test Lab
– Cash?
o Environment to conduct any tests available?
o The application to test it is installed with the correct version (versioning policy of the client)?
o The access (login / passwords) to applications and other servers valid?
– Preparation?
o The test cards are up to date or she date a year ago?
o Automated test scripts are identified and in the right directories?
– Clarity?
o The names of campaigns and test sheets are quite explicit for your next tier include?
– Data?
o At’on all the data needed to run the cards?
– Coverage?
o The entire campaign covers happens objective identified?

Good practices during the execution of the test sheets:
– Have environments, platforms and networks available
– Availability of the coffee machine effective
– During the execution of steps:
o Follow the procedure in the « description » on LETTER!
o The tests outside the marked paths are BANNED!
o Compare the result (RO) with the field Expected Result (or expected outcome (RA)).
o

Management of anomalies or Defects:
Fundamental:
– Have a workflow defined anomalies that is known, validated, shared and clear. This is for all players
– If yes, do all the players are aware of their roles and responsibilities?
– If the execution proceeds failure:
o Verify that the specified outcome is correct
o Enter the result as clearly as possible
o Check that the anomaly is reproducible integrator or ridicule you and not take into account the anomaly
o Open an anomaly
o Describe the anomaly as clear as possible otherwise your work will not help and you will lose a lot of time in explanation
o ALWAYS associated with a sheet test

– Reproducibility?
o The anomaly is it reproducible under the same conditions?
– Compliance?
o The abnormality has been detected by following the procedure laid down in the sheet test?
o expected results included in the file are updated?
– Uniqueness?
o The anomaly detected is not already open?
To do this, ask your colleagues and your manager is a good start
Use filters and search fields
o Is not there already opened a ticket on a subject almost identical?
Clarity?
– Gravity?
o What is the level of severity of the anomaly?
Critical
Major
Minor

A final practice for the road? Make a copy and paste the above practices in an Excel file, the file named « Checklist guaranteeing the quality of the test repository ». You do not have:
– Go to request and ask a bonus to your manager ;-)
– And submit your client to be finally a real example of industrialization of testing tools

And for the record, know that putting into practice every day these recommendations will make the implementation of this tool CMMI level 3 (see article on CMMI3 and QC).

Bonnes pratiques des référentiels de test

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
• Un STEP = UNE SEULE ACTION
• 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 !

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