Top Gun Testing pour Agile : Tests automatisés des pilotes de chasse

Vous pensez peut-être que vous n’avez pas grand-chose à apprendre sur les tests automatisés en regardant Top Gun, mais les pilotes de chasse ont des leçons importantes sur ce dont vous avez besoin dans un outil de test que vous voulez savoir.

Vous connaissez le mantra actuel du développement agile dans un environnement DevOps : Déployez souvent (en développement, en test ou en production), échouez rapidement (de préférence en développement ou en test) et redéployez plus tôt. Bien que personne ne le mentionne, vraisemblablement quelque part entre « échec rapide » et « redéploiement », vous corrigez l’échec.

La raison habituelle pour laquelle nous commençons à penser aux tests automatisés est de pouvoir effectuer tous nos tests de régression – nous reconnaissons que nous n’aurons jamais la main-d’œuvre ou le temps pour tout tester de régression si nous devons continuer à exécuter des scripts de test manuellement. Nous commençons également à penser aux tests automatisés car il est plus facile d’intégrer des tests automatisés dans notre Canalisations DevOps.

Mais nous n’atteindrons le mantra agile de « l’échec rapide » que si nous utilisons un logiciel de test qui prend en charge la façon de penser des pilotes de chasse.

Tester comme un pilote de chasse

C’est parce que nous sommes déjà venus ici ou, plus précisément, Lieutenant John Boyd de l’US Air Force est déjà venu ici. En tant que pilote de chasse F-86 Sabre pendant la guerre de Corée, Boyd voulait expliquer pourquoi les pilotes de chasse américains surpassaient les pilotes de chasse nord-coréens, bien que les Coréens aient, dans le MiG-15, un avion techniquement meilleur.

L’explication, décida Boyd, était la Boucle OODA (observer-orienter-décider-agir) qui, selon lui, décrit le processus que les pilotes de chasse ont traversé à plusieurs reprises pendant le combat. Les pilotes ont commencé par observer la situation, s’orientant (en utilisant ces informations pour prendre une décision), décidant d’une posture d’attaque, puis agissant pour mettre en œuvre cette décision. Grâce à une combinaison d’une meilleure formation et d’une meilleure conception du cockpit, les pilotes américains parcouraient cette boucle plus rapidement que les pilotes nord-coréens.

Ce traitement plus rapide via la boucle OODA signifiait que, alors que les pilotes nord-coréens intégraient encore les informations sur ce qui se passait, la situation était sur le point de changer car les pilotes nord-américains agissaient déjà en modifiant ou en abandonnant leur posture d’attaque. Les pilotes nord-coréens ne sont jamais arrivés à la phase Act car ils ont dû recommencer en observant la nouvelle situation.

Ce qui devrait également être l’objectif des tests :

1. Observez le problème rapidement (échouez tôt)
2. Orientez en traçant ce problème jusqu’à sa source probable
3. Décidez comment y remédier
4. Agir pour réparer et redéployer
5. Refais-le

Votre objectif, dans un environnement agile, est de le faire assez rapidement pour que les problèmes n’atteignent pas la production ou, s’ils le font, soient résolus alors que leur impact est minime : au moment où quelqu’un remarque l’échec, la situation a déjà changé et l’échec a disparu.

Autrement dit : tout découle de l’observation précoce des défaillances.

Ce qui est requis

Cela signifie que, lorsque vous envisagez une solution de test, vous souhaitez d’abord un outil qui réduit le temps de création d’un test. Avec un bon outil de test, vous pouvez créer un script de test simplement en allumant un enregistreur de test, en exerçant votre application, puis en révisant le test. Plus il est facile de créer un test efficace (y compris les simulations nécessaires pour isole ton code), plus il est probable que vous a) passerez un test, et b) pourrez déplacer votre test vers plus tôt dans le processus.

Bien sûr, créer des tests n’est pas d’une grande aide si vous ne pouvez pas les exécuter sans effort : plus il faut de travail pour exécuter un test, moins ces tests seront exécutés souvent et plus tard vous découvrirez vos échecs. Un gestionnaire de test efficace est essentiel ici. Et, à mesure que le nombre de vos tests augmente, afin d’obtenir les résultats rapidement, vous devrez pouvoir exécuter facilement des tests en parallèle sur plusieurs ordinateurs.

Ces outils vous donnent une chance d’observer l’échec afin que vous puissiez, en fait, « échouer rapidement ».

Prochaines étapes

L’étape suivante – s’orienter en utilisant les informations produites par votre processus de test – signifie que vous avez besoin d’un bon système de rapport pour vous faire savoir, dès que possible, quand quelque chose a échoué. Traquer le problème nécessite de mettre en œuvre les meilleures pratiques dans la construction de tests – isoler vos tests est essentiel ici, par exemple pour réduire la portée de la recherche lors de la recherche du problème.

De toute évidence, les dernières étapes (décider de la solution et agir pour résoudre le problème) relèvent du domaine des bonnes pratiques de programmation et des architectures d’application bien conçues. Mais, comme je l’ai dit ailleurs, bonnes pratiques de programmation et tests efficaces vont de pair—certainement des applications faiblement couplées construites à l’aide de Principes SOLIDES faciliter les tests (et, en particulier, les tests automatisés). En fait, s’il est difficile de tester votre application, il vous sera coûteux de l’étendre ou de l’améliorer.

Et, à la fin de votre boucle, vous êtes prêt à vous redéployer. Des tests automatisés efficaces sont essentiels, non seulement parce qu’ils permettent des tests de régression approfondis, mais parce qu’ils sont fondamentaux pour toute la philosophie de la méthodologie agile.