Fausses idées sur le test logiciel

Si vous lisez cet article, vous êtes sûrement testeur de logiciel ou souhaitez le devenir. Félicitations … et désolé pour vous. Pourquoi devrais-je être désolé pour vous? Parce que cela est loin d’être le métier le plus facile et vous avez probablement besoin de défendre vos positions et idées presque tous les jours. Mais si vous êtes passionné par votre travail, alors je suis sûr que c’est un plaisir pour vous de discuter de ce sujet, et d’argumenter avec des gens ayant un point de vue différent et expliquer pourquoi vous pouvez vous féliciter d’avoir fait le bon choix avec cette activité.

Alors, quelles sont les idées fausses sur le test logiciel que vous pourriez avoir à discuter?

Les testeurs cassent le produit

“Je ne casse pas le logiciel. Il était déjà cassé quand je l’ai eu.” — Michael Bolton

J’adore cette phrase de M. Bolton. Un testeur ne casse pas le produit, il essaye simplement de dissiper l’illusion que tout fonctionne comme un charme. Votre ami développeur sera toujours là pour vous dire que “ça marche” et je suis sûr qu’à chaque fois que vous entendez ça, vous avez ce sentiment étrange que quelque chose doit clocher quelque part. C’est normal, vous êtes un testeur avec cet état d’esprit spécifique qui vous pousse à explorer les choses, à vérifiez les connus connus, à évaluer l’inconnu connu, et à essayer de découvrir l’inconnu inconnu … Si vous cassez quelque chose pendant le test, vous devrez rassembler toutes les informations possibles (journaux, capture d’écran, les étapes pour reproduire les environnements impliqués, etc.) parce que votre travail n’est pas de casser le produit (les utilisateurs vont le faire pour vous), mais de donner des informations aux parties prenantes quant à l’état du produit.

Vous êtes un testeur parce que pas assez technique pour être un développeur

J’ai commencé ma carrière dans l’informatique en tant que développeur. C’était l’époque où l’IDE était vi ou emacs, où vous deviez exécuter un make dans un terminal et attendre la fin de la compilation pour savoir si ce que vous aviez fait était correct ou non. Croyez-moi, ce n’était pas facile sans un vrai IDE comme aujourd’hui. Donc, si j’avais fait le choix de continuer en tant que développeur, après 15 ans, je suppose que je ne devrais pas être si mauvais que ça. Être un testeur est la plupart du temps un choix et c’est mon cas, car c’est une activité qui sait être passionnante. Seuls ceux qui ne comprennent pas le métier de testeur pensent que c’est ennuyeux, et vont répandre la fausse rumeur que vous n’avez pas besoin de beaucoup de connaissances techniques pour être bon dans ce domaine. Premièrement, si vous avez l’intention de développer des contrôles (checks) automatisés, bien sûr vous aurez besoin d’être un développeur brillant parce que c’est loin d’être aisé. Deuxièmement, vous devez comprendre le système en cours de test, trouver les bons journaux (logs), être en mesure d’utiliser des outils pour ralentir le réseau ou de simuler un comportement que vous ne pouvez pas faire en cliquant simplement dans un navigateur. Vous pouvez être un spécialiste des tests d’intrusion (pentest), un testeur sécurité, un testeur d’API, etc. Un testeur de logiciel n’est pas un développeur raté qui veut seulement cliquer sur des boutons et croiser les doigts en attendant de tomber sur un bug.

Quelque chose ne fonctionne pas en production, c’est la faute du testeur

Comment? J’ai entendu plusieurs fois “ça fonctionne parfaitement, bravo aux développeurs”, mais aussi “Il y a un problème en production, pourquoi les testeurs on laissé passer?”. Donc, les éloges sont pour les développeurs (et le management) quand tout est ok, et les reproches pour les testeurs quand quelque chose ne va pas? Non, j’espère que cela n’est plus le cas, mais ce fut le cas dans des entreprises avec la culture du blâme.

“Les tests ne sont pas responsables des bugs insérés dans le logiciel, pas plus que le soleil est responsable de la création de la poussière dans l’air.” — Dorothy Graham

