Comment le contrôle qualité crée une interaction efficace avec les développeurs. Une voie possible

L'un , complété par un autre , mes articles se sont avérés être un guide d'action possible pour ceux qui n'ont pas encore trouvé «leur propre style» et ne savent pas par où commencer.

Certains ont répondu que j'écrivais sur les «vérités communes», mais j'ai reçu une bonne réponse dans les commentaires et les messages personnels de la catégorie «c'était utile», «ce dont j'ai besoin maintenant», etc. Mais il y avait des questions. Les questions, pour la plupart, se résumaient à la «douleur» qui n'a pas passé un seul AQ dans sa carrière:

• Comment interagir efficacement avec les développeurs?
• comment organiser le travail avec eux pour qu'ils acceptent: y a-t-il un autre avis sur le projet, l'avis de l'AQ, et est-ce aussi important?
• comment les encourager à interagir, par exemple, lors de la création d'une automatisation de test commune lorsqu'ils ne sont pas configurés pour fonctionner ensemble?
• comment agir dans le cas où vos compétences techniques dans la pile de technologies utilisées ne sont tout simplement pas suffisantes?

Faites immédiatement une réserve que le sujet est très sensible, en en parlant, vous devez toujours équilibrer sur le point de ne pas nuire à la fierté des développeurs et de l'assurance qualité elle-même. Par conséquent, je vous prie de lire avec un cœur froid et d'essayer de mettre en évidence quelques points utiles et de les essayer dans la pratique.

Présentation

Premièrement, comme le montre la pratique, souvent les AQ qui n'arrivent pas à s'introduire dans le développement comme l'exige la profession

• tout simplement pas sûr de soi. Ils ne peuvent pas réaliser qu'ils ont été entendus, car ils parlent de manière inaudible, non raisonnable, exprimant des doutes constants;
• ils ont peur de faire des erreurs et encourent des responsabilités supplémentaires;
• complexe en raison de connaissances techniques imparfaites.

Deuxièmement, les développeurs de l'équipe perçoivent l'AQ comme un appendice qui appuie simplement sur les boutons avant de donner le produit au client, ou qui n'imagine tout simplement pas comment interagir avec eux. Cela peut être dû au fait que

• ils pensent encore à l'AQ en tant que testeurs il y a 10 à 20 ans, alors qu'ils l'étaient vraiment;
• tous les précédents AQ avec lesquels ils ont travaillé exactement de la même manière et se sont comportés, et ils ne savent tout simplement pas ce qui se passe autrement;
• en principe, ils ne savent pas l'essence du travail de l'ingénieur QA, car ils n'en ont tout simplement pas besoin - ils développent leurs compétences;
• le développement de code est déjà bien établi et changer quelque chose n'est que paresse.

Commençons par le premier problème.

Ingénieur QA! Faites un nettoyage de printemps dans votre tête

Travailler à comprendre votre métier

Si vous voulez changer le monde, commencez par vous-même. Vérité bien connue et très pertinente dans notre sujet.
En tant qu'ingénieur QA, cela ne vous fait vraiment pas de mal de savoir pour quel poste vous travaillez. Si votre projet vit toujours selon les principes de l'architecture en cascade et que vous avez été embauché simplement par un testeur manuel qui, comme OTK dans les entreprises, vérifie la préparation du produit final, alors c'est une chose, et ici tout est assez transparent.

Et si vous êtes dans la position d'un ingénieur QA à part entière, ce qui est presque universel maintenant, cela signifie que votre responsabilité, définie par les canons de cette profession en [1], consiste non seulement à tester le produit fini, mais aussi à participer directement à l'organisation des processus de sa création et à l'interaction des participants. l'ensemble du projet. N'oubliez pas que sans processus et organisation clairs de l'équipe, il est presque impossible d'obtenir un produit de qualité.Par conséquent, dans ce domaine, la voix de l'assurance qualité doit être sûre et claire. Pour éviter l'apparition de bugs, et non pour les corriger après coup - c'est le lot d'équipes bien organisées. Et faire des efforts pour minimiser le nombre de bugs est le lot de l'équipe QA. (Le cercle se ferme.)

Par conséquent, le tout premier, rappelez toutes les choses fondamentales sur les principes, les types, les niveaux de test et le libellé de la définition de la profession d'ingénieur QA. Comprendre le fameux "Qui suis-je?" et "Pourquoi suis-je ici?"

Trouvez les réponses aux questions

