L’automatisation des tests est vitale pour toute organisation qui souhaite adopter Agile ou DevOps, ou qui souhaite simplement apporter des changements informatiques plus rapidement.
Si vous demandez à une partie prenante « Qu’espérez-vous obtenir de vos tests ? » la réponse commune que vous recevez est d’assurer la qualité. Mais plus vous vous plongez dans la dynamique organisationnelle de l’automatisation des tests, la réponse semble être différente.
Il semble que la principale motivation pour automatiser les tests ne soit pas la qualité, mais aller plus vite et réduire le coût des tests. Cela semble un peu cynique, mais c’est étonnamment courant lorsque vous prenez du recul et regardez la dynamique organisationnelle, en particulier lorsque les dates de livraison déterminent la culture d’une organisation.
Vous pensez peut-être : « La qualité n’est-elle pas implicite dans l’activité de test de toute façon ? » Ou qu’en accélérant les tests grâce à l’automatisation, la qualité ressortira inévitablement. Cette pouvait être vrai, mais pas quand il y a un problème fondamental dans la façon dont les organisations comprennent la qualité et le rôle que les tests y jouent. Dans ce cas, des tests plus rapides ne sont pas synonymes de meilleure qualité.
Demandez-vous comment vos équipes de test rendent compte de l’activité de test et de ses résultats ? Est-il basé sur les tests effectués et la couverture des tests – et peut-être le redoutable « nous avons une couverture des tests à 100 % ? » Demandez-vous ensuite pourquoi les parties prenantes peuvent encore remettre en question la qualité lorsque vous leur dites que vous avez atteint une couverture de test de 100 % ? Qu’entendez-vous vraiment par là ?
Leçons de qualité tirées de plus de 16 ans de transformation des tests
Ayant passé de nombreuses années à essayer de créer une capacité de test technique à partir d’un centre d’excellence traditionnel, j’ai rencontré de nombreux succès. Ils allaient de la création d’une équipe d’automatisation centralisée et de la normalisation des cadres à la création d’une capacité de virtualisation de l’environnement. Pourtant, tout cela semblait en quelque sorte trop à court terme et trop sur mesure.
En faisant face aux défis de la création d’une capacité de données de test centralisée, j’ai réalisé que ce que nous faisions, et avions toujours fait, reposait sur des fondations fragiles. Nous ne savions pas ce que le produit était censé faire au départ. Comment pourrions-nous alors prouver qu’il l’a fait, sans parler d’essayer d’automatiser les exigences inconnues, de créer des données de test pour celles-ci et de créer des interfaces représentatives pour les tester ?
Figure 1 : Une compréhension initiale limitée risque-t-elle d’entraîner un scénario « entrée de données, sortie de données » dans vos tests ?
En vérité, nous étions réactifs, reconcevant les systèmes par le biais de tests. Le taux de changement n’aidait pas le problème, pas plus que les méthodes traditionnelles de création de monticules de cas de test dans les outils de gestion de test habituels. En fait, les deux l’exacerbaient, créant de plus en plus de tests d’une valeur douteuse, tout en donnant aux parties prenantes la fausse confiance que l’exécution de centaines de tests équivaut à la « qualité ». Nous décalions à droite alors que nous aurions dû décaler à gauche.
Décaler vers la gauche pour construire de meilleures choses
Mais le décalage vers la gauche ne devrait pas être uniquement destiné aux tests, un point qui est souvent négligé. En tant que collectif, nous nous permettrions de déplacer le changement informatique vers la droite, sachant que les fondations n’étaient pas bonnes. En tant que testeurs, nous avions perdu le métier de tester, nous concentrant davantage sur le fonctionnement de l’automatisation plutôt que sur la garantie que l’automatisation teste les bonnes choses.
La même chose peut être dite de nos amigos avec qui nous travaillons depuis la conception et le développement : il ne semble pas y avoir une compréhension commune de « Construisez la bonne chose, construisez la bonne chose! »
L’indicateur principal évident de ce problème pour votre équipe de test est de se demander, comment votre approche de test complète-t-elle l’architecture ou les modèles de conception de l’équipe, s’il y en a même ? Ou comment cela complète-t-il la méthodologie de livraison ? Si vos équipes travaillent sur des sprints de deux semaines et que vous avez une grande phase de test de bout en bout à la fin, il y a de fortes chances que vous ayez un théâtre Agile et que vous deviez à nouveau « construire la bonne chose » en équipe.
Le rôle critique des tests dans la compréhension et la collaboration
Se concentrer sur la construction de la bonne chose mènera très rapidement à une collaboration et à une conversation autour d' »inconnues »: des solutions qui commencent la vie comme des boîtes noires ou qui sont devenues trop complexes au fil du temps. L’utilisation de techniques telles que la modélisation pour prototyper la réflexion sur la conception et capturer les conversations peut très rapidement aider à visualiser des règles ou des hypothèses jusque-là inconnues qui ont brouillé la compréhension de l’équipe et des parties prenantes concernant le fonctionnement réel du système.
Je tiens à souligner ici que, bien que l’outillage soit un catalyseur, cela ne se limite certainement pas à acheter un outil et à faire les mêmes choses que nous avons toujours faites. Ce serait simplement commettre les mêmes erreurs sous un nouveau mot à la mode – une erreur dans laquelle nous vivons tous actuellement d’une manière ou d’une autre.
Ce dont nous parlons vraiment, à la base, c’est d’un questionnement critique et d’une collaboration, ainsi que de comprendre où cibler les efforts appropriés pour obtenir un résultat de qualité.
Nous devraient construire des modèles, mais cela devrait être une aide pour les conversations, les requêtes, les règles et au-delà de ce que nous devons obtenir des différentes parties prenantes. Les modèles fournissent une représentation structurée de « Construisons-nous la bonne chose ? A travers ce questionnement, nous nous rendons compte que nous avons en réalité de nombreux clients qui ont des besoins à satisfaire (que ce soit la conformité, la sécurité, les opérations), ainsi que le consommateur final du logiciel en cours de création.
Les modèles nous permettent, en tant que testeurs, d’avoir une conversation plus riche, mais ils constituent également « juste assez de documentation » pour l’ensemble de l’équipe. Ainsi, nos modèles deviennent le cahier des charges vivant :
Figure 2 : La modélisation permet une conversation plus riche et fournit la documentation vivante nécessaire à l’ensemble de l’équipe.
Les modèles doivent décomposer la complexité, pas l’ajouter
La modélisation est extrêmement précieuse, mais l’approche adoptée est importante. La modélisation « statique », en conception et en test, offre des bénéfices à court terme, mais peut devenir une source de dette technique. Cela se produira à mesure que les systèmes modélisés deviendront inévitablement plus complexes, avec plus de fonctionnalités ajoutées.
La modélisation statique peut inclure l’utilisation de produits comme Office (Word, Excel, Vision) ou certaines des nouvelles offres d’outils qui semblent aller de pair avec l’argumentaire de vente Agile. Il diffère des spécifications « vivantes » (modèles), qui peuvent vous guider vers l’impact du changement. C’est les facteur clé pour maintenir le train de livraison continue et pour empêcher la « superposition », dans laquelle la compréhension est répartie sur plusieurs sites et devient difficile à maintenir.
Modélisation pour devenir prêt pour l’automatisation des tests
Donc, dans nos équipes, nous avons maintenant des modèles, et ces modèles sont basés sur des règles du système et des questionnements méthodiques. Nous avons maintenant une coche dans la case pour construire la bonne chose ! Dans le même temps, nous avons également créé l’environnement parfait de critères prévisibles et reproductibles avec des résultats attendus absolus. Et maintenant nous sommes prêts à donner aux parties prenantes ce qu’elles veulent… l’automatisation !
La différence est que nous créons maintenant l’automatisation pour toutes les bonnes raisons. Nous savons que chaque test dérivé du modèle est précieux, ce qui signifie que nous pouvons affirmer en toute confiance que les activités de test réalisent l’élément de vérification de la solution :
Figure 3 : L’automatisation des tests est ancrée dans une conversation et un consensus concernant le système souhaité, indiquant que nous testons les bonnes choses.
Bien que nous dérivions des tests du modèle, nous devrions toujours augmenter nos tests avec l’exploration. Ce qui est essentiel, c’est que nous réinjections ce que nous apprenons dans nos modèles, de sorte que nous repoussons toujours les limites de la compréhension, en comprenant que nous ne pouvons jamais tout savoir :
Figure 4 : Essais sur les volcans et importance de l’exploration/apprentissage continus.
Modéliser pour s’assurer que nous construisons et testons correctement
Jusqu’ici, tout va bien : nous avons commencé la modélisation (flux structurés), posé des questions et tous nos problèmes ont disparu. Sauf qu’ils ne le feront pas si nous ne changeons pas où nous ciblons notre validation. Si nous sommes trop concentrés sur les seuls flux métier, nous créons des modèles de flux métier qui imposent à leur tour une approche de test trop basée sur l’interface utilisateur. Pourtant, nous savons que les tests sur l’interface utilisateur sont lents et que l’automatisation de l’interface utilisateur est la plus difficile à réaliser.
Au lieu de cela, nous devons examiner la bonne approche pour nous assurer que nous validons la façon dont les choses sont imaginées pour fonctionner sous «l’iceberg» d’une solution que nous sommes invités à tester. Nous devons valider (modèle) au niveau du service/de l’API, et ces modèles doivent se connecter aux flux métier :
Figure 5 : Tests sur l’ensemble de la pile technologique et de la pyramide des tests.
Sinon, comment la vérification aura-t-elle jamais une chance de prouver quelque chose qui n’a jamais été défini autrement que dans la tête d’un développeur, ou dans une spécification statique obsolète et heureuse ? L’infrastructure est souvent ignorée, mais cela peut-il encore être le cas compte tenu de la prolifération du cloud ?
Une approche centrée sur la qualité
Briser les silos traditionnels et comprendre la qualité est quelque chose qui nécessite un consensus avant de pouvoir être prouvé. Cela semble être «l’éléphant dans la pièce» fondamental, souvent manqué dans la poursuite des tests continus. Là où elle est comprise, l’automatisation prospère.
Pourtant, le changement culturel intéressant est que les parties prenantes qui parrainent ces équipes hautement performantes comprennent également que la qualité ne naît pas de l’automatisation des tests. Au lieu de cela, l’automatisation est le résultat de prendre le temps de définir à l’avance ce que signifie la qualité.
L’inspection n’améliore pas la qualité, ni ne garantit la qualité. L’inspection est trop tardive. La qualité, bonne ou mauvaise, est déjà dans le produit. Comme l’a dit Harold F. Dodge, « Vous ne pouvez pas inspecter la qualité d’un produit. »
– W. Edwards Deming (The MIT Press : 2000), Sortir de la crisep. 29