Get best of the week

Les autotests pensent-ils aux bugs électriques

Récemment, l'automatisation des tests a été qualifiée de «solution miracle» à tous les problèmes du projet. De nombreuses personnes démarrent l'automatisation de manière très spontanée et légère, sans calculer tous les avantages et inconvénients, avantages et inconvénients, maintenance et retour sur investissement. 

En général, l'automatisation des tests est un outil très coûteux et spécifique. Il faut donc l'aborder avec le bon niveau de maturité du code et du projet lui-même. Sinon, vous pouvez dépenser des millions d'heures et d'argent, et l'effet est microscopique ou pas du tout.

Dans cet article, j'ai essayé:

  • pour éclairer les «plaies des enfants» de la gestion des tests, en cherchant à automatiser tout ce qui n'est pas épinglé,
  • Expliquer comment l'automatisation des tests peut bénéficier au budget du projet sans une analyse détaillée de sa portée et une préparation appropriée,
  • compiler une feuille de route pour préparer l'automatisation du projet.

La source 

La tendance est que maintenant l'automatisation teste les trous dans tous les projets, clouant des clous avec un microscope. Il arrive au point qu'il devient difficile pour un testeur sans compétences en automatisation de trouver un emploi, car dans la plupart des postes vacants, les compétences en analyse de test et en conception de test font défaut, mais une expérience dans l'automatisation de quelque chose est requise.

J'aimerais croire qu'avec le temps, nous aurons tous un désir obsessionnel d'automatiser tout d'un coup, mais pour l'instant une liste de contrôle nous aiderait beaucoup à déterminer si des tests automatiques dans le projet sont nécessaires et si le projet est prêt pour eux. 

En fait, avec ces réflexions, je suis allé faire une présentation sur "Strike-2019", puis j'ai écrit ce post en fonction de cela.

Nous parlerons de grands autotests sérieux de bout en bout qui automatisent la régression en termes d'interface utilisateur et de services Web. Et aussi ce qui leur est lié. Nous n'aborderons pas le sujet des tests unitaires que les développeurs écrivent ou devraient écrire. Il s'agit d'une couche distincte d'auto-test, et de nombreux articles ont déjà été écrits à ce sujet:

 
Je ne nommerai pas le projet, je dirai seulement qu'il s'agit d'un système d'information conçu pour plusieurs dizaines de millions d'utilisateurs. Il est intégré à plusieurs portails d'État, ainsi qu'à des dizaines, voire des centaines, de portails régionaux et commerciaux. D'où les exigences accrues de fiabilité, de tolérance aux pannes et de sécurité. Eh bien, en général, pour que tout "tourne et ne tombe pas". 

Notre credo sur tous les projets de test LANIT est l'amélioration continue. En général, tout ce qui nous permet de tester plus rapidement, mieux, plus haut, plus fort, fait gagner du temps et des efforts aux testeurs et, par conséquent, au budget. Nous avons mis en œuvre sur ce projet, probablement toutes les meilleures pratiques qui nous ont permis de respecter les délais et les tâches. En conséquence, parmi les gros jetons non réalisés, seule l'automatisation de la régression est restée. Ce sujet lui-même pendant un certain temps était dans l'air, et pendant longtemps nous l'avons refusé, reposant sur tous nos membres, car le profit n'était pas très clair. Mais à la fin, ils ont décidé d'automatiser. Et puis il y a eu un saut prolongé dans l'eau froide.
 

Une petite digression. Méthodes d'automatisation


Il existe deux façons principales d'automatiser les tests d'interface utilisateur. 

La source

Automatisation par des testeurs manuels


Vous n'avez pas besoin d'aller loin pour des exemples - tout est sur Habré. Je ne nommerai pas l'entreprise. Ceux qui étaient intéressés par le sujet ont probablement vu ces webinaires d'une heure et demie, à quel point ils sont cool, comment ils sont cool, comment toute l'équipe de testeurs portables a appris Java d'eux, est allé automatiser, tout est couvert, tout est génial, tout fonctionne, un avenir radieux est déjà arrivé. Il existe une telle approche. 

