Say uncle… What these famous criteria are for stop the tests?

5 02 2009

It is a question often addressed in training for testing, sometimes asked by customers and never discussed by the teams of testers in the projects! Strange isn’t it?
Shutdown criteria tests are certainly not to be confused with the question « Did we tested enough? Because this is another issue concerning the coverage of tests and their completeness (among others).

Establishing criteria for tests to stop ISTQB
« Criterion release: all generic and specific conditions agreed with the managers, in order to complete a formal process. The objective of an exit test is to prevent a task is considered completed when there are still parts of this task were not completed. The exit criteria are used in the test to make reports and to schedule the shutdown of the test. [After Gilb and Graham] ».

While this definition is unclear, and that’s why I try to list the criteria the most common:
Shutdown criteria common to all types of tests:

  • All scenarios were performed (performance, functional, etc.).
  • All records, files and test cases were performed successfully
  • All critical defects have been resolved and Non-Regressions Testing (NRT) place
  • Your client to sign the minutes of revenue, the record presented and you have to keep your business
  • After 252 deliveries integrator is unable to correct and the customer decides to stop the project
  • The platforms, environments, networks, etc. are no longer available
  • Attainment of the maximum rate anomaly discovered during the (definition and achievement of a previously defined threshold). This type of test is often implemented at customers with a high level of maturity of the testing activities or imposing contractual constraints very strong.

This can also be divided by functional area. Example:

  • Stop if tests detect more than 50 major anomalies
  • Exhaustion of the resources of tests:
  • End Budget
  • Human Resources Department
  • End of time / load
  • True physical exhaustion of resources
  • The SNA receivability / testability / Pre-conditions are blocked or in NOK
  • Criteria specific to certain types of test:
  • Techniques:
  • All connectors and « jobs » (this means: jobs, jobstreams and batchs) plans have been initiated and run

Readers, if you know of another I suggest you contact us to make suggestions to the community of testers. Thank you.

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

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.

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!

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 !

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 »

Bonnes pratiques des référentiels de test

15 10 2008

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

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

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

Unicité ?

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

Clarté ?

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

Précision ?

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

Validité ?

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

– Testabilité ?

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

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

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

L’arborescence du plan de test doit :

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

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

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

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

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

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

o Avoir des données qui soient :

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

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

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

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

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

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

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

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

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