Posted by jc-Qualitystreet on 8 avril 2010
Les tests exploratoires se définissent comme l’apprentissage, la conception et l’exécution simultanée des tests. Pour faire simple, moins ces activités sont séparées, plus le niveau d’exploration est jugé élevé : on parle alors de tests exploratoires.
Dans l’univers des tests logiciels, les tests exploratoires se distinguent donc clairement des techniques scénarisées (« scripted tests »), fondés sur des cas de test (valeurs d’entrée / script d’exécution / résultats attendus). Sur les projets IT, ils sont un complément très utile à ces tests « classiquement » scénarisés, notamment niveau interface, pour plus de feedback et peuvent les remplacer efficacement en cas de flou ou d’instabilité dans les exigences.
Aller plus loin… Vers un test exploratoire centré ergonomie
L’approche des tests exploratoires est plutôt récente et en pleine expansion, d’autant qu’elle colle plutôt bien aux nouvelles exigences de tests apparues avec les méthodes Agiles.
Interactive et créative, la démarche est en effet centrée avant tout sur le résultat plutôt que sur la conception, documentation et l’archivage de cas de tests (valeur et principes agiles). Elle se concentre aussi sur le métier de Testeur, ses compétences, son savoir-faire, bref sa valeur ajoutée.
Et l’évaluation cognitive experte dans tout cela, une technique reconnue depuis longtemps en ergonomie des logiciels ? Des tests exploratoires qui intègrent ce volet ergonomie apportent une richesse supplémentaire dans cette quête perpétuelle de la QUALITE et du BON PRODUIT et dans la recherche des défauts. C’est aussi un + pour le testeur dans sa connaissance du produit et des attentes des utilisateurs.
Les bénéfices sont évidents mais nécessitent de la part du testeur une montée en compétences sur sa connaissance des processus cognitifs humains ainsi que sur les principaux critères ergonomiques de conception.
Tester le système du point de vue de l’utilisateur : une raison d’opter pour le test exploratoire
Tests scénarisés vs Tests exploratoires : une question de moment et de STRATEGIE DE TEST. Toutefois, il est clair que s’engager régulièrement, par exemple à chaque sprint (contexte Agile) dans une session de test exploratoire, dans la peau des futurs utilisateurs, est aujourd’hui indispensable.
Concrètement, la technique va consister à simuler les processus utilisateurs en jeu avec le système, et à s’arrêter à chaque étape du processus pour vérifier que l’utilisateur peut enchaîner. Le testeur se met donc à la place de l’utilisateur, accomplit chaque tâche comme celui-ci le ferait, en s’arrêtant et en s’interrogeant à chaque écran :
- les utilisateurs comprendront-ils quoi faire?
- les utilisateurs comprendront-ils comment le faire?
- les utilisateurs comprendront-ils les feedback?
Il va se fonder sur sa connaissance des facteurs humains et des processus cognitifs…
- Attention
- Perception et reconnaissance de l’information et des actions
- Mémorisation
- Apprentissage
- Communication
- Résolution de problème
- Décision
… et sur des questions types à se poser, comme par exemple :
- L’action correcte à engager sera-t-elle évidente pour l’utilisateur ?
- L’utilisateur va -t-il remarquer que l’action correcte est disponible ?
- L’utilisateur va-il interpréter la réponse à l’action correctement ?
Une approche toujours structurée mais deux Prérequis pour déterminer l’oracle de test
Une session de test exploratoire obéit à des règles qui la cadrent. Elle est délimitée dans le temps, commence toujours par une charte de session et se termine toujours par un mini rapport de test rassemblant la liste des défauts et des problèmes identifiés ainsi que les principales notes produites.
Les tests exploratoires centrés sur l’ergonomie ont quant à eux deux pré-requis. Outre de très bonnes connaissances en ergonomie, une vision claire et complète des futurs utilisateurs du produit est également nécessaire avant de se lancer dans le test.
C’est là que les PERSONAS interviennent car pour se mettre dans la peau de ses utilisateurs, il faut bien les connaitre : leurs buts, les déclencheurs de leurs actions, leurs influences, leurs freins ou les bonnes surprises !
Posted by jc-Qualitystreet on 6 octobre 2009
Première étape de mon parcours au travers d’un référentiel Agile CMMI, et premier billet d’une longue série qui s’adresse en priorité à mes lecteurs AGILISTES, aux praticiens CMMI et à ceux qui s’intéressent de prés ou de loin à l’amélioration des processus.
Ma posture est celle d’un coach agile qui accompagne une organisation cherchant à atteindre, pour diverses raisons, le niveau de maturité 3 CMMI, mais souhaitant garder un mode de fonctionnement agile fondé sur des pratiques SCRUM et XP.
Voici donc REQM, “Gestion des exigences“, l’un des 7 domaines du Niveau de maturité 2, dont l’intention est de « gérer les exigences des produits et composants de produits du projet et d’identifier les incohérences entre ces exigences et les produits d’activité du projet ».
La gestion des exigences (REQM) est avec RD (Développement des exigences) la base de ce qu’on appelle l’Ingénierie des exigences, des activités ô combien cruciales dans les projets informatiques. Les exigences sont fonctionnelles (« ce que les système doit faire ») ou non fonctionnelles (attributs de qualités, par exemple fondés sur l’ISO 9126).
Au programme, REQM dans une perspective Agile CMMI :
- Quels sont les objectifs spécifiques à satisfaire OBLIGATOIREMENT?
- Quelles sont les pratiques spécifiques initialement recommandées, et comment l’agilité se marrie-t-elle avec celles-ci?
- Quels sont les objectifs génériques à satisfaire OBLIGATOIREMENT ( Niveau 2 & 3), et comment se positionne l’agilité sur les pratiques génériques initialement recommandées?
1 OBJECTIF(S)SPECIFIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI
REQM SG1 : Gérer les exigences
OK AGILE CMMI
Un seul objectif à satisfaire mais il est de taille. Les exigences sont gérées, et les incohérences avec les plans du projet et les produits développés sont identifiées. C’est l’objectif à atteindre, et l’agilité le permet largement.
2 PRATIQUES(S)SPECIFIQUES DE REFERENCE RECOMMANDEE POUR CMMI
Il s’agit des pratiques recommandées dans le modèle théorique. Non imposées, elles servent souvent de guide pour ceux qui démarrent leur projet d’amélioration des processus mais peuvent être remplacées par des pratiques alternatives, contextualisées à l’entreprise, pourvu qu’elle permettent d’atteindre l’objectif fixé. L’idée pour nous est de prouver qu’avec un process Agile, vous gérez les exigences !
REQM-SP1.1 Développer une compréhension commune des exigences et de leur signification avec ceux qui les ont fournies.
OK AGILE CMMI
L’agilité se retrouve bien dans cette pratique qu’elle pourrait faire sienne. Les ateliers de travail, les face à face, pour construire de manière collaborative une Vision PARTAGEE, et un Backlog de produit, ESTIME et PRIORISE vont dans ce sens. La réunion de lancement en fait partie. Les critères d’acceptation portant sur chaque User Story (élément du Backlog) prolongent cet effort de compréhension commune et concourent à l’atteinte de l’objectif.
Qui : Product Owner, Equipe
Quoi : Vision, Backlog de produit, Réunion de lancement, Réunion d’estimation, Réunion de planification, User Stories
REQM-SP1.2 Obtenir des participants au projet leur engagement sur les exigences.
OK AGILE CMMI
Engagement et responsabilisation : voilà des points forts des méthodes Agiles. La réunion de planification (à chaque début de sprint) est un moment où l’équipe s’engage collectivement sur la réalisation, durant le sprint, d’une partie du Backlog de produit (et user stories). Chaque jour, les membres de l’équipe s’engagent sur la réalisation d’une tâche pour construire les user stories : c’est le Daily Scrum.
Qui : Equipe, ScrumMaster
Quoi : Réunion de planification (CR PPT ou Wiki), Daily Scrum
REQM-SP1.3 Gérer les modifications aux exigences au fur et à mesure de leur évolution en cours de projet.
OK AGILE CMMI
Maintien et contrôle des exigences : c’est aussi l’objectif du Backlog de produit, qui vit et évolue au fur et à mesure de l’avancée du projet. Il est actualisé à la fin de chaque Sprint (suite à la réunion de fin de sprint).. Historiser les versions du Backlog est très pertinent dans un contexte CMMI.
Le changement dans les exigences peut se traduire aussi au niveau des user stories (éléments du Backlogde produit). Mettre à jour, faire vivre, la partie « Conversation » de l’User Stories est déjà une pratique en place chez beaucoup d’équipes.
Le burndown chart montre concrètement au quotidien ce qui est réalisé, et les changement éventuels survenus.
Au final, ce qui compte ici, c’est UN BACKLOG DE PRODUIT ET DES USER STORIES à JOUR.
Qui : Product Owner, Equipe
Quoi : Backlog de produit, User stories, Burndown Chart, Réunion de fin de sprint (CR PPT ou Wiki)
REQM-SP1.4 Maintenir une traçabilité bidirectionnelle entre les exigences et les produits d’activité.
OK AGILE CMMI
On s’en fait une montagne, et pourtant …il suffit d’envisager la fonction développée et présentée en DEMO comme la barquette de viande vendue au supermarché. Le cas échéant, on doit pouvoir remonter toute la chaine, et mesurer les enjeux collatéraux. Pour les végétariens, vous vez aussi la métaphore du Petit Poucet J Le quatuor (Backlog de produit - User Stories - Tâches - Produit Développé) assure un système de suivi des exigences souple et performant, se concrétisant dans la démo de fin de sprint. CMMI attend une matrice de traçabilité des exigences. Les feuilles de calcul et les outils du marché gérant les Backlog de produit permettent d’atteindre cet objectif.
Qui : Product Owner - Equipe
Quoi : Backlog de produit, Démo, Réunion de fin de sprint (CR PPT ou Wiki)
REQM-SP1.5 Identifier les incohérences entre les plans du projet et les produits d’activité d’une part et les exigences d’autre part.
OK AGILE CMMI
Cette pratique est un vrai point fort de l’Agilité. Elle s’effectue de manière continue, dans la collaboration, durant tout le sprint avec comme clé de voute les critères d’acceptation définis pour chaque User story mais aussi grâce aux daily scrum. La démo de fin de sprint est un RDV formel permettant de déterminer ce qui a été fait ou pas, ce qui est bien fait de ce qui ne l’est pas. Ce RDV qui donne lieu potentiellement à des actions correctives et à l’actualisation du Backlog de produit. FEEDBACK ET ADAPTATION.
Qui : Product Owner - Equipe - ScrumMaster
Quoi : Backlog de produit, User Stories, Daily Scrum, Démo, Réunion de fin de sprint (CR PPT ou Wiki)
3 OBJECTIF(S) GENERIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI, et PRATIQUES ASSOCIEES
REQM GG1 : Réaliser les objectifs spécifiques
OK AGILE CMMI
En somme pour REQM, les exigences doivent être gérées (renvoie à REQM SG1 : Gérer les exigences)
REQM GG2 : Institutionnaliser le processus en tant que processus discipliné
OK AGILE CMMI
Là cela devient intéressant… Cet objectif n’est pas le plus simple à atteindre ; il est pourtant nécessaire dans les contextes CMMI et Agile CMMI. Il ne nécessite pas forcement une adaptation des pratiques Agiles, mais plutôt un élargissement de celle-ci à l’entreprise : « J’ai réussi un projet agile, et je souhaiterais capitaliser et faire en sorte que mes autres projets en bénéficient ». Des expériences que je capitaliserais à nouveau pour les améliorer.
Je vous parle donc de PROCESS AGILE, Capitalisation et amélioration continue. Je vous parle donc d’ENTREPRISE AGILE… C’est dans l’ère du temps non ?
REQM-GP2.1 Établir et maintenir une directive organisationnelle traitant du processus Gestion des exigences…
OK AGILE CMMI
C’est un élément incontournable de mon Process Agile. Je m’appuie généralement sur le sponsor pour travailler cette directive qui vient d’en haut. Le plus souvent, elle reste générique (les méthodes agiles) mais on peut aborder brièvement, c’est mieux, la gestion « agile » des exigences (développement et gestion). C’est en quelque sorte officialiser le process Agile dans l’entreprise.
Qui : Coach Agile, Sponsor, Direction, Equipes
REQM-GP2.2 Planifier le processus Gestion des exigences…
OK AGILE CMMI
Une adaptation des pratiques agiles est nécessaire puisqu’on doit introduire pour chaque projet un plan de projet ou charte projet qui décrira dans les grandes lignes le Qui, Quoi, Quand, Ou du projet. Je conseille aux équipes de le faire en Sprint 0 et demande au ScrumMaster de s’en charger. C’est un petit doc, commun à beaucoup de domaines de process CMMI (exigences, risques, qualité …). C’est court, PPT, Word ou Wiki.
Qui : ScrumMaster.
REQM-GP2.3 Fournir les ressources adéquates pour le processus Gestion des exigences…
OK AGILE CMMI
Preuve doit être donnée que les ressources adéquates (humaines, outils …) ont été fournies. Dans notre cas, cela passe entre autres par le choix de l’outil de Backlog, et par la désignation d’un Product Owner (disponible). Cette pratique m’est très utile car elles la question des moyens est souvent un facteur d’échec des projets agiles. Avec cette pratique, on gagne en maturité. Cette activité fait partie intégrante du rôle du ScrumMaster, en Sprint 0. Donc pas de problème.
Qui : ScrumMaster.
REQM-GP2.4 Assigner la responsabilité et l’autorité pour mettre en œuvre le processus Gestion des exigences…
OK AGILE CMMI
C’est une composante du Process Agile, à inclure dans le Plan de projet. Qui fait quoi ? Cela revient à décrire brièvement le rôle de Product Owner …
Qui : ScrumMaster.
REQM-GP2.5 Former les personnes qui mettent en œuvre ou soutiennent le processus Gestion des exigences…
OK AGILE CMMI
Cela fait partie de mon travail de coach Agile. Dans ce cas précis, cela passe par la mise en place de formations et ateliers dédiés au Product Owner, aux testeurs, à l’équipe.
Qui : Coach Agile.
REQM-GP2.6 Placer les produits d’activité identifiés du processus Gestion des exigences au niveau de contrôle approprié…
OK AGILE CMMI
Comme sur tous les projets informatiques … Il s’agit du niveau de configuration d’éléments comme le Backlog de produit ou les User Stories. Les CR de réunions de planification ou de sprint rentrent aussi dans cette catégorie.
Qui : Product Owner, ScrumMaster.
REQM-GP2.7 Identifier et impliquer les parties prenantes concernées par le processus Gestion des exigences…
OK AGILE CMMI
Un petit tableau dans le Plan de projet fait en Sprint 0 est tout à fait pertinent. Le Product Owner est l’acteur principal sur laquestion mais, l’équipe (en particuliers les testeurs) est fortement partie-prenante. Business analysts, Ergonomes, Utilisateurs… sont aussi concernés.
Qui : ScrumMaster.
REQM-GP2.8 Suivre et contrôler le processus Gestion des exigences …
OK AGILE CMMI
Cette pratique consiste à suivre l’avancement des activités de gestion des exigences sur la base d’indicateurs. La fin du sprint est un jalon essentiel avec la collecte de données : sur les user stories (Done / Ready), le burndown chart, les changement sur les stories…. Cela fait partie « par défaut » des attributions du ScrumMaster.
Qui : ScrumMaster
REQM-GP2.9 Évaluer objectivement le respect du processus Gestion des exigences…
OK AGILE CMMI
Relié aussi au GP2.2. C’est du QA. Le ScrumMaster est le garant de la bonne application du Process Agile sur le projet. Cela fait partie « par défaut » de ses attributions. Maintenant attention, le Process Agile est adaptatif…
Qui : ScrumMaster.
REQM-GP2.10 Revoir l’état du processus Gestion des exigences avec la hiérarchie et résoudre les problèmes…
OK AGILE CMMI
C’est à la fois donner de la visibilité et remonter des problèmes potentiels à la hiérarchie. C’est justement le rôle du ScrumMaster (le « Chien de berger ») qui doit aussi protéger l’équipe et faire remonter, les obstacles éventuels soulevés par l’équipe (par exemple en Daily Scrum). Il peut s’appuyer sur des éléments du radiateur d’informations, burndown chart et fiches de Sprint pour donner de la visibilité à sa hiérarchie sur cette question des exigences.
Qui : ScrumMaster, Product Owner, Hiérarchie
REQM GG3 : Institutionnaliser le processus en tant que processus ajusté
OK AGILE CMMI
Comme précédemment, pas facile mais nécessaire (pour la maturité 3). On est plus que jamais dans du Process Agile…on est dans du standard mais dans une perspective qui me plaît bien, c’est à dire adaptative et non figée, fondée sur l’amélioration continue.
REQM-GP3.1 Établir et maintenir un processus Gestion des exigences ajusté
OK AGILE CMMI
Une description du processus Agile « standard » de l’entreprise doit être disponible .Elle servira de référence, mais sera ajustée à chaque projet (cela doit être prouvé). On est en plein dans de l’AGILITE en CONTEXTE.
Définir le Process Agile standard, de manière collaborative et participative (jamais seul !)cela fait partie de mon travail.
L’adaptation au projet : c’est le boulot du ScrumMaster avec l’équipe et le Product Owner.
Qui : Coach Agile, les ScrumMaster, les Product Owner, les Equipes
REQM-GP3.2 Collecter l’information d’amélioration du processus Gestion des exigences
OK AGILE CMMI
Le projet doit se servir de retour d’expérience à la fois pour le Process Standard et pour les autres. C’est très agile, c’est très adaptatif (niveau organisation), et c’est la base de l’amélioration continue. Les agilistes doivent se féliciter de cette pratique.
Qui : Agile, les ScrumMaster, les Product Owner, les Equipes
Une autre référence sur la sujet : Flex”i”MMI
Posted by jc-QualityStreet on 11 mars 2009
On dit toujours que l’agilité met l’accent sur la qualité. C’est vrai :
- des pratiques telles que l’intégration continue, les tests unitaires, les tests de recette, le pair programming mais aussi une volonté évidente d’automatisation jouent indéniablement sur la qualité du produit logiciel…
- le client sur site et de courtes itérations, pour plus de collaboration et de feedback permettent de s’assurer que le “bon produit” est développé…
- Avec l’ajout d’un regard Lean et d’une approche ergonomique, le compte est souvent bon…
ET POURTANT dans les faits, stratégie de test et testeurs ont du mal à se retrouver dans les projets Agiles, comme si toute une approche qualité était occultée, menée de manière anarchique, sans ligne directrice…
ça doit changer; ça va changer !
VERS UNE NOUVELLE VISION DES TESTS DANS LES PROJETS AGILES… trois éléments déterminants
Intégrer les testeurs dans l’équipe Agile et enrichir leur rôle (à la fois plus proches et au service de l’équipe mais aussi en soutien fort du Product Owner, du Métier). Cette alerte Agile (Où sont les testeurs) allait dans ce sens, et les résultats sont le plus souvent probants.
Donner un nouvel élan à la stratégie de test dans une dynamique agile. La stratégie de test se doit d’abord d’être envisagée dans une dimension high level en Sprint 0 pour l’ensemble de la version (une version, c’est entre 3 et 6 mois). Ensuite, le challenge du testeur est de l’ajuster en contexte à chaque début de sprint, en fonction du contenu du sprint à venir et de ce qui a été qualifié de Done au sprint précédent. A ce niveau, on va à l’essentiel : la stratégie de test, niveau sprint a la particularité d’être à la fois synthétique et trés précise !
S’appuyer sur le génialissime modéle de Brian Marick (signataire de l’Agile Manifesto et Star de la qualité logiciel) pour formaliser cette stratégie de tests. A chaque sprint, piocher son type de tests dans tel ou tel quadrant. Un modèle, trés visuel, instantanément compréhensible et trés parlant non seulement par le spécialiste QA qui sommeille en vous, mais aussi par toute personne impliquée dans un projet informatique.
4 quadrants qui à eux seuls guideront l’ensemble de votre stratégie:
- Tests orientés Technologie en soutien de l’équipe (ex : Tests unitaires et approche TDD , le plus automatisé possible)
- Tests orientés Business en soutien de l’équipe (ex: les tests sur storyboard, les tests fonctionnels pour vérifier les critères d’acceptation du Product Owner: l’approche de conception centrée utilisateurs et l’ergonome y trouvent leu compte)
- Tests orientés Business pour critiquer le produit (c’est avant tout du manuel, à tout moment ou en End Game pour le systéme complet en test d’acceptation. L’approche ergonomique ressort encore : quand on vous dit qu’il faut faire des Tests Utilisateurs !)
- Tests orientés Technologie pour critiquer le produit (des tests essentiels qui se doivent d’être outillés et qui peuvent nécessiter la présence de spécialistes, perf / sécurité; souvent en End Game hormis simulations)
- gile Testing Quadrants Brian MArick
Posted by jc-QualityStreet on 16 février 2008
Le principe de base est qu’un environnement propre et bien rangé contribue à la réalisation d’un travail efficace et de qualité.
Bon, à 35 ans c’est parfois difficile de changer ses habitudes, mais avec un peu d’autodiscipline et de rigueur, croyez-moi on y arrive… et puis, tout ce qui peut éviter de me faire perdre du temps est le bienvenu…
La pratique des 5 S (Seiri, Seiton, Seiso, Seiketsu, Shitsuke) est une méthode d’organisation japonaise précisément du Toyota Production System (TPS), initié par Taiichi Ohno (DG de Toyota); TPS dont Mary et Tom Poppendieck, se sont inspirés dans le cadre du développement logiciel avec leur “Lean Software Development“, que j’ai déjà évoqué dans d’autres billets.
LES 5S:
Seiri (Débarrasser)
Débarrasser son espace de travail de l’inutile, garder l’essentiel : une première étape incontournable. C’est la fin des bureaux encombrés, des armoires pleines, des disques durs engorgés. Pour cela, il suffit de se fier à la fréquence d’utilisation !
Seiton (Mettre en ordre)
Organiser son espace de travail de façon efficace. Une place pour chaque chose et chaque chose à sa place ! Quand on cherche quelque chose, on le trouve vite ! C’est vital pour ses propres dossiers, ça l’est aussi sur un projet ou pour la GESTION des connaissances de l’entreprise.
Seiso (Nettoyer)
Un travail propre se réalise avec des outils propres. Il s’agit donc de nettoyer son poste de travail le plus régulièrement possible.
Seiketsu (Standardiser)
Maintenir l’ordre et la propreté; cela passe par des règles (de rangement, d’indexation notamment) claires, évidentes … et connues de tous si on se place une nouvelle fois au niveau d’un projet ou de l’entreprise.
Shitsuke (Encourager les efforts)
Maintenir ces principes jours après jours, années après années… et même essayer de les améliorer. C’est souvent le plus difficile, et la dessus que j’ai toujours “dérapé” … jusqu’à maintenant !!
Tout cela paraît facile, et ça l’est, alors allons-y. Et pour se motiver davantage, rappelons que ces 5S sont les fondamentaux, le point de départ, vers les autres principes du Toyota Production System et du Lean software Development, des principes qui ont prouvé leur efficience. On pourrait citer par exemple:
- Réduire les stocks (ou plutôt les tâches non réalisées ou en cours de réalisation, les bugs …)
- Éliminer les sources de gaspillage (c’est à dire toutes les activités qui n’apportent pas de valeur au client … anomalies, situations d’attente, fonctionnalités inutiles)
- Favoriser l’apprentissage et adopter une démarche d’amélioration continue…
- Livrer vite mais à un niveau de qualité élevé (cycle de développement courts favorisant le feedback)
- …
D’ailleurs en parlant de Lean, je vous engage tous, à faire sur vos derniers projets, juste pour voir, une petite cartographie des flux de valeurs (la fameuse “Value stream map“) mais là, c’est une autre histoire !