Vous ne pouvez pas tout tester, ceci est tout simplement impossible, et même si vous le faites à 100%, le lendemain quelque chose aura changé (une mise à jour, une nouvelle configuration, un nouvel environnement, etc.), puis quelque chose que vous ne pouviez pas tester la veille est maintenant disponible.

“Une infinité de test ne peut pas prouver que le logiciel est bon, un seul test peut prouver qu’il n’est pas bon.” — Amir Ghahrai

La plupart des testeurs font partie du département Assurance Qualité (AQ/QA). Ce nom (QA) est une sorte de non-sens. Car il faut l’avouer, les testeurs ne peuvent pas garantir la qualité. Les testeurs ne prennent pas la décision de ne pas résoudre un problème et de le laisser dans la version finale, ceci est la responsabilité du responsable produit (PO). Les testeurs ne peuvent pas corriger les bugs, ceci est le travail des développeurs. Donc, en tant que testeur, comment pourriez-vous assurer la qualité si vous ne pouvez pas améliorer le produit? Notre travail consiste à donner de l’information, également de communiquer ce qui n’a pas été testé à qui de droit, et notamment ce qui potentiellement comporte un risque.

À propos du nom QA et de son mauvais usage, je vous conseille de regarder cette vidéo de @friendlytester

Tester permet de trouver tous les bugs

“Les tests logiciel sont utilisés pour montrer la présence de bugs, mais jamais pour prouver leur absence” — Edsger Dijkstra

Je trouve cette réponse parfaite à cette fausse idée. Tout comme il est impossible de tout tester, vous ne trouverez jamais tous les bugs. Imaginez que vous testez une application Android et renseignez-vous sur la fragmentation Android. Il suffit de lire ce rapport annuel de OpenSignal où 682.000 appareils sont répertoriés. Même si vous décidez de ne supporter qu’un seul d’entre eux, disons un Galaxy S6 Samsung, il n’existe pas une seule version de Samsung Galaxy S6, mais plusieurs en fonction de la version Android et des mises à jour appliquées ou pas, aussi selon le revendeur qui vous l’a fourni, vous pouvez même avoir une surcouche logiciel de l’opérateur (comme orange). Alors, même si vous décidez de ne supporter qu’un seul modèle avec une ROM bien précise, l’environnement de test sera différent selon ce que vous faites avec les nombreuses options de configuration disponibles. Cela donnera probablement une infinité de possibilités. Surtout avec les smartphones, j’ai été plusieurs fois confronté à un bug reproductible sur un seul appareil (celui du client) et non pas sur un autre (celui qu’on a en test).

Le test peut être automatisé

“C’est de l’automatisation, pas de l’automagie” — Jim Hazen

Il y a beaucoup d’articles différenciant la vérification (check) du test, celui-ci et cet autre de James Marcus Bach et Michael Bolton sont toujours une bonne référence, même si beaucoup décrié ces derniers temps notamment sur twitter, et parce que la personnalité des leaders historiques du CDT (Context-Driven Testing) n’est pas toujours facile à supporter. L’avantage de l’utilisation de ces 2 termes, donc la validation (pour ce qui est fait par une machine automatisée, ou par un non-expert suivant une suite d’étapes et sans essayer de trouver autre chose que ce qui est décrit dans les cas de test) et le test (pour toutes les activités qu’un véritable testeur humain peut faire) est de faciliter la communication de ces deux types d’activités bien distinctes et complémentaires.
Tester est une activité plus complexe et cognitive que la simple vérification. Vous rappelez-vous un moment où vous avez trouvé un problème tout en testant autre chose? Cela arrive presque tout le temps, j’aime la sérendipité du test. Vous rappelez-vous un moment où vous avez vu un petit problème du coin de l’oeil? Certains éléments clignotant sur l’écran, une partie de l’interface disparaissant pour une raison inconnue …Ce sont des choses qu’un contrôle exécuté par un ordinateur va probablement manquer (à moins de spécifiquement vérifier cette partie), mais pas votre cerveau.

