Il y a quelque temps, j'ai écrit
un article sur mon expérience dans l'organisation du travail d'ingénieur QA sur un projet. Maintenant, je veux continuer ce sujet, mais dans une direction plus étroite - l'automatisation des tests. Il s'agira
du même projet , il est petit, mais évolue selon les demandes des clients réguliers. Peut-être que mon approche n'est pas très adaptée aux équipes de dizaines d'employés et que chacun est responsable de sa part (à mon avis, chaque projet doit être strictement réglementé, sinon il est tout simplement impossible de gérer un tel colosse, même s'ils trouveront un grain sain), mais il sera certainement intéressant pour ceux qui, comme moi, ont une fois trouvé un nouvel emploi et se sont tenus à la croisée des chemins pour organiser leur propre place sous le nouveau soleil.
Se préparer à étudier
Alors, comment organiser l'automatisation des tests sur un projet? Si votre réponse est de prendre le merveilleux sélénium et une sorte de cadre pour cela et ainsi de suite, à partir de la hauteur de 13 ans d'expérience dans les tests, je ne le ferais pas avec certitude. Devra maîtriser de nouveaux horizons.
Qu'est-ce qui est lourd avec l'approche de "faire des cycles dans le sélénium"? Et le fait que vous ayez déjà lu et entendu plus d'une fois. Le fait que ces tests soient de l'interface utilisateur, ils sont coûteux et longs à la fois en écriture et en exécution, et pour maintenir les performances. Tout le monde le sait, mais toute la douleur de cette vérité n'est rencontrée que lorsqu'elle est ignorée. Les autotests de bout en bout de l'interface utilisateur devraient être obligatoires, personne sauf eux ne vous donnera l'assurance que ce que le client
verra après le prochain déploiement ne sera pas une déception pour lui. Mais ils ne doivent pas devenir le centre d'automatisation de vos tests.
Prenez
Test Pyramid Principles comme centre de contrôle qualité. Les mêmes, dont beaucoup a déjà été dit, mais dans la pratique, tous les AQ ne comprennent pas comment appliquer cette pyramide.
Il est dessiné comme ceci:
Et comme ça:
Chacun trouvera une option pour son architecture.
Mettre les principes de la pyramide de test en AQ
Premièrement, peu importe à quel point il peut être paresseux et inhabituel, maîtrisez les tests à peau blanche et devenez un «développeur partiel».Relancez le projet localement, comme le font tous les développeurs (à coup sûr, le projet a de la documentation sur la façon de le faire, trouvez-le). Vous allez probablement cesser de maudire cette entreprise une douzaine de fois, en le faisant pour la première fois, vous aurez un million de questions et de problèmes, mais quand vous le ferez, vous en saurez déjà beaucoup: quelles sont les idées architecturales, quelle base de données, d'où sont transmises, où sont les configurations nécessaires , et surtout, où les autotests sont stockés et comment les exécuter.
Deuxièmement, traitez les autotests écrits par les développeurs eux-mêmes.Trouvez leur place dans la structure du projet, quels types de tests et d'outils sont utilisés, comment ils sont lancés. Évaluez la couverture du projet avec des autotests, apprenez à les parcourir. Il existe de nombreux outils pour l'évaluation automatique de la couverture, vous pouvez l'utiliser, mais je n'en parle pas maintenant. Je suis plus sur le développement de vos instincts: prenez un morceau de fonctionnalité et voyez comment elle est couverte par des tests automatiques: bons ou mauvais. Si c'est bon, vous devriez être calme pour cette partie; si c'est mauvais, vous vous êtes trouvé un front de travail pour les jours où il n'y a pas de tâches urgentes à l'ordre du jour. En attendant, gardez à l'esprit que lors de chaque exécution, gardez à l'esprit que cette place dans le code est vulnérable.
Troisièmement, prenez courage, examinez la demande d'appel des développeurs.Chaque fois que vous commencez à développer une nouvelle fonctionnalité, notez-en tous les cas de test. Marquez ceux que vous devez nécessairement automatiser afin de ne pas revenir au test manuel de cette fonctionnalité. Passez en revue les demandes d'extraction des développeurs et exigez raisonnablement la mise en œuvre des autotests qu'ils ont manqués. Plusieurs fois, je suis tombé sur des développeurs très cool qui ont écrit des tests sympas, mais même ils ont cédé à un bon contrôle qualité pour comprendre comment le client final utilisera probablement le produit. Par conséquent, même pour les spécialistes chevronnés, il y a quelque chose à recommander lors de la rédaction des autotests.
Quatrièmement, soyez encore plus courageux et écrivez les autotests directement dans le code produit.Oui, tout comme les développeurs. À égalité avec eux. Chaque fois que vous rencontrez un scénario de test qui doit être automatisé, ne vous précipitez pas pour l'implémenter immédiatement avec des outils distincts qui ne sont utilisés qu'au sein de l'équipe QA. Et tout d'abord, posez-vous la question: peut-il être automatisé via des auto-tests unitaires / d'intégration dans le code produit? Si c'est le cas, faites-le. Si cela fait peur, alors ce n'est effrayant que pour la première fois, mais quel niveau de vos compétences, car des programmeurs expérimentés examineront vos demandes de tirage. Oui, au début, tout ce que vous avez fait sera détruit, mais le développement implique toujours de la douleur :) Mais à la fin, vous recevrez de merveilleux dividendes:
- ces tests seront pris en charge par toute l'équipe de développement
- ils travailleront en continu, en continu et rapidement
- ils seront intégrés dans CircleCi et s'exécuteront chaque fois qu'ils se déploient automatiquement (si cela est implémenté sur le projet)
- les trous seront corrigés lors des tests (vous écrivez ce qui n'a pas été écrit avant vous)
- vous pouvez aider les développeurs à écrire des tests s'ils n'ont pas le temps
Cinquièmement, créez un petit ensemble limité d'autotests de bout en bout de l'interface utilisateur qui imitent les actions d'un utilisateur final dans un navigateur.Ce seront des tests qui ne seront pris en charge que par l'équipe QA. Ils peuvent être incarnés
- les scénarios clients critiques les plus populaires
- le fait que dans les tests d'intégration dans le code principal, il n'est pas possible d'implémenter complètement, par exemple, de travailler avec des services tiers
Et oui, vous avez maintenant accès au projet, et vous n'avez pas besoin de mettre à jour le front-end du projet afin d'avoir des localisateurs pratiques et fiables pour Selenium. Pas besoin d'attendre et de demander qui que ce soit - ouvrez les demandes de tirage dans le code produit principal.
Ce qui en sort
Maintenant, je travaille sur un tel scénario. Par conséquent, au sommet de ma pyramide de tests, il n'y a que 9 tests de bout en bout. Et leur soutien est de ma responsabilité. Et toutes les autres dizaines et centaines de tests cohabitent avec le code produit principal, commencent leur travail sur l'ordinateur local du développeur et sont pris en charge par toute l'équipe d'ingénieurs.
Mes tests de bout en bout fonctionnent pendant un certain temps, car ils téléchargent des fichiers vidéo sur la plate-forme, puis les convertissent avec différents paramètres, les envoient pour traitement à des services tiers, attendent une réponse, etc., sans stubs. Par conséquent, dans les autotests, il y a de nombreux moments d'attente pour la fin de l'opération. L'équipe n'aimait pas la perspective d'avoir de tels tests dans CircleCi, et ce n'est pas vraiment nécessaire. Je les ai donc implémentés comme un travail à Jenkins.
Une fois toutes les vérifications de test dans le code produit terminées, nous déployons le brunch testé dans l'environnement de test et exécutons des tests de bout en bout sur celui-ci à l'aide de Jenkins. Encore quelques tests fonctionnels manuels pour plus de fidélité de la part de QA et c'est tout, vous pouvez fusionner le brunch dans le maître. Aujourd'hui, je ne suis pas le seul à piloter Jenkins pour les autotests dans un environnement de test, les développeurs les lancent constamment lorsqu'ils ont besoin de générer de nouvelles données de test et de simuler l'activité des utilisateurs. Ils sont peu nombreux, ils sont donc stables et fonctionnent toujours. Pratique pour tout le monde.
Je noterai un autre avantage agréable pour l'ingénieur QA dans une telle implémentation de la pyramide de test. Il s'avère que vous faites partie intégrante d'une équipe d'ingénieurs. Vous faites vraiment partie intégrante d'un même travail - écrivez du code avec tout le monde, regardez le code des développeurs, communiquez avec eux, et ils font de même pour vous. Vous voyez le travail de chacun, une meilleure collaboration, un renforcement d'équipe plus fort. Vous comprendrez le projet non seulement de l'extérieur, mais aussi de l'intérieur, digne de respect, n'est-ce pas?
Adieu final
Mon article ne prétend pas être une pilule universelle qui peut être utilisée à tout moment et en tout lieu. Tous les projets sont très différents, toutes les équipes sont très différentes - chacun doit construire lui-même son meilleur chemin, souvent c'est la quintessence de différentes approches et outils. Même le célèbre Scrum, combien de projets j'ai vus, chacun professe à sa manière :) Je ne crois généralement pas aux instructions strictes, je crois qu'elles sont nécessaires comme lignes directrices et je dois agir en fonction de la situation.
Cependant, le monde informatique se développe et de plus en plus de personnes y entrent, donc je suis sûr que parmi les lecteurs de ce matériel, il y aura certainement quelqu'un à qui mes petites instructions m'aideront à choisir la bonne voie. Souriez-moi dans les commentaires si c'était utile :), les retours me seront agréables!