Approche de conception


Et il y a une deuxième approche: une équipe d'autotesteurs est recrutée - avec de l'expérience, des connaissances et des compétences en POO, et l'automatisation est effectuée directement par les forces de cette équipe, et une équipe de testeurs manuels agit en tant que clients et experts. Oui, ils peuvent intégrer l'équipe d'automatisation après la formation, la sélection, mais ils ne combinent jamais deux rôles en même temps.

Ci-dessous, j'ai décrit les caractéristiques de ces approches, mais je ne les marque pas spécifiquement comme des «avantages» ou des «inconvénients» - chacun déterminera le signe pour lui-même.

Caractéristiques de l'automatisation "à part entière"


Source

1) Lorsque nous automatisons avec l'aide de testeurs manuels, nous obtenons un effet rapide "regardez, ce test a pris un jour avant, maintenant je peux le remplacer par un robot, cela prend 2 jours, mais je ne participe pas ici". Naturellement, cela améliore les qualifications et élargit les horizons des spécialistes: ils commencent à comprendre le code. Mais il n'y a pas de résultat clair et tangible pour l'entreprise. Combien d'heures ont été consacrées au développement et combien pourraient être dépensées si une personne expérimentée faisait cela? Combien d'heures sont sauvées? À quelle fréquence le test sera-t-il lancé? Où? Qui accompagner? Combien ça coûte? Ce n'est pas très bon pour moi, car, malheureusement, je n'ai pas encore vu de clients prêts à payer sans fin - pour le processus. Par conséquent, un résultat clair et tangible est toujours important pour moi.

2) Pas de délais. D’une part, c’est bien: personne n’encourage l’équipe, «automatisons rapidement tout, apprenons vite», la tension n’augmente pas chez une personne. Il continue de tester avec ses mains et plonge calmement dans l'automatisation. En revanche, il n'y a pas de délais, on ne peut pas se renseigner sur les résultats, et on ne comprend pas quand il sera prêt.

3) Il n'y a pas de support de code et de continuité. D'une part, différentes approches, les enquêtes donnent lieu à de meilleures méthodes d'écriture, parfois, en réécrivant à partir de zéro, vous pouvez accélérer plusieurs fois l'autotest. Mais c'est mégatrack. De plus, qui accompagnera tout cela si les spécialistes quittent le projet, et cela se produit s'ils partent pour un autre domaine d'activité ou une autre équipe? Pas très clair non plus.

Caractéristiques de l'approche projet


Source

1) Dans ce cas, nous parlons déjà du projet. Et le projet c'est quoi? Ce sont des ressources, du temps, de l'argent. En conséquence, le budget est calculé ici, en tenant compte de toutes les nuances présentes dans ce projet. Tous les risques sont calculés, tous les travaux supplémentaires sont calculés. Et ce n'est qu'après approbation du budget que la décision est prise de lancer.

2) Sur cette base, la phase de préparation ne sera probablement pas rapide, car le calcul du budget pour quelque chose devrait être construit.

3) Naturellement, des exigences accrues sont imposées aux spécialistes qui participeront au projet. 

4) Ici, j'écrirai également des solutions d'infrastructure complexes, mais plus à ce sujet plus tard. 

5) Modernisation des processus de test et de publication existants. Parce que les autotests sont un nouvel élément de l'équipe. S'il n'a pas été fourni précédemment, respectivement, vous devez l'intégrer dans le processus. Les auto-testeurs ne doivent pas être suspendus à droite, à gauche, du projet.

6) L'approche projet donne régularité, cohérence, même si, d'autre part, sa mise en œuvre peut être plus lente que la mise en œuvre de la première approche.

7) Eh bien, les rapports. Beaucoup de rapports. Parce que pour tout budget on vous demandera. En conséquence, vous devez comprendre comment fonctionnent les autotests (mauvais, bon), quelles tendances, quelles tendances, ce qui doit être augmenté, ce qui doit être amélioré. Ceci est contrôlé par les rapports.

