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 : nouvelle version de Quality Center en ALM 11 !

23 03 2011

Credo d’HP cette année « Instant-on » : un terme pour tenter d’exprimer « Agilité + Web 2.0 + plateforme unique »

(Ceci est une synthèse très rapide de la nouvelle version Quality Center vers Application Lifecycle Manager  11 (ALM 11). Prochainement je mettrai en ligne l’article complet)


  • Avis général :

o   L’ergonomie et la navigation ne change presque pas

o   Similitudes étonnantes  à noter par  rapport à la plateforme Jazz d’IBM / Rational

o   Planification des tests via un module « façon Outlook »

  • Requirement :

o   Ouverture direct dans ALM des fichiers Word contenant des uses cases pour utilisation dans l’onglet requirement

o   Création des requirements via des templates, import de business modèle

  • Plus grande intégration et communication entre tous les acteurs des projets :

o   Gestionnaire de tâches « tasktop » :  Exemple :  un développeur peux consulter les anomalies de QC directement depuis son framework Eclipse

o   Focus important sur les projets Agile et la technologie Ajax

  • Tests « manuels » plus facile :

o   Arrivée de la « fonction » nommée HP Sprinter (à noter que le terme est directement extrait des projets en mode agile !)

o   Il s’agit d’un mélange de macro et de fonctions (définition non éclairci côté HP) intégré dans un navigateur et permettant d’aider les tests manuels :

§  Permet d’enregistrer très rapidement et facilement des scénarios de test

§  Enregistre également les jeux de données

§  Exécutions des tests par Sprinter

§  Remontées des anomalies via le navigateur

  • Performance Center :

o   Prise en compte effective d’Ajax – Ajax compliant

o   Lancement des tests via l’IDE du client (par le plugin intégré au butineur)

o   Interface et ergonomie sexy pour la création des scénarios de tirs

o   La tendance est à moins de codage pour plus de facilité – Adieu les « mains dans le cambouis » ou presque…

  • Le futur selon les trois utilisateurs témoignant :

o   « Il faut se concentrer sur l’intelligence des activités de tests : la stratégie, les ROI, la gestion des exigences, l’industrialisation, les jeux de données »

o   « Assurer un bon compromis entre agilité et industrialisation »

Peu ou pas d’informations sur le modeling…

A bientôt dans le futur du testing !





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.




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





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