Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Éliminer la négativité des tests négatifs

Par Jessica Lavoie

5 septembre 2019

4  min lire

Les idées fausses conduisent souvent les testeurs à avoir la mauvaise réputation de «casser» le logiciel. Les développeurs et les parties prenantes peuvent appeler cela des tests négatifs, mais le résultat est un meilleur produit, et tout est positif.

Les testeurs sont les premiers utilisateurs du nouveau logiciel, et ils sont essentiels pour le rendre utilisable. En fin de compte, tout le monde a le même objectif de fournir le meilleur produit possible, donc laisser les testeurs explorer et découvrir de nouveaux bogues est toujours une bonne chose - plus il y a de bogues trouvés, mieux c'est! Encourager les tests exploratoires au début du cycle de vie du développement logiciel déplace les activités de recherche de bogues plus tôt, lorsqu'elles sont plus faciles et moins coûteuses à corriger.

Bien sûr, la plupart des bogues que je trouve ne sont pas liés aux exigences fonctionnelles. Les problèmes de performances sont un exemple courant. Dans la plupart des cas, les exigences ne disent pas combien de temps quelque chose devrait prendre, mais il est facile pour un testeur de dire quand quelque chose ne va pas. Si je m'impatiente d'attendre notre logiciel, nos clients le seront aussi. Et ne préférez-vous pas entendre cela de moi quand nous pouvons encore le réparer, plutôt que plus tard de nos clients?

Que testons-nous exactement?

Il est 8 h 30 et notre chef de produit entre dans notre bureau et demande: «Où est le chef de projet?»

«Il vient de sortir», déclare le développeur principal. "Comment pouvons-nous vous aider?"

"Quel est le statut de la user story pour la migration de la base de données de MySQL vers MariaDB?"

«Nous sommes en retard car certains éléments clés des tables primaires MySQL ne sont pas faciles à migrer vers MariaDB», répond le développeur principal.

Le ton de la voix du chef de produit devient immédiatement plus net. «Combien de retard? Des jours, des semaines? »

Notre développeur principal répond honnêtement: "Au moins quatre jours de plus."

Il y a du silence dans la pièce. Enfin, le chef de produit dit: «Pouvez-vous dire au chef de projet de venir à mon bureau? J'ai besoin de lui parler. Il se retourne et part.

Il est clair que le chef de produit n'est pas satisfait de la progression de notre user story, et tous les développeurs et testeurs se sentent désormais stressés.

Lors de notre réunion de planification plus tard dans la journée, l'équipe considère tous les chemins possibles: le chemin heureux, le chemin malheureux et les cas de coin et de bord. Ensuite, je suis assis dans ma cabine pour tester la user story, et même si la plupart des tâches sont toujours en cours, je décide de faire des tests négatifs. Poussé par la curiosité, je commence à naviguer vers des zones non liées aux modifications de la base de données, et je trouve un défaut critique.

À ce stade, le chef de projet revient du bureau du chef de produit et il n'a pas l'air content. Je vais voir le chef de projet et l'informe que j'ai trouvé un bug critique dans la page de connexion lors de l'exécution de tests négatifs.

"Vous testez autre chose que la user story?" il a répondu. «S'il vous plaît, n'essayez pas de trucs drôles et négatifs juste pour casser l'application. Nous sommes en retard, et je ne pense pas qu’un utilisateur normal se heurtera à ce défaut. »

«D'accord», dis-je, «je vais signaler le bogue et passer à autre chose.»

En privé, cependant, je me demande: Qui ou qu'est-ce qu'un "utilisateur normal"?

Tester pour le monde réel

L'idée fausse selon laquelle un ingénieur en qualité de logiciel casse le produit existe toujours. Les testeurs eux-mêmes s'exclameront: «Vous voyez? J'ai cassé le logiciel - il se brise lorsque vous cliquez ici! »

Bien sûr, ils ne l'ont pas vraiment fait. Le logiciel ne casse pas; il fait simplement ce pour quoi il a été conçu et codé, pour le meilleur ou pour le pire.