Un long chemin vers un avenir meilleur


Avertissement: nous avons été si intelligents tout de suite (en fait pas).

Source

Voici une classification des problèmes que nous avons rencontrés. J'analyserai chacun individuellement. Je vais le faire exprès, afin que vous preniez en compte ce "rake". Parce que ces problèmes, qui ne sont pas résolus au début du projet, affecteront directement, au moins, sa durée, au maximum - ils augmenteront son budget ou pourront même clôturer le projet.

La source

  • Différentes équipes - différentes approches.
  • Faible immersion de l'automatisation dans le fonctionnel.
  • Structure non optimale des cas de test.
  • Documentation du cadre.
  • Des problèmes de communication.
  • Achat de licences en temps opportun.

Différentes approches de l'automatisation


La source 

Torture nombre de fois


La première tentative que nous avons eue était selon le premier modèle (voir méthode numéro 1). Un petit groupe d'initiative (mais fier) ​​de testeurs a décidé d'essayer l'automatisation. Dans l'ensemble, nous voulions voir ce qui en ressortait. Maintenant, bien sûr, nous ne le ferions pas, mais alors il n'y avait aucune expérience, et nous avons décidé de l'essayer. 

Source

Nous avions un chef d'équipe avec une expérience en automatisation, 3 brûlant avec le désir d'automatiser le testeur et beaucoup de désir de maîtriser ce chemin. Certes, Timlid était un nouveau venu et ne pouvait pas consacrer beaucoup de temps au projet, mais l'effet positif de son travail était que nous avons écrit notre propre cadre. Nous avons regardé les cadres qui étaient là, ils étaient chers et cool ou gratuits, et l'instruction "attachée au dossier à goûter après assemblage" leur était attachée. En général, pour un certain nombre de raisons, nous n'avons pas pu les utiliser. En conséquence, nous avons décidé d'écrire notre propre cadre. Le choix lui-même et le processus d'écriture sont un sujet pour un article séparé, ou même pas un.

Pour ne pas dire que cette tentative a été un échec, elle a tout simplement survécu et a pris fin. Lorsque nous avons réalisé que nous avions besoin d'un budget, nous avions besoin de forces supplémentaires, nous avions besoin de compétences, nous avions besoin d'une autre organisation d'équipe. Nous avons automatisé une centaine de cas, vu que cela fonctionnait et arrondi.

Tentative numéro deux


Source 

Rien n'attire comme un sandwich mordu.

Après un certain temps, nous sommes revenus sur le sujet de l'automatisation.

Mais, se souvenant de la première expérience, nous sommes passés à la méthode n ° 2. Ici, nous avions déjà une équipe plutôt «compétente», automatisant plus d'un projet. Mais ici, nous sommes confrontés à une autre catastrophe. Cette équipe a suivi l'exemple de l'équipe de test de l'interface utilisateur. Comment est-ce arrivé?

"Nous voulons automatiser cela!"
- Peut-être que nous y penserons.
- Non, nous ne voulons rien penser, nous voulons ces autotests.

Avec des efforts titanesques, ils l'ont automatisé, et cela a même fonctionné. Mais au fil du temps, la stabilité des lancements a commencé à décliner, et lorsque nous avons réuni notre propre équipe d'ingénieurs en automatisation et commencé à leur confier le projet, il s'est avéré que la moitié des tests ont été effectués sur des béquilles, la moitié a vérifié ce que la machine avait l'intention et non ce que le testeur manuel voulait. 

Et tout cela parce que les autotests fonctionnaient sur du code brut, qui était soumis à des corrections quotidiennes. Ceux. l'ensemble initial de cas n'était pas correct. Nous avons dû nous plonger dans les sujets que nous souhaitons automatiser, du point de vue de son automatisation (ci-après beurre). Il est très important d'aborder les cas que nous donnons pour l'automatisation, et à un moment donné en éliminer certains, en séparer certains, etc. Mais nous ne l'avons pas fait. 