Le principal problème ici est que certains ont tendance à penser que tout peut et doit être automatisé. En fait, nous ne devrions automatiser que les tests les plus ennuyeux, ceux qui sont répétés des dizaines, centaines ou plus de fois avec juste une petite variation (et à chaque release), ceux qui peuvent être utilisés avec beaucoup de données en entrée… Tout n’a pas besoin et ne doit pas être automatisé. Il ne faut pas oublier que chaque test a un coût de développement, d’exécution et surtout de maintenance.

Tout le monde peut tester

Tout le monde peut coder, tout le monde peut cuisiner, tout le monde chanter, mais qui le fait vraiment bien ? Comme toute autre compétence, tester requiert de l’expérience, de la pratique, de la formation. Pour être un vrai bon testeur, vous devez avoir un état d’esprit spécifique. Vous travaillez probablement très proche de développeurs, et probablement loin des vrais utilisateurs, mais vous avez besoin de déterminer quel est le meilleur comportement du produit et de le défendre, vous devez argumenter en permanence votre position pour le bien des futurs utilisateurs que vous ne connaissez pas encore et rester calme lorsqu’un problème est classifié “se comportant comme prévu” parce que le code dicte le comportement.

“Un test pas trop mauvais est facile à faire (ce qui en partie explique pourquoi certaines personnes aiment à dire que le «test est mort» — ils pensent que les tests ne nécessitent pas d’attention particulière, car ils constatent que tout le monde peut trouver au moins quelques bugs de temps en temps). Par contre, exceller dans le test est assez difficile à atteindre.” — James Bach

Montrer du doigt les faiblesses et les problèmes à une équipe qui a mis tout son temps et son expertise dans le produit peut ne pas être très bien accueilli dans un premier temps. Rester toutefois confiant à ce moment précis peut épargner votre entreprise, vos collègues et futurs utilisateurs de beaucoup de tracas futurs.

De plus, vous allez être celui qui va remonter les problèmes alors que toute l’équipe est déjà en train de célébrer la fin de la toute nouvelle belle fonctionnalité prête à être sortie. Vous pourriez être détesté pour cela et vous aurez à enseigner aux gens comment faire face à cela et rester confiant dans votre travail à chaque fois.

Pour résumer, n’importe qui ne peut pas être un bon testeur.

Le test est effectué à la fin

Si vous avez lu ci-dessus, vous savez maintenant que tester ne signifie pas juste cliquer comme un singe dans une interface afin de trouver un maximum de bugs, ce n’est pas non plus simplement vérifier à la fin. Vous pouvez tester à tout moment, et vous pouvez tester à peu près tout. Vous pouvez tester les exigences, les user stories, vous pouvez tester avant que la toute première ligne de code ne soit écrite. Vous pouvez par exemple préparer votre future session de test avec tous les documents disponibles. Vous ne ne testez pas qu’une interface utilisateur, mais lorsqu’ils sont disponibles, vous pouvez tester une API, ou le serveur avec des commandes curl. En tant que testeur, j’aime aussi lire les revues de code. Même si je n’ai pas beaucoup de commentaires intéressants à faire (en particulier avec ces langages javascripts étranges), cela m’aide à comprendre ce qui sera à tester et parfois je peux détecter quelque chose d’inconsistant sans avoir à attendre le produit prêt à être délivré.

“Plus un problème est découvert tôt, moins il en coûtera pour le réparer” — Moi

Les tests peuvent être estimés

Vous ne savez jamais à l’avance ce que vous allez découvrir. Cela peut sembler un aveu de faiblesse, mais je n’ai jamais été en mesure d’estimer avec précision une phase de test. Vous pouvez donner une estimation précise du test que si vous savez tout ce que vous avez à tester. Mais pour avoir une bonne compréhension de ce qui est à tester, alors vous avez besoin de tester, explorer et apprendre de nouvelles choses menant à de nouveaux tests et peut-être à un changement de portée.

“Le test est un processus infini consistant à comparer l’invisible à l’ambigu afin d’éviter que l’impensable n’arrive à l’inconnu.” — James Bach

Merci pour la lecture, n’hésitez pas à ajouter un commentaire ci-dessous.