Les meilleures stratégies de test logiciel en 2026

Stratégies de rythme de publication

Avec cet état d’esprit en place, le premier endroit où chercher une amélioration rapide est votre rythme de publication.

Listez des exemples avant que les programmeurs n’écrivent du code

Les spécifications d’un mot de passe ont tendance à être rédigées sous forme d’exigences : « Au moins huit caractères, dont au moins une majuscule, un chiffre ou un caractère spécial ». Dans la pratique, ces exigences laissent place à l’interprétation, de sorte que les développeurs mettent en œuvre ce qu’ils pensent que les règles signifient et ne découvrent que plus tard des cas limites ou des inadéquations entre l’intention et le comportement. Les programmeurs écrivent le code sur la base de ces spécifications et essaient ensuite de trouver des problèmes, tels que des caractères spéciaux qui sont rejetés par le filtre d’entrée.

Pour réduire l’ambiguïté, accompagnez les exigences d’exemples, comme un simple tableau d’exemples de mots de passe, chacun étant qualifié de bon ou de mauvais. Mieux encore, avant le début du codage, demandez à au moins trois rôles clés – programmation, voix du client, tests – de collaborer à l’élaboration de cette liste. Cela n’éliminera pas tous les défauts, mais cela peut permettre de faire fonctionner des cas d’utilisation simples, sans avoir à apprendre Ruby, à écrire des exemples en Gherkin ou à les câbler avec Cucumber.

Ajoutez RCRCRC à votre cadence de publication

Alors que la fabrication vise à produire des articles identiques, un système de construction vise à générer quelque chose de différent à chaque fois. Si nous disposons d’informations sur ce qui est différent, pourquoi tester la même chose ?

C’est exactement ce que fait l’heuristique RCRCRC de Karen N. Johnson, en suggérant des idées pour essayer différemment chaque nouveau test qui mérite d’être exploré par un humain. Elles représentent les domaines auxquels les testeurs devraient accorder une attention particulière. Les lettres de RCRCRC signifient :

• Récent. Éléments qui ont changé récemment.
• « Core ». Éléments essentiels qui doivent fonctionner.
• Risqué. Domaines que les membres de l’équipe peuvent qualifier de risqués.
• Sensible à la Configuration. Comportement qui peut changer en fonction de la configuration.
• Réparé. Éléments récemment réparés.
• Chronique. Éléments qui tombent souvent en panne.

Pour appliquer le RCRCRC, il suffit de prendre une pile de notes adhésives ou un tableau blanc numérique partagé et de dresser une liste d’idées de tests suffisamment détaillée pour qu’une personne rationnelle puisse les réaliser en 10 à 20 minutes. Ordonnez la liste – vote par points si nécessaire – mettez-les sur un Kanban, et tirez les cartes jusqu’à ce que vous manquiez de temps. Une fois la version terminée, décidez des tests à exécuter à nouveau et de ceux à arrêter. Un ingénieur pourrait faire remarquer que les tests de régression seront limités si les composants individuels sont médiocres.

Stratégies basées sur les composants

Une fois que vous avez amélioré la façon dont vous testez à nouveau pendant les cycles de publication, l’étape suivante consiste à réduire les tests de régression – ou à les éliminer complètement – en testant les composants de façon isolée.

Séparez l’interface utilisateur du back-end

De nombreux logiciels utilisent une interface graphique, appellent une API et affichent le résultat. Le front-end devra vérifier les erreurs courantes avec la plateforme – différentes tailles d’appareils, rotations, versions du système d’exploitation ou perte de signal internet, par exemple. Il faut également prévoir un test de contrôle pour s’assurer que les valeurs non valides sont piégées, ainsi que quelques exemples de scénarios qui passent du texte à la base de données et s’affichent correctement.

