Stratégie de test, Qualité et Agilité: la Vision qui change tout

Posté par jc-QualityStreet le 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:

1. Tests orientés Technologie en soutien de l’équipe (ex : Tests unitaires et approche TDD , le plus automatisé possible)
2. 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)
3. 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 !)
4. 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)

Alerte Agile N°5: où sont les testeurs ?

Posté par jc-QualityStreet le 8 septembre 2008

… pas dans l’Equipe, et c’est bien dommage !

WAIT! There is more to read… read on »

Toute une démarche ergonomique dans CMMI : c’est possible ?

Posté par jc-QualityStreet le 10 avril 2008

Oui mais y-a du boulot car CMMI (Capability Maturity Model Integrated) n’offre pas à l’ergonomie un domaine réservé !
Voici néanmoins quelques pistes dans ce billet sur Ergonomic Garden : “CMMI, Ergonomie: quelle collaboration possible ?” et dans les commentaires associés.

Une 1ère étape pour des bénéfices mutuels…

Un référentiel CMMI évidemment ajusté, léger et dynamique (Esprit Agile et Lean Thinking prennent ici tout leur sens) peut donc s’enrichir et bénéficier ici ou là, des techniques, outils et méthodes de l’ergonomie informatique pour atteindre des objectifs spécifiques bien définis. Outre une meilleure qualité de vos produits, plus d’efficacité, la démarche ergonomique éliminera pas mal de zones de flou et rationalisera vos choix d’interface !

Dans le même temps, la mise ne place de ces bonnes pratiques d’ergonomie, dans un cadre CMMI, va les institutionnaliser et permettre à une organisation de gagner en maturité en terme de Conception Centrée Utilisateurs, et devenir réellement USER FOCUSED.

Vers un TRIO GAGNANT: CMMI, Méthodes Agiles, Ergonomie…

Mais associer ergonomie et CMMI n’est qu’une étape dans des cycles d’amélioration continue. Le vrai challenge, et les GAINS LES PLUS NOTABLES n’interviendront qu’au travers:

• du respect des principes fondateurs de l’agilité (courtes itérations, développement incrémental, timeboxing, focus sur la qualité et feedback clients …)
• d’une approche lean thinking
• de la mise en place des pratiques agiles, ingénierie et gestion de projet, les plus adaptées aux contextes et qui ont fait leurs preuves en termes de qualité, efficacité, réduction des risques, adaptabilité et réactivité, vélocité et visibilité des projets.

Alors, au boulot !

5 S … Dorénavant … C’est promis !

Posté par jc-QualityStreet le 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 !

ISO 9126, SQuaRE : Qualité, Utilisabilité … et une aubaine pour l’Ergonome

Posté par jc-QualityStreet le 7 novembre 2007

L’ISO 9126 « Software Product Quality » (2001) et l’ISO SQuaRE « Software Product Quality Requirement and Evaluation » (2005) (fusion de 9126 et 14598, son volet évaluation) font partie de ces normes qu’il est bon de connaître quand on travaille dans le développement de logiciels ou plus largement dans la conception de services interactifs.
MàJ du 08/11/2007 : Pour une définition plus précise de l’ergonomie et de l’utilisabilité, jetez-un oeil à ce billet ”Ergonomie = Utilité + Utilisabilit锑

L’essentiel pour moi, Ergonome

• La mise en avant de l’Utilisabilité (facilité d’utilisation) : c’est l’une des 6 caractéristiques du modèle de qualité
• La présence de l’Attractivité en plus de sous caractéristiques plus classiques : c’est la reconnaissance de l’esthétisme, de l’affect, du “beau” au niveau de l’interface… élément qui fait régulièrement débat
• L’introduction (forme révisée) du concept de “Quality in use” avec 4 caractéristiques : Efficacité, Efficience, Sûreté, Satisfaction… mon “Ergonomie en 3 mots” pourrait pourquoi pas, se transformer en une “ergonomie en 4 mots”
• La mise en oeuvre des mesures

En bref
ISO 9126 et ISO SQuaRE fournissent un modèle, fait de caractéristiques et sous-caractéristiques, permettant de lier les qualités externes d’un logiciel à ses qualités internes, et introduisent fort justement (même si on a tendance à l’oublier) le concept de “Quality in use” (« the user’view of the quality of the software product when it is used in a specific environment and a specific context of use ») : une vraie porte ouverte vers les Tests Utilisateurs et l’observation en contexte.

6 caractéristiques de qualité (avec un focus sur l’Utilisabilité)

1. Capacité fonctionnelle
2. Fiabilité
3. UTILISABILITE (en anglais, “usability” qu’on peut traduire aussi par “facilité d’utilisation”, c’est à dire un “Ensemble d’attributs portant sur l’effort nécessaire pour l’utilisation et sur l’évaluation individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs”) : Facilité de compréhension, Facilité d’apprentissage, Opérabilité, Attractivité, Conformité aux standards d’ergonomie
4. Rendement
5. Maintenabilité
6. Portabilité

Pourquoi ça m’intéresse ? Qu’est ce que ces normes m’apportent ?

• La qualité des produits est mon leitmotiv, ce vers quoi je tends…
• Ces normes sont à elles seules le symbole de la convergence de plusieurs disciplines de l’ingénierie
• C’est la reconnaissance de ma propre discipline, l’Ergonomie, de mon rôle et de mon expertise (en particulier sur les questions relatives à la facilité d’utilisation), cela peut légitimer mon intervention
• C’est un point d’entrée idéal pour l’ingénierie des exigences (du recueil à la gestion des exigences en passant par l’analyse du besoin): j’utilise ces caractéristiques pour qualifier les exigences fonctionnelles et non fonctionnelles recueillies
• Cela facilite ma collaboration avec les services QA (Quality Assurance) et sur un projet avec un Responsable de test
• Il existe un lien fort avec des domaines de processus CMMI, niveau 2 et 3, je pense notamment à RD “Développement des exigences”, REQM “Gestion des exigences”, VER “Vérification”, VAL “Validation”, TS “Solution technique”, MA “Mesure et Analyse” …