Pourquoi la maintenance d'automatisation des tests est complexe ?
Bien que la maintenance soit une prestation complexe du point de vue des ressources, du temps, du coût et de l'effort, l'automatisation des tests est devenue une tâche essentielle. Quelle que soit l'innovation de l'idée, les solutions splendides n'émergent pas du jour au lendemain par hasard. Une part des coûts d'exploitation élevés provient des projets logiciels de code d'automatisation de maintenance. Par exemple, le code implique régulièrement une maintenance pour :
- Maintenir le code de test dans un état testable pour les prochains sprints,
- Corriger ou remplacer les tests automatisés,
- La maintenabilité des environnements,
- Maintenir les outils utilisés dans le code d'automatisation des tests,
- Construire et maintenir des infrastructures pour toutes les suites de tests, et les suites de tests automatisés ou les cas eux-mêmes,
- Soutenir et ajouter des utilitaires supplémentaires dans l'automatisation des tests, si nécessaire,
- Une configuration et une mise à jour plus faciles et l'installation de la bibliothèque utilisée dans l'automatisation des tests,
- La suppression du dead code,
- Une mise à jour de tous les éléments pour assurer la traçabilité,
- Un partage constant des connaissances et bien d'autres choses encore.
Alors que j'observe des équipes qui font toutes ces tâches pour le bien du code de test de maintenance, les tests de régression sont toujours aussi précieux pour les fonctionnalités existantes pour la sortie d'une nouvelle version du logiciel !
La valeur de la maintenance du code d'automatisation des tests comprend la :
- Collaboration en équipe,
- Formation des parties prenantes du projet,
- Responsabilité de l'équipe,
- Avoir plus confiance dans la version des produits,
- Les membres de l'équipe doivent adopter le nouvel ensemble de compétences,
- Bonnes pratiques de développement de logiciels,
- Environnement propice à l'amélioration continue,
- Conserver/partager les connaissances au sein de l'équipe,
- Dans l'ensemble, le processus devient plus agile pour s'adapter rapidement aux changements de logiciels,
- Un retour d'information constant et une amélioration en tant qu'équipe.
Cela apporte de la joie au voyage du code de test de maintenance !
Comment maintenir le code d'automatisation des tests ?
Maintenant que nous avons vu les défis et les valeurs de l'automatisation des tests, laissez-moi partager avec vous quelques aspects de la façon dont nous l'avons fait dans l'un de nos projets pour maintenir le code d'automatisation des tests.
Objectifs:
- Identifiez si vous avez besoin d'un site correctif de maintenance ou préventif de maintenance pour le code d'automatisation des tests.
- Fixez un calendrier pour les activités et vérifiez constamment vos progrès pour le code d'automatisation des tests.
Risque :
Identifiez le risque pendant que vous maintenez le code d'automatisation des tests afin de ne pas sacrifier la sortie d'une nouvelle version du logiciel.
Plan :
- La stratégie d'automatisation des tests est très importante pour que l'équipe pense à la maintenabilité de l'automatisation des tests. Par exemple, ne pas automatiser tous les tests ou automatiser le test à des niveaux ciblés.
À titre d'exemple, si c'est le cas, je vous recommande cet exposé sur la stratégie d'automatisation des tests de Richard Bradshaw : Pyramids Are Ancient - Test Automation Strategy, Richard Bradshaw - Ministry of Testing | Sauce Lab
- Avoir une bonne testabilité (selon ma compréhension de la terminologie signifie, la capacité de tester avec facilité) est un must pour l'équipe qui pense à maintenir une bonne automatisation des tests. "C'est parce que la testabilité est la base de tous les efforts de test. Si les équipes logicielles peuvent tester facilement le morceau de logiciel, elles peuvent, à leur tour, déterminer la capacité d'automatiser et de maintenir le morceau de code automatisé avec facilité."
10-ps-de-testabilité : J'aime la façon dont Rob Meaney et Ash Winter ont partagé ce qu'ils ont fait pour leur équipe afin d'améliorer la testabilité à partir de différents points de vue et sont arrivés aux P (les P sont appelés MNEMONIQUES ici), et comment ils l'ont expliqué (conférences publiques, livres, blogs, etc.).
- Comprendre ce qu'est la dette de test (selon ma compréhension de la terminologie, cela signifie un énorme arriéré pour le test), et travailler avec les membres de l'équipe pour prioriser et résoudre le problème. Par exemple, une situation où une énorme tâche d'automatisation des tests est en attente pour le développement du code d'automatisation des tests, et les tests de régression deviennent un point douloureux pour l'équipe. Le résultat est un ralentissement du processus de développement logiciel.
Processus :
- Avoir un moyen de faciliter le processus afin que toute l'équipe puisse contribuer, ce qui inclut les développeurs et les parties prenantes de l'entreprise. Par exemple, les développeurs peuvent contribuer à l'écriture du code d'automatisation et à la révision du code d'automatisation des testeurs, tandis que les parties prenantes de l'entreprise peuvent améliorer la couverture des tests en indiquant les domaines nécessitant l'attention du produit logiciel.
- Avoir une opportunité où les membres de l'équipe peuvent s'approprier les rotations. Ainsi, ils peuvent avoir un retour d'information précieux, qui pourrait être utilisé pour améliorer la maintenance du code d'automatisation des tests logiciels.
- La découverte de schémas dans l'échec de l'exécution du code de test d'automatisation prouve que l'équipe dispose d'un flaky test dans la suite de test. Faire une analyse des causes profondes aide beaucoup à maintenir le morceau de code d'automatisation des tests.
Environnement:
- Améliorer constamment et utiliser des environnements propres pour exécuter l'automatisation des tests. La pratique courante et réussie consiste à utiliser autant que possible la réplique de l'environnement de production.
- Avoir des cas de test automatisés indépendants des environnements de test (environnements dev, test, UAT) du point de vue des données de test de maintenance. Les données de test de maintenance sont très importantes lors de la maintenance du code d'automatisation des tests pour exécuter les tests dans différents environnements. De nos jours, les entreprises/projets ont une stratégie de ramification, et pour les suites d'automatisation des tests, la situation devient cruciale pour les exécuter indépendamment et avoir le résultat du test plus rapidement dans différents environnements selon les besoins de l'entreprise.
- Idéalement, l'équipe devrait développer le cadre d'automatisation des tests de manière à ce qu'il soit plus facile d'ajouter un test ou de supprimer des tests automatisés. De nos jours, les entreprises utilisent différentes stratégies de mise en production telles que les tests A/B en production, les tests de déploiement, les tests Canary, les tests Blue-Green, les tests de configuration, les tests de reprise après sinistre et les tests statistiques. Tout en maintenant le code d'automatisation des tests logiciels, nous devons comprendre quelle méthode notre équipe utilise pour s'adapter à une telle situation.
Données d'essai:
- Avoir une bonne compréhension de la façon de créer et de maintenir les données de test pour l'application sera plus utile dans la maintenance du code d'automatisation des tests.
Journalisation et rapports:
- Ajouter plus de journaux dans le site rapport de tests afin que tous les membres de l'équipe puissent comprendre les étapes du test directement à partir du site rapport de tests au lieu de passer par le code d'automatisation du test. Le but ici est de comprendre où le test a échoué exactement. Cette activité sera également utile car elle permettra de mieux comprendre les exceptions lancées par le cadre d'automatisation des tests dans rapport de tests, ce qui facilitera grandement le débogage dans la maintenance du code de test.
- L'ajout de journaux à l'application testée aidera à déterminer pourquoi les tests automatisés échouent parce que l'application testée ne fonctionne pas comme prévu. Il suffit de voir les logs autour des rapports de test ou d'avoir accès au filtre/à la recherche dans le système de logs en recherchant l'exception lancée par l'application.
- Disposer d'une capacité dans le cadre d'automatisation des tests pour capturer les captures d'écran, les journaux (référentiel de test, l'application testée, les journaux JavaScript), etc. avant d'échouer le test réel. Cela aidera à faire l'analyse et à maintenir le code de test.
- Partager constamment le site rapport de tests avec l'équipe, afin que celle-ci ne perde pas le fil ou ne se désintéresse pas du site de maintenance du code d'automatisation des tests.
Codage:
- Écrivez un code de test simple et compréhensible, car la maintenance du code d'une autre personne peut être difficile et prendre du temps.
- La révision du code d'automatisation des tests est très importante.
Test de l'interface utilisateur :
- Lors des tests d'interface utilisateur, les outils ont recommandé de réduire au minimum l'utilisation des localisateurs et de privilégier les identifiants et les CSS.
- Les outils recommandent d'utiliser un état d'attente fluide pour éviter l'exception de l'élément périmé par Selenium.
Dépendance:
- Réduire au minimum les dépendances sur le site référentiel de test, afin de faciliter le code de test maintenir .
- Minimiser les dépendances dans le site référentiel de test afin de faciliter la mise à jour et maintenir la dépendance du cadre d'automatisation des tests.
Réflexion et actions :
- Les leçons que j'ai apprises comprennent une réflexion constante sur ce que vous apportez à l'automatisation des tests. Reconnaître comment vous contribuez à l'automatisation des tests a un effet direct sur le produit testé. Apprendre à trouver le schéma des échecs et des améliorations fera de vous un testeur plus fort.
- Améliorer le code d'automatisation des tests en fonction des attentes de chaque partie prenante et obtenir d'excellents résultats de test. Pour maintenir le rythme du code d'automatisation des tests, il est recommandé d'établir certaines règles pour soi-même et pour les membres de l'équipe, afin que ces derniers aient une idée claire de l'action à entreprendre et de la personne à qui il est recommandé de la confier dans une situation donnée. Définir clairement la propriété est très important pour que l'équipe collabore à la réussite du projet.
Par exemple, si le travail du pipeline de test devient rouge, c'est une alarme pour l'équipe concernée et l'équipe doit analyser le test défaillant en signalant l'adresse bug ou en le réparant. Mais l'équipe doit analyser dans les 6 heures de la fenêtre de temps.
Maintenir une attitude d'apprentissage:
- Partagez constamment les connaissances au sein de l'équipe pour que les gens soient au courant de ce qui se passe dans l'équipe. Si les futures versions nécessitent des améliorations de la suite d'automatisation, n'importe quel membre de l'équipe peut effectuer les mises à jour nécessaires.
- Tenez-vous au courant pour assurer la réussite du projet, de l'équipe ou de l'entreprise.
- Demandez l'aide de la communauté. Cela peut être à l'intérieur de l'entreprise & ou à l'extérieur de l'entreprise.
Erreurs courantes à éviter lors de l'approche de l'automatisation des tests et de l'automatisation des tests de maintenance.
- Les outils ou l'automatisation des tests ne peuvent pas résoudre un problème donné si l'attention au projet de test logiciel manque dans l'équipe.
- Il n'est pas recommandé d'avoir l'esprit d'automatiser tous les cas de test, mais plutôt de suivre la stratégie d'automatisation des tests, la portée, la nécessité, le coût et le temps déterminés par l'équipe/le projet.
- Adopter l'attitude selon laquelle nous devrions automatiser tous les bugs trouvés dans les différents environnements et cas de test n'est pas la pratique recommandée.
- Ne pas suivre le principe du Paradoxe du Pesticide (ce qui signifie ne pas mettre à jour régulièrement les cas de tests/ suites de tests, qui ont été automatisés à un moment donné). Dans certaines situations, les équipes automatisent le flux de travail. Dans ce cas, le flux de travail doit être mis à jour régulièrement.
- Traiter Selenium comme le seul outil pour l'automatisation des tests, et mettre en œuvre tous les tests automatisés en utilisant Selenium comme outil pour toutes les couches comme les tests API et DB n'est pas une pratique recommandée. Idéalement, l'approche devrait consister à automatiser les tests en utilisant le bon ensemble d'outils, et la bonne couche sera bénéfique pour le projet.
- Ne pas automatiser en tenant compte de la façon dont les utilisateurs réels vont utiliser les applications logicielles en temps réel. Par exemple, de nombreuses équipes de développement logiciel automatisent les cas de test en utilisant des agents utilisateurs, des émulateurs, des simulateurs, des navigateurs sans tête, etc. L'utilisateur réel n'utilisera aucun de ces éléments, alors pourquoi l'équipe mène-t-elle de telles activités dans le seul but de mettre en place la secousse des tests d'automatisation ?
- Les testeurs de l'équipe de développement logiciel ont un manque de connaissances sur les outils d'automatisation des tests. Alors comment peuvent-ils contribuer à une telle situation pour tester le code de maintenance?
- Manque d'appropriation et de temps dans l'équipe pour aborder l'automatisation des tests et sa maintenance.
- Utiliser un cadre d'automatisation des tests simplement parce qu'il est open-source n'est pas une méthode de travail recommandée.
- Le manque de coordination et de communication entre les membres de l'équipe peut affecter les efforts d'automatisation des tests de maintenance.
- Nous ne devrions pas utiliser l'automatisation comme un retour sur investissement, ce qui inclut également l'utilisation des mauvaises métriques pour mesurer le succès du projet et la contribution des tests automatisés.
- Ne pas prêter attention au cycle vicieux de vérifications automatisées rouge-vert fourni par tout résultat de test automatisé. Cette situation ne profitera pas à l'équipe en ayant des tests automatisés en place.
- Ne pas résoudre un seul problème ou même avoir un seul objectif à la fois du point de vue du code de test de maintenance. S'attaquer à tout en même temps met en péril l'équipe.
- Utiliser l'automatisation des tests pour surmonter des défis distincts au sein de l'équipe (comme un processus), sans avoir la vision plus profonde de l'utilisation de l'automatisation des tests pour ses avantages.
- Automatisation de tâches plus importantes/complexes par opposition à l'automatisation. L'automatisation est une tâche qui prend du temps alors que l'équipe peut consacrer ses efforts à la résolution de problèmes simples.
- Se concentrer uniquement sur l'automatisation, même lorsque le projet exige l'utilisation d'autres techniques de test (comme les tests exploratoires).
- Une assertion et une validation insuffisantes dans les cas de tests automatisés existants ne profiteront pas à l'équipe qui a mis en place l'automatisation des tests.
- L'équipe a un énorme manque de connaissances sur l'application logicielle en cours de développement, et a toujours l'attitude d'aborder l'automatisation et la maintenance des cas de test automatisés. Cette situation peut être bénéfique pendant une courte durée, mais à long terme, elle peut être plus nuisible.
- Ne pas impliquer toutes les parties prenantes. Les testeurs automatisent les contrôles en silos et gaspillent les efforts, le temps et les coûts nécessaires à la réussite du projet.
- Manque d'effort envers l'automatisation des tests de maintenance dans l'équipe de développement du logiciel.
- Avoir trop d'attentes vis-à-vis du code d'automatisation des tests. Par exemple, les tests automatisés trouveront tous les bugs. Non, ce ne sera pas le cas !
Pour résumer cette partie, j'aimerais partager cette pensée : "facile, simple, collaboration, état d'esprit de croissance comme dans toutes choses, le contexte importe, et aucun projet et aucune personne ne sont les mêmes".
Conclusion
J'écris mes pensées avec les pensées motivantes sur la "maintenance" que j'ai lu et qui m'ont inspiré.
Construire demande de la passion et de l'énergie. La maintenance est horrible. Ce n'est que de la fatigue. Une fois que vous avez atteint le sommet, maintenir cette bête est affreux, mais c'est d'une importance cruciale.'' - Urban Meyer. De même, la maintenance de code d'automatisation des tests est la maintenance de code d'automatisation peut être fastidieux, mais il peut être très gratifiant lorsque vous constatez que votre prochaine version permet des activités de test plus rapides et de meilleure qualité".
J'aimerais apprendre de vous. Veuillez partager dans la section des commentaires vos méthodes/trajets/défis en abordant le maintenance du code de test ?
Réviseur: Profonde gratitude à JeanAnn pour avoir revu cet article, en donnant ses précieux conseils et son temps.