Les 11 portraits robots du « mauvais Testeur Logiciel »

Tout ce à quoi un bon Testeur de Logiciel  ne doit pas ressembler

Pour comprendre ce que sont les bonnes pratiques du Test Logiciel, rien ne vaut l’argumentaire inversé. Les caractéristiques du « Mauvais Testeur », récoltées auprès des Consultants d’Acial et de notre confrère indien TestHuddle en disent long sur l’attitude que se doit d’avoir un Consultant Test dans un contexte  professionnel, car bien souvent, il s’agit plutôt d’attitude, voire de posture, que de compétences.

Le Robot : il s’arrête net au premier signe d’erreur et remplit son rapport d’anomalie. Ne nous trompons pas : remplir des rapports d’erreur est très important – comment pourrait-on résoudre les bugs sinon ? Mais quelques investigations préalables sur son propre test ou environnement de test feraient toute la différence, et garantiraient la validité des anomalies découvertes.

Le Snob : « je ne sais pas coder, je ne veux pas savoir comment on code, c’est le boulot du développeur ». Il refuse de comprendre les détails techniques du logiciel à tester ou les implications techniques des erreurs qu’il a découvertes. Il se comporte comme un utilisateur avec un regard fonctionnel sur le logiciel, ce qui est bien ; mais il ne fait preuve d’aucune curiosité technique, ni d’un minimum d’empathie pour le développeur, ce qui l’est moins.

La Princesse : elle fait un prérequis indispensable au Test de disposer de toute l’information sur l’application à tester. C’est une bonne pratique, Madame, de chercher à comprendre le contexte fonctionnel et technique de ce que vous avez à tester, mais la terre ne va pas s’arrêter de tourner si vous testez sans que toutes les conditions ne soient parfaitement réunies… Parfois, avec un peu d’imagination et de bonne volonté on peut aussi très simplement commencer à tester sur la base du produit, d’un accès à une base de données, d’un peu de code et des informations fournies par le développeur, ou un utilisateur.

Le Besogneux : il teste, il remplit ses rapports, il trace son activité et son avancement. Bien discipliné. En revanche, il produit peu d’effort pour connaître mieux le produit, le code ou les développeurs. Résultat : un logiciel testé mais rien de plus, aucune capitalisation de la connaissance pour l’équipe.

Le Râleur : « le code est pourri, le plan de test est pourri, je ne peux pas tester cette appli, que quelqu’un d’autre avec des connaissances techniques, métier ou n’importe quoi se débrouille pour tester ça (toutes les 5 minutes) ! »

Le Dictateur : Moi ou rien. Ce sont « ses idées » contre « vos idées » et pas les idées du projet. C’est « sa solution » contre « votre solution ». On peut parier sans risque qu’on se disputera. D’une manière ou d’une autre, il reviendra sans arrêt sur un test que vous avez réalisé. Cet individu est un obstacle majeur à la productivité et sera le premier à céder sous la pression et à accuser les autres. Cet individu est nuisible à l’équipe quelles que soit son expérience ou ses aptitudes au test.

Le Frileux : ce testeur se fige si toutes les exigences ne sont pas gravées dans le marbre, panique si toute la documentation n’est pas disponible, se bloque parce qu’il n’a pas 100% de couverture de test. Ces personnes feraient n’importe quoi pour éviter de sortir de leur zone de confort. Les bons testeurs ont une propension à sortir de leur zone de confort, plus ou moins rapidement, pour partir en exploration.

Le Techos : il se fait fort utiliser les outils et méthodes les plus récents pour tester des logiciels. « Cet outil de quatrième génération, piloté par le comportement, avec autodiagnostic automatique va résoudre tous nos problèmes de qualité ! ». Hélas, il va consacrer beaucoup trop de temps pour préparer l’outil et l’environnement, et le fonctionnement s’avèrera finalement décevant. S’impliquer à fond sur l’outillage se justifie, mais ça ne doit pas détourner de la mission essentielle de l’équipe de Testing : tester l’application et détecter les bugs !

Le Susceptible : se met dans tous ses états parce que son manager  refuse de valider une de ses anomalies ; alors à quoi ça sert que je teste ? Ben oui, mais quelques fois il faut composer avec la qualité ; « si je te dis que c’est pas un bug, et que ça passe tranquille en prod, fais-moi confiance, et ne te braque pas 😉 »

Le Nonchalant : il compose souvent avec la rigueur qui sied si bien à la profession de Testeur Logiciel ; lors des phases d’exécution, il finit souvent le premier, remplissant à la va-vite le rapport de test ; plein de compassion pour le développeur, il trouve des solutions de contournement pour ne pas avoir à déclarer un bug… Parfois il oublie aussi de faire une sauvegarde, une copie d’écran ou n’arrive pas à reproduire les bugs. Dangereux

Le Dogmatique : doté d’une connaissance théorique approfondie de l’Assurance Qualité Logiciel dont il applique avec beaucoup de rigueur les préceptes. C’est très bien en principe. Sauf que lorsqu’on aurait besoin d’un peu de souplesse, Monsieur se réfugie derrière ses principes, et la rigueur tourne à la psychorigidité…

Vous vous êtes reconnu dans un de ces portraits ?

Surtout ne postulez pas chez Acial, et n’envoyez pas votre CV à recrutement@acial.fr !

Sinon faites-le, nous vous recevrons avec plaisir !

Laisser un commentaire