Lorsque l'auto-creusage professionnel est terminé, définissez un plan pour vous-même, ce que vous ferez, vous pouvez prendre des idées de mes articles ou élaborer votre propre plan qui convient à votre situation. Chaque point de votre activité doit être clair pour vous vous-même - pourquoi, comment le mettre en œuvre, quel est le profit.

Ce n'est que dans ce cas que vous pourrez parler en toute confiance du projet. Même si jusqu'à présent vous ne connaissez que les réponses aux questions «pourquoi» et «quel est l'avantage», mais vous ne savez pas «comment». Sentez-vous déjà confiant du fait que vous voyez l'avant du travail, la formulation correcte de la tâche est un succès à 80%.

L'étape suivante consiste à noter les questions que vous devez résoudre afin de répondre à la question «comment». Et allez voir les gens avec cela, c'est-à-dire discutez avec l'équipe - lors d'une réunion spécialement organisée, discutant entre les entreprises ou de manière informelle dans la cuisine autour d'une tasse de café, cela n'a pas d'importance. Il est important que votre projet soit plein de gens qui ont une expérience différente, d'autres connaissances, utilisez ce magasin d'informations utiles, communiquez, demandez et tout sera clarifié.

Laissez tomber l'expérience que vous n'êtes pas parfait

Si vous êtes très timide ou dans la vie un maximaliste qui s'efforce toujours d'être un leader, alors il sera difficile de jouer le rôle d'AQ. Parce que QA Engineer est un ingénieur, c'est une personne impliquée dans le développement, mais en même temps, nous nous retrouvons sur des projets avec une pile de technologies et d'architecture différente, tandis que les développeurs ont leur propre spécialisation. Reconnaître que vous êtes «hors sujet» pour certaines personnes signifie vous écrire dans un «maillon faible». Et c'était mon problème, que j'ai lutté pendant très, très longtemps. "Est-ce que je dois dire que je ne sais pas, que je ne sais pas quoi, je ne comprends pas?!" - Plus d'une fois, je suis tombé dans une stupeur en discutant de tous les aspects techniques.

Mais ce n'est qu'à un certain moment que j'ai finalement réalisé que ne pas savoir n'est pas une honte. J'ai honte de continuer à "me cacher dans la coquille" et de ne pas essayer de le découvrir. Et garder le silence, sembler tout comprendre, est plus cher à soi-même.

Vous avez été embauché, ils ont lu votre CV (vous serez sûr de vos capacités;)), vous vous êtes entretenu lors de l'entretien et vous avez été embauché. Votre pile de compétences techniques convient donc à tout le monde et à ceux qui vous ont embauché ont deviné à quoi s'attendre. Par conséquent, sauter au-dessus de votre tête n'a plus de sens. Et quand vous dites: "Je n'ai jamais travaillé avec ça, mais je veux le comprendre, aidez-moi à comprendre ceci et cela" - c'est une situation absolument normale, saine et correcte (n'apportez pas seulement le plus primaire au point d'absurdité connaissances - définitions et formulations - apprendre d'Internet). Et lorsque vous indiquez aux autres que vous ne comprenez pas ce contexte technique, premièrement, ils estiment déjà qu’il est nécessaire de communiquer plus simplement, et deuxièmement, vous pouvez poser des questions de clarification en toute conscience. Si vous avez écrit le code une ou deux fois et que vous avez complètement compris l'architecture interne du projet, vous seriez probablement directement impliqué dans le développement, non?

Et mon petit truc préféré est de toujours aider les autres, quand je le peux - par des actes, des conseils, des paroles aimables, cela revient avec le désir mutuel des autres de m'aider.

N'ayez pas peur de faire des erreurs

Tenez pour acquis que les workflows impliquent une discussion de toutes les options possibles. La vérité naît dans un différend. Votre tâche n'est pas d'avoir raison, mais de trouver les meilleures solutions. Et si vous voulez offrir quelque chose, mais avez peur que cela vous paraisse idiot, alors croyez-moi combien d'équipes j'ai vu, les collègues silencieux les plus indifférents semblent perdants. Reconnaître certaines de nos erreurs, soutenir les meilleures idées et contribuer avec enthousiasme à leur mise en œuvre est un flux de travail sain.

Rappelez-vous, l'héroïne de Muravyeva dans le film "Moscou ne croit pas aux larmes" s'est installée avant d'aller à la bibliothèque: "si vous lâchez, lâchez en toute confiance - alors c'est ce qu'on appelle un point de vue". Ça marche vraiment.

