Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>

Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>
Aller à la section
Les bacs à sable de développement peuvent être la clé pour conclure une vente et satisfaire vos clients si vous êtes dans le domaine des API. Mais comment créer un environnement sandbox à faible coût avec la simulation d'API ? Cet article explique comment vous pouvez commencer.
Aller à la section
Aller à la section
Lors de la vente de logiciels, en particulier de produits d'entreprise complexes, nous comprenons qu'une vente ne se termine pas lorsque l'argent arrive à la banque. Le support après-vente est tout aussi important que l'avant-vente pour l'expérience client. En fait, le succès des clients est ce qui génère des revenus et il existe de nombreuses données pour le montrer. Khalid Saleh d'Invesp a créé un fantastique infographique sur ce. Voici quelques points clés à retenir :
Fondamentalement, le succès du client est tout dans les ventes. Cela signifie que vous avez un bon produit. Cela signifie que vous obtenez des prospects gratuits, des cycles de vente plus courts et des taux de conversion plus élevés.
Quel est un moyen clé pour les fournisseurs de plateformes d'augmenter le succès de leurs clients ? Eh bien, pour les plateformes, les outils et les fournisseurs de services, cela signifie qu'ils doivent vraiment se concentrer sur l'intégration. Intégrer les clients sur votre plate-forme signifie que les clients se familiarisent avec vos services afin qu'ils puissent utiliser vos outils comme des pros.
Cela signifie également apprendre à vos utilisateurs à utiliser vos API afin qu'ils puissent créer leurs propres solutions dans les applications. Un bon processus d'intégration doit être transparent et homogène. Les développeurs ne veulent pas mettre leur code « non prouvé » en production. Pour créer efficacement ces intégrations, les développeurs ont besoin d'un environnement de développement sûr pour tester et se familiariser avec votre produit - un environnement sandbox où ils peuvent mettre du code non éprouvé et l'essayer avant qu'il ne passe en production.
Si vous vendez des API, la clé des ventes est un moyen efficace et convaincant de prouver la valeur à vos clients. Les bacs à sable de développement sont idéaux pour cela, mais quelles sont les conditions pour réussir ?
Vos clients ne veulent pas voir de bogues inattendus, de comportements incohérents ou irréalistes. On s'attend à ce que votre environnement sandbox soit soumis aux mêmes tests rigoureux que vos environnements de production et d'assurance qualité.
Les API ne sont pas simples et les développeurs doivent s'adapter rapidement pour se familiariser avec votre produit. Une API et un environnement sandbox bien documentés sont essentiels. Swagger et OpenAPI sont devenus nécessaires en termes de documentation et de définition d'API et de services. Il est tout aussi important de valider que les comportements de ces API adhèrent au schéma tel que défini dans les définitions publiées.
Vos clients sont impatients de commencer, et ne pas avoir accès à leur produit nouvellement acheté est un obstacle important pour le travail de développement et de test de votre client. Toute quantité de temps d'arrêt peut contribuer à une expérience négative.
Dans le monde de la conformité PCI DSS et GDPR, la sécurité peut signifier beaucoup de choses différentes, mais dans le contexte des sandbox API, les données de test plutôt que les données client réelles doivent être utilisées exclusivement. Un bac à sable ne doit jamais avoir accès aux données client, et en général, les applications doivent être suffisamment isolées les unes des autres.
Encore une fois, un bon bac à sable est crucial pour la satisfaction du client. Il y a une raison pour laquelle il y a des Prix DevPortal. Les organisations qui consacrent beaucoup d'efforts à une bonne expérience des produits API sont reconnues.
Les bacs à sable sont utiles mais il y a un hic. Vous ne pouvez pas simplement configurer un tas d'environnements sandbox et vous attendre à ce que cela fonctionne. Ce n'est pas aussi simple. Les API ne font rien par elles-mêmes et nécessitent une orchestration qui s'intègre à plusieurs services internes et externes et systèmes backend et fournit des données.
Configurer un environnement sandbox pour une seule API signifie mettre en place l'ensemble de l'environnement, pas seulement un seul service, et cela peut être difficile.
Il existe quatre défis clés pour créer des sandbox de développement qui sont commodément mappés aux exigences de sandbox ci-dessus - les ABCD des sandbox :
En termes simples, un environnement sandbox doit être stable pour être disponible et offrir une expérience client positive. Les organisations sont déjà aux prises avec leur propre environnement d'AQ. Maintenir et fournir une disponibilité de 100 % est irréaliste et les temps d'arrêt entraînent une mauvaise expérience utilisateur.
Un environnement sandbox doit être une représentation fidèle du système réel. Initialement, les réponses statiques sont bonnes pour les requêtes simples, mais les opérations complexes nécessitent un certain changement d'état et une logique dynamique. Que se passe-t-il lorsqu'un client souhaite effectuer des tests de performance ou de chemin négatif ? Les scénarios de test compliqués peuvent être difficiles à simuler dans un système complexe.
La maintenance d'un environnement de test n'est pas gratuite, pas plus que les dépendances externes. Plus il y a d'utilisateurs, plus ces coûts augmenteront. Comprendre ces coûts et comprendre l'utilisation devient crucial pour déterminer le modèle de tarification ou de rétrofacturation que vous souhaiterez peut-être mettre en œuvre pour vos utilisateurs finaux.
Les données de test dans un environnement de test ressemblent beaucoup à une machine à compter les pièces. Une machine à pièces prend vos pièces et les compte. Il retourne une certaine somme d'argent, mais si plusieurs personnes utilisent la machine en même temps, personne ne sait quel argent leur appartient. La même chose se produit avec les données de test partagées dans des environnements partagés. Une fois les données consommées, elles ne peuvent pas être utilisées pour d'autres tests, à moins que les modifications ne soient annulées d'une manière ou d'une autre, ce qui est complexe et prend du temps.
Ce sont des défis que nous voyons ici qui reflètent ce que nous voyons dans de nombreuses organisations qui cherchent également à améliorer leurs pratiques de test et d'automatisation des tests. Et franchement, la solution est assez similaire.
La virtualisation des services est une méthode pour émuler le comportement de composants spécifiques (virtualiser ces dépendances) dans des applications hétérogènes basées sur des composants, telles que :
C'est une solution puissante en matière de simulation d'API en stabilisant les environnements de test et en permettant un développement agile rapide. La puissance que la virtualisation des services apporte aux tests API et SOA en fait un bon choix pour les serveurs sandbox à faible coût.
La virtualisation offre la possibilité :
Comme vous pouvez le voir, la virtualisation des services coche vraiment les cases.
Dans les engagements que Parasoft a faits, nous avons observé une règle de 80:20. Certains environnements ne nécessitent que des réponses statiques simples aux appels d'API, donc de simples simulations suffisent. Les passerelles API modernes disposent de très bons moyens de stocker ces réponses prédéfinies, par exemple lorsque les simulations sont intégrées. Si c'est vraiment tout ce dont vous avez besoin, la virtualisation des services peut être excessive.
À l'autre extrémité du spectre, l'environnement doit être très proche du réalisme. Les appels d'API nécessitent des données réelles ou des mises à jour réelles des systèmes backend. La question se pose de savoir s'il est rentable de répliquer autant du système réel sous forme de serveurs virtuels. Dans ces cas, il peut être préférable d'utiliser le système réel ou un clone.
Cependant, dans environ 80 % des cas, les exigences se situent quelque part entre ces extrêmes. La virtualisation des services est suffisante pour créer des simulations réalistes pour les scénarios de test et de validation.
L'objectif fondamental d'un bac à sable est de valider les API et les services, généralement des produits tiers, avant de les intégrer à votre système de production. Cependant, il existe une échelle de maturité d'utilisation que nous voyons dans les pratiques de sophistication croissante aidées par les outils et la virtualisation des services.
Parasoft Virtualiser fournit un support pour ces cas d'utilisation ainsi que la surveillance, l'analyse et les rapports requis pour une utilisation plus sophistiquée du sandbox.
Un bac à sable d'API permet une expérience d'intégration fluide pour les produits d'API et de service dans le but d'améliorer la réussite des clients. La virtualisation des services réduit la complexité, le coût et le risque des sandbox d'API. Les bacs à sable ont besoin de services quasi réels et Parasoft Virtualize offre un ensemble de fonctionnalités riche pour reproduire ce comportement de manière rapide et fiable.
Les bacs à sable doivent être rentables et la virtualisation des services offre la solution idéale pour créer un environnement réaliste. Dans cet esprit, Parasoft Virtualize fournit l'évolutivité et la sécurité aux sandbox d'API et propose une variété de modèles de déploiement et une approche modulaire de la virtualisation des services et de la gestion des données.
Au fur et à mesure que votre sophistication dans le développement de sandbox augmente, la virtualisation des services est là pour évoluer avec vous et permettre le prochain niveau de maturité.
API, microservices et tests non fonctionnels améliorés par l'IA