Fin mars, la rencontre du
serveur Allure s'est tenue au bureau de Wrike St. Petersburg. En quelques heures, nous avons réussi à mettre des informations concentrées sur le nouvel outil
serveur Allure , sur les pratiques modernes de travail avec la documentation de test et les auto-tests, et sur une expérience intéressante dans l'interaction des tests Wrike et un nouveau fournisseur sur le marché des systèmes TMS.
Pour ceux qui n'ont pas pu venir, nous publions des vidéos de reportages.
Anton Bashkirov (Wrike QA Lead) a parlé du concept et du produit serveur Allure lui-même, de la façon dont nos besoins de documentation de test rapide et bon marché et de travail centralisé avec lui ont grandi ensemble et ont pénétré les idées de l'équipe
qameta.io . J'ai décrit nos autres plans pour travailler avec le serveur Allure.
Anton Bashkirov - Serveur Allure: transformation de la gestion des cas de test dans Wrike
Le processus de documentation habituel peut ressembler à ceci: QA Manual écrit une liste de contrôle → écrit des cas de test → les donne à l'automatisation → prend en charge la documentation lorsque les autotests changent. Nous avons compris comment simplifier et réduire le coût de cette chaîne en intégrant QA et QAA dans un flux de travail d'équipe commun, en passant à un système de documentation unifié.
Nous apprenons à utiliser tous les artefacts de test comme documentation pour notre produit, nous utilisons activement des annotations de code d'autotest, en les associant aux fonctionnalités correspondantes dans la base de données de profils de serveur, ce qui nous permet de travailler avec des cas de test, des listes de contrôle, des tests end2end et d'intégration dans un seul écosystème ordonné .
Ivan Varivoda (automatisation Wrike QA) a couvert l'histoire de la quarantaine de tests, ce qui est très important pour nous, ce qui nous permet de mettre la sortie des lancements, la réparation et le retour des autotests stabilisés dans le flux. Encore une fois, il s'agit d'une solution conçue d'abord séparément du serveur Allure et intégrée à ce système en collaboration avec les développeurs.
Ivan Varivoda - Tests de quarantaine ou comment ne pas devenir fou avec les tests de sélénium 10K
Dans l'automatisation des tests, malheureusement, les situations ne sont pas rares lorsque certains des autotests cessent temporairement de fonctionner correctement. Il s'agit peut-être de flacons de test ou leurs performances ont été affectées par un problème d'infrastructure ou un bogue - d'une manière ou d'une autre, nous devons «désactiver» ces tests dès le début ou les ignorer.
Lorsqu'un projet a un petit nombre de tests et qu'ils ne poursuivent pas souvent - il n'y a pas de problèmes particuliers, mais avec l'augmentation du nombre de tests et de démarrages quotidiens, il devient extrêmement nécessaire de désactiver les tests interrompus le plus rapidement possible et de pouvoir contrôler les tests «off».
Artyom Eroshenko (qameta.io), Mikhail Levin (directeur Wrike QA) avec la participation de
Dmitry Baev (qameta.io) et le public ont discuté du serveur Allure et, en général, des opinions sur la documentation de test moderne.
