Les tests logiciels corrigent les bogues et les vulnérabilités avant qu’ils n’affectent les utilisateurs, mais la course effrénée vers la ligne d’arrivée – encombrée d’obstacles tels que des budgets limités, des sprints incrémentiels et de mauvaises décisions de gestion – peut entraver le déploiement d’un code de qualité.
Les tests valident que le logiciel fonctionne comme prévu, en identifiant les vulnérabilités et en minimisant les bogues avant que le code ne soit déployé en production. Les outils de test automatisés tels que Selenium, JUnit ou Grinder utilisent des scripts basés sur du code pour examiner les logiciels, comparer les résultats des exécutions et rapporter les résultats. Cependant, malgré une large disponibilité de ces outils, la plupart des codes arrivent en production sans avoir été testés ; les facteurs contributifs incluent la pénurie de développeurs, un manque de compétences parmi les équipes de test et de mauvaises décisions commerciales, selon les analystes du secteur.
« Les logiciels ne sont pas testés simplement parce que les tests [is costly]cela demande du temps et des ressources, et les tests manuels ralentissent le processus de développement continu », a déclaré Diego Lo Giudice, vice-président et analyste chez Forrester Research.
Les développeurs ne testent à l’unité que 50 % de leur code ; Les experts en la matière (PME) testeurs n’automatisent qu’environ 30% de leurs cas de test fonctionnels, ce qui n’a rien à voir avec la complexité du code, a déclaré Lo Giudice.
« Les compétences, les coûts et le temps sont les raisons », a-t-il déclaré.
Selon le Consortium for Information and Software Quality (CISQ), une organisation à but non lucratif qui développe des normes internationales de qualité logicielle, le coût total d’un logiciel de mauvaise qualité dépasse 2 000 milliards de dollars par an, dont 1 560 milliards de dollars en pannes opérationnelles et 260 milliards de dollars en projets informatiques infructueux.
La plupart des codes de production ne sont pas soumis à des tests logiciels.
Mais il y a plus que de l’argent en jeu. « Pour les entreprises qui font du commerce électronique, lorsque le système tombe en panne, elles perdent de l’argent, puis elles perdent leur réputation », a déclaré Christian Brink Frederiksen, PDG de Leapwork, une plateforme d’automatisation des tests sans code. Cela peut entraîner des problèmes de fidélisation de la clientèle, a-t-il déclaré.
Cependant, certains PDG portent des œillères en matière de qualité logicielle. « Si vous parlez à un PDG de tests, vous pouvez voir ses yeux se dire : ‘Vraiment, eh bien, qu’est-ce que c’est ?' », a-t-il déclaré. « Mais s’ils ont connu une panne sur leur plateforme de commerce électronique et quelles en ont été les conséquences, alors c’est une autre histoire. »
Les tests de logiciels complexes nécessitent des compétences complexes
Les tests de logiciels posent des problèmes de compétences car les gens doivent rechercher des vulnérabilités inconnues et essayer de prédire où les systèmes pourraient tomber en panne, a déclaré Ronald Schmelzer, associé directeur de la certification Cognitive Project Management for AI chez Cognilytica.
Pourtant, il y a une pénurie de talents technologiques dotés des compétences de test nécessaires. Alors que la demande des employeurs en talents technologiques augmente de façon exponentielle, le nombre de développeurs et de programmeurs reste stable, créant une concurrence intense entre les employeurs pour embaucher du personnel qualifié, selon le PDG de Quickbase, Ed Jennings, dans une interview en mai.
En plus d’une pénurie de compétences, les tests nécessitent la répétition des tâches pour assurer la couverture de tous les domaines et pour vérifier que les bogues précédents n’ont pas refait surface après les mises à jour, a déclaré Schmelzer.
La couverture et la chasse aux bogues deviennent plus un défi pour les violations à l’échelle du système des bonnes pratiques d’architecture ou de codage, a déclaré Bill Curtis, vice-président principal et scientifique en chef chez Cast Software et directeur exécutif du CISQ. Si une violation est contenue dans un seul module ou composant, un correctif peut être testé relativement facilement, mais les violations au niveau du système – impliquant des interactions défectueuses entre plusieurs composants ou modules – nécessitent des corrections sur plusieurs composants du système, a déclaré Curtis.
« Fréquemment, des corrections sont apportées à certains composants défectueux, mais pas à tous, pour constater que des problèmes opérationnels persistent et que d’autres composants défectueux doivent être corrigés dans une version future », a-t-il déclaré.
Les pressions commerciales et les méthodologies contribuent
Mais alors que les pressions commerciales, telles que le maintien d’un avantage concurrentiel ou la livraison dans les délais, contribuent au problème des tests logiciels, les méthodologies de développement sont également en partie responsables, a déclaré Frederiksen de Leapwork.
« Le problème central des tests de logiciels est que les entreprises ont probablement optimisé l’ensemble de l’approche de développement de logiciels avec des méthodes comme Agile ou CI/CD », a déclaré Frederiksen. Cela donne la fausse impression que le code prêt pour le déploiement a également été optimisé, a-t-il expliqué.
Cela ne signifie pas qu’une méthodologie est pire ou meilleure qu’une autre. « Avec Waterfall, les tests ne faisaient pas mieux – en termes de quantité de tests – avant que le logiciel n’entre en production, par rapport aux tests effectués en Agile », a déclaré Lo Giudice de Forrester.
Les tests / AQ sont généralement une réflexion après coup et à court de personnel. C’est ce qui empêche la mise en ligne du code.
Holger MullerVice-président et analyste, Constellation Research
Selon Holger Mueller, vice-président et analyste chez Constellation Research, Agile peut aggraver les lacunes en matière de tests, car les gens se concentrent trop sur le délai de déploiement plutôt que sur la qualité.
Les systèmes qui sont presque impossibles à réparer après le déploiement, tels que les satellites ou les logiciels de guidage de missiles, nécessitent des tests à 99,999 %, a-t-il déclaré.
« Les logiciels d’entreprise et les logiciels grand public sont souvent les plus bâclés, avec des MVP [minimum viable products] sont souvent publiés sous la pression du temps », a déclaré Mueller, faisant référence au principe Lean de développer rapidement un produit avec suffisamment de fonctionnalités ainsi que l’attente de futures mises à jour et corrections de bogues.
« Les tests / AQ sont généralement une réflexion après coup et à court de personnel. C’est ce qui empêche la mise en service du code », a-t-il déclaré.
Cela ne signifie pas que les équipes doivent jeter leur méthodologie avec l’eau du bain, a noté Mueller, mais des efforts sont nécessaires pour s’assurer que les systèmes sont testés dans leur ensemble.
« Bien que vous puissiez créer du code de manière incrémentielle, il y a des limites aux tests incrémentiels. À un moment donné, le logiciel doit être testé de manière holistique… le test de la ‘soupe aux noix' », a déclaré Mueller. Les testeurs doivent installer l’application complète, tester que le code fonctionne, puis désinstaller et rechercher les problèmes, par exemple en s’assurant que les informations personnellement identifiables sont supprimées.
« Fondamentalement, l’assurance qualité doit suivre le cycle de vie complet du client dans le produit », a-t-il déclaré.
Ce site utilise des cookies pour améliorer votre expérience. Nous supposerons que cela vous convient, mais vous pouvez vous désinscrire si vous le souhaitez.
J'accepteLire la suite
