Gamifying Test Automation: Serpents et échelles

L'automatisation des tests est un domaine clé de la stratégie d'écosystème d'applications de chaque organisation informatique. Qui ne souhaiterait pas une qualité de premier ordre associée à des temps de cycle de test ultra-rapides, des efforts globaux réduits et l'avantage supplémentaire d'éliminer l'erreur humaine? Pour une organisation qui commence tout juste son parcours d'automatisation des tests, cela semble être une stratégie magique et infaillible garantie pour réussir et récolter des avantages rapides. Ce n'est qu'une version incrémentielle des tests fonctionnels manuels de base.

Demandez à n'importe quelle organisation à genoux dans son parcours d'automatisation des tests à l'échelle de l'entreprise, et elle vous dira que la réalité sur le terrain est très différente. L'automatisation des tests est comme un iceberg. La plupart des organisations ne représentent que la partie visible au-dessus de la surface. Ils semblent soit retarder lorsqu'ils aborderont la partie sous la surface, soit ils ne le savent peut-être pas complètement. Parmi les nombreuses raisons d'un parcours décevant d'automatisation des tests, la plus courante et la plus importante consiste à croire que le simple fait d'investir dans un outil ou une plate-forme mènera une organisation vers la terre promise. L'automatisation des tests est un voyage à multiples facettes. Bien que l'outil ou la plate-forme soit un élément clé, la façon dont les entreprises l'utilisent pour parcourir ce parcours est tout aussi importante. L'automatisation des tests est un long processus qui nécessite une approche patiente et pluriannuelle pour voir les avantages dans toute l'entreprise.

Pour mieux comprendre et apprécier ce parcours, nous l'avons gamifié en le comparant au jeu de société "Snakes and Ladders". Voici la corrélation que nous avons considérée:

• La carte dans son intégralité est le voyage de l'automatisation, parsemée de serpents (pièges) et d'échelles (meilleures pratiques).
• Chaque carré / bloc sur la carte est une étape importante dans un le cheminement de l'entreprise vers son objectif d'automatisation des tests
• Les échelles sont des étapes clés que les entreprises devraient prendre pour voir des avantages non linéaires à l'avenir
• Les serpents sont les obstacles rencontrés par les entreprises pendant le voyage et qui peuvent les ramener à la case départ en raison raccourcis pris ou étapes clés négligées (ou inconnues) Il y a des serpents à éviter et des échelles pour aider dans chacun d'eux.

  Coûts de la plate-forme d'automatisation

  • Serpent à éviter : Les organisations semblent souvent adopter une approche de «l'âge de pierre» pour intégrer les coûts des outils dans leur stratégie. Bien qu'ils considèrent le coût initial élevé d'une plate-forme d'automatisation supérieure comme un obstacle, ils n'ont peut-être pas effectué une évaluation complète de la valeur commerciale pour traiter le retour sur investissement et les avantages au fil du temps. D'après notre expérience, les organisations tendent à s'orienter vers la création d'un cadre propre qui s'intègre à d'autres outils d'automatisation qui semblent plus rentables (par exemple, open-source ou commercial). Malheureusement, le degré élevé d'intégration et les protocoles variés rendent ces cadres extrêmement fragiles et ils ont tendance à tomber en panne fréquemment, ce qui rend l'automatisation plus un obstacle qu'une bénédiction.
  • Échelle pour aider à grimper plus rapidement sur la planche : Plutôt que de créer un cadre à partir de zéro en utilisant des talents hautement qualifiés – ce qui peut être difficile à trouver de toute façon sur les marchés concurrentiels d'aujourd'hui – les entreprises devraient se concentrer sur des plates-formes d'automatisation compatibles avec la technologie de bout en bout qui augmentent les ingénieurs de test manuels existants. Cela permet d'économiser sur les investissements dans la formation et le recrutement d'un ensemble de compétences entièrement nouveau. De plus, cela rend l'automatisation facile à adopter à l'échelle de l'entreprise, qu'il s'agisse d'applications Web personnalisées, de produits commerciaux standard (COTS) ou d'applications natives du cloud. Le retour sur investissement dans ces scénarios est plus facile à réaliser, et l'automatisation est perçue plus comme une aubaine qu'un mal nécessaire.

  Maintenance des scripts et frais généraux connexes

  • Snake à éviter : Considérez les applications Web de bureau et mobiles, le plus -des outils d'automatisation des tests communs pour lesquels ils sont souvent de nature open source. Ces outils peuvent réduire considérablement les coûts, mais ils présentent des inconvénients qui peuvent gravement affecter le retour sur investissement et planifier l'adhésion. Les pages Web dynamiques, par exemple, provoquent de nombreux problèmes lors de l'utilisation d'outils open-source, car l'arriéré de scripts à développer et à maintenir ne cesse d'augmenter, ce qui entraîne des efforts de test importants. Finalement, les entreprises se heurteront à un barrage routier et se rendront compte que les efforts de script ne sont pas en mesure de réduire les efforts globaux de test. tout parcours d'automatisation. Si nous continuons l'exemple précédent de pages Web dynamiques dans des projets agiles ou pseudo-agiles, les efforts de maintenance de l'outil sont un facteur critique à prendre en compte lors des calculs de retour sur investissement. Si les outils open source ou COTS traditionnels s'avèrent inefficaces pour de tels scénarios, les entreprises devraient explorer des plateformes axées sur l'intelligence artificielle / l'intelligence qui peuvent mettre à jour leurs référentiels d'objets automatiquement, éliminant ainsi la nécessité de maintenir des scripts.

  Niveau optimal de couverture d'automatisation. 50%? 75%? 100%?

  • Un serpent à éviter : Tout simplement, l'automatisation à 100% n'est PAS l'état de nirvana d'une organisation. De nombreuses organisations pensent que « Si ma couverture d'automatisation est de 60%, je suis toujours inefficace de 40%!» et évoluer vers un scénario dans lequel ils ont automatisé presque tous les cas de test. Cette décision n'est pas sage. Alors que les organisations évoluent vers des niveaux d'automatisation extrêmement élevés, il y a une augmentation linéaire de l'argent dépensé pour les licences d'outils, ainsi que le nombre de personnes nécessaires pour réaliser les scripts. Par exemple, un client a dépensé beaucoup d'efforts et d'argent pour passer de 70% à 90% d'automatisation et maintenir ce niveau. Ironiquement, le client a dépensé plus sur ces 20% qu'il n'avait dépensé pour passer de 0% à 70% d'automatisation en premier lieu, réalisant finalement un retour sur investissement négatif. Des niveaux d'automatisation plus élevés n'entraînent pas toujours un retour sur investissement positif. Il est normal d'avoir de faibles nombres d'automatisation tant que le retour sur investissement continue d'augmenter et que la société atteint son pourcentage de couverture maximal.
  • Échelle pour aider à grimper plus rapidement : suivi dynamique du retour sur investissement et de la dette technique, couplé avec des techniques telles que les tests basés sur l'impact, sont des clés pour éviter une automatisation excessive des suites de tests. Les entreprises doivent toujours se souvenir de la loi de Brooks et de la loi des rendements décroissants lorsqu'elles investissent dans une activité informatique. Une autre dimension que les organisations devraient explorer est d'identifier l'ensemble de suites de tests automatisables pour améliorer la couverture. En utilisant des analyses historiques, le nombre cible d'artefacts à automatiser peut être encore réduit, permettant ainsi un degré élevé d'automatisation à un effort et un coût beaucoup plus bas qu'auparavant. Il existe également des algorithmes disponibles qui peuvent effectuer une évaluation d'impact en analysant la couverture au niveau du code et en identifiant de nouveaux changements. Cette intelligence peut aider à une couverture d'automatisation plus intelligente, ciblant uniquement les cas de test basés sur un module de code impacté et fournissant une confiance élevée sans compromettre la couverture des risques.

  L'automatisation des tests est un voyage à multiples facettes que les organisations doivent assumer avec diligence tout en restant attentives aux avantages à long terme, ainsi qu'aux futures feuilles de route technologiques de l'informatique et de l'entreprise. L'un des avantages de la carte d'automatisation de test ci-dessus est qu'il n'y a pas de lancer de dés requis pour avancer. Les entreprises sont autorisées à choisir le nombre à chaque tour, et plus le nombre est petit, mieux c'est.