N'ayez pas peur de faire appel à vous-même des tâches que vous ne pouvez pas gérer. Rappelez-vous, vous travaillez en équipe et dites que quelque chose ne fonctionne pas et demander de l'aide à l'équipe est normal.

Et même si au cours de votre travail vous arrivez à la conclusion «vous n’avez pas à faire cela», ce sera un progrès, car la prochaine étape est de trouver la meilleure solution.

Publier des normes obsolètes, regarder vers l'avenir

Ces fondements que l'AQ est une position basse, ce n'est pas si important et pas si significatif d'une manière ou d'une autre que l'on retrouve dans les équipes. Et pendant que vous le pensez vous-même, vous sous-estimez, hélas, cette tendance à se nourrir.

Vous travaillez tous les jours, vous faites des efforts tous les jours, améliorez le produit et l'équipe, vous passez du temps et de l'énergie, votre position est définie dans le cadre de projets - cela signifie qu'elle est importante et nécessaire. C’est tout. Ne laissez pas de place à l'auto-mutilation, et ne laissez pas de place dans votre tête aux «railleries» de ceux qui considèrent que vous êtes un statut inférieur à lui. Ces temps, où il y avait de simples testeurs manuels de testeurs de singe, sont tombés dans l'oubli, à l'avenir, les ingénieurs QA sont «un détachement d'élite des forces spéciales dont le succès dépend d'excellentes tactiques et d'armes modernes» [2].

N'oubliez pas qu'aujourd'hui, dans des entreprises de premier plan comme, par exemple, Microsoft et Google, «les développeurs sont responsables de la qualité. Si le produit se casse après sa sortie, les cônes voleront vers le développeur qui a créé le problème, et non vers le testeur qui ne l'a pas trouvé »[2]. Par conséquent, dans ces entreprises, avoir une équipe AQ ​​qui aidera à créer un produit de qualité est un privilège pour les développeurs.

Et c'est entre vos mains d'introduire des principes avancés dans vos entreprises, au lieu de revenir sur les stéréotypes du passé.

Mais encore une fois, je reviens sur le fait que vous devez constamment évoluer dans votre projet. Si vous êtes venu au projet, six mois se sont écoulés et vous n'avez toujours pas trouvé d'automatisation efficace des tests, n'essayez pas de comprendre ce que fait l'équipe, n'analysez pas les autotests existants, alors vous n'êtes pas tout à fait l'élite sur laquelle les livres écrivent.

Il y a des équipes qui vivent sans aucun poste d'ingénieur QA, je les connais. Et si vous vous efforcez déjà aujourd'hui de vous immerger dans le projet et d'apprendre à écrire des autotests avec les développeurs, un jour vous pourrez vendre vos compétences même là-bas et devenir ingénieur logiciel en test là-bas.

Ingénieur QA! Affiner le travail d'équipe

Lorsque le travail sur vous-même est terminé, il est temps de travailler à établir une collaboration avec les développeurs.

La chose la plus importante

• Vos actions doivent être claires et transparentes pour l'équipe. Le plus simple et le plus efficace est de leur transmettre leur mission. Si, sans raison, vous commencez à grimper dans leur bassin avec des demandes demandant "quel genre de tests avez-vous ici?", "Mais vous devriez écrire un tel test", la première réaction (protectrice) sera " où allez-vous?! "," qui êtes-vous / tel pour critiquer mon travail?! ". Il a peut-être préparé ce brunch pendant une semaine, enfin expiré, puis QA l'a compris. Par conséquent, dites-leur à l'avance ce que vous allez faire, pourquoi et quels en sont les avantages pour le projet et l'équipe. Préparez le sol.
• Votre participation au développement a priori doit être perçue comme une bénédiction, comme quelque chose qui améliore qualitativement le travail du développeur. Devenez son partenaire. Par exemple, éduquez - dites comment les clients sont susceptibles d'utiliser la fonctionnalité, quels bogues ont déjà eu lieu et lesquels doivent être évités, ce qui signifie ensemble réfléchir à quels tests et pourquoi sont importants. Ne communiquez pas de manière impérative. Vous pouvez même recourir à des astuces psychologiques - pour noter ceux qui ont augmenté la couverture des auto-tests dans certains rapports finaux au format «nous sommes tous bien faits!». C'est toujours agréable quand votre travail est apprécié. Et les revues d'AQ traditionnelles avec couverture de test automatique sont également une motivation pour travailler ensemble.

