Qualité et rapidité : Notre voyage de sept ans vers une disponibilité de 99,999%.

Face à un écosystème logiciel extrêmement dynamique, le monde des tests de logiciels est resté stagnant. Alors que les produits deviennent de plus en plus complexes, les équipes de développement sont confrontées à un dilemme : la demande de livraison rapide est en guerre avec la nécessité d'assurer la qualité des produits.

Comment vos équipes peuvent-elles adopter une approche plus rigoureuse des tests de logiciels sans compromettre la rapidité et la croissance du produit ?

L'équipe SDET (software developer in test) en pleine croissance au sein de Vonage R&D a défini une solution. Nous l'appelons Qualocityl'approche de test en couches qui tient compte à la fois de la qualité et de la rapidité.

Où cela a-t-il commencé ?

La plupart des entreprises concentrent leurs efforts de test sur deux domaines principaux : les tests fonctionnels, qui émulent l'utilisation de base d'une application, et la charge non fonctionnelle du système. Les groupes de test mesurent généralement la qualité du produit en fonction de la couverture des exigences et du nombre de bogues trouvés, échappés, rouverts - ce qui revient à glorifier les bogues au lieu de les prévenir.

Mais le monde a changé. Nous sommes confrontés à une augmentation de la fragmentation dans des domaines tels que les systèmes d'exploitation, les appareils et la latence du réseau. Nous sommes entrés de plain-pied dans l'ère des applications, une ère dynamique et hautement compétitive. Nous voyons des API et des bibliothèques communes qui permettent maintenant un développement plus rapide, ainsi que divers services en nuage qui fournissent au développeur un environnement qui ne dépend pas des systèmes d'exploitation, de la sécurité, de la redondance ou même de la mise à l'échelle. Tout cela pour dire que les entreprises qui ont des cycles de publication en cascade d'un mois ne peuvent plus rivaliser avec la demande de fonctionnalités et d'innovation.
Les entreprises qui ne peuvent pas livrer rapidement seront en retard sur le marché.

Les couches

Et pourtant, malgré le besoin de rapidité, il y a un risque à se précipiter vers la production avec seulement quelques méthodes de tests de qualité dépassées à notre actif. En effet, si nous continuons à faire les choses comme nous le faisons depuis des années, nous finirons par nous perdre dans un cercle de problèmes de qualité et d'escalades en production, ce qui n'est agréable pour personne. Il nous reste donc ces deux facteurs critiques : La qualité doit s'améliorer, mais nous devons être en mesure d'apporter des changements à la production de manière cohérente et consciente.

Il y a sept ans, nous avons commencé à rechercher d'autres méthodes pour compléter les deux couches initiales, les tests fonctionnels et les tests de charge. Au cours de cette période, nous avons progressivement développé l'approche de la qualité et de la rapidité qui nous a permis d'atteindre une disponibilité du système de 99,999 %, connue familièrement sous le nom de "five nines" (cinq neuf).

Grâce à la recherche et à l'expérimentation, nous avons créé le processus présenté ici, qui se compose de trois couches multidimensionnelles :

Discipline de codage

Il peut sembler évident qu'une discipline de code appropriée est au cœur de la qualité des logiciels. Les tests commencent ici, en suivant systématiquement les normes et les procédures.

• Les revues de code doivent être effectuées par des pairs, à chaque fois, et le code automatisé doit être traité de la même manière.

• Les tests unitaires à large couverture nous permettent de tester facilement et en toute confiance que nous n'avons pas cassé la base de code.

• Outils d'analyse statique découvrent les bogues statiques et les failles de sécurité. Il en existe un grand nombre sur le marché, qui offrent différentes spécifications pour différents besoins.

• Les tests fonctionnels doivent se concentrer sur les simulacres. Testez au niveau de l'API et entourez votre automatisation de simulacres qui testent exactement ce que vous avez demandé. Évitez les tests automatisés de bout en bout, car vous testez votre code et non le produit de bout en bout. En conséquence, la couverture augmentera et les tests deviendront plus stables.

