Contexte
Récemment, une de mes connaissances ingénieur QA, qui a longtemps travaillé dans un projet lent, où ses responsabilités étaient strictement décrites, a changé son travail et s'est lancée dans un projet fraîchement lancé. Après avoir passé quelques jours sans les tâches indiquées ci-dessus, et franchement ennuyée, elle est allée à la direction avec la question "Que dois-je faire?" à laquelle elle a reçu une réponse significative "Organisez votre travail." Et puis elle est tombée dans une stupeur "Et comment est-ce?" Et vraiment, comment?
Il y a quelques mois, j'ai moi-même changé d'emploi et je me suis lancé dans un projet anglais qui n'avait jamais eu de QA auparavant. Le projet lui-même existe depuis longtemps. Comme cela arrive souvent, une entreprise dans laquelle il y a beaucoup d'argent a acheté une entreprise dans laquelle il y a moins d'argent, mais il y a des clients. En conséquence, une grande entreprise a reçu de nouveaux clients et moins un concurrent sur le marché. Mon projet a reçu un changement de gestion et de principes de gestion.
Dès les premiers jours de la rencontre avec une nouvelle équipe, j'ai entendu une question déconcertante et honnête de l'un des développeurs du bureau de Londres: «Que ferez-vous ici?»
En vérité, étant venu à ce projet et regardant autour de moi pendant plusieurs jours, comme mon collègue, je suis d'abord tombé dans la stupeur. Pas parce que je ne savais pas quoi faire. Au contraire, je ne savais pas comment me coincer correctement dans les fondations qui se sont développées ici. L'équipe de développement a eu une merveilleuse existence sans testeurs. Ils ont utilisé le kanban, les principes de la livraison continue, déployés sans crainte, calmement et en toute confiance en production presque tous les jours, même le vendredi. Et tout cela parce qu'ils avaient une excellente couverture avec les autotests. Peut-être le meilleur que j'aie jamais rencontré. Lors de l'examen des demandes des uns et des autres, ils n'ont pas hésité à se dire quels autres autotests ajouter. L'auteur du changement actuel a lui-même déployé son travail à la production, ce qui signifie qu'il était pleinement responsable de son travail. Et il l'a porté, malgré le fait que je sois apparu sur le projet ... et avant le déploiement ce serait bien d'entendre mon avis.
Mais néanmoins, bien sûr, le processus n'était pas parfait: il arrivait que les développeurs ne comprenaient pas les exigences, manquaient les bogues et assez souvent du côté des clients, il y avait des problèmes qui nécessitaient une action.
Confronté à la nécessité de déterminer ma position dans l'équipe, je suis également passé à la direction. Seul notre dialogue a été construit différemment, pas comme celui de mon ami.
Organisation du travail de l'ingénieur QA
Posez les bonnes questions.
Alors. Pour un dialogue, j'ai convoqué la direction et les principaux développeurs du projet. Il y a une merveilleuse règle de gestion que je ne pouvais bien sûr pas oublier: exprimer le problème, exprimer l'option de le résoudre, au moins une.
Néanmoins, j'avais deux questions, les réponses auxquelles je ne pouvais pas savoir. La façon la plus simple de commencer avec eux.
Première question. Quelle est la structure de l'organisation, à savoir qui se tient au-dessus de qui et qui est responsable de quoi?Idéalement, les entreprises devraient avoir un schéma présenté de manière hiérarchique illustrant la structure de l'entreprise. Mais je ne suis pas idéal, il était donc important de savoir à qui s'adresser avec quelles questions et suggestions.
La deuxième question. L'entreprise a introduit QA Engineer dans le projet, quelles sont leurs attentes pour moi, quels étaient leurs objectifs en ouvrant ce poste?Lorsque la réponse est très précise, elle détermine largement le front du travail. Dans mon cas, la réponse contenait beaucoup de phrases générales floues, que j'ai perçues comme "faites ce que vous voulez, mais pour que tout va bien avec nous."
Sur ce point, la première partie de la discussion s'est terminée.
Nous discutons du plan d'action
La deuxième partie des discussions, et peut-être la plus importante, a été la présentation de mon plan de travail et sa justification. J'avais besoin de recevoir la bénédiction de mes supérieurs pour l'introduction sans entraves de moi-même et de mes activités dans le projet.
Il est agréablement évident que les livres intelligents et la théorie n'existent pas à partir de zéro, alors je me suis armé des connaissances acquises en préparation de la certification ISTQB, une fois par curiosité, j'ai lu des livres sur la théorie des tests et Scrum, j'ai laissé tout cela passer par un tamis de dix ans d'expérience et j'ai compilé un pilote projet de stratégie d'AQ.
Négocié avec la direction et pleinement soutenu par lui, il a par la suite acquis le format du document officiel de l'entreprise. Ensuite, je veux partager des idées sur la façon d'élaborer un tel document. Ils ont formé la quintessence de l'expérience antérieure et du chemin parcouru sur le projet actuel.
Et, peut-être, sous forme de citations, je réimprimerai ici quelques fragments dans ma forme originale: en anglais. Je suis sûr que pour chaque ingénieur AQ, la préparation d'un tel plan sera la réponse clé à la question "Comment organiser son travail"
Nous formons une stratégie d'assurance qualité
1. Introduction à l'assurance qualité
Rappelez / introduisez le terme assurance qualité pour la première fois. Croyez-moi, votre équipe est pleine de gens qui imaginent très vaguement ce que c'est. Des définitions assez générales peuvent être empruntées
à Wikipedia . Indiquer tactiquement que la présence de l'équipe AQ sur le projet ne signifie pas que toute la responsabilité de la qualité du travail leur est désormais transférée uniquement:
Les tests font partie de l'AQ. Il nous permet de déterminer le niveau de qualité des fonctionnalités que nous évaluons.
Il n'est pas de la seule responsabilité des testeurs d'effectuer l'AQ. Toute l'équipe peut et doit contribuer à assurer un haut niveau de qualité des produits et services fournis.
2. Introduction à la stratégie d'AQ
Préparez-vous à ce que plus de gens liront.
La stratégie de test est un document évolutif détaillant les processus et la façon dont nous allons assurer la qualité de notre produit à l'avenir.
Faites sonner le contenu. Il peut s'agir simplement d'une table des matières ou de phrases plus abstraites. Ici, mentionnez l'existence de l'approche de test, du processus de test, de la stratégie d'automatisation des tests et de la nécessité d'un plan de test.
C'est important. Indiquez l'intervalle de temps pour la révision de ce document. Et le projet et les processus de l'entreprise se développent, ce document ne doit pas se transformer en dinosaure. Par conséquent, prévoyez une date à laquelle votre stratégie sera révisée et modifiée. À mon avis, six mois suffisent pour revenir avec de nouvelles pensées.
3. Approche d'essai
Qu'est-ce qu'une approche de test? S'éloignant un peu du libellé officiel volumineux de cette définition, je me permets de la simplifier à la thèse selon laquelle il s'agit de «pensées de base avec lesquelles nous commençons à travailler tous les jours». Écrivez ici: quel est le moteur de votre progression?
Les classiques du genre et les approches efficaces sont «proactifs» et «axés sur le risque».
Nous adopterons une approche de test proactive et basée sur les risques.
Proactif - Cela signifie que le processus de conception de test est lancé le plus tôt possible afin de trouver et de corriger les défauts avant la création de la génération.
Basé sur le risque - Cela signifie que nous organiserons nos efforts de test de manière à réduire le niveau de risque produit lors de l'expédition du système. Selon le programme ISTQB «Les tests basés sur les risques sont l'idée que nous pouvons organiser nos efforts de tests de manière à réduire le niveau résiduel de risque produit lors de l'expédition du système. Les tests basés sur les risques utilisent le risque pour hiérarchiser et mettre l'accent sur les tests appropriés lors de l'exécution des tests, mais c'est plus que cela. Les tests basés sur les risques commencent tôt dans le projet, identifiant les risques pour la qualité du système et utilisant cette connaissance des risques pour guider la planification, la spécification, la préparation et l'exécution des tests. Les tests basés sur les risques impliquent à la fois des atténuations - des tests pour fournir des opportunités de réduire la probabilité de défauts, en particulier des défauts à fort impact - et des tests de contingence - pour identifier des solutions de contournement pour rendre les défauts qui nous dépassent moins douloureux. Les tests basés sur les risques consistent également à mesurer dans quelle mesure nous réussissons à détecter et à éliminer les défauts dans les zones critiques »
Lorsque nous parlons d'être proactif, nous devons avant tout parler de la spécification des exigences de contrôle qualité. Les gestionnaires qui compilent les spécifications des éléments du prochain cycle de développement, pour la plupart, pensent comme des utilisateurs ordinaires du système, tandis que la logique des pensées des développeurs existe dans une autre dimension. Tout d'abord, j'ai vu plus d'une fois qu'un développeur, en lisant une spécification, ne peut pas la traduire dans un langage de programmation. Par exemple, il ne peut pas faire correspondre l'utilisateur mentionné dans la spécification avec les rôles / droits d'accès existants dans le système. En conséquence, il peut choisir le rôle le plus approprié, à son avis, qui se révélera incorrect et devra retourner la fonctionnalité pour fonctionner plus tard et perdre du temps; ou posez une question au directeur, qui, peut-être, est parti en vacances et a de nouveau perdu du temps en prévision. QA Engineer est cette merveilleuse couche entre le gestionnaire axé sur l'utilisateur et le développeur soucieux de la technique, surtout si l'ingénieur QA ne néglige pas les tests en boîte blanche. C'est nous qui sommes capables de comprendre les managers et de traduire leurs réflexions auprès des développeurs. À l'heure.
Les tests basés sur les risques ont des méthodes formelles intéressantes pour évaluer les risques des projets et des produits. C’est formidable de pouvoir les mettre en pratique. Mais personnellement, je n'ai jamais assez de temps pour peindre les probabilités d'occurrence, la gravité de leurs conséquences, etc. et calculer les risques selon toutes les règles. Ici, je compte davantage sur mon instinct et mon bon sens. Lors du test ou de la couverture d'autotests avec une zone à risque (ce qui devrait être la première et principale attention) pour la plupart:
- fonctionnalité directement conçue
- zones adjacentes et en interaction
- fonctionnalité commercialement importante
- ce qui casse le plus souvent
- compatibilité descendante (si, par exemple, le format des métadonnées est modifié, les données existantes fonctionneront-elles correctement)
4. Processus de test
Dites-nous à quelle séquence méthodologique de travail vous comptez adhérer. Je n'ai rien inventé de compliqué, mais j'ai repris l'
idée de l'ISTQB et je l'ai utilisée.
Si vous passez mon chemin, familiarisez-vous avec la séquence de travail recommandée par les auteurs de l'ISTQB, sachez quelles mesures vous prendrez et comment. Nous commençons par la planification et le contrôle. Ces deux-là vivent ensemble parce que Sur la base du suivi de leurs propres activités, les plans peuvent être régulièrement redessinés. Ensuite, travaillez avec la documentation et rédigez des cas de test, mettez-les en service (en utilisant les données de test planifiées et un environnement approprié), terminez les tests et nettoyez après vous-même (supprimer les fichiers temporaires, etc.)
Nous utiliserons le processus de test décrit dans le programme ISTQB de niveau Fondation: planification et contrôle des tests, analyse et conception des tests, mise en œuvre et exécution des tests, évaluation des critères et rapports de sortie et activités de clôture des tests.
5. Responsabilités
Identifiez vos responsabilités et celles des autres dans le domaine de l'amélioration de la qualité du produit. Signalez votre mission.
Tout d'abord, insistez à nouveau sur le fait que
chaque membre de l'équipe est un testeur à part entière , chacun teste ce à quoi il se rapporte. A écrit du code - testez-le.
Deuxièmement, clarifiez et comprenez la direction de votre développement continu.
QA Engineer est le principal expert en fonctionnalité des produits : il sait comment et ce qui fonctionne, est capable d'expliquer comment et ce qui doit être testé. C'est une personne qui prédit le comportement opérationnel du client, ce qui signifie qu'il ne permettra pas que de graves problèmes se développent.
Troisièmement, indiquez
comment vous interagissez avec les gestionnaires et les développeurs . Par exemple, arrêtez-vous à l'
approche agile Three amigosCollaboration entre Business, Development et QA
a. Affaires - Quel problème essayons-nous de résoudre?
b. Développement - Comment pourrions-nous construire une solution pour résoudre ce problème?
c. Test - Qu'en est-il de ce qui pourrait arriver
6. Niveaux de test et stratégie d'automatisation de l'assurance qualité
Aujourd'hui, cette section est devenue pour moi un document autonome et distinct. Mais au niveau de l'organisation du processus naissant d'AQ dans l'équipe, indiquez quels types de tests seront effectués par qui. Ce qui sera fait manuellement, ce qui sera automatisé et selon quel principe. Qui est responsable de quels autotests.
Par exemple, sur le projet en cours, je n'écris que des tests de bout en bout, dont le bon fonctionnement est stratégiquement important d'un point de vue commercial. Dans le même temps, je regarde la demande de pull du développeur et, si nécessaire, je fais des recommandations sur la couverture des tests. Tout le reste (unité, intégration, charge, etc.) est le travail des développeurs. Sur le projet précédent, les tests de charge étaient sur moi et j'ai écrit des tests d'intégration avec les développeurs.
7. Flux de travail des fonctionnalités
Aujourd'hui, mon projet fonctionne sur Scrum en utilisant des sprints de deux semaines. Par conséquent, j'ai un document de cycle de vie écrit étape par étape pour chaque histoire.
Quelle que soit la méthodologie à laquelle le projet adhère, décrivez comment effectuer le travail quotidien étape par étape. Si ci-dessus, nous avons parlé davantage de tactiques d'action, alors il devrait y avoir des indications claires de ce qui vient en premier, puis de quoi.
Par exemple, ma version est
Le workflow ci-dessous détaille le processus que nous adopterons en interne.
1. Obtenez l'histoire avant de planifier la session
2. Créez une liste de contrôle selon les critères d'acceptation et la description
3. Notez les détails / questions peu clairs
4. Clarifier les questions sur la planification
5. Mettre à jour la liste de contrôle
6. Mettez en surbrillance toutes les dépendances et comment vous allez les surmonter
7. Lorsque l'histoire est en revue, vérifiez si les critères d'acceptation sont couverts par les autotests
8. Encouragez le développeur à couvrir tous les critères d'acceptation avec des autotests ou faites-le vous-même
9. Lorsque l'histoire est prête à être testée, effectuez un test manuel à l'aide de la liste de contrôle
10. Créez des bogues pour l'histoire s'ils existent et renvoyez l'élément au développement
11. Lorsque les bugs sont corrigés, effectuez à nouveau des tests manuels à l'aide de la liste de contrôle
12. Vérifiez si tous les autotests sont réussis
13. Créez une tâche pour implémenter des autotests d'intégration supplémentaires si nécessaire
14. Déplacer l'histoire dans l'état AQ réussi
8. Plan de test
Choisissez le type de plan de test, la plateforme sur laquelle vous le stockerez et le but de son existence. Donnez à quiconque la possibilité d'y regarder.
Sur ce projet, mon plan de test est un ensemble de listes de contrôle pour chaque histoire. Avec le niveau actuel d'automatisation, cela suffit pour l'instant.
Sur le projet précédent, le plan de test a été utilisé pour des tests manuels approfondis et comme base idéologique pour les futurs autotests.
Si vous avez beaucoup de tests manuels, écrivez des cas de test en détail, de sorte que tout nouvel ingénieur QA, arrivé au projet, puisse les effectuer indépendamment.
Comment travailler avec un document
Écrire tout ce plan et des mots efficaces est très cool. Les autorités apprécieront, je n'en doute pas. Mais il y a un point important dans l'existence de ce document. Ce sont des réponses honnêtes aux questions pour qui et pourquoi tout cela est-il écrit?
Lors de l'écriture de chaque phrase, ce serait bien de réfléchir aux questions:
"Est-ce que je veux vraiment travailler comme ça?" ,
"Vais-je vraiment donner vie à ce projet?"Si les deux réponses sont positives, imprimez en toute confiance.
Si l'une des réponses est «non», à mon avis, c'est un signe certain de ne pas suspendre des tâches inutiles.
Si l'une des réponses provient de la série "Je ne sais pas encore", laissez-la en ligne pour l'instant.
De tels moments sont restés sur la liste de ce qui sera revu en premier dans quelques mois.
Tout d'abord, j'ai écrit mon document pour moi. J'ai des moments où je prends du recul par rapport aux processus décrits et je vais même un peu à leur encontre. S'adapter à la situation afin d'utiliser efficacement les ressources ici et maintenant est normal. Mais l'écrasante majorité, avec le travail de routine habituel, mon document est mon guide. Plus d'une fois, j'étais convaincu que le plan / stratégie existant dans n'importe quel domaine se rapprochait toujours plus rapidement et avec moins de douleur des résultats souhaités que son absence totale. Je vous souhaite de construire votre travail facilement et efficacement!
Avant la publication elle-même, l'article était considérablement réduit, douloureusement gros, il me semblait pour le Sandbox. Je serai heureux de poursuivre ce sujet plus tard. Néanmoins, je suis toujours heureux de développer, s'il y a quelque chose que j'ai complètement oublié, écrivez-moi un commentaire.
Je vous remercie!