Alors. En 2018, lors de la Heisenbug (Moscow Testing Conference), Baruch Sadogursky (Developer Advocate at JFrog) a présenté une allocution intéressante, dans laquelle il a parlé de ses idées de base sur où aller. En 2019, au même Heisenbug, une suite à son rapport a eu lieu sur COMMENT aller pour atteindre cet objectif. D'une part, je voudrais soutenir la version du mouvement de B. Sadogursky, qu'il a diffusée, mais d'une part je ne la connais toujours pas, et d'autre part, je m'aventurerai à formuler ma vision et à décrire mon parcours personnel à partir de ma propre expérience.
Étant donné
Pour le contexte (c'est fictif et toute coïncidence avec des cas réels est une pure coïncidence), nous présenterons une société de fournisseurs informatiques régionale avec une unité de développement assez importante. Au sein de cette unité, il y a une fonction de test, qui comprend conditionnellement 30 personnes de différents niveaux de connaissances et de compétences.
Compagnie
La société présentée possède plusieurs produits qui sont dans la version depuis longtemps et la phase initiale de leur développement a été achevée il y a plus de 7 à 8 ans. Étant donné que l'entreprise est un fournisseur, elle surveille ses produits et les développe régulièrement, mais ne les refait pas à partir de zéro. Cela signifie que les produits contiennent une grande quantité de code hérité, des solutions technologiques et architecturales «anciennes». Les tests sur ces produits aux étapes initiales n'étaient pas envisagés, avant que leur développement ne soit effectué sur le principe "plus rapide, plus rapide et en production", mais aujourd'hui il y a une grande quantité de tests manuels - à la fois la régression et le test de nouvelles fonctions. Sur le plan idéologique, le développement de produits se fait sous la pression des besoins des entreprises afin de ne pas avoir le temps de repenser les idéologies et de refaçonner les produits eux-mêmes. Cela n'est fait qu'au moment où tout le monde comprend que cela ne fonctionnera pas plus loin du mot «complètement».
En plus des anciens produits, l'entreprise développe des solutions complètement nouvelles utilisant les dernières technologies et approches architecturales. Mais ici, tout ne se passe pas bien, car la pression générale des besoins de l'entreprise ne s'atténue pas. Les tests sur de tels projets sont déjà présents aux premiers stades de développement, cependant, des «solutions manuelles» prévalent toujours, qui donnent les résultats les plus rapides et permettent aux développeurs d'écrire exclusivement du code produit sans penser à la façon dont il sera testé.
Fonction test
Maintenant, quelques mots sur la structure: comme je l'ai dit, environ 30 personnes font partie de la fonction de test. Parmi ceux-ci, 17-19 est le lien junior avec une expérience dans ce domaine ne dépassant pas 1 an. Souvent, ce sont des gens sans formation technique, mais avec des «yeux brûlants» et un grand désir de travailler dans le domaine informatique (pourquoi ils ont ce désir est un sujet de discussion séparé). Les 11-13 personnes restantes sont les cadres supérieurs et intermédiaires: 3-4 personnes représentent les seniors et 7-10 personnes - la moyenne. L'ensemble de la fonction de test est répartie sur 13 à 15 produits / projets différents avec différents degrés de participation, de complexité et d'implication.
La culture
Ceci est la dernière introduction.
Malheureusement, il y a encore une certaine incompréhension de la valeur que la fonction de test peut apporter. En effet, le résultat d'un travail sous la forme (par exemple) d'une nouvelle fonctionnalité est visible par tous, compréhensible et pratiquement «tangible» - lors de sa mise en œuvre, la qualité globale du produit augmente, et cela devient du moins pas gênant pour les produits de l'entreprise. Dans le même temps, il existe un culte des développeurs, où les affirmations suivantes sont vraies: "Le développeur est le principal acteur, et s'il n'est pas là, alors le reste peut être renvoyé", ainsi que "Les développeurs sont une ressource coûteuse et ils ne devraient écrire que du code produit et ne pas être distraits par des activités sans importance ". Sur la base de ces déclarations, une certaine «culture» s'est formée dans cette entreprise.
Énoncé du problème
Et comme on dit, quel est le problème? Pourquoi changer quelque chose si tout fonctionne comme ça? Pourquoi déménager quelque part s'il existe un modèle qui fonctionne et qu'il apporte ses dividendes?
Ces questions peuvent logiquement se poser chez une personne qui paie pour l'ensemble du développement. Mais il y a ces 3-4 personnes dans la fonction de test qui se considèrent sous-estimées, qui ont vu le premier rapport de B. Sadogursky et pas seulement qui voient le côté opposé de la situation et qui voudraient changer ce qui se passe pour le mieux et, ainsi, en résoudre quelques-unes malades ».
Suivant - pure fantaisie et suggestions basées sur des documents de divers auteurs et spécialistes du domaine informatique.
Solution (possible)
Commençons par définir les buts et objectifs dans le cadre du changement. Nous allons consciemment omettre le côté mercantile et ne le soulèverons pas, c'est un sujet distinct pour l'holivar, d'autant plus qu'il a joué un rôle important dans la situation actuelle de cette entreprise.
Nous dessinons une image de l'avenir. Que recherchons-nous?
Tout d'abord, nous voulons obtenir dans un court laps de temps un pool de produits de haute qualité (!) Qui apporteront un profit assez élevé. Vous devez comprendre que «rentable» ne signifie pas «qualité».
Que devons-nous faire pour atteindre l'objectif? Tout d'abord, je propose de considérer la voie du point de vue de la technologie et non du commerce. Pour atteindre l'objectif, il est nécessaire de se concentrer sur le fait que les produits doivent satisfaire les besoins des utilisateurs finaux, tout en ayant des coûts faibles à la fois pour le développement de nouvelles fonctions et pour la maintenance de ceux déjà en production. C'est-à-dire que pendant le développement, nous devons: a) comprendre clairement le vecteur de mouvement, b) rendre les produits suffisamment fiables pour qu'il n'y ait aucun problème avec leur fonctionnement, en termes simples, s'assurer qu'il n'y a pas d'erreur lors de l'utilisation du produit. Sur cette base, nous devrions avoir la soi-disant politique zéro bug pour tous les produits, c'est-à-dire que nos tests, en tant que processus, devraient nous donner une garantie de l'absence d'erreurs de production.
Le deuxième aspect est l'accent mis sur le résultat final de l'ensemble du processus de développement, ce qui nous permettra de ne pas développer ce que l'utilisateur ne peut pas utiliser ou ne peut pas comprendre COMMENT l'utiliser. Nous ne mentionnons que la deuxième partie en passant, car le sujet est très vaste, mais il ne fonctionnera pas sans le toucher.
Notre objectif est donc:
" Rapidement, efficacement et pour un prix raisonnable " (à moindre coût, très probablement, vous ne pouvez pas le faire tout de suite).
Essayons maintenant de corréler ce qui a été donné avec le but recherché.
Vite . Oui, c'est possible, mais nous compromettons la qualité: les processus manuels d'assurance qualité existants ne pourront donner une vitesse d'exécution suffisante que sur de petits produits avec des user stories simples. De plus, le profil de l'entreprise est le développement de solutions assez complexes pour automatiser les processus d'affaires. Conclusion - «rapide» ne fonctionne pas, car le travail manuel a priori sur de gros volumes perdra à toute solution automatisée.
Concentrez-vous sur le résultat . C'est possible, mais cela oblige les participants à générer la valeur d'une immersion suffisamment profonde dans le domaine et un temps important consacré à transmettre cette valeur à l'exécuteur final. Dans le même temps, les interprètes sont des développeurs qui, dans le cadre d'une des déclarations, devraient passer le maximum de temps à écrire du code sans se laisser distraire par l'environnement.
De tout cela, il s'ensuit que pour résoudre le problème principal, il est nécessaire d'impliquer non seulement des experts en AQ, mais également des développeurs dans le processus de test. Dans le même temps, pour augmenter la vitesse de livraison de la valeur, il est nécessaire d'examiner plus attentivement les processus d'automatisation de la livraison et d'automatisation de la vérification de ce qui est livré.
Que faut-il faire pour résoudre le problème principal?
À mon avis, sur la base de l'expérience, cela nécessite:
- Plongez davantage les développeurs dans les objectifs du produit de leur produit;
- Convaincre les entreprises que les coûts d'automatisation sont importants et offrent plus d'avantages économiques pour tous les coûts économiques.
- Il est sage d'automatiser tout ce qui peut être automatisé, d'exclure le travail manuel du processus de livraison de valeur au maximum.
- Mettez en œuvre une politique zéro bogue, sans laquelle les utilisateurs seront confrontés à des problèmes qui repoussent nos produits. Soit dit en passant, un exemple réussi de «DoDo» suggère que cela est tout à fait réalisable.
Que devons-nous faire pour convaincre les participants de la nécessité de changer les attitudes et les visions du monde?
Développeurs
Comment argumenter - pourquoi ont-ils besoin de faire autre chose que leur programmation de code fonctionnel préférée? Je propose de me concentrer directement sur les problèmes qui se posent avec une telle organisation. Il y en a plusieurs:
- Développer ce dont personne n'aura besoin. À mon humble avis, c'est l'un des premiers problèmes. Les développeurs font quelque chose, gardant confiance qu'ils le font bien, mais en fin de compte, ils obtiennent le mauvais résultat que l'utilisateur final voulait. Pourquoi? Parce que les tâches et les problèmes ne leur sont pas transmis par ceux qui en fin de compte utilisent le produit, mais par les gestionnaires ou les clients qui n'utilisent pas par la suite ces produits. Pourquoi cela se produit-il? Toutes les personnes ont des vues différentes. Si le développeur ne posait pas une tâche purement technique, mais fonctionnelle avec une description du résultat en sortie (et encore mieux - avec une description du problème que cette tâche devrait résoudre), alors il y aurait plus de compréhension du résultat et, par conséquent, du nombre de cas de développement de quelque chose inutile serait réduit. Oui, c'est une vérité bien connue, mais le problème ne disparaît toujours pas, il doit être résolu avec l'entreprise, justifiant de manière légèrement différente la formulation des tâches de développement. Sur la façon de transmettre cela à l'entreprise - plus loin.
- La nécessité de basculer entre les contextes. Souvent, dans le processus de développement avec la présence de tests manuels, les résultats des tests sont en retard, en conséquence, le développeur doit être distrait en résolvant les problèmes qui apparaissent à la suite des tests. Qu'est-ce qui empêche les développeurs de vérifier après la mise en œuvre leur propre résultat? Il y a deux points. Le premier est un manque de connaissances et de compétences dans le domaine de l'assurance qualité. Le deuxième - les développeurs pensent souvent que ce n'est pas leur travail et, par conséquent, ne veulent pas le faire. Dans l'un des premiers podcasts de RadioQA, il y a tout un problème de développement sans testeurs, qui décrit suffisamment en détail cet effet et les raisons de cette "réticence".
Comment les tests aideront-ils les développeurs ou comment les aider à résoudre les problèmes indiqués?
- Obtenez plus d'informations sur le domaine ou le but des tâches à résoudre. Quelles sont les questions typiques qu'un développeur pose lors de l'introduction d'une tâche? "Comment faire cela?" "Et que faut-il faire ici?" "Et comment faire cela malgré le fait que seul cela soit connu?" "Et comment cela affectera-t-il cette fonction?" Toutes ces questions visent à clarifier la mise en œuvre de la tâche , et ne pas comprendre la variabilité de cette tâche. Que fait un testeur lorsqu'il se familiarise avec une nouvelle description d'une nouvelle fonction? Il pose également des questions, mais d'une manière légèrement différente: «Que se passera-t-il si?» «Pourquoi en serait-il ainsi?» «Que devrais-je obtenir à la fin?» «Qu'est-ce que j'ai au début?» «Comment cela devrait-il être lié? avec ça? " Autrement dit, presque toutes les questions visent à identifier exactement le scénario utilisateur et à comprendre le résultat de cette fonction.
Qu'est-ce qui est important? En posant non seulement des questions de clarification (comment mettre en œuvre), mais aussi des questions visant à comprendre le résultat final, vous pouvez obtenir plus d'informations sur la tâche, rendre les méthodes attendues non seulement familières, mais aussi plus simples et plus efficaces. Dans un scénario positif, cela aidera à ne pas écrire de code supplémentaire ou à créer exactement ce dont l'utilisateur final a besoin, ce dont nous avons besoin.
Quelqu'un demandera: "Pourquoi devrais-je, en tant que développeur, être intéressé, ou devrais-je y penser?" Nous répondrons - afin de ne pas évoluer «vers la table». Les résultats d'une enquête auprès des développeurs de mon environnement montrent à quel point il est démotivant lorsque vous faites quelque chose, mais ne le publiez pas (mettez-le sur une étagère).
- Une autre question: "Pourquoi dois-je, en tant que développeur, faire des tests si nous avons des testeurs?" Ou "Pourquoi dois-je développer du code supplémentaire qui ne remplit pas les tâches de produit définies?" . Ici, vous pouvez proposer autre chose. Les tests automatisés sont essentiellement le même code qui obéit aux mêmes lois de programmation avec une légère nuance. Lorsqu'un développeur travaille dans le cadre d'un grand produit, il est obligé d'obéir aux règles de développement et aux technologies sélectionnées dans le produit, et d'écrire dans le langage que ce produit est écrit pour utiliser les cadres utilisés dans ce produit. Lors de la rédaction d'un test, cela n'est pas nécessaire: personne ne vous oblige à utiliser le même langage ou les mêmes approches: lors de la mise en œuvre de tests automatisés, vous pouvez facilement essayer un tout nouveau langage et en acquérir de l'expérience.
Il y a une règle simple à laquelle les développeurs adhèrent lors de l'écriture du code produit - l'optimisation maximale de ce que vous faites, la consommation optimale de ressources, les performances optimales, (de préférence) la réutilisation maximale, etc. Lors du développement de tests automatisés, il y a aussi des règles, il y a des modèles, il y a des frameworks, mais ils sont différents. Leur tâche est de leur permettre de faire le code de test le plus rapidement possible, ce qui fonctionnera ... Cela fonctionnera tout simplement.
L'optimisation et la vitesse d'exécution dans les autotests sont des points secondaires et ils ne sont pas mémorisés immédiatement. Donc, si vous voulez soudainement essayer avec Kotlin, Java ou tout autre langage, mais que le projet est écrit dans un langage complètement différent de celui que vous voulez (par exemple, en C #), vous pouvez le changer en celui que vous souhaitez en développant des autotests.
- «Comment puis-je tester? Je ne comprends rien à ce sujet. Je suis juste un développeur. " Ici, les testeurs viendront à la rescousse, ou plutôt les ingénieurs QA qui connaissent bien toutes les technologies sur lesquelles le produit principal est écrit. Grâce à leurs connaissances, ils peuvent aider à éduquer les développeurs sur comment et quoi tester, comment choisir les bonnes données, ce que le générateur de données devrait faire pour minimiser les risques par son type et ce à quoi vous ne devriez pas faire attention du tout. Dans un tel tandem, les testeurs tirent le meilleur parti de leurs connaissances et les développeurs ne font pas de travail inutile et inutile.
- «Mais qu'en est-il de la vitesse? Elle souffre! " Oui, elle souffrira dans les premiers stades de développement du projet, et oui, bien sûr, dès le début, plonger dans une automatisation complète coûte cher. Que faire pour que les coûts soient optimaux? Au minimum, nous devons clairement comprendre comment et quoi automatiser. Et il est également logique de ne pas tout fermer sans réfléchir avec des tests et de viser une couverture à 100% du code, mais de le faire sur la base du modèle de risque. Les ingénieurs QA feront de même.
- «Vitesse! Nous voulons obtenir des livraisons assez rapides. Nous voulons également faire confiance et nos produits étaient sans erreur! » Ici, je propose de changer l'approche du développement. S'il était à la mode de tout exécuter en mode débogage localement, maintenant, souvent pour les applications sérieuses, il faut une certaine infrastructure pour fonctionner. C'est là que toutes les nouvelles tendances en matière de dockereization et de mise en place de différents stands sont bien adaptées. Une autre chose est importante: même au tout premier stade de développement, vous devez penser à la façon dont il sera livré sur les postes de travail, c'est-à-dire non seulement déployer tout à la main, mais mettre en place un processus de déploiement automatisé. Que nous apportera-t-il? Lorsque viendra le temps de la livraison à la production, il nous suffira de changer uniquement le point de calcul, et de ne pas configurer tout le processus à partir de zéro. Qu'est-ce que cela donnera au développeur? Plus de confiance qu'il fait tout correctement, car les scripts de livraison ont été vérifiés pendant plus d'un tour, et il ne devrait y avoir aucun problème avec la version.
Entreprise
Mais qu'en est-il des affaires? Pourquoi devrait-il s'intéresser à cette transformation? Pourquoi est-il judicieux pour lui d'investir dans cette approche? Construisant l'explication, je vais suivre le même chemin. Quels problèmes cette entreprise a-t-elle maintenant, quels problèmes devez-vous résoudre lorsque vous travaillez dans le domaine informatique et lorsque vous développez des produits de haute technologie? Encore une fois, je m'appuierai précisément sur mon opinion:
- "Qu'est-ce qui ne convient pas le mieux à l'entreprise?" Souvent, le développement oublie que le produit doit non seulement être développé, mais aussi vendu, pour lequel un ensemble de mesures suffisamment important est nécessaire, y compris sa préparation à l'entrée sur le marché. Faire cela après le développement du produit est un échec garanti, c'est pourquoi la plupart des travaux de préparation des canaux de vente et de promotion d'un nouveau produit commencent presque au moment même où le développement commence.
«Que se passe-t-il si le développement est en retard pour la date de sortie? Ou le développement produira-t-il un produit de qualité insuffisante sur le marché? » Il y aura des pertes. Et pas seulement matériel, mais aussi réputationnel. Il est important pour les entreprises de s'assurer qu'au moment de la vente, le produit sera non seulement prêt, mais également de bonne qualité. S'il y a des étapes manuelles de tests dans le processus de développement, il sera inévitablement nécessaire soit de reprogrammer les délais, soit de prendre en compte les risques de perturbations à ces étapes. Il est possible de prédire le facteur humain, mais il est difficile et (à mon avis) n'est pas moins cher.
- «De quoi d'autre s'occupe l'entreprise?» Bien sûr, il s'inquiète des investissements en capital dans le développement. Mais les investissements en capital, pour la plupart, bien que volumineux, sont effectués au stade initial, c'est-à-dire Avant la sortie, ou du moins avant la sortie, les coûts ne sont pas compensés par les ventes. Parallèlement aux investissements en capital, il y a aussi des dépenses de fonctionnement qui commencent à contribuer au stade opérationnel et il est important d'essayer de les minimiser autant que possible.
"Pourquoi l'automatisation est-elle assez chère (en termes de dépenses en capital) dans ce cas, gagne par rapport à l'approche manuelle?" Mon avis est un facteur évident. L'automatisation est le même développement. , . , , , , . , . Pourquoi est-ce important? . , , « , , , » , , .
- — . , . , , . , .
? , - . . , , , . , , , , , . , .
Supposons qu'une entreprise accepte la nécessité de changements de processus et soit prête à «tout acheter en une fois». Combien cela coûtera-t-il et quelles dépenses devraient être incluses?- , , , , . : X Y , , , X Z , Z < Y. : , , ( ) .
- — QA-. , «» . , QA- , , , . : , , , , , .
— , . . , , , , , , , , , . .
- — . , , . , , , , . , QA-. , . , , «» — , , , . , , .
- , , — (, , - ). . , . , , , , , (), .
Il est impossible de dire que cette voie est nettement plus rentable par rapport à une solution manuelle, mais tout son avantage se révèle sur les deltas de dépenses d'exploitation et de satisfaction des utilisateurs finaux. Nous pouvons comparer cela à l'achat d'une voiture chère mais fiable qui ne nécessite pas de dépenses, à l'exception de l'essence et de l'entretien régulier, et à l'achat d'une vieille voiture d'occasion. Oui, le prix d'un neuf est plus élevé au départ, mais les coûts d'exploitation sont moindres, le confort et le "calme" sont plus élevés. Avec un modèle d'occasion au début, les coûts sont faibles, mais pendant le fonctionnement, les coûts augmentent et, après un court laps de temps, peuvent être comparés au coût de l'achat initial.Allez-y. N'oubliez pas notre contexte et rappelez la composition de la fonction de test.Testeurs
Qu'adviendra-t-il de la fonctionnalité de test existante? Si nous regardons à nouveau la composition de cette fonction, alors avec une certitude de 90%, nous pouvons dire que 60% des employés de toute la structure ne seront pas utiles dans la nouvelle forme de la fonction, mais il y en a plusieurs MAIS.Si vous vous souvenez que nous avons mentionné des produits nouveaux et anciens de notre société. La transition de nouveaux produits vers le modèle de livraison que j'ai décrit sera relativement indolore, car ils ne sont pas encore dans la version ou viennent de le quitter. Dans le même temps, les produits qui fonctionnent depuis longtemps ne permettent pas immédiatement d'appliquer de tels concepts. Cela ne signifie pas que vous devez y mettre fin, il y a quelque chose à changer, mais ce ne sera pas rapide - faire décoller le processus, obtenir des processus de livraison plus fiables et plus rapides.C'est pourquoi la couche de la fonction de test «manuelle» ne cessera pas d'exister du jour au lendemain, pour cela vous devrez faire beaucoup d'efforts. Une partie des testeurs «manuels» auront le temps de devenir ingénieurs en automatisation ou ingénieurs QA. Il est bien évident qu'au cours de ce processus de transition, le lien intermédiaire et supérieur assumera la fonction de support - ils sont les candidats les plus susceptibles d'être intégrés dans de nouveaux concepts à différents niveaux demain. Une équipe senior ayant de l'expérience et des connaissances, également familiarisée avec les concepts d'automatisation et de test ShiftLeft, est prête à jouer le rôle d'ingénieurs QA demain, le lien du milieu prendra un certain temps, mais ils pourront également s'intégrer rapidement dans les rôles d'ingénieur QA ou ingénieur en automatisation.Certainement, je n'ai pas encore répondu à des questions sur ce vaste sujet. Ce sont ceux que je ne comprends pas encore. En attente de vos commentaires.