Top 8 de ce que vous ne savez pas sur la QA

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).

‍

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.

‍

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.

‍

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.

‍

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).

‍