Actualités Logiciels : 5 étapes clés de test de logiciels que tout ingénieur devrait effectuer

Ces dernières années, le terme « tests avec décalage à gauche » est entré dans le langage vernaculaire du génie logiciel. Mais qu'est-ce que ça veut dire ? En clair, cela signifie effectuer davantage de tests logiciels pendant la phase de développement logiciel afin de réduire les défauts et d'épargner à l'entreprise des bugs coûteux.

Les tests Shift-left sont souvent utilisés pour décrire l'implication accrue des ingénieurs d'assurance qualité (AQ) pendant la phase de développement dans le but de détecter les défauts le plus tôt possible, avant que les ingénieurs logiciels n'aient confié le programme à l'assurance qualité pour des tests plus approfondis. La plupart du temps, cela signifie développer et exécuter davantage de tests plus automatisés de l’interface utilisateur et des API. Cependant, il existe certaines étapes de test logicielles de base et essentielles que chaque développeur de logiciels doit effectuer avant de montrer son travail à quelqu'un d'autre, qu'il s'agisse de tests avec décalage à gauche, de tests formels, de tests ad hoc, de fusion et d'intégration de code, ou simplement d'appeler un collègue pour jetez un coup d'oeil rapide. Le but de ces tests de base est de détecter les bugs évidents qui sautent immédiatement aux yeux. Sinon, vous entrez dans un cycle coûteux et inutile où vous devez décrire le problème au développeur, qui doit ensuite le reproduire, le déboguer et le résoudre avant de réessayer. Voici les étapes essentielles de test de logiciels que tout ingénieur logiciel doit effectuer avant de montrer son travail à quelqu'un d'autre.

1. Tests de fonctionnalités de base

Commencez par vous assurer que chaque bouton de chaque écran fonctionne. Vous devez également vous assurer que vous pouvez saisir du texte simple dans chaque champ sans faire planter le logiciel. Vous n'avez pas besoin d'essayer toutes les différentes combinaisons de clics et de caractères, ou de conditions de bord, car c'est ce que font vos testeurs et ils sont vraiment bons dans ce domaine. L'objectif ici est le suivant : ne laissez pas d'autres personnes toucher à votre travail s'il risque de planter dès qu'ils entrent leur propre nom dans le champ du nom d'utilisateur. Si la fonctionnalité est conçue pour être accessible via une API, vous devez exécuter des tests pour vous assurer que la fonctionnalité de base de l'API fonctionne avant de la soumettre à des tests plus intensifs. Si vos tests de fonctionnalités de base détectent quelque chose qui ne fonctionne pas, ce n'est pas un problème. Dis-leur juste que ça ne marche pas, que tu en es conscient, et qu'ils ne devraient pas se donner la peine d'essayer. Vous pourrez le réparer plus tard, mais ne laissez pas de surprises.

2. Révision des codes

Un autre regard sur le code source peut révéler de nombreux problèmes. Si votre méthodologie de codage nécessite un examen par les pairs, effectuez cette étape avant de remettre le code pour test. N'oubliez pas cependant de faire vos tests de fonctionnalités de base avant la révision du code.

3. Analyse du code statique

Il existe des outils qui peuvent effectuer une analyse du code source ou du bytecode sans l'exécuter. Ces outils d'analyse de code statique peuvent rechercher de nombreuses faiblesses dans le code source, telles que des vulnérabilités de sécurité et des problèmes potentiels de concurrence. Utilisez des outils d'analyse de code statique pour appliquer les normes de codage et configurez ces outils pour qu'ils s'exécutent automatiquement dans le cadre de la build.

4. Tests unitaires

Les développeurs écriront des tests unitaires pour s'assurer que l'unité (qu'il s'agisse d'une méthode, d'une classe ou d'un composant) fonctionne comme prévu et testeront sur une gamme d'entrées valides et non valides. Dans un environnement d'intégration continue, les tests unitaires doivent être exécutés chaque fois que vous validez une modification dans le référentiel de code source, et vous devez également les exécuter sur votre machine de développement. Certaines équipes ont des objectifs de couverture pour leurs tests unitaires et échoueront si les tests unitaires ne sont pas suffisamment étendus. Les développeurs travaillent également avec des objets fictifs et des services virtualisés pour s'assurer que leurs unités peuvent être testées de manière indépendante. Si vos tests unitaires échouent, corrigez-les avant de laisser quelqu'un d'autre utiliser votre code. Si, pour une raison quelconque, vous ne parvenez pas à résoudre le problème maintenant, informez l'autre personne de ce qui a échoué afin qu'elle ne soit pas surprise lorsqu'elle rencontrera le problème.

5. Tests de performances pour un seul utilisateur

Certaines équipes intègrent des tests de charge et de performances dans leur processus d'intégration continue et exécutent des tests de charge dès que le code est archivé. Cela est particulièrement vrai pour le code back-end. Mais les développeurs doivent également s’intéresser aux performances d’un seul utilisateur sur le front-end et s’assurer que le logiciel est réactif lorsqu’ils utilisent uniquement le système. Si l'affichage d'une page Web provenant d'un serveur Web local ou émulé (et donc réactif) prend plus de quelques secondes, découvrez quel code côté client ralentit les choses et corrigez-le avant de laisser quelqu'un d'autre le voir.