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 !

Publicités




Best practices and test repository

22 10 2008

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





Survival Manual on Quality Center for testers!

22 10 2008

In the world of test, everybody talks about Quality Center (QC for his nickname) from HP Mercury. Everyone talks about the client to the service, from engineers who swear by this fabulous QC … What wonderful world that ours in which all players share the same project, share and use same benchmark test and ensure that business requirements are at the heart of everyone … But … The reality is less glamorous!
Indeed, among the thousands of engineers only a few really know QC and use it properly.

So I write this article in aim to present the basic tool and make some good practices to implement when using a testing repository (I will not write on the administration part of this tool).

Say Uncle, what is a testing repository ?
Or « How from minimum to maximum effort? « . For the answer see the article on the subject.

Say Uncle, there is what in QC?
Before explaining what is inside it clear that it is just a tool shared management of activities test, that his name was former Test Director (or TD).
The interface of QC is relatively « user friendly » (adapted from users) and practice.

In this tool there are 5 tabs (or parts). Each of these tabs is an important part for each test project. But see more detail each of them:
– Management of requirements
– Management of the test catalog or Test Plan
– Design campaigns to test or Test Lab
– Management of “anomalies” (French term) or Defects
– Management releases (not explained in this article because I want to preserve the suspense)

With tabs for each common features include:
– Reports & Graphics
– Review
– The ability to attach screenshots, documents, etc..
– Printing
– Administration

The logic of use is as follows, first on developing the test strategy and matrix of coverage (tabs requirements and Test Plan). Then we plan executions (Test Plan and Test Lab), when executions are created sheets anomalies through which we validate the corrections.
Finally, it updates the tests and repeats the cycle of tests.

Dives us in QC:
Management requirements:
It is to identify the test requirements (based on business requirements and other specifications), to structure the test plan and specify future test sheets.
Small reminder: requirements may be the expression of needs or the list of features to be tested. Thus, all test requirements define the scope to cover. These requirements are also common among the records of specification and testing to be performed.
Take into account to ensure traceability between the design and execution. Finally, the requirements are support for impact studies of the evolution of specifications on the plans and test sheets.

This tab can also see all the details of requirements and see the status of the results sheets covering a test or its requirements.

Finally, it can be entered manually requirements is to use a macro to use on import documents to Word or Excel. Either in the form of addin or internal development or customer service company.

Managing the test catalog or the Test Plan:
It is designed to test sheets, define scenarios and prepare the reporting (in collaboration with the Lab Test). It is also to create the tree test sheets and sheets and create links between requirements and test sheets.
The Test Plan represents all the test sheets, being built or operational.

Design and execution of campaigns or Test Lab test:
It is the creation and planning campaigns to test. The performance takes place on this tab, whether automated or manual.
Remember that:
– A test campaign is a combination of scenarios (composed of sheets of test)
– A test may be part of several campaigns
– Following the implementation of the various shock, a form of test is considered PASSED status, if and only if all stages composing on the same status
– If at least one of these steps is in FAILED status or not completed sheet will test the same status

Management of anomalies or Defects:
After implementation scenarios / sheets test is to describe the anomalies and reporting information campaign.

Read the article following called « Best practices and test repository »





Manuel de survie sur Quality Center !

15 10 2008

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

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

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

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

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

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

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

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

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

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

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

La suite de l’article concerne les bonnes pratiques