Peut-être que le nombre de chiffres affectera l’affichage, mais nous n’avons besoin que de quelques tests complets de l’interface graphique, en particulier des tests automatisés. Néanmoins, vous voudrez tester de nombreuses soumissions à un certain niveau. Il peut s’agir d’un contrôle API qui passe en boucle par un grand nombre de valeurs d’entrée et vérifie la sortie.

Contrôles micro, unitaires ou d’API

La plupart des organisations modernes utilisant Java, C# ou Python ont quelques tests unitaires qui traînent. Leur véritable puissance réside dans l’exercice d’une unité isolée. Pour ce faire, vous devrez remanier le code de manière que les dépendances se trouvent dans le constructeur et qu’il soit possible de passer des « mocks », des « stubs » et des « fakes ». Cela obligera le code à se composer de petits éléments testables.

Comme exercice de réflexion, considérez la différence entre une base de code de 1 000 unités avec une fiabilité de 90 % et une autre avec 1 000 unités avec une fiabilité de 99,9 %. Nous pouvons déduire que la première base de code a une fiabilité globale qui dépend de la fiabilité de chacune de ces unités. Bien que nous ne puissions pas mesurer cela directement, elle aurait donc une fiabilité de 0,90×0,90×0,90 – avec quelques 0,9 supplémentaires impliqués – ce qui donne un résultat très faible (90 % à la puissance 20 équivaut à 12 % ; 99,9 % à la puissance 20 équivaut à 98 %).

Déployez les composants séparément

L’héritage de Windows et de DOS en matière de logiciels nous a donné l’idée de la publication d’une image disque unique. Dans le contexte du web, on parle parfois de monolithe. Les applications web peuvent déployer HTML, JavaScript, CSS et les fichiers backend séparément, ce qui limite les tests de régression à l’étendue des changements. Cela équivaut à éliminer les tests de régression. Pour être efficace, il faut d’abord séparer l’interface graphique du backend, puis ajouter des vérifications automatisées de bas niveau, et enfin concevoir l’architecture pour une construction et un déploiement séparé par composant.

Créez des tests basés sur des modèles

Par exemple, pour une plateforme de réseaux sociaux, il est essentiel de comprendre l’état actuel de l’application. Il peut s’agir de n’importe quel écran, comme la connexion, le profil, votre flux, un message spécifique ou une interface d’édition et de commentaire. Vous devez également savoir quels liens sont valides sur chacune de ces pages. Ensuite, vous pouvez générer une étape aléatoire et un texte aléatoire à remplir pour les nouveaux messages et commentaires, et rebondir à travers l’application. Des données synthétiques peuvent s’avérer très pratiques pour cet exercice.

En fait, vous créez un modèle pour l’application, vous effectuez des étapes aléatoires dans l’application sur la base de ce modèle et vous déterminez si votre modèle correspond à la réalité. Lorsque vous trouvez une erreur, l’outil retrace ses étapes pour déterminer le nombre minimum d’étapes nécessaires pour reproduire l’erreur, puis la signaler.

Stratégies de publication d’informations

Lorsque vous publiez des métriques sur les bugs les plus anciens, les tickets non résolus, et tout ce qui peut être quantifié de manière objective, il se passe quelque chose d’étonnant. Si la direction surveille la page, les gens résoudront les problèmes et le code s’améliorera. Si le tableau de bord n’existe pas, il n’y a pas d’incitation à améliorer le code. Voici quelques mesures liées au code et aux tests à ne toutefois pas prendre en compte lors de chaque compilation.

Identifiez et remaniez les modules complexes

Les gros modules peuvent être déroutants. Ils comportent trop de variables et celles-ci tirent leur valeur les unes des autres. Il est courant qu’un programmeur responsable de la maintenance coupe et colle du code pour créer les deux côtés d’une instruction if, en apportant une modification subtile à l’un des côtés. Le suivant peut recevoir une exigence, la mettre en œuvre à un seul endroit et ne pas se rendre compte que le code demande à être modifié à deux endroits.

Un code complexe cache des bugs. Certains outils, appelés analyseurs de complexité, peuvent vous indiquer le nombre de boucles et de branches de votre code.

