Les tests logiciels en valent-ils vraiment la peine ?

Oui et non. Bon, comme pour tout, ça dépend. Dans cet article, je vais essayer d'illustrer mon expérience des tests en tant que développeur, puis en tant que fondateur de startup.

Sur moi

Salut! Je suis Simone, développeur full-stack et directeur technique avec 15 ans d'expérience dans le codage dans divers secteurs, notamment les agences Web, le commerce électronique, les logiciels pour adultes et les logiciels d'entreprise. Dans cet article de blog, j'aimerais partager des informations sur les tests de logiciels et sur la manière de déterminer les méthodes appropriées pour les différents besoins et étapes de l'entreprise.

Je suis le directeur technique et cofondateur de Bugpilot, un outil de surveillance des bogues qui aide les équipes SaaS à détecter les bogues qui ont échappé aux processus de développement, de test et d'assurance qualité.

Introduction

Différents types de tests

Dans le monde du développement logiciel, de nombreuses pratiques de test ont longtemps été considérées comme essentielles pour garantir la fiabilité et la qualité des produits logiciels. Cependant, il est important de reconnaître que si ces méthodologies ont leurs mérites, elles ne sont pas sans inconvénients.

Cet article de blog vise à susciter une conversation et à faire la lumière sur les dommages potentiels que TDD et QA peuvent infliger aux équipes logicielles. En reconnaissant qu'il n'existe pas d'approche unique et que différentes entreprises et étapes nécessitent des méthodes appropriées, nous pouvons commencer à naviguer plus efficacement dans les complexités du développement logiciel.

Je reconnais de nombreuses méthodologies différentes, des pratiques courantes et des recommandations concernant les tests de logiciels ; dans ce poste, je me suis principalement concentré sur le développement piloté par les tests et l'assurance qualité.

Voici un aperçu, au cas où vous ne seriez pas familier avec les termes :

TDD

Le développement piloté par les tests (TDD) est une méthode de développement logiciel qui consiste à écrire des tests automatisés avant d'écrire du code. Cela permet de détecter les problèmes au début du cycle de développement, garantissant que le code est testé de manière approfondie et répond aux exigences de l'entreprise. Les développeurs définissent d'abord le comportement attendu d'une nouvelle fonctionnalité avec un test, puis écrivent le code pour réussir le test, et enfin optimisent le code par refactorisation.

AQ

L'assurance qualité (AQ) garantit que le logiciel répond aux normes de qualité avant sa sortie. Généralement, un processus manuel effectué par un ingénieur QA identifie et corrige les défauts grâce à des tests manuels et automatisés, tels que la vérification des exigences fonctionnelles et la vérification des performances. Cela garantit un logiciel fiable et stable qui répond aux besoins des entreprises et des utilisateurs finaux.

Quelques questions pour vous !

Mon objectif avec ce message est de susciter une conversation. Je ne saurais trop insister sur le fait que je crois fermement que des tests sont nécessaires dans de nombreux cas. Pensez aux appareils médicaux, aux logiciels d'avion, aux systèmes de contrôle, aux services bancaires et bien plus encore, aux logiciels utilisés par des milliards de personnes où la couleur d'un bouton fait une différence de profit significative.

Le développement logiciel nécessite un équilibre entre structure et flexibilité, et suivre aveuglément les principes de test sans tenir compte du contexte peut conduire à des résultats sous-optimaux - les bibliothèques de code bénéficient probablement d'une couverture de 99 %. Mais votre logiciel a-t-il également besoin d'une couverture de 99 % ?

J'ai préparé quelques questions. Essayez de répondre par oui ou par non — pourquoi ?

• Avez-vous vraiment besoin de tester vos composants d'interface utilisateur ?
• Avez-vous besoin de tests E2E pour cette fonctionnalité de « mise à jour de l'image de profil » ?
• Échouez-vous à l'assurance qualité et retardez-vous une version s'il y a une incohérence mineure entre les conceptions Figma et l'interface utilisateur réelle ? Quelle est la limite ?
• Dois-je virer John pour avoir refusé d'écrire des tests ?

Chapitre 1. Mon cas contre le Test-Driven-Development

Contester le dogme

Le développement piloté par les tests (TDD) a gagné un public presque religieux. Certains prétendent que cela aide à la santé mentale, et cela s'accompagne souvent de la croyance dogmatique selon laquelle c'est la seule voie vers le succès. Ce chapitre vise à explorer les inconvénients du TDD et à faire la lumière sur le piège de la rigidité, les contraintes de temps et le faux sentiment de sécurité .

