ALM 11, les processus métiers et les exigences ?

14 04 2011

Les avant-ventes de chez HP nous ont offerts des démonstrations sous forme de jeux de rôles. Voici le résumé de celui concernant le « Processus métier et gestion des exigences » ou « Les exigences pour tous » (langage testeurs) ou « Fais péter tes requirements » (langage développeur).

Le module exigence semble (j’utilise toujours le mot « semble » tant que je ne l’ai pas vu en live) plus important et développé.

L’idée étant de créer un vrai processus en standardisant la définition des exigences. Ceci via des templates, l’intégration d’outils de Business Process Modeling, la création des exigences automatique depuis le BPM et assurer la traçabilité du tout.

Aucuns détails sur les outils de Business Process Modeling mais les commerciaux de Smartesting (société de niche sur le sujet) étaient en coulisse. Peut-être aurons-nous des informations plus tard.

L’intégration et le partage, un des points majeurs de cette « nouvelle » plateforme ALM 11 est démontré par l’implication des testeurs, des développeurs et autres utilisateurs.

Choses importantes la mise en avant de l’importance des processus métiers, des exigences, leur traçabilité, leurs standardisation et la gestion des changements.

Bref, du bel ouvrage qui aidera à démocratiser la gestion des exigences dans les DSI.

Fonctionnalités étendues sur les points suivants :

  • Standardisation de la définition des exigences avec l’éditeur de texte riche et des templates
  • Intégration avec les outils de Business Process Modeling
  • Création des exigences automatiquement depuis le BPM
  • Matrice de traçabilité Processus métier mis à disposition d’une population plus large
  • Communication partagée sur le processus métier
  • Amélioration de la couverture des exigences
  • Standardisation des exigences
  • Gestion des changements– Traçabilité des exigences avec BP, exigences, tests et anomalies

Liens vers les autres articles sur ALM 11 :



Publicités




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 !





Outils de gestion des exigences

27 10 2008

Produits

Société

Détails

Analyst Pro Goda Software Outils pour la spécification des exigences.
Doors Telelogic Telelogic DOORS ® est une base éprouvée pour déterminer et prioriser les besoins des clients, assurer la conformité aux exigences et le maintien de la conformité réglementaire. Le résultat final: produits, systèmes ou logiciels sont livrés à la satisfaction du client, générer une valeur accrue pour l’entreprise.
Caliber Borland L’interface intuitive et de puissantes capacités d’aide à la décision de CaliberRM peux aider les équipes sur les principales étapes du projet. CaliberRM permet également de répondre aux besoins des ‘utilisateurs finaux en permettant à tous les intervenants du projet: équipes marketing, analystes, développeurs, testeurs, et les gestionnaires de collaborer et de communiquer la voix du client dans l’ensemble du cycle de livraison logiciel.
Gatherspace Gatherspace.com C’est un outil de gestion des exigences en mode hébergé (en mode ASP).
Requisite Composer IBM ® Rational Requisite Composer ® est un outil pour aider à définir des exigences en collaboration avec les fonctionnels / métiers
Requisite Pro IBM IBM ® Rational Requisite Pro ® est une solution pour gérer  des exigences pour les équipes projet.




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
  • Un STEP = UNE SEULE ACTION
  • Renseigner le résultat attendu (RA) de manière précise et clair car le résultat sera comparé au résultat obtenu (RO) lors de l’exécution

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

o Avoir des données qui soient :

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

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

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

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

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

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

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

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

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