Veiller à ce que les tests fonctionnels s'exécutent partoutLes tests fonctionnels ne sont pas seulement utilisés dans les environnements de développement et d'assurance qualité, mais aussi dans la production. S'ils sont construits correctement, ils constitueront un excellent outil de surveillance et n'échoueront pas souvent. Nous savons tous à quel point il est frustrant d'être alerté à 2 heures du matin pour une fausse alerte.

Tests non fonctionnels

Pour cela, vous devez sortir de votre zone de confort et voir plus grand. Vous devez connaître l'utilisation moyenne de votre produit et la pousser à son paroxysme.

Prenons l'exemple d'une API qui reçoit en moyenne 1 000 appels par seconde, avec un pic de 1 200 appels à 10 heures et à 15 heures, et un creux de 800 appels à 22 heures.

• Pour test de charge vous voudrez effectuer 1000 appels par seconde pendant quelques heures.

• En tests de stress vous continuerez à ajouter des appels jusqu'à ce que vous rencontriez un échec. C'est votre point de stress. Décidez de ce qu'il faut faire et réessayez.

• Tests de stabilité Account pour une utilisation moyenne dans le temps. Pendant une période prolongée, effectuez 1 200 appels par seconde aux heures de pointe, 800 aux heures creuses et 1 000 le reste du temps. Cela vous permettra de vous assurer que vous pouvez rester stable dans le cadre de votre charge moyenne.

Si votre logiciel comprend des fonctions de mise à l'échelle automatiqueassurez des tests sur des instances supplémentaires une fois que la limite est atteinte. Tester la redondance pour les régions et les zones, car n'oubliez pas que vos services en nuage services tomberont en panne de temps en temps. Sécurité dans ce contexte fait référence aux tests de pénétration des applications, aux tests OSS (bibliothèques et API externes) et aux outils d'analyse statique. Les revues de code sont cruciales à ce stade et devraient faire partie du cycle de vie du développement logiciel.

Discipline DevOps

Laisser tremper tremper. Ne vous faites pas d'illusions et ne croyez pas que vous êtes à l'abri de tous les cas de figure une fois que tout ce qui a été mentionné ci-dessus fonctionne bien. Ce n'est pas le cas. Il y a d'autres appareils, d'autres fonctions de compte et d'autres configurations à prendre en compte. Prenez le temps de vous assurer que les tests sont réellement exacts.

N'oubliez pas de procéder à des diffusions graduelles

• Encourager l'élimination des bogues par l'équipe de développement avant de passer à la phase d'essai

• Ensuite, essayez-le sur l'écran alpha (interne) avant de le partager avec les utilisateurs bêta (externes). Ces groupes bêta sélectionnés doivent représenter la majorité de votre base de production, en ce qui concerne les instances et les appareils.

• Une fois que la version est largement disponible, activer un bleu-vert qui alterne les serveurs de production et les serveurs de transit, et vous permet de revenir rapidement à une version antérieure si nécessaire.

• Surveillez scrupuleusement l'état de votre système, mettez en place des alertes et analysez les données de test.

• Discutez avec vos équipes chargées de la satisfaction des clients et explorez d'autres sources de retour d'information, comme les boutiques d'applications, les médias sociaux et les plates-formes communautaires.

Si vous avez suivi toutes ces étapes, nous pouvons vous garantir que vous êtes maintenant prêt pour l'AG.

En conclusion

Ce que nous avons présenté ci-dessus est une approche pour une stratégie de qualité qui, selon nous, est proche de la perfection, tout en restant réalisable. Bien que nous ne l'ayons pas entièrement mise en œuvre pour tous nos services, en particulier pour les codes hérités et les logiciels hérités, nous pouvons affirmer en toute confiance que chaque couche a prouvé qu'elle faisait une différence significative. L'équipe de SDET et d'ingénieurs DevOps de Vonage s'en porte garante. C'est une entreprise gigantesque, mais nous vous encourageons à ajouter progressivement une couche à la fois, jusqu'à ce que vous atteigniez la couverture qui vous convient.

Nous espérons que cela vous a aidé et que cette recherche vous rapproche encore plus de la disponibilité que vous souhaitez.