Bonjour à tous, je m'appelle Sergey. Je teste le frontend Yandex.Market. Je sais que parmi les lecteurs de Habr, il existe de nombreux spécialistes informatiques qui sont en quelque sorte liés au processus de publication et aux tests. J'ai une question pour toi. Est-il déjà arrivé dans votre pratique que les fonctionnalités ne tournent pas longtemps en production? Connaissez-vous les rejets gonflés et leurs contrôles volumétriques?
Je pense que tout le monde avait ça. Je suis arrivé chez Yandex il y a 3 ans, notre équipe était très jeune, les processus n'étaient pas complètement établis. Et j'ai rencontré ces problèmes face à face.
Comme c'était
À cette époque, nos équipes produits n'avaient pas de domaine de responsabilité spécifique et n'étaient engagées que dans le projet pour lequel elles avaient été créées. Puis ils se sont effondrés. Les tests n'étaient pas non plus liés aux équipes de développement. Il existait en tant que service et connecté au projet selon les besoins.
Les tâches n'étaient vérifiées qu'à la main, les tests d'intégration étaient instables, le pourcentage de couverture avec les autotests était faible. Le contrôle a duré très longtemps. Le pool de tâches prêtes pour le calcul était en constante augmentation et pouvait atteindre des tailles énormes.
En ce qui concerne les versions, l'un des directeurs s'est occupé du montage et du calcul. Nous avons tenu des réunions avec tous les managers et décidé de ce qui tomberait dans la prochaine version et de ce qui pourrait être reporté.
Ils ont vérifié les communiqués au hasard: celui qui a eu le temps de les vérifier, il les a vérifiés. L'accent était mis sur les tests de régression manuels, qui pouvaient durer plusieurs jours. Et cela malgré le fait que la version a lancé un pack d'autotests et qu'un département les a écrits et pris en charge.
Ainsi, le problème résolu est tombé dans les tests et pourrait être testé jusqu'à 2 jours. Ensuite, elle est entrée dans la version, elle a été vérifiée pendant 4 jours supplémentaires. En prod, la tâche s'est avérée au mieux en une semaine. Peu de gens l'ont aimé, il a fallu changer quelque chose. Et la chose la plus importante à changer est les processus.
Contour
La première chose que nous avons faite a été d'introduire une division en contours - des équipes de spécialistes de divers domaines. Contrairement aux équipes précédentes, les contours ne se décomposent pas après la fin du projet. Ils continuent de générer de nouveaux projets et idées dans leur domaine de responsabilité.
De 1 à 3 testeurs sont responsables des tests dans chaque circuit. Chaque testeur de circuit responsable est présent à toutes les étapes du développement du produit, de l'idée au débriefing.
En service
Pour structurer le travail des versions, nous avons introduit deux rôles dans notre équipe de test: le maître des versions et le testeur des versions. En tant que maître de la libération, nous avons 4 testeurs en service à la fois, tout le monde est impliqué dans la tâche de libération. Pour chacun de ces rôles, nous avons organisé un horaire de service.
Les tâches qui surviennent pendant le service ont priorité sur le test des fonctionnalités du produit dans les circuits. Pour que les testeurs n'aient pas à attendre longtemps sans interruption, le devoir de libération est organisé comme suit: un quart est en service du lundi au mercredi, le second - du mercredi à la fin du vendredi. Dans chaque quart de travail - 4 personnes, 2 personnes par plate-forme.
La documentation
Et la documentation? Nous n'en avons pas beaucoup, mais ça l'est. Par exemple, lors du déploiement de fonctionnalités, nous déterminons avec les développeurs et le gestionnaire le nombre optimal d'autotests. Si nous ne pouvons pas automatiser quelque chose, ou si une fonctionnalité nécessite une publication immédiate sans autotests, nous écrivons un cas dans la suite de tests de tous les cas de vérification du marché et, si nécessaire, nous l'incluons dans la suite de tests de publication des tests de régression.
Si nous vérifions les correctifs de bogues et constatons que l'autotest n'a pas été écrit sur le bogue, nous définissons également la tâche pour le développer, et l'édition commence immédiatement avec le test écrit dessus.
Lors de la présentation de chaque expérience, nous avons une liste de contrôle, car nous ne savons pas à l'avance si l'expérience réussira.
Une liste de contrôle est un ensemble de contrôles positifs sur les caractéristiques d'une expérience. Le testeur de versions l'utilise avec chaque version pendant que l'expérience fonctionne. Cette liste de contrôle peut également être vierge pour les futures tâches d'automatisation si l'expérience réussit et que nous la déployons à 100% des utilisateurs.
Lors de la vérification des versions, nous utilisons différents kits de test en fonction de la complexité et de la plénitude de la version. Nous avons à la fois de petites suites de tests et des suites avec le nombre maximum de cas de test. Quelle suite de tests utiliser, le testeur de versions décide.
Dans certains domaines, nous utilisons également la liste de contrôle des contrôles positifs pour les développeurs. Avec lui, le développeur peut vérifier lui-même la tâche et prévoir des goulots d'étranglement dans le développement des fonctionnalités. Si le testeur a changé de projet, cela aidera le nouveau spécialiste à rejoindre rapidement le projet. Les listes de contrôle sont écrites avant le début du développement, immédiatement après la planification de la tâche.
C'est tout pour les quais.
Comment nous testons les tâches
Nous utilisons diverses techniques de conception de tests: classes d'équivalence, valeurs limites, tests par paires, scénarios utilisateur. L'expertise du testeur est également très importante. Le marché est une grosse machine, et vous devez savoir comment fonctionnent toutes ses pièces pour réparer ou améliorer quelque chose. Par exemple, nous avons 4 types de cartes de produits et 6 types de problèmes de produits. Sans le savoir, il est tout simplement impossible de tester qualitativement la tâche de modification de ces pages.
Les autotests jouent un rôle important dans la vérification des tâches. Nous exécutons des autotests fonctionnels pour chaque tâche que nous implémentons, analysons les plantages et signalons les bogues.
Dans des cas particuliers, lorsque la tâche affecte de nombreux composants du marché, nous exécutons également des tests d'écran - ils nous aident à détecter les bogues.
Lorsque la vérification de la tâche est terminée, nous laissons un commentaire indiquant que tout va bien et que la tâche peut être mise à disposition. Dans le commentaire, nous indiquons combien de tests ont été écrits, ou nous disons que les tests ne sont pas nécessaires, et nous traduisons la tâche en statut «en attente de publication».
Ensuite, la tâche est récupérée par l'assistant de version et envoyée à la version avec d'autres tâches éprouvées. Nous essayons de remplir les versions avec des tâches afin de les faire vérifier en 8 heures par les mains de 4 testeurs: 2 pour la version tactile du Market et 2 pour la version de bureau. Notre objectif est de déployer au moins 5 versions. Autrement dit, la vitesse de livraison de la tâche au prod par rapport à ce qu'elle était, a été multipliée par 5.
Comment nous vérifions les communiqués
Nous commençons à vérifier la version en vérifiant les tests automatiques et les tests d'écran. Après avoir examiné les rapports, nous pouvons immédiatement détecter jusqu'à 90% des problèmes. Nous analysons le crash des tests: s'ils sont liés à un bug ou cassés par un ticket dans la release, nous recherchons la tâche dans laquelle ce crash est reproduit, et demandons à être réparé. Si cela n'est pas fait, la tâche ne tombe pas dans la version.
Les tests peuvent également mourir d'eux-mêmes. Dans ce cas, nous désactivons le test à partir de l'exécution de l'autotest et commençons la tâche de le réparer et de créer le mox si nécessaire.
Selon les tâches de la version, nous pouvons utiliser le kit de test de version complète ou refuser complètement la régression manuelle. La décision est prise par les testeurs de versions.
Si la version comporte plusieurs petites modifications, la vérification des tâches est effectuée localement et la régression manuelle est remplacée par la vérification des rapports de test automatique.
Indépendamment de l'exhaustivité de la version et des tâches, l'équipe de testeurs de versions vérifie les expériences qui sont actuellement présentées à différents pourcentages d'utilisateurs en production. Une liste de contrôle écrite par un testeur expérimental est utilisée.
Lorsque toutes les vérifications sont terminées, le testeur de versions laisse un commentaire où il répertorie toutes les activités de versions et, si nécessaire, écrit des tâches pour corriger les tests cassés.
Le responsable de la version analyse les rapports de tir (test de charge) et, s'il constate une augmentation des erreurs, les redémarre. Si cela n'aide pas, il cherche le coupable ou demande l'aide du développeur en service.
Si tout va bien avec les résultats de la prise de vue, l'assistant de version ouvre les graphiques du marché et commence à déployer la version en production. Les graphiques doivent être surveillés afin de ne pas manquer la croissance des erreurs.
Si la version est à blâmer pour la croissance des erreurs, le responsable de la version annule et comprend les raisons. Si les plannings sont normaux, il termine la version et commence à en collecter une nouvelle à partir de tâches prédéfinies.
Viser le meilleur
Malgré le fait que tout fonctionne bien, vous devez toujours viser le meilleur. Nous sommes sur le point d'une future livraison continue plus lumineuse, où les tâches seront testées et déployées en production parallèlement les unes aux autres, sans étape intermédiaire sous forme de release. Cela vous permettra de ne pas être distrait par la surveillance des versions et d'accélérer considérablement la fourniture de fonctionnalités aux utilisateurs.
Nous avons décidé de passer au CD par étapes. La première étape a été l'introduction d'un mono-référentiel, qui combine le déploiement de fonctionnalités sur les deux plates-formes - tactile et de bureau - en une seule version. Cette approche présente des avantages pour le développement et les tests. Nous passons beaucoup moins de temps à tester le composant. Les tâches sont désormais au même endroit, ce qui facilite la navigation. Il est plus facile pour le gestionnaire de naviguer, car il connaît le moment exact du déploiement de la tâche de publication dans le prod, et il n'y a pas de jeu entre le déploiement des plates-formes.
La prochaine étape du CD sera l'introduction de la «plaie verte». Pour chaque ticket vérifié par le testeur, 2 types de tests seront lancés pour les deux plateformes: tests fonctionnels et tests d'écran. Tous les tests devront avoir moki. Si les tests pour l'une des plates-formes échouent, la tâche ne sera pas considérée comme vérifiée. Si le test se bloque, vous devrez comprendre pourquoi cela s'est produit. Ce n'est qu'en l'absence de tests de chute et de réussite de tous les contrôles que la tâche sera envoyée au prod.
Merci de votre attention. J'espère que notre expérience vous a été utile, je vous attends dans les commentaires.