Quel est le résultat. Nous avons automatisé une autre pièce, environ 300 cas, après quoi le projet s'est terminé, car il n'y avait aucune stabilité des lancements et aucune compréhension de la façon d'accompagner cela non plus. Et nous avons compris comment ne pas le faire ... pour la deuxième fois.

Tentative numéro trois


Source 

Pour la troisième tentative, nous nous sommes approchés, comme une biche timide, d'un abreuvoir. 

Autour vu des risques (et des pannes de termes). Ils ont abordé d'une manière critique, tout d'abord, les cas de test et leurs auteurs - testeurs d'interface utilisateur - en tant que clients de processus. Nous avons trouvé la même équipe critique d'ingénieurs en automatisation et commencé un projet qui était déjà parfaitement calculé (comme nous le pensions), complètement prêt (ha ha).

Le râteau était déjà couché et nous attendait.

Faible immersion de l'automatisation dans le fonctionnel


Source 

À la première étape (ci-après dénommée la troisième tentative), alors que les communications étaient encore mal établies, les auto-testeurs travaillaient derrière un certain écran: ils recevaient des tâches, ils automatisaient quelque chose là-bas. Nous avons effectué des autotests. Nous avons vu des statistiques que tout va mal avec nous. Creuser les journaux d'autotest. Et là, par exemple, une chute sur une faute d'orthographe dans le nom du fichier en cours de téléchargement. Il est clair que le testeur, qui a testé cette fonctionnalité avec ses mains, commencera un mineur et sautera pour vérifier plus loin. L'autotest tombe et fait tomber toute la chaîne, qui est basé sur sa base. 

Et quand nous avons commencé à plonger les auto-testeurs dans le fonctionnel, pour expliquer ce que nous vérifions exactement dans les cas, ils ont alors commencé à comprendre les erreurs de ces "enfants", comment les éviter, comment les contourner. Oui, il y a des fautes de frappe, il y a des incohérences, mais l'autotest ne tombe pas, il les enregistre simplement.

Structure de scénario de test non optimale


Source 

C'est probablement notre plus gros mal de tête. Elle a donné le plus de problèmes, le plus de temps, le plus d'heures et d'argent que nous avons perdus. En conséquence, nous allons maintenant résoudre un tel problème tout d'abord, si nous automatisons autre chose.

Notre projet est assez vaste, plusieurs dizaines de systèmes d'information y tournent, ils sont unis par des groupes de travail. Et il semble que les normes d'écriture des cas soient les mêmes pour tout le monde, mais dans un groupe, cette pièce est appelée «fonction», dans un autre, elle est appelée «autorité», et l'autotesteur lit à la fois «fonction» et «autorité», et tombe dans une stupeur. C'est juste un exemple. En fait, il y avait des centaines de telles situations. J'ai dû standardiser tout ça, me coiffer.

Qu'avez-vous rencontré d'autre que de telles ambiguïtés? Nous n'avons pas trouvé de cas de test atomique. Ce sont des cas de test qui, à certaines étapes, peuvent être exécutés de manière variable. Par exemple, dans la condition, il est dit "vous pouvez effectuer l'étape 2 sous une telle autorité et sous une telle autorité", et à l'étape 3, par exemple, selon l'autorité utilisée, "appuyez sur le bouton" A "ou sur le bouton" C ". Du point de vue d'un testeur manuel, tout va bien. Le testeur comprend comment le passer, l'autotesteur ne comprend pas comment le passer. Dans une mauvaise version, il choisira lui-même le chemin, dans un bon, il viendra avec des éclaircissements. Nous avons passé pas mal de temps à convertir des cas de test non atomiques.   

Documentation du framework


Source

Vous devez toujours penser à ceux qui viennent après vous. Comment ils vont analyser votre code, analyser, etc. C'est bien s'il y a des ingénieurs, des programmeurs compétents. Mauvais s'ils ne le sont pas. Ensuite, vous pouvez également faire face au fait que vous devez démonter l'héritage des "victoires" passées, documenter à nouveau, attirer des personnes supplémentaires, passer du temps supplémentaire.

