L'inscription est ouverte pour Allure Server Meetup à Saint-Pétersbourg

Nous vous invitons au Meetup Allure Server , qui se tiendra le 21 mars dans le bureau de Saint-Pétersbourg de Wrike.
Chaque département de test s'engage à accélérer et à accélérer la qualité. Chez Wrike, nous écrivons un grand nombre d'autotests, les exécutons le plus rapidement possible et nous nous efforçons en même temps de consacrer un minimum de temps à leur support et à leur documentation. Nous coopérons depuis longtemps avec qameta.io concernant les frameworks et outils d'automatisation. Donc, depuis plus d'un an maintenant, nous roulons dans le nouveau système TMS - Allure.Server, qui correspond bien à nos idées sur la réalisation de la documentation de test et la gestion des autotests. Lors de la réunion Allure.Server, nous parlerons davantage de ce système, des modèles d'utilisation et des implémentations techniques en plus de ce système.

Au programme:

Anton Bashkirov - Serveur Allure: transformation de la gestion des cas de test dans Wrike

Je vais parler de la façon dont nous, chez Wrike, en utilisant Allure Server, avons organisé le processus de création de la documentation de test sur le principe de la «documentation à partir des auto-tests».

Le processus de documentation habituel peut ressembler à ceci: QA Manual écrit une liste de contrôle → écrit des cas de test → les donne pour 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 sur notre produit, nous utilisons activement les annotations du code d'autotest, en les associant aux attributs correspondants dans la base de données d'allure du serveur, ce qui nous permet de travailler avec des cas de test, des listes de contrôle, des autotests et même des tests unitaires d'intégration dans un seul écosystème ordonné .

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 une 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».

Nous allons vous expliquer comment désactiver rapidement les tests, en quoi consiste la quarantaine de tests, pourquoi elle est nécessaire, comment elle fonctionne chez Wrike et qu'est-ce que Allure Server a à voir avec cela.

Discussion: Artyom Eroshenko, Mikhail Levin

Dans le format du dialogue qui va aux questions du public, nous discuterons des problèmes et des directions de développement de la gestion des tests, de l'interaction avec Qameta et des plans futurs pour le serveur Allure.

Nous vous attendons au bureau de Wrike du 21 mars à 19h00.

Inscription

UPD: entrées de rapport habr.com/ru/company/wrike/blog/454730