Évaluation d'une solution de test automatisée

Il est vrai que toutes les solutions de test ne se ressemblent pas. Mais un critère détermine non seulement votre choix ici, mais aussi les tests automatisés en général: c'est la version quantifiée de «Pouvez-vous vivre avec?»

De toute évidence, la fonctionnalité d'une solution de test compte: testez-vous simplement des applications Web? Avez-vous besoin de prendre en charge les tests mobiles? Et les applications de bureau? Quelles ressources devez-vous allouer pour mettre en œuvre des tests automatisés? Quels outils s'intégreront dans votre chaîne d'outils? À mesure que les outils de test évoluent, il devient de plus en plus difficile de déterminer les critères à utiliser pour choisir entre les packages disponibles. Il y a cependant une façon de regarder le problème qui clarifie le problème.

Premièrement, nous sommes tous d'accord pour dire que nous devons faire des tests parce que nous n'avons pas d'autre moyen de nous assurer que nos applications fonctionnent. Ce n’est pas que des alternatives n’aient pas été proposées – logiciel prouvablement correct me vient à l’esprit, par exemple. Jusqu'à présent, cependant, rien n'a remplacé les tests.

Mais, si les tests sont une tâche nécessaire ce n'est pas, du point de vue de nos utilisateurs (les personnes qui paient les factures), un tâche à valeur ajoutée . Les tests n’ajoutent pas ce que les utilisateurs veulent: plus de fonctionnalités, une meilleure expérience utilisateur, etc. Au mieux, les tests éliminent les insatisfaits. En fait, si les tests engagent les développeurs, les tests réduisent en fait votre capacité à fournir ce que vos utilisateurs apprécient. Les tâches nécessaires, mais sans valeur ajoutée, sont suffisamment courantes pour avoir un nom: elles sont appelées «frais généraux».

Ne vous méprenez pas: le fait de classer les tests comme des frais généraux ne diminue pas leur importance. Si vous exploitez une usine, votre facture d’eau est classée comme des frais généraux, mais cela ne signifie pas que vous n’appréciez pas un approvisionnement en eau constant et de haute qualité (et que vous êtes prêt à payer pour cela). Cette classification clarifie cependant ce que vous recherchez dans une solution de test. Et, comme le montre un examen rapide des stratégies / technologies de test, cela explique même pourquoi nous avons adopté les tests automatisés: cela réduit les frais généraux.

Définition des critères pour une solution de test

Par exemple, les tests automatisés nous permettent de réduire le temps que les gens doivent consacrer aux tests répétitifs. Alors qu'une personne (une ressource coûteuse) doit encore développer le test initial, les tests automatisés nous permettent de réexécuter ces tests à peu ou pas de frais. Ce sont des tests automatisés qui ont rendu viables des tests de régression approfondis et complets.

Les tests automatisés peuvent également être intégrés à nos chaînes de construction d'une manière que les tests manuels ne peuvent pas, ce qui réduit les coûts de supervision nécessaires pour garantir que tous (et uniquement) les Des tests «corrects» sont exécutés. Les tests automatisés prennent également en charge les rapports automatisés, garantissant que toutes (et seulement) les bonnes personnes sont informées des problèmes, et uniquement informées des problèmes qui les préoccupent.

Le test de mots-clés est un autre exemple de la manière dont les tests automatisés réduisent les coûts. Les tests de mots-clés permettent aux utilisateurs de créer de nouveaux plans de test sans (trop) l'intervention du développeur, en utilisant des outils avec lesquels les utilisateurs sont familiers (Excel, par exemple). Bien qu'une certaine formation des utilisateurs finaux soit requise, les tests de mots-clés réduisent les coûts en garantissant, d'une part, que tous (et uniquement) les tests que les utilisateurs jugent utiles sont exécutés et, d'autre part, en rationalisant le processus d'approbation des résultats de test en permettant aux utilisateurs finaux de créer,

Un autre exemple: les tests qui incluent l'exercice de l'interface utilisateur d'une application (test de bout en bout ou E2E) ont, traditionnellement, été un pont trop loin pour la plupart des ateliers de développement. Le problème, encore une fois, était presque purement lié à la surcharge: en général, même des modifications insignifiantes apportées à l'interface utilisateur d'une application entraînaient l'échec de plusieurs tests E2E, ce qui nécessitait la réécriture de ces tests. Compte tenu de ces coûts de maintenance continus, la plupart des ateliers estimaient que les coûts des tests automatisés UI / E2E étaient trop élevés. La détection d'éléments mixtes de Telerik Test Studio par exemple, a été spécifiquement conçue pour éliminer ces coûts et rendre les tests E2E viables.