En parlant de conception, un autre mythe courant est que tous les bogues sont des erreurs de codage et des incidents de programmation, alors qu'en fait, une majorité est introduite lors des exigences et de la conception. Les ingénieurs en qualité des logiciels étudient les systèmes, examinent ce que fait le système, puis découvrent et signalent où et comment le logiciel est défectueux, identifiant quand le système échouera sous la charge ou le stress ou fouiller comme n'importe quel utilisateur le ferait.

Donc c'est un testeur obligation pour aller au-delà du chemin heureux positif et révéler ce qui n'est pas si heureux.

Un test positif consiste à cliquer au bon endroit au bon moment. Il est peu probable qu'un utilisateur ne fasse que cela. Les utilisateurs cliquent sur ce qu'ils veulent, quand ils le souhaitent. Nous ne pouvons pas automatiser un utilisateur pour qu'il fasse la même chose tout le temps de la même manière, nous ne pouvons donc pas nous fier à nos tests automatisés pour couvrir l'interaction humaine.

C'est pourquoi je n'aime pas le terme test négatif - ce n'est pas négatif!

Je préfère les «tests dans le monde réel». Chaque utilisateur utilise le produit de manière unique, et nous ne pouvons pas comparer les utilisateurs entre eux ni nous attendre à ce qu'ils naviguent dans l'application en utilisant le même chemin. Les utilisateurs ne suivent pas le chemin heureux. Les utilisateurs ne suivent pas les instructions ou, honnêtement, lisent même généralement la documentation. Les utilisateurs contestent le produit.

Donc, en tant que testeurs, il est également crucial pour nous de remettre en question le produit. Nous devons varier nos tests pour savoir comment le produit répond. Un excellent test ne se limite pas à montrer que le produit peut produire un résultat attendu; cela signifie apprendre ce que fait le produit lorsque les utilisateurs font quelque chose que personne n'a prédit.

Notre devoir en tant qu'ingénieurs qualité logiciel est d'agir et de penser comme de vrais utilisateurs. Nous devons tester en dehors de notre plan de test et sortir du script. Les développeurs et les parties prenantes peuvent appeler cela des tests négatifs, mais le résultat est un meilleur produit, et tout est positif. 

Changer la conversation

Tout logiciel présente des risques potentiels de ne pas fonctionner comme prévu, il est donc crucial de valider au minimum que le logiciel ne plantera pas lorsque quelqu'un se connectera. Je n'effectuais pas de test négatif lorsque j'ai trouvé le bogue dans la page de connexion; J'étudiais le logiciel.

C'est donc à moi de communiquer cela de manière positive. Nos paroles ont un impact important sur la façon dont les autres perçoivent et comprennent notre travail.

Quand j'ai dit à mon chef de projet que j'avais trouvé un bogue en effectuant des tests négatifs, il est compréhensible que sa réaction n'ait pas été agréable. Si j'avais plutôt dit: «Pendant que je testais la page de connexion, j'ai découvert un bogue critique», sa réaction aurait probablement été: «Allez déposer le bogue, et nous l'examinerons plus tard.»

Donc je pense que nous devrions arrêter d'utiliser positif vs négatif terminologie. Parlons plutôt de «découverte» et d '«enquête». C'est moins déroutant, plus explicite et évite le problème potentiel des développeurs et des gestionnaires qui disent quelque chose de loufoque comme: "Oh, vous êtes juste négatif."

Changer mon vocabulaire m'a aidé à améliorer ma communication avec les parties prenantes et les développeurs. Je peux voir un angle différent de l'équation et j'ai pu parler aux développeurs sans aucune friction. Maintenant, l'équipe voit mon travail comme une amélioration positive du produit au lieu d'essayer négativement de casser le logiciel.

Essayez de changer votre vocabulaire de verbes «positifs» et «négatifs» à des verbes plus descriptifs qui expliquent votre exploration. L'équipe sera plus réceptive dans les conversations et pourrait même valoriser davantage votre travail.

Automatisez les tâches de test chronophages pour les développeurs et les testeurs

Par Jessica Lavoie

Jessica est ingénieure en assurance qualité logicielle chez Parasoft, où elle aime tester des fonctionnalités nouvelles et préexistantes pour satisfaire les utilisateurs.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.