Quatre candidats à l'assurance qualité sur cinq souhaitent apprendre à utiliser des tests automatisés. Toutes les entreprises ne peuvent pas répondre aux souhaits des testeurs manuels pendant les heures de travail. Wrike a organisé 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'étudiant en assurance qualité.
J'ai appris à travailler avec Selenium et je supporte désormais de manière indépendante un certain nombre d'autotests pratiquement sans aide extérieure. Et, sur la base des résultats de notre expérience commune et de mes conclusions personnelles, j'essaierai de dériver la formule même de l'école d'automatisation la plus idéale.
L'expérience de Wrike dans l'organisation d'une école
Lorsque le besoin d'une école d'automatisation est devenu évident, son organisation a été confiée à Stas Davydov, le responsable technique de l'automatisation. Qui d'autre que lui peut expliquer pourquoi ils ont pris cette initiative, s'ils ont obtenu des résultats et s'ils regrettent le temps passé ? Donnons-lui la parole :
— En 2016, nous avons écrit un nouveau framework pour les autotests et fait en sorte qu'il devienne facile d'écrire des tests : des étapes normales sont apparues, la structure est devenue beaucoup plus compréhensible. Nous avons eu une idée : nous devons impliquer tous ceux qui souhaitent rédiger de nouveaux tests, et pour faciliter la compréhension, nous avons créé une série de conférences. Nous avons élaboré collectivement un plan de sujets, chacun des futurs conférenciers en a pris un pour lui-même et a préparé un rapport sur celui-ci.
— Quelles difficultés les étudiants ont-ils rencontrés ?
— Principalement, bien sûr, l'architecture. De nombreuses questions ont été posées sur la structure de nos tests. Dans les retours, beaucoup de choses ont été écrites sur ce sujet et nous avons dû organiser des conférences supplémentaires pour l'expliquer plus en détail.
— L'école a-t-elle payé ?
- Oui définitivement. Grâce à elle, de nombreuses personnes ont participé à la rédaction des tests et, en moyenne, à l'hôpital, tout le monde a commencé à mieux comprendre ce que sont les autotests, comment ils sont rédigés et comment ils sont lancés. La charge des ingénieurs automation a également diminué : nous recevons désormais beaucoup moins de demandes d'aide pour l'analyse des tests, puisque les testeurs et les développeurs ont commencé à y faire face eux-mêmes dans presque toutes les situations. Eh bien, il y a plusieurs avantages internes pour le département : nous avons acquis de l'expérience dans les présentations et les conférences, grâce auxquelles certains ingénieurs en automatisation ont déjà réussi à faire des présentations lors de conférences, et avons également reçu un ensemble puissant de vidéos et de présentations pour l'intégration des nouveaux arrivants.
En mon nom personnel, j'ajouterai que la communication entre nos départements a été simplifiée à un niveau carrément ridiculement facile. Par exemple, je n’ai désormais pratiquement plus besoin de réfléchir aux cas et à quel niveau d’atomicité automatiser. En conséquence, toutes les parties intéressées s’occupent pleinement de la couverture des tests, qui ne cesse de croître. Personne n’exige l’impossible des autres.
De manière générale, l’impact sur le travail des équipes est définitivement positif. Peut-être que les collègues qui lisent cet article envisagent également de faire quelque chose de similaire ? Alors le conseil sera simple : ça vaut le coup si les tests automatisés sont une priorité pour vous. Nous aborderons ensuite une question plus complexe : comment organiser tout cela le plus correctement possible, afin que les coûts de toutes les parties soient minimes et le rendement 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 en tant qu'étudiant récent me comparant moi-même dans l'ignorance et moi-même maintenant que j'ai formulé les étapes suivantes pour créer, à mon avis, la manière idéale d'apprendre aux testeurs à comprendre les tests automatisés.
Étape 0. Créer un dictionnaire
Bien entendu, cette étape n’est pas seulement nécessaire pour l’assurance qualité. Cependant, je tiens à le rendre explicite : la base de code d'automatisation doit être conservée sous une forme lisible. Langages de programmation - pas des moindres les langues, et à partir de là, vous pouvez commencer votre plongée.
Voici une capture d'écran d'une vue des tâches avec les noms des éléments. Imaginons que vous testiez TaskView comme une boîte noire et que vous n'ayez jamais vu Selenium de votre vie. Que fait ce code?
(Spoiler - la tâche est supprimée via rest au nom de l'administrateur, puis nous voyons qu'il y a une trace de cela dans le flux.)
Cette étape à elle seule rapproche les langages QAA et QA. Il est plus facile pour les équipes d'automatisation d'expliquer les résultats d'une exécution ; les testeurs manuels doivent consacrer moins d'efforts à la création de cas : ils peuvent être rendus moins détaillés. Pourtant, tout le monde se comprend. Nous avons reçu les gains avant même le début de la formation proprement dite.
Étape 1. Répétez les phrases
Poursuivons le parallèle avec le langage. Lorsque nous apprenons à parler étant enfants, nous ne partons pas de l’étymologie et de la sémantique. On répète « maman », « acheter un jouet », mais on ne rentre pas tout de suite dans les racines proto-indo-européennes de ces mots. C'est donc ici : rien ne sert de plonger dans les profondeurs techniques des autotests sans essayer d'écrire quelque chose qui fonctionne.
Cela semble un peu contre-intuitif, mais cela fonctionne.
Dans la première leçon, il convient de donner les bases sur la façon d'écrire directement des autotests. Nous aidons à configurer l'environnement de développement (dans mon cas, Intellij IDEA), expliquons les règles de langage minimales nécessaires pour écrire une autre méthode dans une classe existante en utilisant les étapes existantes. Nous écrivons avec eux un ou deux tests et leur donnons des devoirs, que je formaterais ainsi : une branche part du maître, mais plusieurs tests en ont été supprimés. Seules subsistent leurs descriptions. Nous demandons aux testeurs de restaurer ces tests (pas via show diff, bien sûr).
Ainsi, celui qui a écouté et tout fait pourra :
- apprendre à travailler avec l'interface de l'environnement de développement : création de branches, de raccourcis clavier, de commits et de push ;
- maîtriser les bases de la structure du langage et des classes : où insérer les injections et où importer, pourquoi les annotations sont nécessaires et quels types de symboles s'y trouvent, en plus des étapes ;
- comprendre la différence entre agir, attendre et vérifier, où utiliser quoi ;
- remarquez 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 une vue des tâches, de sélectionner l'entrée, de saisir du texte et de cliquer sur le bouton Envoyer ;
- formuler des questions auxquelles on répondra à l’étape suivante.
Le dernier point est très important. Ces réponses peuvent facilement être données à l'avance, mais c'est un principe pédagogique important que les réponses sans questions formulées ne sont pas mémorisées et ne sont pas utilisées lorsqu'elles sont finalement nécessaires.
L'idéal serait qu'à ce moment-là, un ingénieur en automatisation de l'équipe QA lui confie la tâche d'écrire quelques tests en combat et lui permette de se sous-engager dans sa branche.
Ce qu'il ne faut 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 sera nécessaire que lorsque vous travaillerez de manière indépendante avec des branches. On ne s’en souviendra pas, il faudra l’expliquer deux ou trois fois, mais nous apprécions le temps des ingénieurs automation, n’est-ce pas ? Exemples : résoudre des conflits, ajouter des fichiers à git, créer des classes à partir de zéro, travailler avec des dépendances ;
- tout ce qui concerne XPath. Sérieusement. Il faut en parler séparément, une fois et de manière très concentrée.
Étape 2. Examiner de plus près la grammaire
Rappelons-nous la capture d'écran de la vue des tâches de l'étape 0. Nous avons une étape appelée checkCommentWithTextExists. Notre testeur comprend déjà ce que fait cette étape et nous pouvons regarder à l’intérieur de l’étape et la décomposer un peu.
Et à l'intérieur nous avons ce qui suit :
onCommentBlock(userName).comment(expectedText).should(displayed());Où se trouve onCommentBlock
onCommonStreamPanel().commentBlock(userName);Nous apprenons maintenant à dire non pas « acheter un jouet », mais « acheter un jouet dans le magasin Detsky Mir, situé dans l'armoire bleue de la troisième étagère en partant du haut ». Il est nécessaire d'expliquer que nous pointons vers un élément de manière séquentielle, à partir d'éléments plus grands (flux -> bloc avec les commentaires d'une certaine personne -> la partie de ce bloc où se trouve le texte spécifié).
Non, ce n'est toujours pas le moment de parler de XPath. Mentionnez simplement brièvement que toutes ces instructions sont décrites par eux et que l'héritage passe par eux. Mais il faut parler de tous ces matchers et waiters, ils sont spécifiquement liés à cette étape et sont nécessaires pour comprendre ce qui se passe. Mais ne surchargez pas : votre élève pourra étudier seul des assertions plus complexes plus tard. Très probablement, devrait, waitUntil, display();, exist();, not(); devrait suffire.
Le devoir est évident : une branche dans laquelle le contenu de plusieurs étapes nécessaires à un certain nombre de tests a été supprimé. Laissez les testeurs les restaurer et rendez le run à nouveau vert.
De plus, si l'équipe de test a non seulement de nouvelles fonctionnalités dans son travail, mais également des corrections de bugs, vous pouvez lui demander d'écrire immédiatement des tests pour ces bugs et de les publier. Très probablement, tous les éléments ont déjà été décrits ; seules quelques étapes peuvent manquer. Ce sera l’entraînement parfait.
Étape 3. Immersion totale
Le plus complet possible pour un testeur qui va continuer à exercer ses fonctions directes. Enfin, nous devons parler de XPath.
Tout d'abord, précisons 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 n’importe quel XPath existant et montrons comment l’onglet Éléments contient un et un seul élément. Ensuite, nous parlerons de la structure : quand vous devez utiliser WebElement et quand vous devez créer un fichier séparé pour un nouvel élément. Cela vous permettra de mieux comprendre l’héritage.
Il doit être explicitement indiqué qu'un seul élément est la vue des tâches entière, qu'il contient un élément enfant - le flux entier, qui contient un élément enfant - un commentaire séparé, etc. Les éléments enfants se trouvent à l'intérieur des éléments parents à la fois sur la page et dans la structure du framework d'autotest.
À ce stade, le public devrait avoir bien compris comment ils sont hérités et ce qui peut être saisi après le point sur onCommentBlock. À ce stade, nous expliquons tous les opérateurs : /, //, ., [] et ainsi de suite. Nous ajoutons des connaissances sur l'utilisation dans la charge @class et d'autres choses nécessaires.
Les étudiants doivent comprendre comment traduire XPath de cette façon. Consolider - c'est vrai, des devoirs. Nous supprimons les descriptions des éléments, les laissons restaurer le travail des tests.
Pourquoi ce chemin particulier ?
Nous ne devons pas surcharger une personne de connaissances complexes, mais nous devons tout expliquer en même temps, et c'est un dilemme difficile. Ce chemin nous permettra d'abord de faire en sorte que les auditeurs posent des questions et ne comprennent pas quelque chose et d'y répondre dès l'instant suivant. Si nous parlons de l'ensemble de l'architecture, au moment où le sujet des étapes ou de XPath sera analysé, les parties les plus importantes seront déjà oubliées en raison de leur incompréhensibilité.
Cependant, certains d’entre vous pourront probablement partager leur expérience sur la façon dont le processus peut être encore plus optimisé. Je serai heureux de lire des suggestions similaires dans les commentaires !
Source: habr.com