Je m'appelle Maria Snopok, je suis la responsable de la direction de l'automatisation au sein du département des tests du département de développement et de support des produits Big Data du groupe X5 Retail. Dans cet article, je partagerai notre expérience de la mise en œuvre des autotests et de la réduction des coûts associés. Espérons que ces informations seront utiles pour les équipes qui ont du mal à passer aux tests automatisés.
Comment nous sommes arrivés aux autotests
Avant l'avènement de l'automatisation, j'ai travaillé en tant que responsable des tests sur l'un de nos produits. Lorsqu'un modèle de test assez volumineux a été formé là-bas, nous avons commencé à distribuer le pool de tests de régression à toute l'équipe de développement - si elle est responsable de la publication, alors elle teste également. Une telle régression d'équipe a résolu les tâches suivantes:
- les développeurs qui avaient précédemment traité leurs différentes fonctionnalités ont pu voir l'ensemble du produit;
- nous avons accéléré la régression et publié plus souvent à cause de cela;
- nous n’avons plus réduit les recours - la qualité s’est améliorée.
Mais c'était cher, car les tests étaient effectués par des spécialistes coûteux - développeurs et analystes - et nous avons commencé à évoluer vers l'automatisation.
Les tests de fumée ont été les premiers à être lancés - des vérifications simples pour s'assurer que les pages s'ouvrent, se chargent, ne plantent pas et que toutes les fonctionnalités de base sont disponibles (jusqu'à présent sans vérifier la logique et les valeurs).
Nous avons ensuite automatisé des scripts positifs de bout en bout. Cette étape a apporté le maximum d'avantages: des tests ont permis de s'assurer que les principaux processus métiers du produit fonctionnaient, même s'il y avait des erreurs dans des scénarios négatifs, alternatifs et secondaires.
Et enfin, nous sommes arrivés à l'automatisation des contrôles de régression avancés et des scénarios alternatifs.
À chacune de ces étapes, nous avons été confrontés à un certain nombre de difficultés qui ont sérieusement ralenti et compliqué l'ensemble du processus. Quelles solutions pratiques nous ont permis d'accélérer et de faciliter le travail des automates?
Quatre façons de réduire les coûts des tests automatiques
1. Convenir des formats des attributs de test à terre
Les développeurs et les testeurs automatisés doivent convenir à l'avance des règles de dénomination des éléments HTML pour leur utilisation ultérieure en tant que localisateurs dans les tests automatiques. Il est souhaitable d'avoir le même format pour tous les produits. Nous avons développé des exigences pour comprendre comment nommer les attributs, avant même que la fonctionnalité ne soit transférée en développement; cette compréhension existe à la fois du côté des développeurs et du côté des testeurs. Nous avons convenu que chaque élément html visible se voit attribuer un attribut data-qa personnalisé, par lequel le testeur le recherchera. L'attribut est nommé selon le modèle suivant:
[nom d'écran] [nom du formulaire / de la table / du widget] [nom de l'élément]
Exemple:
data-qa = "plu-list_filter-popover_search-input"
data-qa = "common_toolbar_prev-state"
Il est facile d'isoler un tel attribut simplement de la documentation et de la mise en page, et tout le monde sait quelle devrait être sa signification. Lorsqu'un développeur entreprend une tâche, il attribue, selon ces règles, des attributs data-qa à tous les éléments visibles de la page - en-têtes, boutons, liens, sélecteurs, lignes et colonnes de tableaux, etc. En conséquence, le testeur peut commencer à écrire des autotests même en cours de développement d'une fonctionnalité, basée sur uniquement à la mise en page et à la documentation, car il sait déjà comment les attributs seront nommés.
L'introduction d'attributs de test nous a permis de réduire les coûts de développement et de support des autotests de 23% en moyenne par rapport à la période précédente en réduisant les coûts de mise à jour des tests et de localisation des éléments pour les autotests.
2. Nous écrivons des tests manuels afin qu'ils soient faciles à automatiser
Les testeurs manuels et les ingénieurs en automatisation vivent dans des univers différents. Les manuels visent à vérifier plusieurs objets de test à proximité différents avec un seul script. Les automates, quant à eux, ont tendance à tout structurer et à ne vérifier que les objets du même type dans un seul test. Pour cette raison, les tests manuels ne sont pas toujours faciles à automatiser. Lorsque nous avons reçu des cas manuels d'automatisation, nous avons été confrontés à un certain nombre de problèmes qui ne nous ont pas permis d'automatiser mot pour mot les scripts résultants, car ils ont été écrits pour une exécution facile par une personne vivante.
Si un automate est profondément immergé dans le produit, il n'a pas besoin de cas "manuels", il peut écrire lui-même un script pour l'automatisation. S'il arrive au produit «de l'extérieur» (dans notre département, en plus des testeurs, les équipes ont également des tests en tant que service dédié), et qu'il existe déjà un modèle de test et des scripts préparés par des testeurs manuels, vous serez peut-être tenté de lui demander d'écrire des autotests sur la base de ces cas de test «manuels».
Ne cédez pas à cela: le maximum pour lequel un automate peut utiliser des cas de test manuels est juste de comprendre le fonctionnement du système du point de vue de l'utilisateur.
En conséquence, il est nécessaire de préparer dans un premier temps des tests manuels afin qu'ils puissent être automatisés , et pour cela de traiter des problèmes courants.
Problème 1: simplifier les cas manuels.
Solution: détailler les cas.
Imaginons une description d'un cas manuel:
- ouvrir la page de la liste des versions de révision
- cliquez sur le bouton Créer
- remplir le formulaire
- cliquez sur le bouton "créer"
- assurez-vous que la version de révision est créée
C'est un mauvais scénario pour l'automatisation, car il ne spécifie pas exactement ce qui doit être ouvert, avec quelles données remplir , ce que nous attendons exactement de voir et dans quels champs les regarder. Les instructions "s'assurer que la version a été créée avec succès" ne sont pas suffisantes pour l'automatisation - la machine a besoin de critères spécifiques permettant de s'assurer que l'action est réussie.
Problème 2: branchement de cas.
Solution: le cas ne doit avoir qu'un scénario linéaire.
Les constructions avec "ou" apparaissent souvent dans des boîtiers portatifs. Par exemple: "ouvrir la révision 184 sous l'utilisateur 1 ou 2". Ceci est inacceptable pour l'automatisation, l'utilisateur doit être clairement indiqué. Les conjonctions «ou» doivent être évitées.
Problème 3: non-pertinence du cas.
Solution: vérifiez les cas avant de les soumettre à l'automatisation.
C'est le plus gros problème pour nous: si la fonctionnalité change fréquemment, les testeurs n'ont pas le temps de mettre à jour les cas de test. Mais si un testeur manuel rencontre un cas non pertinent, il ne lui sera pas difficile de corriger rapidement le script. Un automate, surtout s'il n'est pas immergé dans le produit, ne pourra pas le faire: il ne comprendra tout simplement pas pourquoi le boîtier ne fonctionne pas bien, et le percevra comme un bug de test. Passera beaucoup de temps sur le développement, après quoi il s'avère que la fonctionnalité testée a longtemps été coupée et que le script n'est pas pertinent. Par conséquent, la pertinence de tous les scripts d'automatisation doit être vérifiée.
Problème 4: pas assez de conditions préalables.
Décision:pile complète de données auxiliaires pour l'exécution du cas.
Les testeurs manuels ont tendance à se brouiller les yeux et, par conséquent, lorsqu'ils décrivent les conditions préalables, ils passent à côté de certaines nuances qui sont évidentes pour eux, mais pas évidentes pour les automates qui ne sont pas si familiers avec le produit. Par exemple, ils écrivent: «ouvrir une page avec un contenu calculé». Ils savent que pour calculer ce contenu, vous devez exécuter un script de calcul, et l'automate, qui voit le projet pour la première fois, décidera qu'il est nécessaire de prendre quelque chose de déjà calculé.
Conclusion: dans les conditions préalables, il est nécessaire de rédiger une liste exhaustive des actions à effectuer avant de démarrer le test.
Problème 5: plusieurs contrôles dans un scénario.
Décision:pas plus de trois vérifications par scénario (sauf pour les scénarios coûteux et difficiles à reproduire).
Les testeurs manuels ont très souvent le désir d'économiser de l'argent sur les cas, en particulier lorsqu'ils sont lourds, et de tester autant que possible dans un scénario, en y entassant une douzaine de tests. Cela ne devrait pas être autorisé, car à la fois dans les tests manuels et automatisés, cette approche pose le même problème: le premier test n'a pas réussi, et tous les autres sont considérés comme non réussis ou ne démarrent pas du tout dans le cas de l'automatisation. Par conséquent, dans les scripts d'autotest, de 1 à 3 contrôles sont autorisés. Les exceptions sont des scénarios vraiment difficiles qui nécessitent des pré-calculs longs, ainsi que des scénarios difficiles à reproduire. Ici, vous pouvez compromettre la règle, même s'il vaut mieux ne pas le faire.
Problème 6: dupliquer les chèques.
Solution: pas besoin d'automatiser encore et encore la même fonctionnalité.
Si nous avons la même fonctionnalité sur plusieurs pages, par exemple un filtre standard, alors cela n'a aucun sens de le vérifier partout lors des tests de régression, il suffit de chercher au même endroit (à moins, bien sûr, que nous parlions d'une nouvelle fonctionnalité). Les testeurs manuels écrivent des scripts et testent des choses comme ça sur chaque page - simplement parce qu'ils regardent chaque page de manière isolée, sans entrer dans la structure interne. Mais les automates doivent comprendre que les tests répétés de la même chose sont une perte de temps et de ressources, et il leur est assez facile de détecter de telles situations.
La solution des problèmes ci-dessus nous a permis de réduire le coût de développement des autotests de 16%.
3. Synchronisation avec les équipes produits sur la problématique du refactoring, de la refonte, des changements significatifs de fonctionnalité, afin de ne pas écrire de tests "sur la table"
Dans notre département Big Data, où 13 produits sont développés, il existe deux groupes d'automates:
- automates directement dans les équipes produit;
- un service de flux d'automatisation en dehors des équipes produits, engagé dans le développement du framework et des composants communs et travaillant sur les demandes des produits avec des tests fonctionnels prêts à l'emploi.
Les automates de flux ne sont pas si profondément impliqués dans le produit au départ, et avant de ne pas assister aux réunions d'équipe quotidiennes, car cela prendrait trop de temps. Une fois que cette approche nous a laissé tomber: nous avons accidentellement appris de sources tierces qu'une équipe allait refactoriser son produit (décomposer le monolithe en microservices), c'est pourquoi certains des tests que nous avons écrits sont envoyés à l'archive. C'était très douloureux.
Afin d'éviter que cela ne se produise à l'avenir, il a été décidé qu'au moins une fois par semaine, un automate du flux viendrait aux réunions de l'équipe de développement pour se tenir au courant de ce qui se passe avec le produit.
Nous avons également convenu que les tests ne sont automatisés que pour les fonctionnalités prêtes à être produites et ne subissent pas de changements fréquents (régression). Nous devons être sûrs qu'au moins dans les trois prochains mois, il n'y aura pas de refactoring ou de retouches majeures, sinon les automates n'auront tout simplement pas le temps avec les tests.
Les économies de coûts résultant de la mise en œuvre de ces mesures sont plus difficiles à calculer. Nous avons pris le temps de développer des autotests comme base, qui ont perdu de leur valeur en raison de la transition prévue d'une partie des fonctionnalités vers les microservices. Si nous connaissions cette transition à l'avance, nous ne couvririons pas la fonctionnalité variable avec des autotests. La perte totale (également appelée économies potentielles) est de 7%.
4. Mise à niveau d'un testeur manuel vers un ingénieur en automatisation
Il y a peu d'automates de test sur le marché du travail, en particulier les bons, et nous les recherchons activement. Nous améliorons également activement les testeurs manuels existants qui ont un désir et une compréhension de base de l'automatisation. Nous envoyons tout d'abord de telles personnes suivre des cours de langage de programmation, car nous avons besoin d'automates à part entière et de tests automatiques à part entière, et des enregistreurs, à notre avis, il y a plus de moins que d'avantages.
Parallèlement à l'apprentissage d'un langage de programmation, une personne apprend à écrire des scripts corrects et structurés sans problème à partir du point 2, à lire et à analyser les résultats des rapports d'autotest, à corriger les erreurs mineures dans les localisateurs, les méthodes simples, puis à maintenir des tests prêts à l'emploi et à écrire les leurs. Tout le développement a lieu avec le soutien de collègues expérimentés du service de flux. À l'avenir, ils peuvent participer à la finalisation du framework: nous avons notre propre bibliothèque, évolutive pour tous les projets, elle peut être améliorée en ajoutant quelque chose de notre propre.
Cette direction de réduction des coûts n'en est qu'à ses débuts, il est donc trop tôt pour calculer les économies, mais il y a tout lieu de croire que la formation du personnel contribuera à réduire considérablement les coûts d'exploitation. Et en même temps, cela donnera à nos testeurs manuels l'opportunité de se développer.
Résultat
Désormais, nous avons automatisé environ 30% des tests sur cinq produits, ce qui a permis de diviser par deux la durée des tests de régression.
C'est un bon résultat, car le temps est d'une grande importance pour nous: nous ne pouvons pas tester indéfiniment et nous ne pouvons pas donner le produit sans vérification; L'automatisation, d'autre part, nous permet de fournir le volume requis d'inspections de produits au moment optimal. À l'avenir, nous prévoyons d'augmenter le pourcentage d'autotests à 80-90% afin de publier des versions aussi souvent que possible, mais en même temps de ne pas couvrir les projets avec des autotests où les tests manuels sont encore plus rentables.