Cet article intéressera ceux qui, comme nous, sont confrontés au problème de la sélection d'un spécialiste approprié dans le domaine des tests.
Curieusement, avec l'augmentation du nombre d'entreprises informatiques dans notre république, seul le nombre de programmeurs dignes augmente, mais pas celui des testeurs. Beaucoup de gens sont impatients d’exercer ce métier, mais peu en comprennent le sens.
Je ne peux pas parler au nom de toutes les sociétés informatiques, mais nous avons confié le rôle d'AQ/CQ à nos spécialistes qualité. Ils font partie de l'équipe de développement et participent à toutes les étapes du développement, de la recherche jusqu'à la sortie d'une nouvelle version.
Un testeur dans une équipe, même au stade de la planification, doit réfléchir à toutes les exigences fonctionnelles et non fonctionnelles pour accepter une user story. Il doit comprendre les caractéristiques opérationnelles du produit ainsi que les programmeurs, voire mieux, et aider l'équipe à ne pas prendre de mauvaises décisions même au stade de la planification. Le testeur doit avoir une compréhension claire du fonctionnement de la fonctionnalité implémentée et des pièges possibles. Nos testeurs créent eux-mêmes des plans de tests et des cas de tests, ainsi que préparent tous les bancs de tests nécessaires. Les tests selon une spécification toute faite comme un clicker de singe ne sont pas notre option. Travaillant au sein de l'équipe, il doit contribuer à la sortie d'un produit digne et tirer la sonnette d'alarme à temps si quelque chose ne va pas.
Ce que nous avons rencontré lors de la recherche de testeurs
Au stade de l'étude de nombreux CV, il semblait qu'il y avait des spécialistes ayant une expérience appropriée pour nous et qu'il n'y aurait aucun problème pour choisir un testeur pour notre équipe. Mais, lors de rendez-vous personnels, nous rencontrions de plus en plus de candidats qui étaient en réalité assez éloignés du monde de l'informatique (par exemple, ils ne savaient pas comprendre les principes d'interaction entre un navigateur et un serveur web, les bases de la sécurité, du relationnel et du non-respect des technologies de l'information). bases de données relationnelles, ils n'avaient aucune idée de la virtualisation et de la conteneurisation), mais en même temps s'évaluaient au niveau Senior QA. Après avoir mené des dizaines d'entretiens, nous sommes arrivés à la conclusion que le nombre de spécialistes qui nous conviennent dans la région est négligeable.
Ensuite, je vais vous dire quelles mesures nous avons prises et sur quelles erreurs nous avons marché afin de trouver ces combattants de qualité tant attendus.
Comment nous avons essayé de régler la situation
Après nous être épuisés à sourcer des spécialistes prêts à l'emploi, nous avons commencé à cibler les zones proches :
- Nous avons essayé d'appliquer des pratiques d'évaluation pour identifier parmi les nombreuses personnes « laissées pour compte », celles-là mêmes à partir desquelles nous pouvons former de solides spécialistes.
Nous avons demandé à un groupe de candidats potentiels ayant à peu près le même niveau de connaissances d'accomplir des tâches. En observant leur réflexion, nous avons tenté d'identifier le candidat le plus prometteur.
En particulier, nous avons proposé des tâches pour tester l'attention, la compréhension des capacités de la technologie et des caractéristiques du multiculturalisme :
- Nous avons organisé des rencontres pour les testeurs afin de repousser les limites de la compréhension de la profession parmi le contingent existant.
Je vais vous parler un peu de chacun d'eux.
Ufa Software QA and Testing Meetup #1 est notre première tentative de rassembler ceux qui se soucient de la profession et en même temps de comprendre si le public sera intéressé par ce que nous voulons leur transmettre. Fondamentalement, nos rapports portaient sur par où il est préférable de commencer si vous décidez de devenir testeur. Aidez les débutants à ouvrir les yeux et à considérer les tests comme un adulte. Nous avons parlé des étapes que les testeurs débutants doivent suivre pour accéder à la profession. Qu'est-ce que la qualité et comment y parvenir dans des conditions réelles. Et aussi, qu'est-ce que le test automatique et où il est plus approprié de l'utiliser.
Ensuite, à un intervalle de 1 à 2 mois, nous avons organisé deux autres rencontres. Il y avait déjà deux fois plus de participants. Lors du « Ufa Software QA and Testing Meetup #2 », nous avons approfondi le sujet. Ils ont parlé des systèmes de suivi des bogues, des tests UI/UX, ont abordé Docker, Ansible, et ont également parlé des conflits possibles entre un développeur et un testeur et des moyens de les résoudre.Notre troisième réunion, « Ufa Software QA and Testing Meetup #3 », était indirectement liée au travail des testeurs, mais a été utile pour rappeler aux programmeurs leurs tâches techniques et organisationnelles : tests de charge, tests e2e, Selenium dans les tests automatiques, vulnérabilités des applications Web. .
Pendant tout ce temps, nous avons appris à créer une lumière et un son normaux dans les retransmissions de nos événements :
→
→
→ - Et finalement, nous avons décidé d'essayer d'organiser un hackathon pour les testeurs
Comment nous avons préparé et mené un hackathon pour les testeurs
Pour commencer, nous avons essayé de comprendre de quel genre de « bête » il s’agit et comment elle est habituellement réalisée. Il s’est avéré que des événements de ce type n’ont pas eu lieu souvent en Fédération de Russie et il n’y a nulle part où emprunter des idées. Deuxièmement, je ne voulais pas investir immédiatement beaucoup de ressources dans un événement qui semblait douteux à première vue. Par conséquent, nous avons décidé d'organiser de courts mini-hackathons, non pas pour l'ensemble du cycle de travail d'assurance qualité, mais pour des étapes individuelles.
Notre principal problème est le manque de pratique parmi les testeurs locaux dans la création de cartes de tests claires. Ils ne passent pas de temps à rechercher des témoignages d'utilisateurs avant la mise en œuvre et à créer des critères d'acceptation clairs pour les développeurs concernant les exigences fonctionnelles et non fonctionnelles, l'UI/UX, la sécurité, les charges de travail et les charges de pointe. C'est pourquoi nous avons décidé, pour la première fois, d'aborder la partie la plus intéressante et la plus créative de leur travail : l'analyse et la formation des exigences lors de la recherche avant-projet.
Nous avons estimé le nombre potentiel de participants et décidé que nous avions besoin d'au moins 5 backlogs pour les versions MVP, 5 produits et 5 personnes qui agiraient en tant que propriétaires de produits, déchiffreraient les besoins commerciaux et prendraient des décisions sur les restrictions.
Voici ce que nous avons : .
L’idée principale était de proposer des sujets aussi éloignés que possible du travail quotidien de tous les participants et de leur laisser la possibilité d’une envolée créative de l’imagination.
Quelles erreurs avons-nous commises et que pourrions-nous faire mieux ?
Le recours aux pratiques d'évaluation, si populaires dans le domaine du recrutement de commerciaux et de managers de niveau inférieur, a demandé énormément d'efforts, mais n'a pas permis d'accorder suffisamment d'attention à chaque participant et d'évaluer ses capacités. En général, cette option de sélection crée une image négative de l'entreprise, car de nombreuses personnes reçoivent un retour d'information insuffisant et créent par la suite en elles-mêmes et chez les autres l'effet de tyrannie de l'employeur (la communication dans les communautés informatiques est très développée). En conséquence, nous nous retrouvons littéralement avec deux candidats potentiels avec un avenir très lointain.
Les meetups sont une bonne chose. Une base d'élaboration étendue est créée et le niveau général des participants augmente. L'entreprise devient de plus en plus reconnaissable sur le marché. Mais l'intensité de main-d'œuvre de ces entreprises n'est pas minime. Vous devez clairement comprendre que l'organisation de rencontres prendra environ 700 à 800 heures de travail par an.
Quant au hackathon de test. Ce type d’événements n’est pas encore ennuyeux car, contrairement aux hackathons pour développeurs, ils sont beaucoup moins fréquents. L'avantage de cette idée est que vous pouvez échanger de manière détendue une grande quantité de connaissances pratiques et déterminer assez précisément le niveau de chaque participant.
Après avoir analysé les résultats de l'événement, nous avons réalisé que nous avions commis beaucoup d'erreurs :
- L'erreur la plus impardonnable a été de croire que 4 à 5 heures nous suffiraient. En conséquence, la simple introduction et familiarisation avec les arriérés a pris près de 2 heures.
Travailler avec les propriétaires de produits au stade initial et le temps nécessaire pour se plonger dans le domaine a pris le même temps. Le temps restant n’était donc clairement pas suffisant pour développer complètement les cartes de test. - Il n'y avait pas assez de temps et d'énergie pour un retour détaillé sur chaque carte, car il faisait déjà nuit. Par conséquent, nous avons clairement échoué dans cette partie, mais elle était initialement destinée à être la plus précieuse du hackathon.
- Nous avons décidé d'évaluer la qualité du développement par un simple vote de tous les participants, en attribuant 3 votes à chaque équipe, qu'ils pourraient donner pour un travail de la plus haute qualité. Il vaudrait peut-être mieux organiser un jury.
Qu’avez-vous réalisé ?
Nous avons partiellement résolu notre problème et nous avons désormais 4 hommes courageux et beaux qui travaillent pour nous, couvrant l'arrière de 4 équipes de développement. Un bassin important de candidats potentiels forts et des changements tangibles au niveau de la communauté d’assurance qualité de la ville n’ont pas encore été remarqués. Mais il y a des progrès et cela ne peut que nous réjouir.
Source: habr.com