Publiez le nombre de bugs à corriger ou les bugs les plus anciens à corriger

Bien que les bugs ne soient pas tous égaux, et que la seule mesure du volume occulte ce fait, vous pourriez suivre le nombre de bugs à corriger auxquels personne ne s’est attaqué. Cela permettra non seulement de les corriger, mais aussi de réduire le délai de correction, ce qui augmentera la productivité globale. De même, une simple liste des bugs les plus anciens marqués comme devant être corrigés encouragera les gens à les corriger ou à revoir leur statut. Certains bugs ou vulnérabilités, aussi étonnant soit-il, ne sont pas nécessairement à corriger. Tout simplement parce que les effets de ces deux problèmes peuvent être très difficilement reproductibles. Dans les deux situations, cela demande de documenter ces cas limites.

Rendez visible à l’œil nu la couverture des tests

La plupart des entreprises ne disposent même pas d’une visualisation de leurs fonctionnalités – du moins au début. Il peut s’agir d’une simple analyse des caractéristiques clés du système sous forme de carte mentale. De même, à l’exception de la couverture des tests unitaires, la plupart des entreprises ne disposent d’aucune mesure de la qualité des tests ou de la couverture du logiciel. Au lieu de cela, les tests sont une sorte de boîte noire. Lorsque les choses vont bien, la direction peut faire pression pour que les fonctionnalités soient livrées plus rapidement, ce qui implique de réduire les tests. En cas de problème grave, elle peut réunir tout le monde dans une salle et demander : « Comment ce bug a-t-il pu vous échapper ? ». Non seulement c’est un piège pour les employés, mais cela ne fournit pas non plus à la direction les outils dont elle a besoin pour piloter.

Commencez par un modèle de couverture. Il peut s’agir d’une simple carte mentale. Pour ajouter une couverture, il suffit d’entrer un chiffre d’un à dix pour indiquer dans quelle mesure la fonctionnalité est couverte. Les équipes devront élaborer leur propre grille d’évaluation de la signification de ces chiffres. Cette carte sera unidimensionnelle – elle n’inclura pas les modes de défaillance courants de la plateforme ni les bugs déclenchés par un parcours utilisateur qui touche plusieurs fonctionnalités – mais c’est un début. Le modèle heuristique de stratégie de test de James Bach et Michael Bolton propose d’autres façons d’examiner les logiciels, au-delà des simples flux de travail et des fonctionnalités, afin de construire un meilleur modèle.

Une fois que la direction dispose du modèle, elle a des options. Elle peut suggérer des tests supplémentaires pour les domaines qui présentent des lacunes, ou réduire la couverture pour les fonctionnalités qu’elle considère comme non critiques. Ensuite, lorsque des bugs sont détectés en production, il s’agit probablement des éléments pour lesquels la direction a choisi de ne pas investir de temps dans les tests. Vous devrez peut-être encore avoir une conversation sur les problèmes et sur la manière de les résoudre, mais elle sera probablement bien différente et plus agréable.

Expérimentez de nouvelles stratégies de test

Si vous êtes un contributeur technique, choisissez une chose, quelque chose que vous pouvez faire sans permission, et faites-le. Si cela nécessite le soutien de l’équipe, essayez-le à titre expérimental pendant deux semaines. Si vous utilisez Scrum, proposez-le lors d’une rétrospective pour un sprint. Même si les gens s’y opposent, ils seront peut-être prêts à l’essayer pendant deux semaines.

Si vous savez déjà quelles sont les stratégies qui vous conviennent et que vous les mettez toutes en œuvre avec succès, vous avez plus de chance que la plupart des autres. Dans ce cas, l’étape suivante consiste à inventer votre propre stratégie.

Matt Heusser est directeur général d’Excelon Development, où il recrute, forme des développeurs et réalise des tests et des développements de logiciels.

Phil Kirkham, consultant expert en assurance qualité, a participé à l’évaluation de cet article.