Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

Révolutionnez le développement agile en ajoutant l'IA aux tests d'API

Révolutionnez le développement agile en ajoutant l'IA aux tests d'API Temps de lecture : 11 minutes
Dans la dernière version de Parasoft SOAtest, nous avons apporté l'intelligence artificielle à nos clients pour les aider à démarrer et à évoluer avec une stratégie de test API efficace.

Parasoft a toujours eu une mission principale - simplifier l'automatisation des tests - et cela est évident dans toute la suite d'outils Parasoft, de l'analyse statique à la simulation d'environnement avec la virtualisation des services. Mais l'idée de simple n'a jamais été aussi présente que dans la dernière version de SOAtest. Dans cette version, nous avons supprimé les complexités associées aux tests d'API en créant une solution simple et élégante pour aider les organisations non seulement à démarrer avec les tests d'API, mais également à jeter les bases d'une stratégie de test d'API évolutive et maintenable qui prend en charge le développement agile.

Rendre les tests d'API «faciles»

Notre PDG Elizabeth Kolawa avait une directive simple alors que nous discutions du développement de cette nouvelle idée d'automatisation des tests. Elle a dit, "rendre facile." Cette simple déclaration s'est transformée en une analyse approfondie des défis actuels associés aux tests à l'ère moderne et a conduit à une réalisation clé:

Les outils de l'industrie des tests logiciels ne sont pas axés sur la simplicité pour le monde agile.

Agile est avant tout une activité axée sur le développement. Dans ses termes les plus élémentaires, agile est une méthodologie de développement logiciel dans laquelle les activités SDLC typiques qui s'étalent traditionnellement sur la durée d'un projet sont décomposées en parties beaucoup plus petites appelées sprints. En règle générale, un sprint dure de 2 à 3 semaines et dans un sprint, les activités de développement sont axées sur les nouvelles fonctionnalités et améliorations.

Un sprint ressemble à ceci:

Un sprint commence par la phase de conception et de création, où la nouvelle fonctionnalité est divisée en user stories, portée, puis le développement commence immédiatement à créer quelque chose. À la fin du sprint, il peut y avoir ou non des activités de publication, mais quoi qu'il en soit, des commentaires sont obtenus, puis un autre sprint commence et le processus se répète encore et encore.

Agile permet aux organisations d'allumer un sou, car les commentaires recueillis au cours de chaque sprint peuvent être appliqués au sprint suivant et aident à guider, façonner et cibler le projet. Cela fonctionne très bien pour le développement, mais si vous regardez la partie test du sprint, cela commence à devenir compliqué.

Test n'a pas accès pour tester les nouvelles fonctionnalités et améliorations avant le début du Sprint, et pour des raisons logiques. L'équipe de test doit attendre que l'équipe de développement ait développé toutes les fonctionnalités, donc le test est toujours un peu en retard sur le développement dès le début.

Pourquoi le test ne peut pas suivre le rythme du développement

Ce problème ne fait que s'intensifier au fur et à mesure que le sprint se poursuit et que les testeurs s'appuient sur les tests d'interface utilisateur (interagissant manuellement avec l'interface utilisateur). Le test d'interface utilisateur est la pratique de test la plus courante car il est facile à utiliser - il est facile d'associer des actions dans l'interface utilisateur à la user story, il est facile à faire évoluer sur un grand nombre de testeurs, et en raison de fonctionnalité d'enregistrement et de lecture, il est facile de faire un premier tour d'automatisation.