Laissez les changements sur le projet se faire en douceur. Si vous venez travailler un matin et dites: "J'ai lu un article sur Habré, et vous allez commencer à donner une fessée à une chaussure sur une plateforme conditionnelle, en secouant l'air, ils disent, maintenant je vais vous montrer la mère de Kuzkin!", Ils vous regarderont comme étrange, c'est un fait. Oui, et ce sera difficile pour vous - face à des problèmes sur tous les fronts - il y aura un désir irrésistible de renoncer à l'idée d'améliorer le travail de l'AQ.

Mieux vaut définir de petites tâches compréhensibles pour tout le monde, les réaliser et entreprendre les tâches suivantes. Avancez prudemment, le temps passe vite, un jour ce sera bien de rebrousser chemin.

Réponses à des questions spécifiques

Après mon deuxième article , qui proposait un travail approfondi d'AQ et de développement, le public a expiré de la catégorie "nous avons essayé, mais le chef d'équipe des développeurs ne voulait pas vraiment se rencontrer." De mon niveau actuel de développement professionnel, je ne peux que conseiller les éléments suivants.

Soyez amical et traitez avec sagesse ceux qui n'acceptent pas votre travail comme vous vous y attendez. Dans ma pratique, j'ai rencontré de nombreux développeurs différents et tous ceux qui étaient vraiment matures professionnellement sont toujours venus me rencontrer, toujours aidés, et nous avons obtenu d'excellents résultats communs, ils étaient tous satisfaits. Ceux qui «reniflent» et «s'éloignent de vous», hélas, appartiennent à la catégorie des «adolescents professionnels». Ils n'ont pas encore appris à faire face à leurs sentiments, se considérant comme les plus à droite (et l'âge physique ne joue pas de rôle ici). Ils ne savent tout simplement pas comment travailler en équipe et vous en faites partie intégrante. Vous pouvez simplement les aider à grandir, mais, malheureusement, certains ne grandissent jamais. Et ici, vous ne pouvez les influencer que grâce au soutien du leadership et à l'autorité collective du reste de l'équipe qui vous soutiendra. Si vous connaissez les meilleurs moyens, partagez!

Il y avait aussi une question intéressante sur comment être si vous ne savez pas encore lire le code développeur, vous ne pouvez pas comprendre leurs autotests.

Je vais laisser ma réponse ici, afin qu'elle ne soit pas perdue, peut-être que quelqu'un vous sera utile. Si vous ne pouvez pas le lire, j'insisterais pour inclure une liste d'autotests développés dans la description du RP et je me concentrerais dessus. Je crois que c'est le plein droit et le devoir de l'équipe QA d'être aussi conscient que possible de la couverture du produit avec des autotests, sinon l'idée de l'assurance qualité est perdue ... Si nous considérons la situation de limitations de temps sévères de toute l'équipe, y compris le développeur, alors j'insisterais sur l'examen Couverture des scénarios critiques / stratégiques par autotests d'intégration. Et pour tous les autres scénarios, j'ai documenté des tâches distinctes pour les faire plus tard. Dans tout projet, il y a des périodes calmes où il n'y a pas de délais - alors il vaut la peine de concentrer le chef de produit / chef d'équipe / Scrum Masters sur la façon d'inclure ces tâches: c'est plus compliqué - laissez les développeurs le faire, apprenez vous-même les plus simples.

Conclusion

Je ne peux pas dire que tout ce qui est écrit ci-dessus vous aidera certainement, après tout, j'ai le sentiment que ma propre voix et mon style professionnels viennent avec l'expérience et à travers des bosses farcies. Il est impossible de prendre et comment appliquer le script de travail de quelqu'un d'autre à votre projet via un gabarit. Mais si mon gribouillage vous a incité à ne pas supporter les moments que vous n'aimez pas et que vous aviez des idées en tête que vous pouvez faire pour vous-même, pour l'équipe, pour le produit, alors j'ai passé le temps pas en vain. Et oui, ne pensez pas que je dépeins QA Shark, qui sait tout, sait tout. J'étudie et change constamment. Je suis bien conscient que dans un an mes principes de travail pourront changer. Toujours très satisfait des commentaires et je serai heureux d'apprendre de votre expérience, écrivez;)

Et si vous voulez lire quelque chose pour renforcer votre propre motivation, commencez par deux merveilleux livres, une référence à laquelle j'ai donné dans le texte:

1. Fondements des tests de logiciels: certification ISTQB
par Dorothy Graham, Rex Black, Erik van Veenendaal, Isabel Evans
2. Comment tester sur Google
James Whittaker, Jason Arbon, Jeff Carollo

Merci à tous pour votre attention!