Quality Center et ALM 11 ?

14 04 2011

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 :

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.





Comment mettre en oeuvre des tests unitaires ?

18 05 2009

Définition :

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

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

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

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

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

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

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

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

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

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

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

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

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

Exemples d’autres types de tests unitaires :

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


Outillages des tests unitaires :

Outils d’intégration continue :

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

Les Framework de tests :

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

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

Les trois concepts de bases de Junit sont :

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

Les outils d’analyse de couverture des tests :

· Cobertura. Il peut produire :

o Le nombre de classes par paquetage

o Le pourcentage de lignes testées

o Le pourcentage d’expressions testées

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

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

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!

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!





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

5 02 2009

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

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




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

23 01 2009

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 !