Mais les tests d'interface utilisateur posent de nombreux problèmes:

  • Il y a des coûts cachés qui découlent de l'inefficacité des tests d'interface utilisateur. Le défi le plus fondamental avec les tests d'interface utilisateur est le temps nécessaire au développement pour corriger les défauts lorsqu'il est soumis à un test d'interface utilisateur en tant que reproduction. En règle générale, lorsqu'un testeur commence le processus de détection des défauts, il commence par des tests exploratoires (recherchant méthodiquement l'application pour un comportement inattendu). Lorsqu'ils trouvent un défaut, ils doivent le reproduire pour le développement, ce qui implique de rédiger des «étapes à reproduire». Lorsque le développement reçoit ces instructions, il doit trouver la version de l'application utilisée par le test, la mettre debout et suivre les étapes d'exercice de l'interface utilisateur. Si le défaut se reproduit, ils doivent alors associer ce défaut au code sous-jacent pour déterminer la cause première. Le développement commence à travailler sur un correctif qui les oblige à déchirer l'application, à corriger le défaut, puis à reconstruire l'application avant que le contrôle qualité puisse recommencer les tests. Cela retarde davantage le processus de livraison du logiciel et ralentit l'ensemble du pipeline.
  • Les tests d'interface utilisateur ne testent pas de manière exhaustive une application. Les tests au niveau de l'interface utilisateur valide le flux de processus d'une application de bout en bout, mais ne testent pas nécessairement toute l'étendue des composants internes du système. Souvent, lorsque de nouvelles fonctionnalités sont introduites dans une application, cela nécessite de modifier ou de mettre à jour les interfaces existantes. Certains de ces composants peuvent ne pas être accessibles lors de l'utilisation de la nouvelle fonctionnalité, mais présentent des risques importants pour l'organisation s'ils ne sont pas testés.
  • Test n'a pas accès au code, il est donc difficile pour eux de mapper les actions qu'ils exécutent dans l'interface utilisateur à la source sous-jacente. Par conséquent, les tests générés ne fournissent pas une couverture API complète. Très souvent, des choses sont manquées. Lorsque vient le temps d'exécuter le cycle de régression complet, des défauts critiques peuvent être découverts. Souvent, cette détection de défaut de cycle tardif entraîne des retards de libération importants et augmente le coût total des tests.
  • Il est difficile de maintenir l'automatisation de l'interface utilisateur. L'une des principales raisons pour lesquelles les tests ont du mal à suivre le rythme du développement est que trop de temps est passé à gérer les tests d'interface utilisateur cassés. En fait, jusqu'à 80% du temps de test est passé soit à exécuter manuellement les tests d'interface utilisateur, soit à réparer les tests d'interface utilisateur automatisés qui ont échoué à la suite d'un changement d'application.

Chacun des facteurs ci-dessus peut entraîner des retards importants dans un sprint, mais lorsque vous tenez compte du fonctionnement d'un cycle de projet traditionnel, il s'agit d'une série de ces sprints suivie d'un cycle de durcissement ou de régression.

À chaque étape du processus, les tests ont du mal à suivre le rythme du développement - mais en raison des techniques de test traditionnellement utilisées, ils ne peuvent jamais obtenir les tests complets et complets qu'ils souhaitent.

Cela ressemble à ceci:

En règle générale, ils seront en mesure de valider les nouvelles fonctionnalités et capacités, mais ne parviennent pas à couvrir complètement les tests.

C'est frustrant pour beaucoup de testeurs, mais ce n'est pas de leur faute - c'est juste la nature de la bête étant donné les capacités qui existent sur le marché de l'outillage. La partie dangereuse est que sans ces pratiques de qualité, les défauts s'infiltrent dans la production et érodent les avantages perçus de l'agilité.

Qu'en est-il des tests d'API? Peut-il sauver l'agilité?

Tout le monde s'accorde à dire que les tests d'API peuvent identifier plus précisément la cause première des défauts que les tests d'interface utilisateur, car les tests d'API sont plus proches du code, plus faciles à automatiser et plus résistants aux changements d'application. De plus, les tests API offrent une meilleure forme de reproduction des défauts et de communication entre le développement et le test car l'artefact de test représente la convergence de ces deux domaines. (Dans un blog récent, j'ai exploré les tests d'API, ce qu'ils sont et comment créer une stratégie de test d'API complète. Vous pouvez lisez-le pour obtenir plus d'informations sur cette pratique de test extrêmement efficace.)

Les tests au niveau de la couche API sont une excellente pratique pour le développement agile, en particulier parce qu'ils permettent aux testeurs de valider les fonctionnalités compte tenu de la chronologie compressée, et les tests d'API sont hautement réutilisables.

De plus, les tests d'API présentent les avantages suivants qui simplifient et prennent en charge les tests agiles:

Réduction du temps de résolution des défauts par rapport aux tests d'interface utilisateur

Si un test d'API échoue, vous pouvez être très sûr de savoir à peu près où chercher dans le code. Les développeurs adorent obtenir des tests d'API de la part des testeurs, car les développeurs peuvent les exécuter directement sur leur application sans avoir à connecter l'ensemble de l'environnement. Et ils peuvent les réexécuter en continu au fur et à mesure qu'ils commencent à corriger le défaut.

Le délai de résolution des défauts plus court signifie qu'en général, le développement peut résoudre un bogue plus rapidement lorsqu'il est fourni un test d'API par rapport à un test d'interface utilisateur. Lorsque l'on considère les délais impliqués dans l'agilité, c'est exactement ce dont nous avons besoin. Une fois qu'un défaut est découvert, un test d'API est fourni au développement, qu'il peut utiliser pour trouver, corriger et valider le défaut, le tout sans avoir à reconstruire l'ensemble de l'application, ce qui économise énormément de temps. C'est exactement le type de vitesse dont nous avons besoin pour être agile

Les tests d'API sont «prêts pour l'automatisation»

Les API représentent la communication invisible qui a lieu dans les coulisses d'une application. La nature invisible de la communication facilite le processus d'automatisation. Il y a beaucoup moins de complexité impliquée dans l'obtention d'une application au point où vous pouvez commencer à interagir avec elle au niveau de l'API que ce qui serait nécessaire pour mettre en place une application dans son intégralité afin que vous puissiez fonctionner au niveau de l'interface utilisateur.

En conséquence, les tests d'API peuvent facilement être exécutés dans l'automatisation à des étapes antérieures du SDLC. La plupart de mes clients les exécutent en même temps qu'ils exécutent leurs tests unitaires en fonction de l'enregistrement du code. Ces tests d'API peuvent également être associés au système de suivi des bogues de manière beaucoup plus simple, de sorte que lorsque les défauts sont résolus, les tests d'API qui les accompagnent peuvent facilement être transférés entre le développement et le test. Cela réduit considérablement le processus global de transfert car au lieu de classer le défaut, de fournir les étapes à reproduire, puis d'attendre une nouvelle version du développement, les testeurs peuvent recevoir des notifications du système de suivi des bogues indiquant qu'un défaut a été résolu et voir le test automatisé. cas qui valident la résolution. Ces tests d'API peuvent facilement être intégrés dans une suite de régression et réutilisés encore et encore.

Les tests d'API sont plus résistants au changement que les tests d'interface utilisateur

Dans le cadre de notre recherche, nous avons constaté que 80% du temps de développement était consacré à la gestion et à la mise à jour des tests d'interface utilisateur qui s'étaient interrompus à la suite d'un changement. Le changement est une grande perte de temps en matière d'agilité, mais en raison de l'augmentation des enregistrements de code et des délais raccourcis introduits avec l'agilité, le changement est constant.

Si une organisation s'appuie exclusivement sur les tests d'interface utilisateur, le changement d'application peut être dévastateur car de nombreux cas de test qui ont été conçus pour valider les fonctionnalités critiques cessent tout simplement de fonctionner. L'un des principaux principes de l'agilité est la capacité à démarrer en un rien de temps, ce qui signifie que les interfaces utilisateur et les fonctionnalités changent constamment et que le fardeau de la prise en charge et de la maintenance de ces tests peut devenir écrasant pour les équipes de test. D'un autre côté, les tests d'API ne voient même pas l'interface utilisateur. Les API ont également des capacités de contrôle de version spécifiques intégrées, qui permettent aux testeurs de maintenir la stabilité pendant que l'application subit des modifications. En outre, les API sont définies avec le contrat de service qui peut être utilisé pour mettre à jour les cas de test lorsque l'application subit ces modifications.

Les tests d'API peuvent économiser l'agilité en donnant à une organisation la possibilité de tester facilement une application aux premiers stades de développement ainsi que de fournir un mécanisme de communication efficace entre le développement et le test qui est très résistant au changement. Les organisations qui adoptent les tests d'API comme élément fondamental de leur stratégie de test peuvent tirer parti de l'agilité qu'elles fournissent pour vraiment devancer les défis des tests.

Alors, pourquoi les organisations ne testent-elles pas l'API?

Même avec tous les avantages qui découlent des tests d'API, l'industrie se concentre toujours sur les tests d'interface utilisateur:

Nous pensons que c'est parce que les testeurs ne savent pas comment tester l'API et/ou ne savent pas comment leur application utilise les API. Il n'est pas immédiatement évident de savoir par où commencer pour tester l'API d'une application, et comprendre comment assembler toutes les "pièces du puzzle" de manière significative nécessite une connaissance du domaine de l'application.

Étant donné que les organisations ont toujours tendance à tirer parti d'une pratique de test centralisée, les testeurs ont besoin d'une connaissance approfondie de toutes les différentes interfaces d'application et de savoir comment les assembler correctement. Ce n'est pas une tâche insignifiante.

Les tests API sont toujours considérés comme un no man's land. Dans une enquête récente, nous avons interrogé une série de développeurs et de testeurs responsables des tests d'API dans leur organisation.

  • 70% des testeurs ont déclaré que développement est responsable des tests API.
    • Pourquoi ? "L'équipe de développement a créé les API et au fur et à mesure de leur création, elle aurait dû également créer des tests d'API pour valider qu'elles fonctionnent comme décrit"
  • 80% des développeurs ont déclaré que tester est responsable des tests API
    • Pourquoi ? «Nous avons créé ces API pour qu'elles soient tournées vers l'extérieur et les avons documentées avec un contrat de service. L'équipe de test doit entrer et valider que les API fonctionnent comme décrit "

Comme vous pouvez le voir, il existe une certaine confusion quant à savoir qui est en fin de compte responsable des tests d'API. Nous avons cherché à résoudre ce problème. Nous pensons que les tests d'API relèvent à la fois de la responsabilité des développeurs et des testeurs, sous différentes formes, mais c'est cette déconnexion qui conduit à une faible couverture des tests d'API.

Les tests au niveau de l'API nécessitent des compétences et des outils spécialisés afin d'obtenir une couverture de test complète. Ce n'est pas intuitif. Il existe des outils sur le marché qui tentent d'aider les organisations à élaborer une stratégie de test d'API, mais la grande majorité d'entre eux nécessitent un haut niveau d'expertise technique pour créer des tests d'API complets. De plus, les testeurs doivent encore comprendre le fonctionnement des API, ce qui nécessite une connaissance du domaine. En conséquence, les organisations ont tendance à faire le strict minimum pour les tests d'API, ce qui est le contraire de ce dont nous avons besoin pour l'agilité.

Intelligence artificielle pour l'automatisation des tests

Pourquoi l'IA, pourquoi maintenant? La seule façon de résoudre ce problème de l'industrie est de créer des outils qui simplifient les tests d'API. Nous travaillons dans le domaine de l'automatisation des tests logiciels depuis trois décennies et, au cours de cette période, nous avons amassé de nombreuses données pour nous aider à comprendre ce qui est nécessaire pour créer un test d'API complet. Aujourd'hui, l'intelligence artificielle nous aide à tirer parti de cette expertise pour simplifier le défi des tests d'API pour les testeurs de l'industrie.

Le générateur de test Smart API

Le nouveau générateur de test d'API intelligent Parasoft SOAtest a été conçu à partir de zéro pour aider à réduire la complexité des tests d'API. Le Smart API Test Generator est un plugin pour Chrome qui utilise l'intelligence artificielle pour convertir les tests d'interface utilisateur manuels en tests API automatisés, réduisant les compétences techniques requises pour adopter les tests API et aidant les organisations à élaborer une stratégie de test API complète évolutive.

Alors, comment ça marche?

Convertit l'activité de l'interface utilisateur en tests API automatisés

Le générateur intelligent surveille le trafic en arrière-plan pendant que vous exécutez des tests manuels, analyse ce trafic et utilise l'intelligence artificielle pour créer automatiquement un ensemble significatif de scénarios de test d'API. Lors de la création de ces tests d'API, le Smart Generator identifie d'abord les appels d'API, puis découvre des modèles et analyse les relations entre eux, afin de pouvoir générer des scénarios de test d'API complets, pas seulement une série de tests d'API.

Réduit la courbe d'apprentissage aux tests d'API

Le générateur intelligent fournit aux testeurs un endroit facile pour commencer à créer des tests d'API, afin qu'ils n'aient pas à toucher aux activités difficiles associées à la création manuelle de tests d'API, c'est-à-dire trouver la bonne définition de service, comprendre la charge utile des données ou exécuter un test sur et encore une fois pour comprendre les relations entre les demandes et les réponses afin que vous puissiez commencer à créer des assertions.

Au lieu de cela, le générateur intelligent fait tout ce gros travail automatiquement, en fonction de l'activité qu'il observe pendant que le testeur utilise l'interface utilisateur. Cela aide les utilisateurs novices à mieux comprendre les tests d'API en général, car ils peuvent mapper les activités qu'ils ont effectuées dans l'interface utilisateur aux tests d'API qui ont été créés et acquérir une meilleure compréhension de la relation entre l'interface utilisateur et les appels d'API sous-jacents, ce qui aide stimuler les futurs efforts de test des API.

Aide les utilisateurs à élaborer des stratégies de test d'API complètes

Bien que le test d'API soit l'une des pratiques de test logiciel les plus efficaces, de nombreuses organisations n'ont pas réussi à adopter cette pratique car elle nécessite des compétences et des outils spécialisés. Pour aider les organisations à adopter une pratique complète de test d'API, Parasoft SOAtest fournit des outils visuels faciles à adopter, permettant aux débutants des tests d'API de commencer à créer de puissants scénarios d'API en moins de temps qu'avec d'autres outils. Le générateur intelligent comble le fossé, amenant les utilisateurs novices dans le monde des tests d'API

Qu'est-ce que cela signifie?

Le développement Agile aide les organisations à mettre sur le marché des logiciels de qualité plus rapidement, mais sans la technologie nécessaire pour aider les organisations à tester pleinement leurs applications à grande vitesse, les risques associés à une livraison accélérée érodent les avantages potentiels d'Agile. Il est maintenant temps pour les organisations de devenir intelligentes en matière de tests d'API.

Une solide stratégie de test d'API permettra aux organisations de tirer le meilleur parti de leurs transformations agiles. Pour que cela devienne réalité, les outils de test devraient fonctionner pour nous, et la dernière version de Parasoft SOAtest le fait. Le nouveau Smart API Test Generator de SOAtest réduit la complexité associée aux tests d'API, abaisse ses barrières d'adoption et aide les organisations à mettre en place une stratégie de test gérable, maintenable et évolutive. Essayez-le par vous-même!

Écrit par

Chris Colosimo

Chef de produit chez Parasoft, Chris élabore des stratégies de développement de produits pour les solutions de test fonctionnel de Parasoft. Son expertise en accélération SDLC grâce à l'automatisation l'a conduit à des déploiements majeurs en entreprise, tels que Capital One et CareFirst.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.