Comment améliorer CI / CD avec des tests de décalage à gauche

Auparavant, le test des applications était une activité techniquement exigeante et chronophage programmée des jours ou des semaines avant la sortie d'une application. Les équipes de développement ont eu la latitude de coder jusqu'à la onzième heure, et les testeurs, qui faisaient une grande partie de leur travail manuellement, n'avaient guère d'autre choix que de se contenter du peu de temps qui leur était imparti. Le résultat a été que de nombreuses applications ont subi des tests de qualité inférieure et que les équipes technologiques ont été obligées de répondre aux problèmes de production et aux défauts escaladés par les utilisateurs finaux et les systèmes de surveillance des applications.

Les pratiques d'intégration continue Devops, les cadres de tests unitaires et les pratiques d'automatisation des tests ont bouleversé ce paradigme. Au lieu d'effectuer une assurance qualité à la fin du processus de développement, de nombreuses pratiques de test commencent maintenant et s'exécutent entièrement pendant le codage, l'intégration et le déploiement. Les équipes Devops et Agile automatisent les scripts de test, et les pipelines CI / CD appellent à exécuter les tests pendant leurs phases d'intégration ou de livraison de code. Le résultat net est que les développeurs sont alertés lorsque leurs modifications de code interrompent la génération et peuvent prendre des mesures immédiates pour résoudre le problème signalé.

L'automatisation des tests et l'intégration de scripts de test dans les pipelines CI / CD est connue sous le nom de test de décalage à gauche. Cela implique que davantage de pratiques d'assurance qualité peuvent être mises en œuvre dans la phase de développement pour détecter les problèmes plus tôt dans le calendrier de publication. L'automatisation des tests est l'une des priorités de pré-déploiement pour les équipes agiles et devops qui souhaitent augmenter les fréquences de déploiement.

Lors de l'introduction de nouvelles fonctionnalités, les scripts de test construits valident les nouvelles fonctionnalités. Ces tests peuvent ensuite être automatisés et inclus dans les étapes de génération ou de déploiement. Au lieu de demander aux ingénieurs d'assurance qualité d'exécuter des tests de régression à la fin d'un processus de publication, vous pouvez exécuter et valider nombre de ces tests dans le cadre du développement. Ces tests se déplacent à gauche de la fin du processus de publication aux phases de développement et de codage antérieures.

Les tests Shift-Left permettent aux équipes agiles de s'engager en faveur de la qualité

Les tests Shift-Left n'augmentent pas seulement l'efficacité et améliorent la qualité, ils créent également un changement de culture significatif dans le processus de développement agile.

Certaines équipes de développement perçoivent l'assurance qualité et les tests comme un obstacle à la livraison de leur code en production. Après tout le travail acharné pour satisfaire les propriétaires de produits agiles et compléter le code, les coéquipiers de l'assurance qualité identifient une liste de bogues nécessitant une correction. Si le contrôle qualité trouve beaucoup de bogues, cela peut avoir un impact sur la chronologie de la publication pour les corriger. Pire encore, lorsque des sections importantes du code doivent être repensées car des failles exposent des problèmes de logique, de sécurité ou de performances. Dans ce scénario, les développeurs et les ingénieurs QA peuvent faire partie de la même équipe agile mais n'agissent pas en équipe.

Les tests Shift-Left permettent aux équipes agiles de transférer les responsabilités de qualité à l'ensemble de l'équipe de développeurs et de testeurs. Lorsque les tests s'exécutent dans le cadre du pipeline CI / CD, ils offrent une meilleure opportunité aux développeurs de résoudre les problèmes de qualité au moment où ils travaillent sur le code pertinent. Le pipeline CI / CD alerte le développeur de l'échec de la génération, et la plupart des équipes de développement auto-organisées doivent résoudre ces problèmes immédiatement.

Les tests Shift-Left offrent également aux développeurs et aux ingénieurs QA la possibilité d'automatiser davantage les tests. Une bonne pratique consiste pour les équipes à décider qui implémente l'automatisation en fonction des types de tests requis pour la fonctionnalité développée. Par exemple, les développeurs sont souvent responsables de l'automatisation des tests unitaires et d'API, mais les ingénieurs d'automatisation QA développent souvent des tests d'expérience utilisateur de bout en bout et des tests de transaction qui simulent des appels d'API en plusieurs étapes à plusieurs services.

Quand appliquer le test de décalage gauche

Les tests Shift-left fonctionnent mieux pour les tests atomiques plus unitaires qui ont des temps d'exécution courts. Il est essentiel que les tests soient automatisés dans le pipeline CI / CD, et qui s'exécutent chaque fois que les développeurs déclenchent une compilation, s'exécutent rapidement et ne ralentissent pas les processus de construction.

Les tests plus complexes et chronophages tels que les tests d'expérience utilisateur de bout en bout, les tests de transaction, l'analyse de code statique et les tests de sécurité s'exécutent souvent mieux en dehors des pipelines CI / CD et selon des horaires quotidiens ou plus fréquents. Ces tests fournissent toujours un retour d'information précoce aux développeurs sur les problèmes de qualité, mais ils sont automatisés en dehors de CI / CD pour éviter le ralentissement ou le goulot d'étranglement des builds.