Alors que Les tests E2E sont précieux en soi abaisser Les coûts des tests d'interface utilisateur permettent également des tests sans code en permettant aux utilisateurs de générer des tests simplement en interagissant avec l'application. Tout comme les tests de mots-clés, les tests sans code permettent aux utilisateurs de créer les tests dont ils ont besoin, de les exécuter et d'examiner les résultats. Les tests sans code réduisent également la nécessité pour les développeurs (une ressource relativement coûteuse et limitée) de créer de nombreux tests. Les tests sans code n'éliminent pas le besoin des développeurs, mais ils peuvent désormais se concentrer sur les scénarios que les tests sans code ne peuvent pas résoudre.

Les coûts réels des tests automatisés

La ​​réalité est que vivre avec une solution de test est en cours. les coûts qui y sont associés. Et, lorsque vous pensez à la gestion des coûts permanents / généraux, vous pensez à votre coût total de possession (TCO), car le prix d'achat n'est qu'une petite partie de la possession de votre solution.

Vous pouvez voir ce point de vue reflété dans les tester des solutions. La plupart des outils de test modernes ne nécessitent plus de compiler un agent de test dans l'application pour prendre en charge les tests automatisés. Une des raisons de ce changement est d'ordre philosophique: tester une application avec un agent spécial signifie que vous ne testez pas la version de l'application que vous allez publier. Mais la raison la plus critique est liée aux frais généraux: exiger qu'une application dispose d'un agent de test complique à la fois le test et la mise en production des processus – un coût permanent qui augmente vos frais généraux. L'élimination des agents de test élimine les coûts.

La mise en route des tests automatisés comprend des coûts ponctuels tels que la configuration de votre environnement de test, l'intégration des tests dans vos processus de développement / livraison et la formation des personnes à la création de tests. Mais les coûts réels que vous voulez éviter sont les coûts permanents. Votre chaîne d'outils de développement / livraison va évoluer avec le temps. Par exemple: vous ne voulez pas avoir à répéter ces coûts de configuration à chaque fois que vous peaufinez votre processus de développement.

Il est facile de passer à côté de certains des coûts permanents associés à certaines parties des tests, à savoir les rapports, par exemple. Un bon outil de rapport de test garantit d'abord que tous ceux qui ont besoin de connaître un problème de test sont informés (ce qui peut même impliquer des problèmes de conformité). Mais les rapports doivent également faciliter la recherche du problème à résoudre et le traitement des rapports de suivi qui indiquent aux personnes appropriées que le problème a été résolu.

Open-source Solutions

Selenium is bon exemple des défis à relever pour choisir un bon outil de test. En tant qu’outil open source, l’investissement initial de Selenium ne peut être moindre: il est gratuit. Selenium possède également un écosystème riche qui fournit une variété de packages tiers (certains gratuits, d'autres non) pour répondre aux besoins de test.

Ce qui est une bonne chose car, par exemple, Selenium ne prend pas en charge les tests d'applications mobiles. Cependant, un package tiers, Appium (également gratuit) prend en charge les applications mobiles en exploitant les interfaces Selenium. Par conséquent, si vous connaissez Selenium, vous savez tout ce que vous devez savoir pour commencer à utiliser Appium.

Cependant, comme Appium et Selenium sont des outils séparés, créer un environnement de reporting intégré à partir de leur sortie peut être… difficile. Pour cela, vous allez regarder un référentiel comme Maven qui fournit un endroit pour stocker des informations à partir de divers outils, et un outil de rapport comme Allure qui peut générer des rapports provenant de diverses sources.

Mais, tout d'un coup, votre TCO augmente. Bien que les composants open source soient gratuits, leur intégration dans une solution peut être coûteuse.

En outre, d'autres coûts commencent à s'accumuler lorsque vous assemblez une infrastructure de pointe: vous gérez maintenant les correctifs et les mises à niveau pour plusieurs outils, tous sur des calendriers de sortie différents. Les problèmes d'intégration deviennent importants et vous pouvez vous retrouver à devoir passer du temps à rechercher des problèmes avec votre chaîne d'outils de test, en plus de résoudre des problèmes avec votre application.

En plus de cela, la résolution des problèmes d'infrastructure de test peut prendre du temps dans la meilleure catégorie. solutions: vous googlez Stack Overflow plutôt que d'appeler le support technique. Acquérir une expertise dans une variété de packages n'est pas non plus gratuit. Si le résultat est que vous avez quelqu'un dont le travail consiste à maintenir votre infrastructure de test, alors vous devez sentir que quelque chose ne va pas pour atteindre vos objectifs de test.

De toute évidence, tout cela est à la fois faisable et gérable. Ce qu’elle n’est pas est gratuit.

Les applications modernes intègrent des microservices et des clients tout en diffusant une logique métier complexe sur tous ces composants système. Pour prouver que ces applications «fonctionnent comme prévu», il faut intégrer à la fois des connaissances techniques et commerciales tout en prenant en charge une variété d'approches de test (UI, régression, E2E, API, charge, etc.). Garantir la qualité n’est possible qu’avec un outillage qui prend en charge toutes ces exigences et le fait sans augmenter les frais généraux des équipes.