En tant que CTO, j'ai rencontré des collègues qui insistaient fermement sur le TDD, même pour les fonctions les plus triviales. Le dogme dominant semblait être : "Tu dois faire du TDD, ou tu es un idiot !" Cette croyance inébranlable dans le TDD comme seule approche acceptable m'a souvent amené à remettre en question mon propre jugement et ma compétence. Je me souviens distinctement des incidents où on se moquait de moi pour avoir refusé d'écrire des tests pour une simple fonction à 2 lignes pour filtrer un tableau.

Cette expérience personnelle a mis en évidence l'un des principaux pièges du TDD : le piège de la rigidité. L'adhésion dogmatique à l'écriture préalable des tests peut parfois conduire à des processus rigides, qui peuvent, à leur tour, avoir un impact sur le délai de mise sur le marché et l'avantage concurrentiel d'une entreprise.

Cela vaut-il vraiment le temps ?

Un défi important posé par le TDD est la contrainte de temps qu'il impose au processus de développement.

L'écriture de tests complets pour chaque élément de code peut prendre du temps, en particulier pour les fonctions triviales qui ont un impact minimal sur l'ensemble du système. Dans les environnements au rythme rapide où des itérations rapides et une livraison rapide sont cruciales, les frais généraux supplémentaires de TDD peuvent ralentir le cycle de développement et entraver l'agilité.

Je trouve déraisonnable de toujours suivre l'approche « J'ai besoin d'une couverture à 99 % ». Équilibrer rigueur et efficacité est essentiel, et il existe des scénarios où une approche de test plus rationalisée peut être plus appropriée, permettant des itérations plus rapides et des réponses plus rapides aux demandes du marché.

De plus, la complexité et l'imperfection de l'écriture de tests qui impliquent des interactions avec des dépendances externes ou des systèmes complexes peuvent encore aggraver les contraintes de temps de TDD.

En tant que développeur, je pourrais même dire que j'aime écrire des tests, mais… trouvez un PDG qui est content que son équipe passe 80 % de son temps à écrire des tests pour du code qui sera éventuellement supprimé.

Les développeurs ont souvent besoin de créer des objets fictifs ou des stubs pour simuler le comportement de ces dépendances lors des tests. Bien que les simulations puissent être des outils précieux pour isoler le code et réduire les dépendances, elles peuvent également introduire une surcharge et une complexité supplémentaires.

Le recours à des simulations peut conduire à une représentation imparfaite des interactions du monde réel, car il peut être difficile de reproduire avec précision le comportement de systèmes externes ou de composants tiers. Cela peut introduire un niveau d'incertitude dans le processus de test, entraînant potentiellement des faux positifs ou des faux négatifs.

Les tests passent; Je peux avoir une bonne nuit de sommeil, n'est-ce pas ? Droite?

Les tests passent; Je peux dormir sain et sauf !

Il existe un danger inhérent, mais souvent négligé, à se fier uniquement aux tests : un faux sentiment de sécurité. Bien que les tests soient sans aucun doute essentiels pour identifier et prévenir les défauts, ce n'est pas une solution infaillible.

"Avons-nous testé sur chaque appareil ?"

Il est également difficile de tester tous les cas possibles. Surtout dans le domaine du développement Web, il existe une multitude de facteurs qui peuvent avoir un impact sur l'expérience utilisateur. L'un de ces facteurs est la diversité des appareils des utilisateurs finaux, y compris les différentes tailles d'écran, résolutions, systèmes d'exploitation et navigateurs. Chaque combinaison présente un ensemble unique de défis qui peuvent affecter la façon dont le logiciel fonctionne et apparaît aux utilisateurs.

Considérez la vaste gamme d'appareils et de configurations : smartphones, tablettes, ordinateurs portables et ordinateurs de bureau, fonctionnant sur iOS, Android, Windows ou macOS, utilisant différentes versions de navigateurs comme Chrome, Safari, Firefox, Edge ou Internet Explorer. Chaque combinaison d'appareil, de système d'exploitation et de navigateur peut rendre le contenu Web différemment, et les interactions des utilisateurs peuvent également varier. Il est pratiquement impossible d'anticiper et de tenir compte de chaque appareil et configuration possibles, ce qui rend difficile pour les tests de fournir une couverture complète.

« Ai-je testé cette interface utilisateur comme si j'étais ma grand-mère ? »