Des problèmes de communication


Source  

1. Absence de réglementation sur l'interaction.

Une équipe d'automatisation est venue, elle ne sait pas comment communiquer avec l'équipe de tests fonctionnels manuels, et personne, en fait, ne sait de quel genre de personnes il s'agit. Oui, il y a des prospects qui communiquent entre eux, et tous les autres ne sont que des voisins du projet. 

2. La présence de règlements pour l'interaction

Ensuite, les règlements ont été rédigés, mais les gars ont travaillé pendant un certain temps sans l'autre, et lorsque les règlements ont été rédigés, ils ont pris cela comme le seul outil d'interaction. Tout ce qui allait au-delà était ignoré. 

Autrement dit, au début, les gars ne savaient tout simplement pas comment communiquer entre eux, ils semblaient être dans les mêmes bavardoirs, mais s'ils pouvaient poser des questions ou non, ils ne savaient pas. Et alors qu'ils travaillaient déjà depuis un certain temps dans de telles conditions, ils ont développé leurs propres communautés informelles et fermées: nous sommes des «gardiens», nous sommes des automates. Comment communiquer? Ici, nous avons le règlement - selon le règlement. 

Achat en temps opportun de licences logicielles spécialisées


À un moment donné, il s'est avéré que pour le développement de certains cas, nous avons encore besoin de logiciels payants, mais il n'y a pas de licence pour cela. J'ai dû l'acheter dans un ordre d'incendie (encore une fois, des coûts supplémentaires en argent et en temps d'arrêt). 

Feuille de route


Istonik En 

conséquence, nous avons maintenant une feuille de route, comment lancer de tels projets, elle se compose, en fait, d'étapes, chaque étape est divisée en certains points.

Stage préliminaire


La source 

Nous avons besoin d'un chef d'équipe


Timlid, un architecte en général, celui qui sera avec nous jusqu'au bout, celui qui comprend l'automatisation, qui est techniquement averti, compétent. Il est conseillé que ce soit un développeur avec 5 ans d'expérience dans certains langages de programmation utilisés sur notre projet. Parce que d'une manière ou d'une autre, notre cadre fonctionnera avec notre projet. Par conséquent, il est préférable que le cadre et le projet utilisent la même pile technologique.

Il doit y avoir un groupe de discussion


De plus, cela ne devrait pas être un groupe de discussion sur l'automatisation. Ce doivent être des personnes qui prendront des décisions à l'avenir. Il est préférable de se faire des amis au tout début, afin de comprendre quelles décisions ils prennent, pourquoi et pourquoi.

Évaluation de l'état de la base de cas de test


J'ai déjà parlé de l'évaluation de l'état de la base de cas de test ci-dessus, respectivement, cela se fait également au stade très préliminaire.

Nous découvrons ce qui n'est pas soumis à l'automatisation


Souvent, il y a un désir d'automatiser tout ce qui bouge (et tout ce qui ne bouge pas, ne bouge pas et n'automatise pas), en fait, environ 40% des cas de test sont généralement si chers à mettre en œuvre qu'en principe, ils ne seront jamais rentables. Par conséquent, ici, vous devez être très clair sur ce que vous voulez: tout automatiser et voler dans le tuyau, ou vous voulez automatiser un certain test fonctionnel qui vous aidera.

Évaluation d'un projet pilote


Nous évaluons le projet pilote au stade préliminaire (combien cela coûtera) et l'exécutons sur les cas les plus difficiles (note).

Pilote


La source 

Normalisation des cas de test


Le pool de cas collecté est soumis à la normalisation. Les ambiguïtés et les conditions préalables inutiles sont éliminées. 

Préparation du cadre


Nous écrivons notre framework, ajoutons l'existant ou utilisons une sorte d'achat.

Infrastructure


Nous préparons des solutions d'infrastructure.

