« Cette API est simple, pas besoin d’autant de tests ».

Tout le monde est content. Le product owner peut délivrer rapidement, le développeur teste seul et n’a pas besoin d’impliquer l’assurance qualité ou un architecte.

Bien que cette approche fonctionne pour les API localisées, ce n’est pas le cas pour les API plus critiques.

Les API sont les pneus sur la route : le seul lien assurant les processus entre votre entreprise et les autres dans l’écosystème.

Certains d’entre eux peuvent prendre en charge des opérations internes s’exécutant 24 heures sur 24, 7 jours sur 7, et beaucoup prendront directement en charge l’expérience utilisateur.

Toute dégradation vous fait perdre un utilisateur potentiel, d’où la nécessité de tests continus d’API en Quality Engineering pour rester en Quality at Speed.

Suivez la QE Unit pour plus de contenu exclusif de Quality Engineering.

Commencez par le pourquoi, pour qui, puis le quoi

Les API sont généralement considérées comme de simples couches techniques et intermédiaires.

Mais les API sont utilisées partout pour résoudre un problème d’utilisateur final : envoyer des données à une plate-forme d’analyse, récupérer une liste de produits, ou passer une commande.

Les API doivent donc répondre aux besoins de personas particuliers.

La première étape avant le codage consiste à identifier les utilisateurs cibles, leurs besoins et les cas d’utilisation associés. Ce n’est qu’à partir de là que la conception technique peut commencer.

La première vérification de Quality Engineering peut déjà être effectuée à ce stade : garantir les cas d’utilisation, le dictionnaire de données, la norme API et la conception des endpoints.

Construire et valider l’API de valeur minimale

Le développement peut commencer à partir d’utilisateurs bien définis et de cas d’utilisation associés. Mais les résultats doivent apparaître rapidement.

Une implémentation en tunnel de l’API complète créera une distance entre le producteur et le consommateur d’API, augmentant le risque de divergence.

Les stubs d’API les plus simples doivent être créés à ce stade pour obtenir un retour au plus tôt des utilisateurs sur la valeur fournie.

Ces simulations peuvent être réalisées à l’aide d’une description swagger pour une API REST par exemple. Assurez-vous d’intégrer des exigences non fonctionnelles telles que l’authentification.

C’est sur l’intégration de l’API que la plupart des problèmes sont découverts, générant des reprises et des temps d’attente importants entre les équipes.

Livrer l’API avec une intégration bout en bout 

Nous pouvons craindre de publier une API qui n’est pas complètement terminée. Les utilisateurs rencontreront des bugs, soulèveront des problèmes et remettront en question nos compétences.

Une intégration d’API en amont soulève des problèmes tôt pour les résoudre plus rapidement avec des coûts minimes. Vous découvrirez peut-être même que des changements structurants sont nécessaires.

C’est la réalité à laquelle le design doit être confronté.

Affrontez la réalité telle qu’elle est, et non telle qu’elle était ou telle que vous voudriez qu’elle soit.

—Jack Welch

Vous devez donc déployer votre API dans des environnements lui permettant d’interagir directement avec les consommateurs dans l’environnement de production.

Vous verrez et résoudrez rapidement tout un ensemble de problèmes avec une API simple, améliorant la conception et la robustesse de votre produit pour continuer à itérer rapidement.

Assurer une amélioration systématique avec des quality gates

Nous ne construisons pas de murs tant que les fondations d’une maison ne sont pas posées. Alors pourquoi faire cela lors de la création d’API ?

La mise en œuvre de la chaîne de livraison de logiciels pour une itération rapide sur l’API est nécessaire pour adapter en continu les API en cycles courts par la suite.

Ne commencez pas par essayer d’implémenter tous les endpoints et cas d’utilisation des API.

Concentrez-vous sur la mise en œuvre des pipelines CI/CD dans tous les environnements, y compris des quality gates minimales qui vous donnent la confiance nécessaire pour effectuer des changements en continu.

De cette façon, vous disposez de toutes les bases pour effectuer des incréments rapides de vos API afin d’augmenter ses exigences fonctionnelles et non fonctionnelles.

Boucler la boucle de rétroaction en vérifiant l’utilité

Une fois votre API terminée, systématiquement déployée à travers des quality gates en CI/CD, une question demeure : Créons-nous de la valeur ?

Les API sont là en premier lieu pour répondre aux besoins des personas. C’est votre travail de vous assurer qu’ils sont respectés et que vous êtes en mesure de développer votre proposition de valeur.

C’est le domaine de l’observabilité, de l’analyse et de la croissance des API.

La majorité des portails d’API disponibles vous fournissent un ensemble de mesures d’utilisation des API. Votre responsabilité est de les calculer mais de vous en servir.

Ce n’est que le début de votre parcours API car vous devrez itérer pour améliorer votre proposition de valeur. C’est pourquoi vous avez besoin du Quality Engineering.

Contraindre votre pipeline d’API au Quality at Speed

Le Quality Engineering est le paradigme qui contraint le cycle de vie du logiciel à la livraison continue de valeur.

Nous avons couvert les différentes étapes de la construction d’API, de la conception à l’analyse, en passant par les phases d’amélioration continue.

Les éléments mis en place n’étaient pas là pour la beauté ou le perfectionnisme ; ils sont nécessaires pour continuer à itérer avec Quality at Speed ​​à long terme.

Les premières vérifications sont minimes sur la documentation et les stubs, partagés avec les utilisateurs, pour pivoter rapidement si nécessaire sans consommer de ressources de développement.

C’est la puissance du Quality Engineering contraignant progressivement le cycle de vie du logiciel à une qualité et une vitesse maximales avec une complexité minimale.

Les choses simples ne sont pas forcément faciles.