Les personas et les profils d'utilisateurs ajoutent une autre couche de complexité. Votre logiciel peut cibler un public diversifié avec des préférences, des comportements et des besoins d'accessibilité différents . Les tests peuvent aider à découvrir les problèmes qui surviennent dans des scénarios typiques, mais ils peuvent manquer des cas extrêmes ou des interactions utilisateur spécifiques qui s'écartent de la norme. Par exemple, les utilisateurs malvoyants qui s'appuient sur des technologies d'assistance peuvent rencontrer des problèmes d'utilisabilité difficiles à saisir uniquement par des tests automatisés.

Outre les variations techniques, le contexte utilisateur et les scénarios du monde réel jouent un rôle crucial dans l'élaboration de l'expérience utilisateur. Des facteurs tels que les conditions du réseau, les limites de bande passante ou l'utilisation simultanée peuvent avoir un impact sur les performances et la fiabilité du logiciel.

Bien que les tests puissent fournir un environnement contrôlé, ils peuvent ne pas simuler avec précision les diverses conditions de réseau et les modèles d'utilisation que les utilisateurs rencontrent dans leur vie quotidienne. Si les tests ne permettent pas de garantir le bon fonctionnement de votre logiciel, en valent-ils la peine en fin de compte ?

Chapitre 2. AQ et besoin de rapidité

J'ai été témoin de première main des défis posés par les pratiques d'assurance qualité « strictes », en particulier lorsqu'il s'agit de petites entreprises qui doivent agir rapidement pour rester au top de leurs concurrents.

Je crois que cela est particulièrement vrai pour les startups en démarrage ; vous êtes en quelque sorte susceptible de jeter toute la fonctionnalité bientôt si vos clients ne l'utilisent pas. Alors, cette semaine entière de tests et d'amélioration des tests unitaires en valait-elle la peine ?

Permettez-moi de partager mes expériences personnelles et de mettre en lumière les dangers de se laisser entraîner dans le perfectionnisme, en particulier lorsque des aspects visuels ou de présentation mineurs deviennent le centre des efforts d'assurance qualité.

Dans mon rôle précédent dans une startup, nous faisions face à une bataille constante entre la livraison rapide de fonctionnalités et la garantie d'une qualité irréprochable. Il y a eu des cas où notre cycle de publication a été inutilement retardé en raison de problèmes mineurs tels qu'une marge CSS mal alignée, un choix de police incorrect ou un saut de ligne manquant. Bien que l'attention portée aux détails soit importante, j'ai commencé à remettre en question l'impact de l'obsession de ces imperfections cosmétiques sur notre capacité à rester en tête du marché.

L'un des risques d'une AQ excessive est la priorité accordée à la perfection plutôt qu'à l'aspect pratique. Dans notre quête de la perfection, nous nous sommes souvent retrouvés à investir beaucoup de temps et de ressources pour corriger de minuscules problèmes visuels. N'est-ce pas l'ennemi de la productivité ?

Bien qu'il soit essentiel de maintenir des normes élevées, j'ai commencé à réaliser que consacrer des efforts considérables à ces détails infimes pourrait être contre-productif, détournant notre attention des fonctionnalités de base et des améliorations de l'expérience utilisateur qui comptaient vraiment pour nos clients.

Le danger est devenu évident lorsque nous avons observé les conséquences d'une approche d'assurance qualité trop prudente. Notre équipe a commencé à montrer une aversion au risque, optant pour un processus de publication lent et méticuleux. Alors que l'intention était de fournir un produit presque irréprochable, nous avons par inadvertance étouffé l'innovation et entravé notre capacité à répondre rapidement aux demandes des clients. En tant que petite entreprise (30 employés), nous nous sommes appuyés sur notre agilité pour itérer rapidement et déjouer nos concurrents plus importants. Cependant, des pratiques d'assurance qualité excessives ont entraîné une peur généralisée des "bugs" qui nous retenait.

Ne devrions-nous pas accepter que des bogues existent ? Quiconque travaille fait des erreurs; si vous ne travaillez pas, vous ne faites jamais d'erreurs. (Désolé - citation de football)

Chapitre 4. Les clients pourraient être les meilleurs testeurs

Les implications financières des cycles de libération prolongée sont devenues évidentes. Les fenêtres de marché manquées, la génération de revenus retardée et le taux de désabonnement des clients potentiels ont commencé à faire des ravages. Nous ne pouvions pas nous permettre de traîner en tant que petite entreprise aux ressources limitées. Nous devions tirer parti de notre agilité et de notre rapidité pour saisir les opportunités et conserver un avantage concurrentiel.

