Regardez la vidéo, lisez la transcription et écrivez votre opinion sur les questions posées dans les commentaires. Découvrons-le ensemble: être ou ne pas être?
Discussion numéro un
Timecodes
0:56 - Les tests sont-ils toujours nécessaires?
14h00 - Pourquoi tester si vous avez besoin de lancer des fonctionnalités sur le marché dès que possible?
3:24 - Est-il possible de tester uniquement les fonctionnalités de base ou une partie de l'application?
5:29 - Critères de test des fonctionnalités
7:28 - À quel moment une start-up ou une entreprise d'externalisation doit-elle arrêter de publier des fonctionnalités et commencer à perdre du temps à tester
La rencontre a immédiatement commencé par une chaude - avec des discussions. Par conséquent, nous présenterons les participants à notre discussion en ligne:
- Dmitry Voronin, ingénieur en chef de l'équipe Speed (Avito).
- Yuri Chechetkin, développeur mobile (Revolut)
- Dmitry Manko, développeur Android (Citymobil)
- Nina Semkina, programmeuse principale (Yandex.Money)
- Vladimir Genovich, programmeur principal (Yandex.Money)
- Dmitry Zhakov, testeur (Yandex.Money)
Nina Semkina: Beaucoup de gens disent que les tests doivent être introduits dans les projets ... Mais tout le monde comprend que cela coûte très cher. Il est très coûteux de passer du temps aux développeurs et de nombreuses ressources couvrant tout le code avec des tests. Les tests doivent-ils toujours être effectués?
Dmitry Manko: Qu'allez-vous tester?
Nina Semkina: application Android. Quand dois-je comprendre que 100% de celui-ci doit être testé?
Dmitry Manko:Si le marché n'attend l'émergence d'aucune fonctionnalité, alors, du point de vue du développement ou du point de vue de la couverture, les tests peuvent être simplifiés ou complètement négligés. Tout dépend du produit. Si nous fabriquons une calculatrice avec 2 fonctions, nous sommes probablement passés par une série de cas de test plus d'une fois. Ainsi, les tests peuvent être ignorés, l'application peut être mise sur le marché plus rapidement et le délai de mise sur le marché peut être réduit.
Nina Semkina:Nous avons toujours une course au time-to-market, le marché a toujours besoin d'un tas de fonctionnalités et nous ne pouvons pas les ralentir. Surtout lorsqu'il s'agit d'un projet qui vient de démarrer et qui doit être lancé sur le marché maintenant, nous n'avons pas de nom, nous sommes en concurrence avec d'autres entreprises. Que nous soucions-nous des tests en ce moment? Nous devons fournir à notre application des fonctionnalités et les jeter plus rapidement, sinon elles deviendront obsolètes dans 3 semaines. Pourquoi les tester?
Dmitry Voronin:En fait, la vitesse de développement à un moment donné commence à dépendre de la couverture des tests. Si, par exemple, une entreprise est liée d'un point de vue architectural à un écran principal, où se trouvent toutes les fonctionnalités principales, et que des modifications y sont apportées de nombreuses fois, alors sans tests, vous pouvez commencer à vous y déplacer plus lentement, même avec un grand «pipeline de fonctionnalités». Il semble dès qu'il y a des signaux que vous revenez souvent sur la régression, c'est-à-dire une raison de penser au fait que quelque chose ne va pas avec le revêtement et que vous ne prenez pas d'actions réactives. Par exemple, quelque chose casse souvent, ce qui signifie que cet endroit n'est pas testé comme il se doit.
Nina Semkina:Puis-je conclure que vous devez constamment tester uniquement les fonctionnalités de base et connecter les fonctionnalités «avec un point». Que ces fonctionnalités individuelles soient avec des bogues, mais peut-être qu'elles existent aujourd'hui et demain elles ne le seront pas. Puis-je tester une seule partie de l'application?
Dmitry Manko: Je dirais plutôt que les éléments clés méritent d'être testés. Ce qui est important d'un point de vue commercial pour ce produit. Et s'il y a des fonctionnalités avec des bogues, elles sont situées quelque part séparément et n'affectent pas quelque chose en commun, alors idéalement les fermer avec une bascule à distance. Et si, d'après les analyses, vous voyez qu'il y a vraiment des bogues et que les utilisateurs se plaignent, désactivez cette fonctionnalité.
Dmitry Voronin:Dima a abordé un bon sujet selon lequel les tests ne sont pas le seul outil de contrôle qualité dont dispose un développeur. Vous devez toujours vous rappeler qu'en plus des tests unitaires et d'intégration, des tests manuels, il y a et doit y avoir une surveillance. Et il existe des moyens de déployer et d'annuler vos modifications. Si vous avez toutes ces pratiques d'ingénierie, vous pouvez en principe négliger certains outils au profit d'autres, si la vitesse en profite. Mais en général, il est toujours considéré comme une bonne forme si le développeur a une culture de test - qu'il est plus confortable et plus fiable pour lui d'apporter des modifications afin qu'il ait testé les fonctionnalités qu'il devrait effectuer. Dans notre entreprise, il est d'usage de laisser un tel code, dans lequel vous pourrez ensuite facilement apporter des modifications, et exécuter rapidement des tests pour comprendre que vous n'avez pas gâché ce qui s'est déjà passé.
Nina Semkina: Ils écrivent dans le chat que vous devez tester ce qui rapporte des revenus. Et lorsque les coûts de test sont inférieurs aux pertes possibles dues aux fonctionnalités non fonctionnelles. En principe, c'est un bon critère pour comprendre ce qui doit exactement être testé. Pourriez-vous nommer d'autres critères pour tester des fonctionnalités spécifiques?
Dmitry Manko: Les critères peuvent être identifiés à l'aide d'analyses. Par exemple, si vous corrigez les fonctions les plus fréquemment utilisées, il est également conseillé de les tester afin que les utilisateurs rencontrent le moins de bogues possible. Si les bogues sont dans des endroits rares, alors c'est un petit problème. Et si l'interdiction est sur l'écran d'autorisation, ce n'est peut-être pas critique, mais toujours un bogue que tout le monde verra. Et c'est déjà un risque de réputation.
Dmitry Zhakov:Les tests en général sont généralement nécessaires. Nous ne devons pas oublier que les tests sont une vérification des exigences que nous imposons à un produit. Si quelque chose ne répond pas aux exigences, il s'agit d'un problème, d'un bogue, d'un problème. Tous les cas de test et les tests peuvent être automatisés, et s'il n'y a pas assez de temps, il vaut d'abord la peine de vérifier les moments critiques, puis tout le reste. Par exemple, si vous avez une version demain et que votre entreprise veut une fonctionnalité demain, vous vérifiez la fonctionnalité la plus critique. Et si vous avez suffisamment de temps, vous pouvez vous permettre de vérifier les cas moyens et faibles. Il s'agit plus de savoir si vos tests seront manuels ou automatisés. Qu'il s'agisse de métriques ou de tests d'interface utilisateur, entièrement vérifiables par un robot.
Nina Semkina:Nous parlons tous maintenant au nom de grandes entreprises dotées de nombreuses ressources et opportunités. Et si l'on considère le point de vue des petites entreprises, des startups, qui ont un temps et des ressources limités. Je pense qu'au début, tout le monde sacrifiera les tests là-bas. À quel moment pouvons-nous comprendre qu'il s'agit de l'étape critique où nous devons arrêter et arrêter le déploiement des fonctionnalités et consacrer des ressources aux tests?
Dmitry Manko:Je peux partager mon avis, puisque je viens d'une entreprise de sous-traitance. L'externalisation concerne principalement l'endroit où les heures de travail sont vendues, et les tests y coûtent vraiment cher. Parfois, cela coûte plus cher que de développer la fonctionnalité elle-même. De telles sociétés d'externalisation, lorsque le client attend l'application et «la met à côté», ne sont pas réputées pour leurs tests. Dans notre équipe, nous sommes confrontés à la situation suivante. Le produit est un menu pour bars, où des promotions ont été utilisées pour un grand nombre de caisses (anniversaire, 2 pour 1, étudiant, etc.). Et nous avons remarqué que cette fonctionnalité de stock se cassait tous les mois pendant un an. Et puis les tests unitaires ont décrit tous les cas, idéalement. Nous avons compris comment tout fonctionne (il y avait environ 70 cas de test). Nous avons battu ce produit, mais, bien sûr, il ne serait pas possible de le faire partout.
Yuri Chechetkin:Mon expérience de travail dans de grandes entreprises - Yandex, Alfa-Bank, Revolut - dans la fintech, où la criticité de tout bug devient tout simplement hors de portée. Cela étant dit, j'ai de l'expérience dans une startup, et même là, des tests étaient absolument nécessaires. Je pense que peu importe que ce soit une startup ou non, car le développeur doit être responsable de son code, et les tests sont une garantie que ce code fonctionne. Un développeur est avant tout un ingénieur responsable du produit en cours de développement. Par conséquent, vous devez écrire des tests non pas parce que vous en avez besoin, mais parce qu'ils devraient vous aider. Si ce sont des tests écrits pour show, cela peut ralentir le développement. Et si vous avez besoin de tests et que vous le comprenez vous-même, ils doivent être écrits. Si un développeur écrit du code et est convaincu qu'il fonctionne sans tests, alors c'est un risque et c'est son choix. Mais je pense toujoursque le développeur ne devrait pas prendre ce risque et devrait se couvrir et tout couvrir de tests.
Nina Semkina: Nous avons donc décidé que nous devions en quelque sorte tester notre code, nous analyserons ce sujet plus en détail. Je donne maintenant la parole à Vladimir Genovitch avec son rapport .
Discussion numéro deux
Timecodes
0:09 - Comment supprimer la charge de régression du QA avant les versions? Les entreprises ont-elles une stratégie pour améliorer la stabilité des applications?
4:25 - Est-il judicieux d'utiliser des faux ou des faux objets dans les tests d'interface utilisateur
8h05 - Test sur les utilisateurs: est-ce acceptable ou pas?
Nina Semkina: Pendant le rapport, nous avons reçu une question dans le chat, et c'est de lui que je voudrais poursuivre notre discussion. Comment supprimer la charge de régression du contrôle qualité avant les versions? Quelles pratiques nos intervenants utilisent-ils pour choisir les lieux de test? Les entreprises ont-elles une stratégie pour améliorer la stabilité des applications et décharger les spécialistes de l'assurance qualité?
Dmitry Zhakov:Notre stratégie est de tout tester. Parce que nous sommes la dernière frontière, en tant qu'employés avant les utilisateurs. Par conséquent, nous ne donnons qu'une telle application au client, qui fonctionne de manière stable toujours et partout. La seule question est la vitesse. Au départ, l'exécution manuelle nous a pris beaucoup de temps - jusqu'à une semaine. Mais grâce à l'automatisation, nous sommes parvenus à ce que la sortie dure en moyenne 24 heures. Par conséquent, si vous développez une fonctionnalité, vous devez accepter que vous ou les testeurs écririez immédiatement des autotests. Et certains cas spécifiques aux mobiles que vous ne pouvez pas automatiser ne devront être vérifiés que lors de la régression, et le robot vérifiera le reste. Ainsi, vous déchargerez les testeurs, ils seront engagés dans des travaux de recherche plus intéressants et vous donnerez au robot toute la routine - les scripts de clic.
Yuri Chechetkin: La plupart des grandes entreprises refusent le contrôle qualité, les tests manuels. Ce n'est pas exactement une voie révolutionnaire, mais un peu une relique du passé. Et, par exemple, dans mon entreprise, où je travaille actuellement, un mot comme régression n'est même pas prononcé. Nous n'avons pas du tout de département d'assurance qualité.
Vladimir Genovich: Vous l'avez probablement automatisé?
Yuri Chechetkin: Pas vraiment, il n'en était qu'au stade initial du projet, puis il était parti du tout.
Vladimir Genovich: Vous exécutez des tests d'interface utilisateur, n'est-ce pas?
Yuri Chechetkin: Il y a bien sûr des tests d'interface utilisateur.
Vladimir Genovich: Et les tests unitaires? Donc exécuter ces tests à la sortie n'est pas une régression?
Yuri Chechetkin:Oui, c'est une régression, mais il n'y a pas de test manuel dont nous avons l'habitude de parler. Et c'est une approche assez intéressante. Cela dégrise et transforme le développeur d'un «enfant» qui écrit du code et le donne aux testeurs, en un ingénieur plus mature et indépendant qui est responsable de son propre code. En ce qui concerne les éléments visuels, l'examen peut être effectué par un concepteur ou un PO. Et il y a des choses comme les tests de capture d'écran - comme Facebook. Il semble donc que les entreprises alimentaires puissent désormais se passer d'AQ. Et les testeurs eux-mêmes peuvent faire un travail plus intéressant. Bien sûr, il y a une histoire légèrement différente dans l'externalisation - ils vendent des heures de travail, et l'assurance qualité peut être vendue comme un service supplémentaire.
Dmitry Zhakov:Il s'avère que vous avez une régression, elle est simplement vouée à l'automatisation, et vous avez des personnes qui sont engagées dans les travaux de recherche de votre application. Les tests peuvent être non seulement une interface utilisateur, mais également différents.
Yuri Chechetkin: Oui, par exemple, des tests sur les utilisateurs.
Nina Semkina: Avant d'aborder ce sujet très dangereux, j'aimerais lire la prochaine question de nos auditeurs. Est-il judicieux d'utiliser des simulacres ou de faux objets dans les tests d'interface utilisateur?
Dmitry Voronin:Cela a du sens, et sans eux nulle part. Parce que les tests d'interface utilisateur avec intégration complète sont très peu fiables. Et vous ne pouvez jamais compter sur un test comportant 30 systèmes, chacun avec un ensemble de points de défaillance exécutant une pull request. De tels tests ne sont pas viables. Et personne dans aucune entreprise ne pouvait faire fonctionner de telles choses. Par conséquent, les tests d'interface utilisateur sont le fléau du développement mobile. Si possible, il est préférable de tester sans interface utilisateur. Mais en raison du fait que nous sommes obligés de vivre avec un cadre, et la seule alternative est une sorte de robotique, et dans iOS, même ce n'est pas le cas. Et afin de vérifier l'interaction avec au moins l'un des systèmes importants pour nous, nous exécutons tout sur l'appareil. L'interface utilisateur est là dans la mesure où, en raison de notre immaturité de développement, nous voulons capturer autant que possible afin de vérifier comment l'utilisateur clique - nous sommes tellement plus calmes. Il me semble,qu'après un certain temps, cela deviendra une chose du passé et nous n'aurons plus peur des moqueries, des clics et ne lutterons pas contre le système pour tout vérifier comme il se doit, car nous ne vérifierons pas tout de toute façon. Il peut y avoir des bogues visuels qui ne seront vérifiés par aucun test d'interface utilisateur. Par conséquent, je pense que la moquerie dans les tests d'interface utilisateur peut et doit être faite, et l'objectif principal est d'augmenter la stabilité de cet outil, de l'amener à un état tel qu'il soit utile. Et le véritable avantage dans ce cas est de s'assurer qu'il n'y a pas de régressions. Et tout instrument qui rince se transforme en deuxième "D" du rapport précédent de Vladimir Genovitch, quand on arrête de faire confiance. Cela se produit lorsqu'un grand nombre de valeurs aléatoires commencent à arriver dans notre test. Et un tel test ne donne aucune confiance en soi, mais ne donne que de faux espoirs que quelque chose a été testé.
Dmitry Zhakov: Environ 70% de nos cas sont automatisés, et ils n'utilisent pas une seule maquette dans l'application. Il peut être plus facile de les migrer vers le backend. Par exemple, s'il fait référence au numéro de carte, vous vous attendez à ce que 3DS ne vous soit pas demandé. Autrement dit, l'application ne sait pas qu'elle est verrouillée. Je pense que c'est un problème d'infrastructure.
Nina Semkina: Avant de passer au prochain rapport, j'aimerais que nous mentionnions un sujet glissant: les tests utilisateurs. Beaucoup pèchent ceci: ils veulent toujours et injectent ... Que pensez-vous de cela? Est-il possible de se permettre de déployer les utilisateurs en cachette, de collecter les plantages et de les réparer vous-même. Et après les avoir testés, déployez de bonnes versions à part entière. Ou est-ce généralement inadmissible? Ou y a-t-il des limites raisonnables?
Yuri Chechetkin:Chez Revolut, nous pratiquons un peu cela dans le sens où cela ne va pas directement à la bataille, mais sur de vrais utilisateurs. La démo est également un test sur les utilisateurs, et pendant la démonstration, des questions sur le flux et ainsi de suite se posent. À ce stade, il peut y avoir des questions sur la conception et la mécanique générale. Entre autres, il y a le roulement interne - l'entreprise est grande, plus de 1000 personnes, et nous pouvons déployer entre collègues. Il s'agit de tests utilisateur, mais pas en externe, et semble être sans danger. Et puis, il peut être déployé à un petit pourcentage d'utilisateurs réels à l'extérieur, mais avec la possibilité de fermer cette fonctionnalité avec une bascule. Selon vous, qu'est-ce qui pourrait mal tourner pendant ces étapes?
Dmitry Manko:Dans notre réalité, les choses peuvent mal tourner. Peu importe à quel point nous essayons de bien mener à bien ces étapes, dans tous les cas, les cas sautent lorsque nous devons surveiller les analyses de crash. La sortie ne se termine pas avec le fait que nous l'avons envoyé au magasin, toutes les étapes sont passées, tout va bien avec nous. Vous devez continuer à surveiller le comportement de l'application.
Yuri Chechetkin: Certainement oui. Dans notre cas, nous avons une démo, un déploiement interne et des tests pour 5% des utilisateurs au lieu de tests manuels. Bien sûr, après la sortie de la fonctionnalité, vous devez regarder. Le roulement ne doit pas être à 100% tout de suite - c'est le principal mécanisme de défense.
Dmitry Voronin:La question éthique des tests utilisateurs est traitée par Google pour nous. Apple ne semble pas avoir cela. Il existe des canaux de distribution spéciaux, comme vous le savez (production alpha, beta ...). Tout le monde peut participer au test bêta, et ils sont d'accord avec la forme compréhensible, qui dit qu'ils sont tout à fait d'accord qu'ils peuvent recevoir une version instable du produit. Et donc il veut faire du bénévolat et aider l'entreprise à améliorer le produit. Dès que nous en informons ouvertement une personne, je pense que ce problème devrait être supprimé et que nous ne devrions pas avoir peur de déployer une version dont nous ne sommes pas sûrs à 100%. Et c'est encore mieux quand nous avons des retours à partir de là, et avec chaque version instable, nous améliorons ce processus. Si une entreprise a des processus qui suivent les tendances de qualité en version bêta, les choses ne devraient que s'améliorer.Et c'est aussi un plus pour les utilisateurs: ils seront les premiers à bénéficier des fonctionnalités. Ce sont pour la plupart des utilisateurs motivés et fidèles à votre produit, et ils voudront eux-mêmes tester de nouvelles choses qui apparaissent dans l'application. Et ils seront même prêts à sacrifier quelque chose pour cela.
Nina Semkina: Nous comprenons que lorsque nous parlons d'un public fidèle, il est fidèle tant que cela n'affecte pas ses intérêts personnels. C'est ainsi que nous pouvons déployer des fonctionnalités avec des petits pains supplémentaires, qui même s'ils tombent, ces utilisateurs ne seront pas très contrariés. Mais même si cette personne a confirmé qu'elle est prête à passer la version de test, mais que quelque chose de grave va mal avec lui (par exemple, de l'argent supplémentaire sera radié), alors il ne sera plus fidèle. Et plus l'entreprise est grande, plus l'utilisateur répondra durement à propos du produit.
Vladimir Genovich:Mais qu'en est-il du premier adoptant qui vous aime, quelle que soit la situation de l'entreprise? Et, très probablement, cette société sera en mesure de récupérer les pertes. D'accord, si nous déployons quelque chose, nous disons à l'utilisateur: «Écoutez, nous avons très peur. Et vous pouvez perdre 1000 roubles. Mais nous vous rembourserons. " Très probablement, un tel utilisateur le fera à ses risques et périls, et si l'argent est perdu, nous ne lui dirons pas plus tard: "Eh bien, vous êtes vous-même à blâmer." Par conséquent, je pense que même dans le cas d'une application bancaire, nous pouvons aider les utilisateurs.
Dmitry Zhakov:Et si vous avez trop peu de bêta-testeurs, vous pouvez utiliser les tests A / B à l'aide de configurations pour activer / désactiver certaines fonctionnalités, de sorte qu'en cas de plantage, vous puissiez immédiatement désactiver quelque chose et le tester si nécessaire. Comme on s'en souvient, il est très difficile de revenir en arrière dans le mobile, il est donc préférable de tout vérifier au maximum avant la sortie.
Vladimir Genovich: Ou écrivez en React Native))
Nina Semkina: Je vais interrompre notre conversation, car le moment est venu pour le prochain rapport. Dima, je vous donne la parole.
Discussion numéro trois
Timecodes
0:05 - Comment améliorer les tests de régression? Comment et quand les tests sont-ils introduits dans le développement des fonctionnalités (expérience d'Avito)
10:43 - Où sont les tests unitaires en cours: sur CI ou localement avant de pousser?
Nina Semkina: Je voudrais contacter Dima Voronin pour entendre son avis et son expérience sur la façon dont ils ont amélioré les tests de régression dans l'entreprise et quand ils introduisent les tests lors du développement de fonctionnalités.
Dmitry Voronin:J'ai vraiment quelque chose à partager. Il s'agit d'une histoire de cinq ans de gestion de la régression manuelle. Et c'est en partie une continuation de la réponse à la question que nous nous sommes posée entre les 2 premiers rapports. Cette question concerne ce qu'il faut faire si vous avez une régression manuelle. Parce que tout le monde ne pourra pas répéter l'expérience Revolut. Les gars sont super, ils ont coupé l'épaule et ils ont réussi à le faire de manière fiable. Cela demande beaucoup de courage, une bonne culture du développement et, surtout, comprendre les leaders du développement qui ne se sentent pas fous de cette approche. Cela se produit parce qu'il y a de l'inertie dans notre travail et qu'il peut être difficile de changer les fondations, en particulier dans les grandes entreprises. L'exemple Revolut prouve que si cela fonctionne, alors c'est au moins plus rapide que la régression manuelle, et chaque développeur commence à se poser les bonnes questions.C'est-à-dire qu'il commence à être responsable de la majeure partie du cycle de publication, c'est-à-dire pas avant le moment où il valide les modifications, mais comme tout ingénieur adulte, il dirige également le produit au stade de la sortie.
Qu'est-il arrivé avec nous? Nous en étions au point où nous avons eu une régression manuelle effectuée par 5 personnes pendant 12 jours ouvrables, et sans cela, l'application mobile ne fonctionnerait pas. C'était en 2015. Et à ce moment-là, nous n'avons pas eu un seul test d'interface utilisateur automatisé. Nous avons écrit des tests unitaires presque dès le début et écrit assez activement. Vladimir dans son rapport a parlé de 10 secondes et de 1000 tests - c'est effrayant pour moi d'imaginer quand nous avons passé un tel moment en 2014. Maintenant, nous avons 12 000 tests unitaires, et ils ne prennent pas 10 secondes, ce n'est pas non plus une pièce gratuite. Même si tous les ingénieurs comprennent et écrivent des tests, il y a eu un moment délicat. Tous ces tests unitaires ne prouvent pas un gramme sur les bogues en production et sur le comportement de l'application. Autrement dit, les tests capturent le comportement, facilitent les modifications et donnent des commentaires,le faites-vous bien. Le problème, c'est qu'il existe un département d'AQ. Bien sûr, ce n'est pas le problème. Le problème est qu'ils ont pour tâche de fournir un certain niveau de qualité. Et ils ont l'habitude d'atteindre ce niveau, ils prennent cette responsabilité. Et il est difficile de tourner ce moment s'il ne vient pas du tout début de votre produit. Quelles recettes y a-t-il? La chose la plus correcte est de ne pas activer le mode difficile lorsque nous renvoyons tout le monde et que tout est pris en charge par l'automatisation. C'est probablement l'approche la plus effrayante et la plus immature que j'ai vue. Qu'est-ce qui ne va pas avec ça? Premièrement, la qualité des tests sera perdue pendant un certain temps. Deuxièmement, tous les processus sont détruits et les nouveaux ne sont pas construits rapidement.Et ils ont l'habitude d'atteindre ce niveau, ils prennent cette responsabilité. Et il est difficile de tourner ce moment s'il ne vient pas du tout début de votre produit. Quelles recettes y a-t-il? La chose la plus correcte est de ne pas activer le mode difficile lorsque nous renvoyons tout le monde et que tout est capturé par l'automatisation. C'est probablement l'approche la plus effrayante et la plus immature que j'ai vue. Qu'est-ce qui ne va pas avec ça? Premièrement, la qualité des tests sera perdue pendant un certain temps. Deuxièmement, tous les processus sont détruits et les nouveaux ne sont pas construits rapidement.Et ils ont l'habitude d'atteindre ce niveau, ils prennent cette responsabilité. Et il est difficile de tourner ce moment s'il ne vient pas du tout début de votre produit. Quelles recettes y a-t-il? La chose la plus correcte est de ne pas activer le mode difficile lorsque nous renvoyons tout le monde et que tout est pris en charge par l'automatisation. C'est probablement l'approche la plus effrayante et la plus immature que j'ai vue. Qu'est-ce qui ne va pas avec ça? Premièrement, la qualité des tests sera perdue pendant un certain temps. Deuxièmement, tous les processus sont détruits et les nouveaux ne sont pas construits rapidement.la qualité des tests sera perdue pendant un certain temps. Deuxièmement, tous les processus sont détruits et les nouveaux ne sont pas construits rapidement.la qualité des tests sera perdue pendant un certain temps. Deuxièmement, tous les processus sont détruits et les nouveaux ne sont pas construits rapidement.
Qu'avons-nous fait? Nous avons commencé notre optimisation en écrivant des tests d'interface utilisateur qui remplacent la régression. Autrement dit, il s'agit de tests d'infrastructure à part entière qui touchent le backend avec les utilisateurs de test. Et, en fait, le résultat de ce travail a été, comme vous le savez, toutes sortes de frameworks populaires - par exemple, Kaspresso. C'est exactement ce que nous avons posé lorsque nous avons commencé. Nous avons laissé derrière nous un tas d'artefacts qui peuvent aider les développeurs. Il est donc plus facile de se lancer dans les tests maintenant. Nous mettons également différents coureurs dans l'open source, et chacun peut voir comment nous travaillons avec eux. Mais nous n'avons pas oublié les tests manuels, leur optimisation et la manière dont ces deux départements commencent à fusionner en un seul processus efficace. Le point B est probablement l'état Revolut. Mais notre route du point A au point B, comme beaucoup d'autres entreprises,prend beaucoup de temps. Nous sommes maintenant au stade où l'AQ joue le rôle de chercheurs, ils s'imprègnent davantage du produit, travaillent sur les exigences fonctionnelles, écrivent des autotests.
La chose la plus intéressante à propos de la pratique d'amélioration de la régression manuelle est l'analyse d'impact. Autrement dit, une tentative pour répondre à la question: "Qu'est-ce qui a changé dans cette version?" Et que pouvons-nous tester et que pouvons-nous déployer l'esprit tranquille aux étapes suivantes. L'analyse d'impact est une question difficile, car lorsque vous avez un cycle de publication important, c'est-à-dire que vous êtes libéré pendant 2-3 mois, l'analyse d'impact vous répondra toujours de la même manière, car pendant une telle période, pratiquement aucune partie de l'application n'a été touchée. Mais si vous raccourcissez ce cycle de publication à une semaine, voire mieux à un jour, l'analyse d'impact montre des choses tout à fait adéquates, laisse des marques qui aideront à optimiser la régression manuelle. Nous avons appliqué cette pratique avec beaucoup de succès. Au début, il y a eu des erreurs, mais nous avons réduit le nombre de tests manuels ponctuels.
La prochaine pratique consiste à optimiser le modèle de test. Curieusement, mais dans les tests, il y a aussi de l'héritage: des tests sont écrits, mais ils peuvent ne pas être très optimaux, puis quelque chose d'autre a été ajouté là-bas, et les cas de test n'ont pas été traités pour cela ... nombre de scénarios de test.
Ces trois directions nous ont permis d'atteindre le point où nous la publions en version bêta une fois par jour, une fois par semaine, elle atteint 100% des utilisateurs, il n'y a pas de régression manuelle. J'espère que cette histoire motivera les entreprises, qui ne sont pas satisfaites de leur état de sortie, à agir - afin d'appuyer uniquement sur le bouton de libération à l'avenir, tout ira aux utilisateurs, et tout le monde ne regarde que les graphiques.
Yuri Chechetkin:Ce ne sont bien sûr pas seulement les pratiques Revolut, mais également dans le monde entier, elles sont utilisées par Google, Facebook, etc. Je conviens que cela devrait être une transition en douceur. Et quand beaucoup deviennent des PO ou se lancent dans un contrôle qualité automatisé, tout devient un peu flou, évolue et se transforme en quelque chose qui se dit. Et en Russie, cette tendance ne fait que commencer. Et comme vous l'avez dit à juste titre, il devrait être aussi sain que possible.
Nina Semkina: Il y avait une telle question. Qui fait exécuter les tests unitaires où? Sur CI ou localement avant de pousser?
Yuri Chechetkin: Il semble que la conduite locale soit la tâche du développeur, c'est-à-dire que vous ne devriez pas le faire par la force. Il est évident pour moi qu'il devrait y avoir 100% sur CI.
Nina Semkina: Merci à tous les participants pour la discussion! Je donne la parole à notre orateurDima Manko avec son rapport.