Des métriques importantes pour les tests de bout en bout

Comment mesurez-vous la qualité du logiciel ?

D'après les résultats de plusieurs études de marché, il est clair que les dirigeants de l'industrie s'accordent à dire que la qualité des logiciels est une priorité absolue pour offrir une valeur commerciale aux clients. Le défi est de savoir comment définir ce que cela signifie et comment y parvenir. Cela implique de sélectionner et d'appliquer des métriques appropriées à vos processus de développement et de test de logiciels.

Une façon d'améliorer la qualité des logiciels consiste à ajouter l'automatisation des tests à votre flux de travail de développement. Cela vous permet de décaler les tests plus tôt dans le cycle de vie, de trouver et de corriger les bogues plus tôt avec des tests plus robustes que ceux qui peuvent être effectués manuellement. Les tests de bout en bout impliquent l'application de plusieurs techniques de test pour traiter toutes les facettes de l'application, du code à l'interface utilisateur en passant par les API.

Récemment, nous avons eu l'occasion de discuter avec Diego Lo Giudice, vice-président et analyste principal chez Forrester Research, de ses réflexions sur les mesures de la qualité des logiciels. Ses avis d'experts sont présentés ici et partagés dans la rediffusion du webinaire à la demande, Offrez des expériences supérieures avec des tests de bout en bout et des mesures qui comptent.

Questions et réponses sur les tests de bout en bout

Avec l'invité vedette Diego Lo Giudice, vice-président et analyste principal chez Forrester Research

Q : Dans le webinaire, Offrez des expériences supérieures avec des tests de bout en bout et des mesures qui comptent, vous avez mentionné qu'Agile et DevOps sont les deux faces d'une même médaille. Comment ces pratiques aident-elles les entreprises à appliquer et à intégrer des tests de bout en bout dans leurs Flux de travail CI/CD?

A: Agile et DevOps sont les deux faces d'une même médaille, ce qui signifie que l'un ne peut pas se passer de l'autre.

Pourquoi ?

Car si Agile aide à abattre le mur entre les équipes de développement et l'entreprise et accélère les choses tout en s'alignant sur les exigences, DevOps continue le travail entre les équipes de développement et les opérations d'I&O. Agile + DevOps apporte une agilité commerciale complète de bout en bout.

D'un point de vue organisationnel et pratique, Agile + DevOps doit supporter de déplacer les tests vers la gauche et de les intégrer à ce qui doit être fait dans le sprint. Si ce n'est pas le cas, la livraison/le déploiement continus ne peuvent pas avoir lieu. Les tests effectués tardivement rompront la boucle DevOps continue.

L'utilisation d'outils CI/CD dans Agile + DevOps peut désormais orchestrer un flux de travail où le code est archivé, les tests unitaires sont exécutés, les tests fonctionnels sont exécutés, les tests de performance sont exécutés et à chaque étape, en fonction de la couverture et de la réussite par rapport à la non réussite tests, des décisions automatiques peuvent être prises pour pousser le code vers l'avant ou vers l'arrière à l'équipe pour corriger et tester davantage.

Vous pouvez maintenant voir que nous avons remplacé ce qui était auparavant un long processus de gouvernance manuel par un flux de travail de test automatisé de bout en bout, qui aurait normalement nécessité de nombreux transferts, réunions de publication, etc. pour faire la même chose. Il réduit le temps de cycle de test en automatisant la gouvernance. C'est l'aide que les entreprises obtiennent.

Q : Au début de la présentation, vous avez noté que la qualité des logiciels est une préoccupation de la direction. De quelles manières le service informatique et les cadres peuvent-ils mesurer et quantifier la qualité le plus efficacement ? Quelles sont certaines des mesures les plus importantes pour les tests et la qualité des logiciels ?

A: Dans la recherche de métriques d'application modernes qui comptent vraiment, les métriques de résultats les plus importantes se concentrent sur la valeur commerciale. Cependant, ce sont les indicateurs de qualité qui mènent à la valeur commerciale.

Les métriques de qualité les plus importantes sont toujours les métriques qui mesurent la qualité du logiciel en production, c'est-à-dire les défauts échappés. Personne ne veut que les défauts atteignent la production car ils entraînent une perte de revenus, font la une des journaux avec une mauvaise réputation et ont un impact sur l'expérience utilisateur.

Les métriques habituelles à suivre incluent les défauts de densité de code au niveau des tests unitaires, les défauts échappés du développement aux tests, le temps d'exécution de l'automatisation des tests, le nombre d'échecs des tests de validation et le nombre d'échecs des tests d'automatisation. J'ajouterais à chacun d'eux des "tendances".

La tendance à la vitesse d'exécution des tests automatisés est-elle à la baisse ? Si oui, cela pourrait être une indication de problèmes dans les tests.

Q : Vous avez également parlé d'éviter une « mer de métriques ». Alors comment savoir si j'en ai trop ? Comment savoir lesquels tailler ?

A: C'est là qu'interviennent des cadres tels que les OKR (résultats clés objectifs) ou le GQM (objectif, question, métrique). Si l'on s'en tient au principe selon lequel vous ne pouvez pas gérer ce que vous ne mesurez pas, vous devez décider ce que vous devez gérer.

Quels sont les objectifs de l'équipe (ou les objectifs du produit) ? À partir de là, dérivez les métriques utiles dont vous avez besoin. Il ne sert à rien d'avoir des mesures de performance si la performance n'est pas le principal problème de votre entreprise et n'est donc pas un objectif pour l'organisation.

Si au lieu de cela, le problème est lié à des bogues techniques, vous voudrez peut-être mettre dans la couverture des tests unitaires du tableau de bord et passer les métriques.

Q : Comment des métriques significatives peuvent-elles aider à justifier la valeur de l'automatisation des tests ?

A: Normalement, selon le cadre mentionné ci-dessus, la qualité est une mesure de premier plan contribuant à la valeur commerciale. C'est un point de départ sur lequel s'entendre avec les intervenants. Par conséquent, le remplacement des tests manuels par des tests automatisés accélérera le cycle de livraison, car le temps de cycle d'exécution des tests diminue également.

La durée globale du cycle de développement, même du cash au code, sera positivement impactée par l'automatisation des tests. La qualité augmente également si l'automatisation est correcte, car vous pouvez exécuter les mêmes tests (pensez à la régression) encore et encore. Vous construisez une fois mais exécutez plusieurs fois. Cependant, sachez à quel point l'automatisation peut être difficile, car le code et les systèmes mal codés peuvent être difficiles à tester unitairement. Ou si un test n'a pas besoin d'être répété, pourquoi l'automatiser ? Bien que cela arrive rarement, surtout en Agile.