Catégories
Start-up et applications

Les recommandations de Forrester pour construire une capacité de test continu réussie

Les organisations adoptent les tests continus (CT) par nécessité, car la compétitivité des entreprises exige des cycles de publication plus rapides. En fait, les équipes ne peuvent pas tenir les promesses de DevOps et CI / CD si les tests ne font pas partie des processus continus et du pipeline.

Le vice-président de Forrester Research et analyste principal Diego Lo Giudice et certains de ses collègues, ont récemment publié une rapport qui comprend 12 incontournables incontournables qui couvrent les personnes, les pratiques et la technologie. Ce qui suit est basé sur une récente interview avec Lo Giudice dans laquelle il a partagé des idées qui sont expliquées plus en détail dans le rapport.

Gens
Les tests en continu nécessitent de tester la transformation de l'équipe. Au lieu d'avoir un centre de test centralisé où résident tous les testeurs, d'exécuter et de gérer tous les tests, il y a maintenant une structure en étoile qui comprend un petit centre d'excellence et des testeurs affectés à différentes équipes.

CONTENU CONNEXE: les tests en continu ne sont plus facultatifs

«De la manière traditionnelle, vous aviez une équipe de développement qui écrivait le code et le jetait au centre de test pour faire le test pour trouver les bogues. Ce n'est pas la façon dont nous fonctionnons aujourd'hui parce que les testeurs font partie des équipes Agiles et que l'équipe centrale est une petite équipe qui se concentre sur les meilleures pratiques », a déclaré Lo Giudice. «L'équipe centrale recommande peut-être des outils, recueille les bonnes pratiques des différentes équipes et les formalise et les partage entre les équipes. Il y a donc un passage d'un centre de test centralisé à un centre de test fédéré.

Les testeurs travaillant dans les équipes Agile ont besoin de compétences Agile, y compris la capacité de parler avec les développeurs et les propriétaires de produits de l'entreprise.

"C'est un personnage de test différent", a déclaré Lo Giudice. «Le personnage de test du passé chercherait des bugs et serait heureux qu'il ait trouvé beaucoup de bugs. Maintenant (que les développeurs et les testeurs sont) dans la même équipe, ils ont des objectifs communs. La qualité en fait partie. Le testeur aide à empêcher les bogues de se produire, il s'implique donc plus tôt dans la conception des cas de test, aidant les développeurs à formaliser les tests unitaires, en s'assurant que les développeurs effectuent leurs tests unitaires et qu'ils couvrent autant de code que possible. (Les testeurs) aident les développeurs à créer un code de meilleure qualité depuis le début. »

De plus, pour aligner leurs efforts et produire conjointement un code de meilleure qualité, les développeurs et les testeurs doivent également partager des métriques communes.

«Dans le passé, nous n'avions jamais mesuré si le niveau d'automatisation s'améliorait. Nous n'avons jamais mesuré le temps nécessaire à l'automatisation, car lorsque ces équipes mesurent l'exécution de l'automatisation, elles archivent le code dans un outil CI et l'exécution démarre. Si cela prend soudainement plus de temps, alors quelque chose se passe », a déclaré Lo Giudice. "C'est une indication que la version sera arrêtée, que le code qui a été archivé reviendra à l'équipe pour déterminer quel était le problème."

Les pratiques
Le développement axé sur le comportement (BDD) est l'une des pratiques adoptées par les équipes. Beaucoup d'entre eux utilisent Cucumber, un outil de développement BDD et Gherkin, son analyseur de langage ordinaire, car lorsque les cas de test et les scénarios de test sont écrits en langage ordinaire, tout le monde peut les comprendre.

«Il facilite la collaboration entre le propriétaire du produit de l'entreprise, le testeur et les développeurs. Le propriétaire du produit écrira ce qu'il veut en termes de comportement de l'application avec les cas de test, puis les gens comprendront cette langue. Il peut commencer à réfléchir à la façon d'écrire l'automatisation pour cela et en fonction des outils qui pourraient être générés à partir de la DSL », a déclaré Lo Giudice.

D'autres équipes ont adopté le développement piloté par les tests (TDD), qui diffère du BDD.

«Le TDD est différent car il a un impact sur le cycle de vie. C'est l'écriture des cas de test, puis le code qui passe les cas de test », a déclaré Lo Giudice.

Décaler vers la gauche est une autre pratique populaire qui consiste à tester dès le démarrage d'un nouveau sprint ou d'un nouveau produit. De plus en plus de types de tests ont évolué avec le temps, et cela continuera d'être le cas. À l'heure actuelle, de nombreuses organisations se concentrent sur le déplacement des tests de performances vers la gauche, car il est trop tard pour les terminer.