Le temps passé à perfectionner des détails mineurs devait être mis en balance avec la nécessité d'une itération rapide et de la réactivité du marché. Reporter, reporter et reporter chaque publication jusqu'à ce que nous soyons « plus certains » que tout fonctionne ; l'expédition le mardi est devenue l'option préférée. Pourquoi expédier le lundi si nous pouvons prendre un jour de plus pour tout tester ?

Bien que les tests aident à identifier et à prévenir les défauts, il est tout aussi important de considérer les commentaires des utilisateurs comme une source précieuse d'informations. Les expériences, les préférences et les suggestions des utilisateurs peuvent fournir des informations qui vont au-delà de ce que les tests seuls peuvent révéler. Nous pouvons créer un produit centré sur l'utilisateur qui répond à ses attentes en favorisant une boucle de rétroaction avec les utilisateurs, en écoutant activement leurs besoins et en incorporant leur contribution dans le processus de développement.

Plutôt que de s'appuyer uniquement sur des tests internes approfondis, impliquer les utilisateurs dans le processus de test peut être très bénéfique. Les premiers tests utilisateur, tels que les tests bêta ou les études d'utilisabilité, permettent d'observer des scénarios et des interactions utilisateur réels.

Cette approche centrée sur l'utilisateur permet d'identifier les points faibles, les problèmes d'utilisabilité et les problèmes imprévus qui peuvent ne pas être détectés uniquement par des tests internes. L'intégration précoce de ces commentaires peut grandement améliorer l'expérience et la satisfaction de l'utilisateur.

Malheureusement, j'ai personnellement été témoin d'un fort « déséquilibre » dans de nombreuses équipes logicielles. Voici une question pour vous : le contrôle qualité doit-il échouer en raison d'une incohérence de l'interface utilisateur ? À quelle fréquence le contrôle qualité doit-il échouer ?

Chapitre 5. "Les utilisateurs partiront s'ils rencontrent un bogue !"

La recherche met constamment en évidence l'impact négatif des fonctionnalités cassées sur la rétention des utilisateurs. On nous a dit que de nombreuses études montrent que les utilisateurs sont moins susceptibles de continuer à utiliser un produit s'ils rencontrent des bogues, des plantages ou des erreurs fréquents qui perturbent leur expérience.

Selon une enquête de Qualitest , 88% des utilisateurs abandonneront une application après seulement une ou deux instances de mauvaises performances. Ces résultats soulignent le rôle essentiel que joue la stabilité fonctionnelle dans la fidélisation des utilisateurs et la création d'un engagement à long terme.

Lorsque les utilisateurs rencontrent des fonctionnalités cassées, cela érode leur confiance dans le produit et l'équipe de développement qui le soutient. Même si les problèmes sont finalement résolus, les utilisateurs peuvent développer une perception négative et être réticents à revenir. Les utilisateurs peuvent perdre confiance dans un site Web ou une application s'ils rencontrent à plusieurs reprises des erreurs ou des problèmes fonctionnels.

Mais… est-ce toujours vrai en 2023 ?

Les bogues sont partout, et nous savons tous qu'un logiciel sans bogue n'existera peut-être jamais .

Les utilisateurs peuvent rencontrer des bogues de temps à autre, et il est important de faire la distinction entre les bogues mineurs et les problèmes de fonctionnalité critiques. Les utilisateurs peuvent aujourd'hui être plus indulgents pour les bugs mineurs qui n'ont pas d'impact significatif sur leur expérience globale. À notre avis, les utilisateurs ont appris à accepter les bogues comme inévitables dans le développement de logiciels ; les insectes font partie de notre quotidien.

Cependant, lorsqu'il s'agit de fonctionnalités de base brisées qui entravent leur capacité à utiliser le logiciel comme prévu, les utilisateurs sont susceptibles d'être moins indulgents et peuvent rechercher des alternatives.

Les bugs B2B sont plus douloureux (ou pas ?)

Dans les scénarios B2B, une fonctionnalité cassée peut avoir de graves conséquences pour les utilisateurs et leurs entreprises. Cela peut entraîner des délais de projet retardés, des délais non respectés et même une perte financière de 440 millions de dollars .

En ce qui concerne les logiciels grand public, les utilisateurs professionnels peuvent devenir frustrés et en colère lorsqu'ils rencontrent des bogues les empêchant d'accomplir leur travail. Leur fidélité à un produit logiciel est étroitement liée à sa fiabilité et à sa capacité à les aider à réussir dans leurs responsabilités professionnelles. Une faible fiabilité devrait équivaloir à un taux de désabonnement plus élevé.

