Il y a un an et demi, nous avons détruit l'équipe de test: nous avons abandonné la régression, transféré les autotests E2E vers Selenium pour soutenir les développeurs, et nous sommes allés vers des équipes qui ont vu des fonctionnalités pour éviter les bogues dans l'œuf. Dans de beaux rêves, il nous a semblé que ce serait plus utile: le contrôle qualité fonctionne sur la qualité, les tests commencent tôt et les développeurs écrivent eux-mêmes des tests automatiques et personne ne les dérange.
Mais ça
Quelles sont les conséquences du premier et du second ordre
Ray Dalio dans Principes a le concept de «conséquences de second ordre». Ce sont des conséquences non évidentes de nos décisions que nous ne pouvons souvent pas prévoir. Par exemple, dans les années 60 du 20e siècle, une guerre avec les moineaux a été lancée en Chine. Les moineaux ont mangé du grain, et pour qu'ils arrêtent de le manger, la Chine a commencé à chasser les oiseaux. Au cours de la chasse, les Chinois ont tué en masse près de deux milliards d'oiseaux.
À la suite du génocide des moineaux, la récolte a augmenté après un an. Ce sont des conséquences de premier ordre. Mais il n'y avait personne pour manger les insectes et les criquets et les chenilles se sont multipliés, ce qui a commencé à détruire encore plus de céréales, ce qui a conduit à une famine massive en Chine dans les années suivantes. Ce sont des conséquences de second ordre.
Les conséquences de premier ordre sont des conséquences directes de nos décisions et se trouvent toujours à la surface. Les conséquences de second ordre sont subtiles et souvent à long terme. Pour les comprendre, vous devez penser et simuler la situation. Par exemple:
- Si vous payez les développeurs pour le nombre de lignes de code, il y aura plus de code, mais la qualité sera pire. Au fil du temps, les gens commenceront à tricher et à produire de plus en plus de mauvais codes pour gagner plus d'argent. Ce sont des conséquences de second ordre.
- Si vous commencez à faire de l'exercice, cela vous fera mal au début et prendra beaucoup de temps. Mais après un certain temps (d'une semaine à plusieurs mois), une habitude apparaîtra, et la santé et l'apparence s'amélioreront. Ce sont des conséquences de second ordre.
- Si vous vous enivrez comme un cochon tous les vendredis, alors le vendredi soir sera bon. Mais samedi matin sera mauvais - ce sont des conséquences de second ordre. Et si vous faites cela régulièrement, pendant des années, cela se développera peut-être en alcoolisme et cirrhose du foie. Mais ce sont déjà des conséquences de troisième ordre et «une histoire complètement différente».
Nous avions une équipe d'assurance qualité et nous l'avons «dispersée»
Je vais maintenant vous dire comment nous avons ressenti les conséquences du premier et du deuxième ordre. Nous avions une équipe de testeurs dédiée et chaleureuse de 7 personnes: 4 d'entre eux ont écrit des autotests et 3 les ont testés manuellement. À un moment donné, nous avons décidé de nous séparer et de nous disperser en équipes. Pourquoi?
Parce que les développeurs ont reçu des commentaires trop tard.
Les bugs étaient au stade où tout le développement était «terminé», tout était «intégré» et il fallait vérifier que le produit était prêt pour la sortie. Il n'y a pas eu de test d'acceptation , il a été réalisé par des analystes produits qui n'avaient pas de compétences en test. De plus, les testeurs et les développeurs étaient dans des mondes différents et interagissaient peu.
La solution évidente (alors) est de diviser les équipes qui travaillent sur certaines fonctionnalités (parties) du système afin d'éviter les bugs dans l'œuf. Nous ne voulions pas abandonner notre travail, nous avons donc décidé de transférer nos fonctions aux développeurs. Nous avons pensé aux autotests - nous les remettrons aux développeurs et ils se testeront sans problème.
Dans un premier temps, ils ont décidé de tester l'hypothèse sur nous-mêmes avec une «expérience»: nous couvrirons les scénarios critiques de régression avec des tests automatiques et refuserons la régression manuelle. Si, à la suite de l'expérience, le nombre de correctifs et d'annulations de version n'augmente pas considérablement, l'expérience peut être considérée comme réussie. Et c'est arrivé - il n'y avait plus de correctifs. Résolu - pas d'accord.
Remarque . L'entreprise a un produit appelé Restaurant. Il comprend tous les services et notre monolithe. L'objectif du produit est d'automatiser et d'optimiser au maximum le travail de tous les employés du restaurant. Notre travail se concentre désormais davantage sur la prévention des erreurs. Maintenant nous sommes QA dans le produit "Restaurant": nous développons les qualités du produit, nous participons à toutes les étapes de développement des tâches.
Conséquences du premier et du second ordre
Conséquences directes . Comme prévu, nous avons commencé à nous impliquer dans le développement des tâches dès le début, à participer au PBR, à la planification, aux ateliers et à leur apporter une expertise en matière de tests. Nous nous sommes rapprochés des équipes de développement, ou plutôt d'une partie, et nos problèmes étaient aussi les problèmes de l'équipe. L'expertise dans les tests, l'assurance qualité et une large connaissance du système ont commencé à se développer dans les équipes. Nous avons, à notre tour, commencé à nous plonger dans le travail des développeurs et à comprendre leurs douleurs.
Maintenant, ce que nous n'avons pas prévu, ce sont des conséquences de second ordre .
Personne ne détermine la qualité du produit . Il y a deux côtés à ce problème:
- qualité en termes de processus;
- qualité des autotests et du pipeline.
Dans notre équipe d'AQ dédiée, nous avons conduit la qualité. Nous avons été les derniers à voir le produit devant les utilisateurs et à comprendre comment ils le voient. Nous avons discuté des changements et des améliorations sur l'équipe rétro, avons fait des propositions aux équipes de développement pour décider ensemble si elles devraient être introduites ou non. Nous avons surveillé les autotests et travaillé sur leur stabilité.
Après nous être dispersés en équipes, tout a disparu quelque part. Dans l'équipe de développement, nous faisons partie de l'équipe,
Toutes les idées visaient uniquement à améliorer l'état de l'équipe - nous avons tout fait pour sortir une fonctionnalité de qualité, pas un produit de qualité. En conséquence, des solutions fondamentalement solides qui peuvent élever la qualité des produits à un nouveau niveau ont cessé d'apparaître.
La compétence d'écrire des autotests a disparu - les autotests ont commencé à se plier et à tomber plus souvent sans changer le code. Au moment où l'équipe a été dissoute, les testeurs manuels commençaient tout juste à comprendre les bases de l'automatisation. Il s'est avéré que ni les testeurs ni les développeurs n'avaient d'expertise. De plus, les grains d'expertise sont devenus confus lorsque les personnes qui ont écrit ces tests sont allées au développement, à la gestion des produits et que quelqu'un a démissionné.
Nous ne savions pas de manière fiable quels autotests nous avons, ce qu'ils couvrent, nous ne savions pas comment ils se développent, évoluent, ajoutent et suppriment - tout a été laissé à la merci des développeurs. En conséquence, lorsqu'il était nécessaire de trouver des informations dans les tests automatiques, c'était ce genre de quête que vous ne pouviez pas comprendre sans développeur.
Travail supplémentaire pour les développeurs . C'est dur d'être développeur. Si auparavant ils avaient l'habitude d'écrire du code produit, qui est vérifié «par magie» et passe en production, ils doivent maintenant écrire eux-mêmes des tests, éditer et stabiliser. Chez PBR, nous déterminons quels scénarios doivent être couverts par les tests, et les développeurs choisissent eux-mêmes le niveau des tests automatiques.
Les développeurs sont passés par plusieurs étapes pour accepter la
Négation... Toutes les versions de Dodo IS sont lancées par des développeurs. Ils organisent le processus, communiquent avec l'équipe de test de charge, consultent les journaux et surveillent pendant la publication. Les développeurs qui ont lancé la version, confrontés au test rouge, n'ont pas essayé de comprendre sa raison, mais ont simplement redémarré le pipeline jusqu'à ce qu'il devienne vert 5-7-10 fois. C'est parce qu'il n'y avait aucune confiance dans les autotests.
Le nombre maximum de redémarrages que j'ai trouvé est de 44 fois !!! Il me semble que la règle que nous avons adoptée sur l'un des rétro «Ne sortez pas avec des tests rouges. Si le test est rouge, déterminez quel est le problème. Si le problème concerne les tests, corrigez-le ou signez-le et créez une carte pour déverrouiller le test et l'ajouter au backlog. "
Colère : les développeurs ont juré lors de nos tests, ils ont dit qu'ils
Il n'y a pas eu de négociation ni de dépression, l' acceptation est venue immédiatement : les développeurs peuvent désormais écrire eux-mêmes des tests d'interface utilisateur et d'API E2E, les stabiliser et les améliorer.
Le nombre de bugs en vente a commencé à augmenter . Des bogues non critiques ont commencé à s'infiltrer dans la production. Il y a plusieurs raisons à cela:
- Nos autotests ne couvrent pas toutes les fonctionnalités, mais uniquement les plus critiques. Et il n'y a plus de test de régression manuel.
- Il n'y avait pas assez d'ingénieurs QA pour toutes les équipes. Les équipes n'avaient pas de compétences en matière de tests, elles n'ont donc pas prêté attention aux tests
En conséquence, nous avons commencé à trouver accidentellement des bogues en production. Ils ne sont pas critiques, mais combien d'entre eux en général n'ont pas été imaginés.
Comment résolvons-nous ces problèmes
Peut-être qu'une autre équipe aurait pu prédire toutes les conséquences non évidentes, mais nous n'avons pas pu. Nous avons pris une décision, après quelques mois, nous avons vu les conséquences et avons commencé à les éliminer.
Création d'une guilde ou d'une communauté de pratique d' AQ des restaurants , qui comprenait tous les QA des restaurants. L'objectif de la communauté est de piloter la qualité de l'ensemble du produit, de diffuser les bonnes pratiques de test à toutes les équipes produit. Il s'agit d'une formation qui combine les avantages d'une équipe QA dédiée et nous bénéficions également d'être QA dans l'équipe de développement.
Nous nous réunissons une fois par semaine: nous partageons les résultats, les découvertes et prévoyons de travailler ensemble sur la qualité. Nous allouons également plusieurs créneaux par semaine pour travailler sur les tâches de guilde. Par exemple, nous terminons notre robot assistant pour les releasemen.
Devoir... La guilde couvre partiellement le problème du manque de propriétaire de qualité et d'autotests. Mais la guilde n'a pas de fortes compétences en développement et en automatisation, donc notre CTO a pris une décision volontaire et a organisé une tâche sur le pipeline.
Désormais, les développeurs peuvent systématiquement améliorer le processus de pipeline: stabiliser, trouver les problèmes qui retardent les versions et les résoudre. Un développeur de l'équipe de développement devient propriétaire du pipeline pendant un mois et l'améliore systématiquement. Il ne libère pas, mais s'améliore plutôt - il rend le processus de publication et de maintenance des tests facile et sans effort. Maintenant que les métriques du produit se sont améliorées, nous nous sommes débarrassés de ce préposé, mais nous pouvons revenir à tout moment. (Tout en écrivant un article, nous sommes retournés parce que l'avis commence à se dégrader la stabilité)
Cours... Nous clôturons le problème du manque de compétences avec des cours pour les testeurs manuels et un travail en binôme avec des développeurs expérimentés en automatisation.
Travail supplémentaire pour les développeurs . Vous ne pouvez rien y faire, les développeurs ont juste atteint le stade d'acceptation des autotests. Maintenant, ils écrivent eux-mêmes des tests E2E, si ceux de niveau inférieur ne peuvent pas couvrir une fonctionnalité, et ils stabilisent le pipeline. Comme on dit dans les livres intelligents, c'est une bonne pratique lorsque toute l'équipe, les développeurs et les testeurs peuvent écrire des tests. Cela affecte également notre voyage du côté des microservices bu du monolithe. Il y a moins de tests dans le monolithe, et de plus en plus dans des référentiels séparés, le pipeline devient plus stable.
Explorez le produit... Nous résolvons les problèmes de bogues en production en commençant à rechercher sur le produit des incohérences avec le comportement attendu. Nous avons programmé des sessions d'essais exploratoires hebdomadaires. Et nous rapportons les bogues du backlog au Product Owner.
Que ferions-nous maintenant?
Le fait de ne pas prendre en compte les conséquences du deuxième et du troisième ordre a conduit à de mauvaises décisions. Elle est particulièrement dangereuse lorsque la première et non la meilleure option renforce un biais déjà existant. Mais maintenant, avec toute l'expérience acquise, nous aurions agi différemment.
Par exemple, la perte de compétences pourrait être résolue par le fait que quelques mois avant la transition des personnes ayant des compétences en automatisation, demandez-leur de partager la compétence à tous les ingénieurs QA d'un produit ou aux développeurs des équipes. Et mieux pour tous à la fois.
Il n'y a aucun moyen de compenser le problème du travail supplémentaire pour les développeurs , mais il serait possible de réduire la douleur d'écrire des tests en ne le mettant pas avant un fait, mais:
- montrer explicitement la valeur des tests;
- apprendre aux développeurs à rédiger, améliorer et maintenir ces tests;
- ( ), .
Lorsque nous nous sommes séparés, nous n'avons même pas pensé à ces problèmes. «Avec le recul», il semble, eh bien, comment est-ce possible, d'y penser est élémentaire. Mais avec le recul, nous sommes tous forts - essayez de prédire l'avenir.
Les conséquences du deuxième ou du troisième ordre pour moi peuvent être les conséquences du premier ordre pour les personnes plus expérimentées qui ont pris de telles décisions à plusieurs reprises et ont vu les résultats de ces décisions.
Il y a trop d'incertitudes et de variables affectant les résultats.
Il est important de ne pas prévoir les conséquences, mais, au moins, de savoir ce qu'elles pourraient être. Avant de prendre une décision, il est important de réfléchir aux conséquences probables, de lire les informations sur les cas dans d'autres entreprises afin d'avoir au moins une idée de l'ampleur des conséquences non évidentes possibles.
Quiconque apprend à prédire les conséquences du deuxième (et même du troisième) ordre de toute décision pourra sauver ou détruire l'humanité. Ou gagner plus d'argent que Scrooge McDuck - du moins grâce aux fluctuations du cours des actions.
Comment vais-je essayer de prédire les conséquences maintenant
J'ai lu des articles sur ce sujet et déduit pour moi-même quelques règles qui, selon les auteurs, aideront à prévoir de telles conséquences. Je vais essayer de les utiliser:
- Avant de prendre une décision - posez-vous la question "Que va-t-il se passer ensuite?" et ajoutez des plages horaires à la question. Que se passera-t-il dans 10 minutes, 10 mois ou 10 ans?
- Entraînez votre réflexion sur de telles conséquences en réfléchissant à différentes situations. Par exemple, quelles pourraient être les conséquences du premier deuxième ou même du troisième ordre si le monde entier passe aux voitures électriques, ou, par exemple, introduit un revenu de base inconditionnel. Il n'y a pas de réponses correctes dans cet exercice, mais cela vous permettra de réfléchir plus largement.
- N'oubliez pas que la première pensée dans votre tête est le premier ordre. Est toujours.
Si vous avez rencontré d'autres problèmes lors du changement d'organisation de l'équipe de test ou d'autres équipes, écrivez dans les commentaires, il sera intéressant de savoir quels problèmes vous avez rencontrés et comment vous les avez résolus.
P.S. 2 QA- « » . . : , , SRE- mobile SRE . . , : (@EvgenSkt) HR (@alexpanev).
, , , : « » « » ( «» — ). QA, « ? ».
-, .