Thomas J. Sweet, vice-président des services informatiques chez GM Financial, a partagé avec moi ses idées personnelles sur les limites des stratégies de test de décalage-gauche. Il suggère: «Le décalage vers la gauche est toujours une stratégie, sauf lorsque vous effectuez des tests d'intégration sur des livraisons de fournisseurs tiers, car vous n'avez souvent pas accès à leur code source. Même lorsque vous disposez d'applications internes avec des architectures monolithiques héritées, vous pouvez commencer par appliquer des politiques d'enregistrement de base qui nécessitent une révision du code et une analyse de sécurité. L'enregistrement doit être rejeté si l'analyse comporte des avertissements et des échecs essentiels. »

Une solution potentielle aux tests en aval avec les partenaires d'intégration consiste à implémenter la virtualisation des services. Cette technique permet aux équipes de développement de simuler la réponse d'un système en aval à différentes entrées. Cela fonctionne bien lorsque les systèmes en aval sont bien définis. Les outils de Micro Focus, Tricentis et autres permettent cette fonctionnalité.

Rob Pociluk, un responsable de l'assurance qualité hautement expérimenté, est un fervent partisan des tests de décalage à gauche dans le développement agile. «Être prêt et capable de tester de petites sections de code permet à l'assurance qualité d'être flexible et dans la boucle pendant la progression d'un sprint. Les équipes doivent toujours se garder d'utiliser trop de décalage vers la gauche, car vous risquez de perdre l'objectif du code lui-même. "

Ainsi, même lorsque les équipes adoptent pleinement les tests de décalage gauche, il existe de bonnes raisons de planifier une fenêtre de test sur une version complète de code destinée à la publication. Il garantit que tous les tests automatisés sont effectués sur la version finale, mais permet également de planifier des tests supplémentaires qui nécessitent un système pleinement opérationnel.

L'un de ces tests est l'UAT (tests d'acceptation par les utilisateurs), où des utilisateurs finaux sélectionnés et des experts en la matière valident et fournissent des commentaires. Certains UAT peuvent être effectués pendant le développement, mais il peut ne pas être facile d'amener les gens à effectuer ces tests fréquemment ou lorsque la fonctionnalité n'est pas entièrement prête.

Conditions préalables aux stratégies de test de décalage vers la gauche

Le test Shift-Left est une pratique de développement croissante, mais il a ses prérequis et son investissement initial. Certaines capacités et pratiques essentielles sont requises.

  • Une capacité de test et des environnements suffisants sont nécessaires pour prendre en charge le nombre de versions et de tests exécutés simultanément.
  • Les équipes agiles ont besoin d'une boîte à outils de produits de test qui s'intègrent facilement dans les pipelines CI / CD et les outils de planification des travaux, et qui peuvent valider la fonctionnalité, la qualité du code, la sécurité et les performances.
  • Les architectes, les spécialistes de l'infosec, les responsables de l'assurance qualité et les autres membres de haut niveau de l'organisation devraient établir des normes de test et des objectifs de niveau de service qui constituent les critères d'acceptation par défaut.
  • Lorsque les applications nécessitent une entrée utilisateur, les équipes de test ont besoin de suffisamment de données et de modèles de test pour valider suffisamment de personnages, de cas d'utilisation et de modèles d'entrée.
  • Lors de l'engagement de sprint ou plus tôt, les équipes Scrum, y compris les ingénieurs d'automatisation des tests d'assurance qualité, doivent définir une stratégie de test sur les capacités à tester, les types de tests mis en œuvre, les processus d'automatisation mis à jour et qui développe les tests.
  • Les équipes Devops doivent mesurer la durée des exécutions du pipeline CI / CD et signaler lorsque les étapes de test automatisées ont un impact sur la productivité. Les équipes Devops ont souvent besoin de calendriers de tests supplémentaires en dehors des pipelines CI / CD pour exécuter des tests de plus longue durée.
  • Les équipes doivent régulièrement discuter des lacunes de leurs tests automatisés, en particulier des validations qui nécessitent des experts en la matière, l'UAT ou des tests avec des partenaires. Si les équipes agiles ne peuvent pas combler ces lacunes par l'automatisation, les cycles de publication doivent prendre en compte les frais généraux pour réduire les risques et terminer ces tests.

Enfin, les équipes agiles et les organisations de développement devraient régulièrement mesurer et discuter de leur couverture de test. Utiliser une stratégie de test de décalage gauche ne fonctionne pas si les équipes de développement et les ingénieurs en automatisation de la qualité ne mettent pas en œuvre, automatisent et n'intègrent pas suffisamment de tests pour détecter les problèmes et résoudre les risques.

Accélérer les cycles de publication ou permettre une livraison continue sans une automatisation suffisante des tests peut entraîner des problèmes de qualité importants qui dégradent l'expérience des utilisateurs finaux. Les équipes de développement agiles qui poussent des versions trop fréquemment se retrouvent alors à résoudre les problèmes et les défauts de production au lieu d'investir dans une automatisation plus et meilleure.