Cependant, j'ai appris que ce n'est pas toujours le cas. Une fois qu'une organisation entière a adopté une technologie, est-il si facile de faire basculer l'ensemble de l'entreprise vers une solution concurrente ? Peu probable.

Le e-commerce a (plus) d'enjeux de fidélisation.

Dans le commerce électronique, les utilisateurs disposent de nombreuses alternatives à portée de main. En tant qu'utilisateur, votre travail à faire est très clair. Vous devez acheter un aspirateur. Si l'application Amazon plante, combien de temps avant d'essayer la prochaine application dans votre tiroir ?

Des fonctionnalités cassées ou des bogues peuvent entraîner des paniers d'achat rapidement abandonnés, une diminution permanente de la satisfaction des clients et des opportunités commerciales perdues.

Chapitre 6. TDD & QA sont-ils la seule solution ?

De toute évidence, non. Bien que les tests jouent un rôle crucial dans l'identification et la prévention de certains défauts, des mesures supplémentaires peuvent être prises pour minimiser l'impact des bogues sur les utilisateurs. Voici quelques approches que j'ai étudiées :

Surveillance et suivi des erreurs

La mise en œuvre de systèmes de surveillance et de suivi des erreurs robustes permet une identification et une résolution proactives des problèmes. La surveillance en temps réel peut aider à détecter les anomalies, les problèmes de performances et les erreurs, permettant une correction rapide avant qu'ils n'affectent plusieurs utilisateurs. Le suivi des erreurs permet de capturer les détails des erreurs et aide à hiérarchiser les corrections de bogues en fonction de leur impact sur les utilisateurs.

Des outils tels que Sentry , Rollbar , Bugsnag et Bugpilot aident les équipes à détecter automatiquement les erreurs de codage et les sessions UX problématiques, afin que les équipes puissent résoudre les problèmes de manière proactive.

Commentaires et assistance des utilisateurs

Encourager activement et collecter les commentaires des utilisateurs fournit des informations précieuses sur les problèmes d'utilisabilité, les bogues et les domaines à améliorer. Le fait de traiter rapidement les problèmes signalés par les utilisateurs et de fournir une assistance démontre un engagement à résoudre les problèmes et à maintenir une expérience utilisateur positive.

Des outils tels que Canny , Hotjar et Bugpilot aident les équipes à recueillir facilement les commentaires de leurs utilisateurs.

Documentation et formation des utilisateurs

Une documentation claire et complète et des supports de formation des utilisateurs peuvent aider les utilisateurs à naviguer efficacement dans le logiciel et à minimiser le risque d'erreurs induites par l'utilisateur. Fournir des ressources qui expliquent les problèmes courants et les étapes de dépannage permet aux utilisateurs de résoudre les problèmes mineurs de manière indépendante.

Chez Bugpilot, nous utilisons une page Notion pour conserver toute notre documentation. Facile et gratuit.

Conclusion

Les tests agissent comme une mesure préventive cruciale en identifiant les problèmes tôt dans le processus de développement. Des tests approfondis, y compris des tests unitaires, des tests d'intégration et des tests de bout en bout, aident - dans une certaine mesure - à détecter les bogues et à garantir la stabilité et la fonctionnalité du logiciel. Mais des tests excessifs et des processus trop stricts sont très susceptibles de nuire à l'entreprise à long terme.

Cependant, des erreurs peuvent parfois passer à travers le filet de test malgré tous nos efforts. Par conséquent, il est tout aussi important de mettre en place des stratégies d'atténuation. En mettant en œuvre des solutions d'atténuation, les équipes logicielles peuvent détecter et résoudre rapidement les erreurs, en minimisant leur impact sur les utilisateurs et en résolvant rapidement les problèmes qui surviennent.

Reconnaissant qu'aucun logiciel ne peut jamais être entièrement exempt de bogues , il est essentiel de créer un environnement qui encourage les commentaires des utilisateurs et offre un support client efficace. En écoutant activement les rapports des utilisateurs et en répondant rapidement à leurs préoccupations, les équipes logicielles peuvent maintenir une relation positive avec leurs utilisateurs et favoriser la confiance et la fidélité.

tl;dr

N'exagérez pas. Vous n'avez probablement pas besoin d'une couverture de test unitaire de 99 %. Expédier rapidement.