Quatre demandeurs d'emploi sur cinq veulent apprendre à travailler avec les autotests. Toutes les entreprises ne peuvent pas satisfaire ces désirs de testeurs manuels pendant les heures de travail. Wrike a dirigé une école d'automatisation pour les employés et a réalisé ce désir pour beaucoup. J'ai participé à cette école précisément en tant qu'élève-AQ.
J'ai appris à travailler avec Selenium et maintenant je supporte indépendamment un certain nombre d'autotests sans presque aucune aide extérieure. Et, sur la base des résultats de notre expérience commune et de mes conclusions personnelles, je vais essayer de dériver la formule même de l'école d'automatisation la plus idéale possible.
Expérience de l'organisation de l'école Wrike
Lorsque le besoin d'une école d'automatisation est devenu clair, son organisation est tombée sur Stas Davydov, responsable technique de l'automatisation. Qui d'autre que lui peut expliquer pourquoi ils ont proposé cette initiative, ont-ils obtenu des résultats et ne regrettent-ils pas le temps passé? Nous lui donnons la parole:
- En 2016, nous avons écrit un nouveau cadre pour les autotests et fait en sorte que les tests deviennent faciles à écrire: des étapes normales sont apparues, la structure est devenue beaucoup plus compréhensible. Nous avions une idée: nous devions attirer tous ceux qui voulaient passer de nouveaux tests, mais pour faciliter la compréhension, nous avons créé une série de conférences. Nous avons collectivement élaboré un plan pour chacun des futurs conférenciers qui en a pris un et préparé un rapport à ce sujet.
- Quelles ont été les difficultés des étudiants?- Fondamentalement, bien sûr, l'architecture. Il y avait beaucoup de questions sur la structure de nos tests. Dans les commentaires, nous avons beaucoup écrit sur ce sujet et nous avons dû mener des conférences supplémentaires pour expliquer plus en détail.
- L'école a-t-elle porté ses fruits?- Oui, certainement. Grâce à elle, beaucoup de gens ont participé à la rédaction des tests et, en moyenne dans un hôpital, tout le monde a commencé à mieux comprendre ce que sont les autotests, comment ils sont écrits et comment ils fonctionnent. De plus, la charge sur l'automatisation a diminué: nous recevons maintenant plusieurs fois moins de demandes d'aide pour l'analyse des tests, car les testeurs et les développeurs ont commencé à y faire face eux-mêmes dans presque toutes les situations. Eh bien, il y a des avantages internes pour le département: ils ont acquis de l'expérience dans les présentations et les conférences, grâce auxquelles certains automatistes ont déjà réussi à faire des présentations lors de conférences, et ont également reçu un ensemble puissant de vidéos et de présentations pour intégrer les nouveaux arrivants.
Pour ma part, j'ajouterai que la communication entre nos services a été simplifiée à un niveau ridiculement facile. Par exemple, maintenant je n'ai pratiquement plus besoin de penser à quels cas et à quel niveau d'atomicité donner pour l'automatisation. Par conséquent, le soin apporté à la couverture des tests, qui ne cesse de croître, provient pleinement de toutes les parties intéressées. Personne ne demande l'impossible aux autres.
En général, l'impact sur le travail d'équipe est particulièrement positif. Peut-être que les collègues qui lisent cet article envisagent également de tenir quelque chose comme ça? Le conseil sera alors simple: cela vaut la peine si les autotests sont votre priorité. Ensuite, nous parlerons d'une question plus complexe: comment organiser le tout aussi correctement que possible afin que les coûts de toutes les parties soient minimes et que l'échappement soit maximum.
Conseils d'organisation
L'école était utile, mais, comme Stas l'a admis, il y avait quelques difficultés, à cause desquelles il était nécessaire d'organiser des cours supplémentaires. Et c'est juste en tant qu'étudiant récent qui a étudié la comparaison de lui-même dans l'ignorance et lui-même maintenant, j'ai formulé les étapes suivantes pour créer la manière idéale, à mon avis, d'enseigner aux testeurs comment gérer les autotests.
Étape 0. Créez un dictionnaire
Bien sûr, cette étape est nécessaire non seulement pour l'AQ. Néanmoins, je tiens à le dire explicitement: la base de code d'automatisation doit être stockée sous une forme lisible. Les langages de programmation sont, notamment, des
langages , et à partir de là, vous pouvez commencer la plongée.
Voici une capture d'écran de taskview avec les noms des éléments. Imaginez que vous effectuez une tâche comme une boîte noire et que vous n'avez jamais vu de sélénium de votre vie. Que fait ce code?
(Spoiler - pendant le repos, la tâche est supprimée au nom de l'administrateur, puis nous constatons qu'il existe un enregistrement à ce sujet dans le flux.)
Cette étape à elle seule vous permet de rapprocher les langues QAA et QA. Il est plus facile pour l'automatisation d'expliquer le résultat d'une exécution; les testeurs manuels doivent dépenser moins pour la compilation des cas: ils peuvent être rendus moins détaillés. Pourtant, ils se comprennent. Nous avons obtenu une victoire avant même le début de l'entraînement.
Étape 1. Répétez les phrases
Nous continuons le parallèle avec la langue. Quand on apprend à parler dans l'enfance, on ne sort pas de l'étymologie et de la sémantique. Nous répétons "mère", "achète un jouet", mais nous n'allons pas immédiatement dans les racines pré-indo-européennes de ces mots. Alors ici: cela n'a aucun sens de plonger dans les profondeurs des caractéristiques techniques des autotests, sans essayer d'écrire quelque chose qui fonctionne.
Cela semble quelque peu contre-intuitif, mais cela fonctionne.
Dans la première leçon, il vaut la peine de donner une base sur la façon d'écrire directement les autotests. Nous aidons à configurer l'environnement de développement (dans mon cas, Intellij IDEA), expliquons les règles de langage minimales qui sont nécessaires pour écrire une autre méthode dans une classe existante en utilisant les étapes disponibles. Nous écrivons un ou deux tests avec eux et donnons des devoirs, que je concevrais comme suit: une branche attribuée par le maître, mais plusieurs tests y ont été supprimés. Seules leurs descriptions sont restées. Nous demandons aux testeurs de restaurer ces tests (pas via show diff, bien sûr).
En conséquence, ceux qui ont écouté et ont tout fait pourront:
- apprendre à travailler avec l'interface de l'environnement de développement: création de branches, raccourcis clavier, commits et push;
- apprendre les bases de la structure du langage et des classes: où insérer des injections, et où importer, pourquoi les annotations sont nécessaires et ce qu'il y a généralement pour les symboles, à l'exception des étapes;
- comprendre la différence entre l'action, l'attente et la vérification, où utiliser quoi;
- notez la différence entre les autotests et les vérifications manuelles: dans les autotests, vous pouvez extraire l'un ou l'autre gestionnaire au lieu d'effectuer des actions via l'interface. Par exemple, envoyez un commentaire directement au backend au lieu d'ouvrir la vue des tâches, de mettre en surbrillance l'entrée, de taper et d'appuyer sur le bouton Envoyer;
- formuler les questions auxquelles il sera répondu à l'étape suivante.
Le dernier point est très important. Ces réponses peuvent facilement être données à l'avance, mais il s'agit d'un principe pédagogique important: les réponses sans questions formulées ne sont pas mémorisées et ne s'appliquent pas lorsque, finalement, elles sont requises.
Il serait idéal que, à ce moment-là, l'automate de l'équipe QA lui accroche une tâche en écrivant quelques tests dans une bataille et lui permette de s'engager dans son fil.
Ce que vous ne devez pas donner:
- une connaissance plus approfondie des fonctionnalités de l'environnement de développement et du langage de programmation lui-même, qui ne seront nécessaires que lorsque vous travaillez de manière indépendante avec des succursales. Je ne me souviens pas, je vais devoir l'expliquer deux ou trois fois, et nous apprécions le temps de l'automatisation, non? Exemples: résolution de conflits, ajout de fichiers à git, création de classes à partir de zéro, utilisation des dépendances;
- tout ce qui concerne xpath. Sérieusement. Vous devez parler de lui séparément, une fois et de manière très concentrée.
Étape 2. Nous regardons la grammaire
Rappelons la capture d'écran avec taskview de l'étape numéro 0. Nous avons une étape appelée checkCommentWithTextExists. Notre testeur comprend déjà ce que fait cette étape et vous pouvez regarder à l'intérieur de l'étape et la décomposer un peu.
Et à l'intérieur, nous avons les éléments suivants:
onCommentBlock(userName).comment(expectedText).should(displayed());
Où onCommentBlock est
onCommonStreamPanel().commentBlock(userName);
Maintenant, nous apprenons à ne pas dire «acheter un jouet», mais «acheter un jouet au magasin Detsky Mir, debout dans une armoire bleue sur la troisième étagère d'en haut». Il est nécessaire d'expliquer que nous pointons l'élément de manière séquentielle à partir d'éléments plus grands (flux -> bloc avec commentaires d'une certaine personne -> la partie de ce bloc où se trouve le texte donné).
Non, pas encore le temps de parler de xpath. Juste pour mentionner brièvement que toutes ces instructions sont décrites par eux et que l'héritage les traverse. Mais vous devez parler de tous ces testeurs et veyters, ils se rapportent à cette étape et sont nécessaires pour comprendre ce qui se passe. Mais ne surchargez pas: votre élève pourra étudier lui-même plus tard des exercices plus complexes. Très probablement, devrait, attendre jusqu'à ce que, affiché ();, existe ();, pas ();.
Le devoir est évident: une branche dans laquelle le contenu de plusieurs étapes est supprimé, ce qui est nécessaire pour un certain nombre de tests. Laissez les testeurs les restaurer et faites en sorte que la piste redevienne verte.
De plus, si l'équipe du testeur a non seulement de nouvelles fonctionnalités, mais aussi des corrections de bogues, vous pouvez lui demander d'écrire des tests pour ces bogues immédiatement et de les abandonner. Très probablement, tous les éléments ont déjà été décrits, seules quelques ou trois étapes peuvent être manquées. Ce sera l'entraînement parfait.
Étape 3. Immersion complète
Aussi complet que possible pour un testeur qui va continuer à assumer ses responsabilités directes. Enfin, vous devez parler de xpath.
Tout d'abord, nous indiquons clairement que tous ces onCommentBlock et commentaires sont décrits par eux.
Total:
"//div[contains(@class, 'stream-panel')]//a[contains(@class,'author') and text()='{{ userName }}']//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}')]"
L'ordre de l'histoire est très important. Tout d'abord, nous prenons tout xpath existant et montrons comment dans l'onglet éléments il y a un et un seul élément. Ensuite, nous parlons de la structure: quand vous devez utiliser WebElement, et quand vous devez créer un fichier séparé pour un nouvel élément. Cela aidera à mieux comprendre l'héritage.
Il est nécessaire de dire explicitement qu'un seul élément est entièrement une tâche, il contient un élément enfant - le flux entier qui contient l'élément enfant - un commentaire séparé, etc. Éléments enfants - à l'intérieur du parent à la fois sur la page et dans la structure du cadre d'autotest.
À ce stade, le public doit déjà avoir une solide compréhension de la façon dont ils sont hérités et de ce qui peut être entré après le point sur onCommentBlock. À ce stade, nous expliquons tous les opérateurs: /, //,., [] Et ainsi de suite. Dans la charge, nous prouvons les connaissances sur l'utilisation de
@class et d'autres choses nécessaires.
Les étudiants doivent comprendre comment traduire xpath de cette manière. Pour réparer - à droite, les devoirs. Nous supprimons les descriptions des éléments, laissons-les restaurer le travail des tests.
Pourquoi exactement de cette façon?
Nous ne devons pas surcharger une personne avec des connaissances compliquées, mais nous devons tout expliquer en même temps, et c'est un dilemme difficile. De cette façon, nous pourrons d'abord amener les auditeurs à poser des questions, à ne pas comprendre quelque chose et à y répondre dès l'instant suivant. Si nous parlons de l'architecture entière, alors au moment où le sujet des étapes ou xpath est analysé, les parties les plus importantes de celui-ci seront déjà oubliées en raison de leur incompréhensibilité.
Néanmoins, l'un d'entre vous pourra probablement partager son expérience sur la façon d'optimiser encore plus le processus. Je suis heureux de lire ces suggestions dans les commentaires!