Ici, il est très important de ne pas perdre: vous aurez un désir irrésistible d'utiliser au premier stade une sorte d'ordinateur domestique sous la table pour exécuter des autotests. Ce n'est pas nécessaire (les tests ralentiront et tomberont si quelqu'un a accidentellement mis un ordinateur hors tension ou renversé du café dessus). Il est nécessaire d'utiliser des solutions d'infrastructure prêtes à l'emploi, des machines virtuelles, de surveiller la pratique de l'application. En conséquence, calculez immédiatement sa puissance à la fois pour ce projet et pour le prochain gros. Pour ce faire, nous avons besoin d'un spécialiste en automatisation.

Sous-totaux et ajustements


Nous écrivons les premiers cas. Nous évaluons la vitesse de tout ce bonheur. Nous évaluons les besoins supplémentaires des personnes, car nous savons déjà combien de cas seront automatisés. Autrement dit, nous avons automatisé cinq pièces, maintenant nous devons comprendre combien de personnes nous avons besoin pour automatiser, conditionnellement, 5 000 autres. Quelques licences supplémentaires, matériel pour le stand, à la fois pour le stand qui exécutera les autotests et pour le stand de l'application elle-même. Eh bien, en fait, la nécessité de finaliser les cas de test est à quel point tout est mauvais.

Résumé du pilote


Nous résumons, rédigeons un rapport et décidons si nous passerons à l'automatisation ou non.

J'ai déjà écrit plus tôt qu'il peut arriver que nous n'y allions pas. Autrement dit, si, par exemple, la période de récupération est de 18 ans et que la durée de votre projet est de 5 ans, vous devriez vous demander pourquoi vous en avez besoin.

Phase de lancement


 

Les éléments sources sont répertoriés séquentiellement, mais en fait, ils doivent tous être effectués en parallèle.

  • Nous commençons la sélection de l'équipe.
  • Nous déterminons les pistes.
  • Priorisons les études de cas.
  • Nous normalisons les cas de test.
  • Nous résolvons les «difficultés d'infrastructure».
  • Nous rédigeons des règlements et des instructions, établissons des communications, éliminons les goulots d'étranglement.
  • Nous améliorons le cadre pour le travail simultané de plusieurs autotests et la parallélisation de groupes de tests en cours.
  • Nous réalisons un module de reporting et de statistiques (ponctuel et cumulatif).
  • Nous commençons à écrire des autotests.

Scène principale


Source 

Au stade principal, tout est simple (haha): les autotests sont écrits, un support écrit est fourni, les résultats du lancement sont évalués, les décisions de gestion sont prises, les pouvoirs sont resserrés, les flux sont ajoutés et, en fait, la communication et encore la communication avec l'équipe de l'interface utilisateur. Tout le monde devrait naviguer dans le même bateau et ramer dans une seule direction.

Étape d'escorte


Source 

La scène d'escorte est légèrement différente de la scène principale. Une différence importante réside dans sa durée. En outre, il a un pourcentage beaucoup plus faible de nouveaux autotests en cours de développement. Selon nos estimations, 6-10% par sortie, sinon c'est très similaire à la scène principale.

Quel est le résultat?


Nous avons automatisé environ 1 500 cas de bout en bout. La stabilité des lancements réussis a maintenu plusieurs versions à environ 92-95%.

Les frais de recours ont diminué de près de 2,5 fois. Les courses elles-mêmes ont lieu en 3-4 heures, cela se fait la nuit, de sorte que le matin pour avoir des résultats prêts à l'emploi.

Les détails de la mise en œuvre technique sont décrits dans une série d'articles rédigés par mes collègues:


Si nous commençons maintenant, en tenant compte de tout ce que j'ai écrit, je pense que nous économiserons considérablement nos nerfs, notre temps et notre budget.

Merci pour l'attention. Posez des questions, nous discuterons. 

La source 

Et nous attendons également notre équipe de jeunes testeurs!
, , .

More articles:


All Articles