7 principes Qualité Agile ?

Être réactif et à l’écoute

Description

Généralement, lorsque l’on contribue à la construction d’un service numérique, on pense la qualité autour de critères fonctionnels et non fonctionnels au sens de l’ISO-25010, et de temps en temps, en terme de qualité à l’usage au sens de l’ISO 25019.

Ces deux approches sont très importantes, néanmoins la qualité d’un service numérique est autant liée à une qualité « objective » qu’à une qualité perçue par les utilisateurs.

Et la qualité perçue par les utilisateurs dépend énormément de leurs sensation d’écoute et de prise en compte de leurs retours.

En cela un produit de qualité est aussi un produit qui évolue en écoutant et prenant en compte les retours de ses utilisateurs.

Conséquences

Comme écrit plus haut, la qualité perçue n’est pas directement liée à la qualité « objective ». Il est possible d’avoir un produit « moyen » mais qui évolue avec les retours utilisateurs qui sera plus apprécié qu’un produit « super » mais où les utilisateurs sont (ou se sentent) ignorés.

C’est d’ailleurs le principe de l’Agile et du MVP. On propose un produit qui apporte de la valeur aussi tôt que possible puis on le fait évoluer et grandir en fonction des différents retours.

Ces feedbacks utilisateurs sont particulièrement importants pour plusieurs raisons:

  • ils aident à prioriser en identifiant ce qui a le plus de valeur

Ce qui est essentiel car il est préférable de livrer une fonctionnalité de qualité moyenne d’un besoin important qu’une fonctionnalité avec la meilleure qualité du monde mais qui n’apporte pas de valeur aux utilisateurs.

  • ils permettent d’identifier des manques ou des bugs

C’est un élément qui est ressorti lorsque j’ai commencé à travailler sur l’atelier « les indicateurs dont vous êtes le héros« . Les indicateurs de satisfaction permettent d’identifier des problématiques très complexes à mesurer autrement.

  • ils permettent d’ajuster son travail et le processus qualité

La qualité dépend du contexte. Ce que l’on peut tester également. Ces retours utilisateurs aident à mettre en lumière ce qui fonctionne et ce qui fonctionne moins. Identifier ces éléments permet d’ajuster ses processus pour être aussi efficient que possible. De même ce qui fonctionne parfaitement un jour et sembler immuable peut devenir beaucoup moins efficace avec le temps et devoir évoluer… Car, comme le dit le premier principe de cette série: tout évolue.

Principes du test liés

Les principes du test liés à ce principes sont:

  • Les tests dépendent du contexte. Et il est toujours important de bien percevoir le contexte qui dépend fortement de l’utilisation du service.
  • Les tests exhaustifs sont impossible. On ne pourra pas tout tester pour rendre une qualité objective « parfaite ». Il faut faire des choix en fonction des priorités. Ces priorités dépendent en (grande) partie des utilisateurs.

Exemples

Je ne vais pas être original et vais prendre l’exemple de XRay. La qualité de cet ALM est, sur le papier (et encore plus au début), bien inférieur aux principaux ALM du marché. Néanmoins il a connu un très grand succès. La première est qu’il répondait à une demande: unifier l’outil de suivi des développement avec celui des tests. La seconde c’est qu’il a su s’améliorer et évoluer en fonction des retours utilisateurs.

Si l’on perçoit une légère baisse actuelle de sa popularité elle est principalement à chercher côté JIRA qui est moins hégémonique qu’il y a quelques temps. Car sans JIRA il n’y a pas de XRay.

Ce qu’il faut retenir

Lorsque vous travaillez sur un service numérique pensez à être à l’écoute de vos utilisateurs (ou potentiels utilisateurs). Faîtes évoluer le produit en fonction de besoins exprimés, adaptez vos processus qualité pour couvrir ces besoins et pensez à corriger aussi vite que possible les bugs remontés par des utilisateurs. Pour un utilisateur, voir ces remontées de bugs pris en compte et corrigés est un signe de grande qualité et le fidélise! De plus cela l’encourage à remonter d’autres problèmes ce qui aide grandement à améliorer la qualité gloable mais aussi la qualité perçue!

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

processus

La phase de Retest

Le cycle de vie d’un bug  comporte plusieurs étapes décrites ci-dessous : Dans ce cycle, une étape est malheureusement souvent négligée : La phase de Retest (ou de vérification). A quoi correspond exactement cette phase ? La phase de retest d’un bug a plusieurs buts : ·        Vérifier que le bug est bien corrigé : un

Lire la suite »
Les petits trucs de testeur
Campagnes

Petits trucs de testeur: faire évoluer ses tests

Introduction Lorsque l’on travaille sur un logiciel (que j’appellerai produit) qui est ancien ou développé depuis un petit moment on a généralement une campagne de régression conséquente. Cette campagne, dont un nombre significatif de tests sont souvent automatisés, se retrouve souvent complexe avec de nombreux tests. Ces tests sont maintenus

Lire la suite »
conférence

Test Bash Home : une réussite internationale

Vous connaissez surement le Ministry of testing, qui regroupe la plus large communauté de testeurs à travers le monde. Et chaque année, plusieurs événements tests, appelés Test Bash, ont lieu un peu partout dans le monde. Comme vous le savez, un certain virus a décidé de faire de cette année

Lire la suite »