«Les testeurs font partie de l'équipe et sont impliqués dès le début. Il s'agit de commencer les tests, et les tests unitaires sont un moyen de décaler vers la gauche, mais il s'agit des testeurs travaillant avec les propriétaires de produits et l'équipe définissant immédiatement des cas de test ou des critères d'acceptation des utilisateurs lorsque nous commençons à écrire les user stories en arrière-plan » Lo Giudice.

La virtualisation des services est également essentielle pour déplacer les tests vers la gauche, car les développeurs et les testeurs peuvent simuler des ressources au lieu de déposer un ticket et d'attendre ensuite que les opérations rendent une ressource disponible ou en concurrence avec d'autres pour accéder à une ressource.

Forrester a cessé de couvrir la virtualisation des services séparément car elle n'a pas son propre marché, elle est donc désormais incluse dans le cadre des tests continus.

"Vous n'avez pas besoin des capacités de virtualisation de service complet qu'offraient les outils il y a trois à cinq ans, mais des versions simplifiées qui vous aident à faire un stub très rapidement", a déclaré Lo Giudice.

Les équipes doivent également déplacer les tests à droite comme à gauche.

"Il surveille la vue de la production. Si vous déployez fréquemment vos fonctionnalités en production et que le développeur peut surveiller une partie du code qu'il déploie, il peut éviter que des problèmes de performances ne se produisent », a expliqué Lo Giudice.

Enfin, les tests exploratoires remplacent l'ancienne méthode des tests manuels. Les tests manuels ne disparaissent pas, mais leurs utilisations diminuent.

La technologie
La pile technologique est plus axée sur l'automatisation intelligente que sur l'automatisation de test traditionnelle. L'automatisation intelligente utilise l'IA et l'apprentissage automatique pour aider les développeurs à se concentrer sur ce qui compte, ce qui simplifie et accélère les tests.

«Les outils d'automatisation intelligents tirent parti de l'apprentissage automatique et de l'IA pour générer à partir d'exigences des cas de test plus précis qui optimiseraient la couverture de l'entreprise, de sorte que ce soit au niveau de la conception», a déclaré Lo Giudice. "Mais il y a aussi l'automatisation de l'exécution des tests. Lorsque le code est archivé, dois-je exécuter tous mes tests de régression ou, en fonction du changement, puis-je déterminer ceux qui doivent être exécutés et raccourcir l'exécution? »

Les tests d'API sont également importants car les développeurs écrivent davantage d'applications basées sur l'API et les microservices. Au-delà de cela, il devrait y avoir des tests en couches et un contrôle de version avec tous les actifs stockés de manière centralisée.

«Tous les actifs de test nécessaires pour accélérer l'automatisation finissent par être stockés avec le code, vous stockez donc le code qui est testé, le code que nous utilisons pour écrire les cas de test et tous les autres actifs afin que je puisse version tout cela », A déclaré Lo Giudice. «Si je trouve un bogue et que je dois revoir et mettre à jour l'automatisation des tests, je peux le faire très rapidement, donc dans la pile technologique, l'intégration CI / CD avec la gestion du cycle de vie des applications reste fondamentale.»

Pour les tests de performances avancés, la gestion des données de test est recommandée.

«Vous ne pouvez pas utiliser l'ancienne méthode de génération de données de test lorsque nous effectuons des tests rapides en continu», a déclaré Lo Giudice. "Vous devez avoir quelque chose qui s'intègre dans le sprint ou le cycle de vie et met à jour les données tout au long."

L'approvisionnement en libre-service des environnements de test est également essentiel. Cela se fait dans le cloud, en accélérant et en ralentissant les environnements de test.

Attendez-vous à ce que l'IA et l'apprentissage automatique aient un impact sur le classement des fournisseurs
Au moment d'écrire ces lignes, Forrester est sur le point de publier son Forrester Wave sur Continuous Test Automation. Sur les 26 critères utilisés dans la vague, plus de la moitié des critères (15 ou 16) se concentrent sur la fonctionnalité.

"Une très grande partie de ceux-ci avaient une question sur comment et pourquoi utilisez-vous un ML ou une IA dans cette capacité", a déclaré Lo Giudice. "La réponse a été que les fournisseurs sont enfin passés à cette étape. Cette année, vous voyez déjà l'utilisation de l'IA dans les outils et la façon dont ils l'utilisent. Ils l'utilisent pour rendre les choses plus intelligentes. "

Comment, exactement, sera couvert dans le numéro d'août de SD Times, qui comprendra une plongée approfondie sur l'apprentissage automatique et l'IA dans le contexte de la tomodensitométrie.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *