Top 8 de ce que vous ne savez (probablement) pas sur la QA et les tests

En tant que PO, afin de ne plus avoir de bug, je veux une QA de qualité.

Voilà une story qu’on aimerait bien voir livrée pour améliorer dans notre expérience de product manager/owner. Pourtant, la réalité est que, trop souvent, s’il y a des choses qui ne passent pas en MVP, c’est bien les tests et la QA. Et qu’est ce que je peux comprendre ! Une équipe dédiée à faire l’entonnoir sur nos livraisons avec des tests qui ne font qu’apporter plus de travail à nos développeurs, ce qui casse leur moral sans dire celui du produit… Mais quelle plaie ! Bah, détrompez-vous. La quality assurance ou qualification de logiciels (oui, ça claque plus en anglais) est un élément ultra important, voire indispensable à votre stratégie et votre processus de développement.

Si vous êtes dans une situation où vous devez vous décider entre 0 ou 2 QA, investir dans plus QA, convaincre la personne qui doit prendre ces décisions ou encore que vous remettez en cause l’utilité d’un QA, vous êtes au bon endroit.

Cet article fait partie d’une série qui vous permettra de mieux comprendre cette profession un peu particulière. Alors allons y commençons par les bases.

1. La QA, c'est avant tout un métier

Cela paraît peut-être évident pour certains, mais il faut tout de même le rappeler : la qualification de logiciel est un métier. Il est exercé depuis que les premiers programmes informatiques ont vu le jour. Lorsque les logiciels se sont complexifiés, les tests sont devenus de plus en plus nécessaires. Le métier s’est développé. Il y a aujourd’hui des spécialistes comme pour la sécurité, l’automatisation ou la documentation, mais encore des généralistes ou des managers qui vont gérer des équipes complètes.

Mais alors, c’est quoi un QA ?

La quality assurance est une discipline qui regroupe toutes les méthodes visant à l’évaluer le risque et à prévenir des comportements indésirables lors de l’utilisation d’une application. Autrement dit, le QA va protéger l’utilisateur final des défauts d’un logiciel afin d’en assurer la satisfaction. C’est un acteur dans le produit, et il faut le traiter de la sorte !

2. La QA, ce n'est pas juste tester

Dire d’un QA qu’il est testeur, c’est comme dire qu’un commercial est un vendeur ou un développeur est un codeur. Cette description est peu appréciée parce qu’elle est très réductrice. Pour faire simple, le QA évalue le risque à chaque mise à jour. Cela comprend des tests, mais aussi des lectures de code, de documentation, des analyses, et même (on le verra tout à l’heure) de la conception.

3. La QA doit participer à la conception

Le QA peut donner un sacré coup de main au PO/PM pour maximiser la valeur. Pensez-y : Il passe tout son temps dessus, il connaît tous les dysfonctionnements, toutes les tâches difficiles, tous les scénarios qui cassent le plus facilement. Avant de vous lancer dans une nouvelle fonctionnalité, faites appel à lui. Ce moment est important pour échanger sur l’utilisation de la feature, les cas extrêmes (ou edge-case).

D’ailleurs, un QA expérimenté connaît mieux le logiciel que les autres membres de l’équipe. Donc, PO/PM : fais-toi un ami de ce QA ! 😉

4. Il se peut bien que vous n’investissiez pas assez en qualité

La qualité du logiciel dépendra de l’investissement en qualité. C’est plat, je sais, mais c’est vrai. Mais vu que vous êtes arrivés au point 4 de cet article, je devine qu’il vous a appris quelque chose. Si c’est le cas, il est fort probable que vous n’investissiez pas assez en QA. Si vous avez une dizaine de développeurs pour deux testeurs (qui font certainement le mieux qu’ils peuvent), vous avez de bonnes chances d’avoir encore des problèmes de qualité. Ces problèmes vous coûteront aussi bien en réputation qu’en lead time, donc n’ayez pas peur d’investir.

Comme on l’a vu dans le premier point, il existe un très grand nombre de types de QA. Malheureusement, la majorité des personnes sur le marché pourront écrire et suivre des scénarios simples. Mais il existe aussi des profils bien plus techniques comme des spécialistes en sécurité ou en automatisation.

Ces derniers sont d’ailleurs des profils très convoités et très recherchés. De manière générale, ils coûtent le même prix qu’un développeur senior. Si vous en avez un, assurez-vous qu’il ait tout ce dont il a besoin. Si vous n’en avez pas, soyez prêt à y mettre le prix.

5. Ne pas tester coûte plus cher que tester

La dette technique va réduire votre vélocité et augmenter votre lead time. Certains d’entre vous connaissent le concept. Pour ceux qui ne le connaissent pas, on parle ici de toute la partie du logiciel qui reste sans test et sans documentation. En documentant et en testant régulièrement, vous aurez moins de surprises, moins de temps à dépenser sur la compréhension de l’existant. Donc testez plus et plus souvent !

6. Il ne sera jamais possible de tout tester

Étant donné que ces tests sont à faire régulièrement et le plus humainement possible, il faut à tout prix prioriser les éléments à tester. Pour chaque fonctionnalité que vous livrez, un QA va évaluer le risque et en dégager une stratégie de tests.

Un logiciel n’est jamais testable à 100 %. Même avec la plus grosse équipe de QA, et les automatisations de tests dans tout le logiciel, il existera toujours une partie qui manquerait de tests. Il y a encore un cas qui n’a pas été prévu.

Et Non : même dans une dimension parallèle le temps a été arrêté, et que la QA soit faite d’androïdes de l’imaginaire de Ridley Scott, l’utilisateur trouvera un bug. On ne peut pas tout contrôler, certains cas sont tout simplement trop difficiles ou trop rares pour que l’on puisse l’imaginer.

7. Le QA a une démarche scientifique pour trouver des bugs

Et oui ! Je l’ai dit, et je le dirai encore. Un bug se détecte avec une démarche scientifique. Dire que quelque chose ne marche pas ne veut pas dire qu’on a trouvé un bug.

Si vous n’avez pas fait de cursus scientifique, souvenez-vous la démarche se fait comme-ci : vous avez une hypothèse, vous déterminez ce que va valider votre hypothèse, vous testez l’hypothèse et vous en dégagez les conclusions. Si l’hypothèse est valide, on va plus loin, si l’hypothèse est fausse, on la rejette.

Trouver un bug n’est pas juste de déterminer qu’un incident a eu lieu ou qu’un crash est soudain apparu. En fait, dans la QA, on ne peut parler définitivement d’un bug que lorsqu’on a réussi à déterminer avec certitude pourquoi et comment ce bug se reproduit.

Sur le ticket fourni par le QA pour ce bug, vous y trouverez d’ailleurs 3 éléments indispensables :

  • Les étapes pour reproduire le bug de manière systématique
  • L’attendu à la fin de ces étapes (s’il n’y avait pas de bug)
  • L’observé qui détermine en quoi le comportement est différent et donc un bug

8. Les QA s'attachent à leurs bugs

De la même manière qu’un PO ou un dev s’attache à sa feature, le QA va s’attacher à son bug. Donc quand vous rejetez le bugs ou vous ne l’indiquez pas dans le backlog, c’est pour eux une non-reconnaissance de leur travail. Soyez vigilants, les QA n’ont pas toujours raison et peuvent mal prendre vos arbitrages. N’ayez pas peur, avec un peu de diplomatie, vous leur ferez comprendre votre position. S’ils vous comprennent, ils s’assureront à ce que leurs tests soient plus pertinents pour la stratégie sur le produit.

Bonus (insolite): Les QA ont souvent un sens de l'humour un peu particulier

C’est souvent le cas, oui. Ils rigolent et s’excitent à la vue d’un bug ! Mais c’est quoi ce comportement ? Tout d’abord, ce n’est pas (forcément) un sens de l’humour que nos voisins outre-Rhin vont appeler Schadenfreude (ce qui se traduit par « plaisir dans le malheur des autres »). Un QA a pour but de chercher des défauts. Naturellement, quand il trouve un bug, cela justifie sa recherche. Cette découverte va donc lui faire plaisir (contrairement au développeur).

Un QA va sourire, et même rire alors que nous autres avons plus envie de soupirer ou de pleurer. C’est une réalité, mais prenez en de l’inspiration, un bug trouvé, c’est une solution à chercher et à résoudre ce bug sera encore plus satisfaisant pour le QA que quand il l’a trouvé.

Alors, encore un doute ? Viens nous dire ce que tu penses dans les commentaires ! Comme précisé précédemment, cet article est le premier d’une série sur la qualité et le produit. Dans l’article suivant, nous traiterons des tests et comment procéder pour tester son logiciel et détecter les bugs.

Le Product Management vous passionne ? Vous souhaitez en savoir plus et vous former aux métiers du Product Management ? La Wi-Formation vous propose 3 modules en fonction de vos besoins. Pragmatique et orientée terrain, plus d’informations ici : Formation au Product Management 

Author avatar
Mathieu Stiehl

Commentaires