Un avis ? Un commentaire ?
Cet espace est pour vous.
Le mois dernier, avec Rose Lutz de Alt QA, nous avons parlé d’une déformation professionnelle fréquente chez les QA : le pessimisme.
Nous revenons ce mois-ci avec un nouvel épisode de “Comment les QA voient le monde”, axé sur un autre trait courant : l’empathie !
Rassurez-vous, on ne vous parle pas de devenir un Whisperer comme dans la saison 9 de Walking dead*, mais plutôt de développer cette force des QA qu’on nomme souvent “empathie”.
(*) les Whisperers se camouflent sous une peau de zombie pour passer inaperçus et vivre parmi les vrais zombies.
L’empathie, c’est être capable de voir le monde d’un autre point de vue que le sien. En tant que QA, on fait ça tout le temps, pour aborder le produit testé sous différents angles.
Avant d’aller plus loin, distinguons quand même l’empathie de la sympathie et de la compassion : lorsqu’on est empathique, on comprend les perceptions et sentiments des autres, mais pour autant on garde une certaine distance affective. Aussi, si vous trouvez un bug à la soumission d’un formulaire d’inscription sur Parcours Sup, ce sera normal de ne pas pleurer parce que votre avenir sera foutu !
Quand on parle de l’empathie des QA, on pense avant tout à “se mettre dans la peau des utilisateurs”.
Pourtant, l’empathie est multi-dimensionnelle :
Mettons, par exemple, que l’équipe travaille sur un produit qui s’étoffe peu à peu. Chaque membre comprend parfaitement la logique de ce produit, les spécifications sont bien connues, suffisamment complètes et semblent correspondre en tous points au besoin exprimé.
Eh oui, “semblent”… Car en effet, comment l’affirmer ? Le 7ème principe du test logiciel est l’illusion d’absence de défaut. La seule vérification du logiciel ne suffit pas, car ce qui est spécifié est souvent incomplet vis-à-vis des besoins réels, dont une partie reste tacite. L’empathie permet alors de se poser des questions qui comblent les vides.
“Le formulaire doit être iso-fonctionnel… certes… et en effet, si on compare les fonctionnalités seules, la correspondance entre le nouveau système et l’ancien semble adéquate. Mais proposer un produit “iso-fonctionnel” suffit-il ? Comment travaillent les personnes ?”
On testera différemment en sachant que :
Parfois, on découvre ces informations en fin de projet, ce qui produit une forte résistance au changement. Vous connaissez déjà le shift left, rappelez-vous, le rôle de QA c’est aussi challenger les specs. Alors autant anticiper et se poser la question dès le début : pour qui créons-nous ce logiciel ? À quoi ressemble le quotidien de ces personnes ? Quelles sont leurs pratiques et leurs attentes secrètes ? Pour ne pas découvrir ces informations trop tard, notre rôle de QA c’est aussi de questionner au plus tôt les POs et UI/UX Designers pour connaître ces informations.
Levons donc au plus tôt ce mystère inutile !
Une suggestion pour démarrer : en tant que QA, participez aux ateliers de connaissance de la cible. Si aucun atelier n’est prévu, suggérez l’idée et faites participer vos collègues : la qualité est un travail d’équipe, bien plus vaste que le testing seul.
Deux modèles d’atelier permettant de développer la connaissance de sa cible : la carte d’empathie et les personas. Ces modèles sont proposés en ligne gratuitement par la société Atlas Management.
Mais l’empathie s’applique de manière plus large, par rapport à l’ensemble de notre équipe, notamment les devs : n’oublions pas que notre rôle est de trouver et leur remonter des bugs dans le fruit de leur travail : la diplomatie s’impose ! Même s’il s’agit davantage de la capacité à communiquer, dans les faits réussir à comprendre comment les devs peuvent percevoir les choses aide à avoir une communication plus cordiale (“il y a un bug” vs “tu as mal codé” : merci la CNV !)
D’ailleurs, en tant que QA, nous nous attachons nous aussi au fruit de notre travail, nous connaissons donc bien les émotions que peuvent ressentir les devs quand leur travail fait l’objet de demande de changements, voire de suppression.
Chaque membre de l’équipe mérite une écoute respectueuse de ses émotions, qui n’est qu’un signal (positif ou négatif, anodin ou significatif) de la santé du projet.
Souvent, on pense l’empathie uniquement par rapport à l’affect : qu’est-ce que pourrait ressentir l’utilisateur ? Mais il y a aussi un aspect plus factuel, qui consiste à identifier les comportements de l’autre. On sort du ressenti, on entre dans la motivation.
Ce deuxième aspect est particulièrement utile pour les tests end-to-end. Il ne s’agit pas juste de faire un parcours et vérifier que tout se passe comme demandé. On cherche surtout à incarner une vraie personne pour reproduire ses comportements en partant de son intention initiale : quel objectif vise-t-elle ? Quelle attitude a-t-elle (par exemple users, mis-users, abusers) ? Et on voit si le cheminement est fluide et robuste.
Enfin, dans le cas des tests exploratoires on active les deux – ressenti et motivation – simultanément pour se faire une idée de l’application et trouver des dysfonctionnements de tous ordres : utilisabilité, habitudes, failles, etc.
L’empathie ne se résume donc pas à une simple qualité relationnelle, mais c’est un véritable moteur de performance dans le monde du test logiciel. En se mettant dans la peau des autres – dans notre équipe ou au-delà, parmi la multitude de profils pouvant utiliser notre produit – on réinvente notre façon de concevoir, de tester, de travailler ensemble.
Reste à trouver vos moyens de développer ce super-pouvoir ! Comment procéderiez-vous ?
Cet espace est pour vous.