Les testeurs manuels sont souvent poussés vers l'automatisation, et je pense que cette méthode est tout à fait naturelle. C'est ainsi que les meilleurs produits d'automatisation sont obtenus. Tout d'abord, ce sont de bons freins à main, et déjà dans le second - un peu de développeurs.
Dans cet article, je partagerai mon opinion sur la raison pour laquelle cela vaut la peine de procéder de cette façon et sur ce qui se passera si l'automatisation vient différemment.
Avertissement: je ne veux offenser aucun des testeurs avec mon article. Je respecte vraiment le «frein à main» et j'ai commencé mon parcours par des tests manuels.Je travaille en tant que chef du département des tests depuis environ deux ans. Récemment, beaucoup d'automatiseurs sont venus me voir pour des entretiens, qui n'ont pas de base pour les tests. Ils ont une expérience de l'automatisation en tant que telle. Mais dans leur travail, ils comptent toujours sur la conception des tests de quelqu'un d'autre (faite par des «bracelets à main»).
Dans un monde idéal, ces compétences correspondent à la tâche: les testeurs fonctionnels élaborent des cas de test et formulent réellement des tâches pour les auto-tests. La machine doit décrire ce qu'il voit. Mais sur de vrais projets, l'ingénieur en automatisation doit aller un peu plus loin dans l'essence du sujet. Si la tâche requiert ses propres compétences en conception, une machine de test automatisée sans base préférera tout faire sur un coup de tête, tout simplement parce qu'elle lui semble juste. Cela conduit souvent au fait que certains cas sont vérifiés deux fois, tandis que d'autres ne le sont pas du tout.
Je le répète, je ne veux offenser personne. Mais l'abondance de ces candidats m'a fait peser une fois de plus quels facteurs sont importants dans le travail d'AQ. Et voici trois conclusions:
- sur des projets réels, l'ingénieur en automatisation a besoin des compétences d'un «frein de stationnement»;
- Le «frein à main» qui se développe laissera tôt ou tard des tests manuels, peut-être dans l'automatisation;
- le chemin du «frein à main» à l'outil d'automatisation est le chemin vers une plus grande indépendance, qui correspond bien au format de travail à distance.
Je m'attarderai un peu plus sur chacun d'eux.
Pourquoi l'automatisation a-t-elle besoin de l'expérience du «frein à main»?
Comme je l'ai déjà noté au tout début, l'automate a besoin d'une base théorique. Mais je ne parle pas d'une éducation spécifique. Nous avons besoin d'expérience dans l'analyse pratique d'applications réelles.
Pour tester la prochaine fonctionnalité, qui est en cours de préparation pour la production, les testeurs fonctionnels analysent la spécification pour tenter de fermer la plupart des cas. Ils apprennent à couvrir le nombre maximum de cas et les problèmes possibles avec un minimum de temps (à la fois leur propre et, relativement parlant, processeur). Lors des tests, c'est l'une des compétences de base - comme la marche. Et comme on dit, si vous ne savez pas marcher, vous ne pourrez pas jouer au football (automatiser).
Une machine d'automatisation qui a souvent réussi la phase de test manuel peut simplement écrire du code. Mais cela ne suffit pas. Et en un mot, vous ne pouvez pas expliquer toute la base manquante. Pour l'obtenir, vous devez vous tourner du côté des tests fonctionnels, même si cela peut sembler étrange. Nous sommes avant tout des testeurs, et ensuite seulement de l'automatisation.
Vaut-il le frein à main pour passer à l'automatisation?
À un moment donné, l'automatisation m'a attiré avec le fait que, contrairement aux tests manuels, les tâches ne sont pas si uniformes. Dans le rôle d'un frein de stationnement, je m'ennuyais. J'ai toujours voulu faire quelque chose pour réduire la routine. Et de l'automatisation, je suis devenu élevé.
Alors que j'étais encore un frein à main, j'ai commencé à utiliser le Selenium IDE (à mon avis, il est toujours en vie), ce qui me permet d'enregistrer des actions manuelles. Il a automatiquement formé une sorte de script avec des localisateurs trouvés automatiquement. Quand j'ai fait des expériences avec lui, tout avait l'air plutôt maladroit, tombant parfois, mais c'est Selenium IDE qui m'a poussé à réfléchir: pourquoi ne pas écrire quelque chose toi-même? J'ai réalisé l'idée dans le travail de mon maître, puis je suis allé travailler comme ingénieur en automatisation.
Le chemin du «frein à main» à l'automatisation est l'un des deux possibles. Il s'agit d'un développement de branche technologique. En améliorant vos compétences, vous vous rapprochez du développement. De la même manière, vous entrez dans le code, seulement, à mon avis, c'est encore plus intéressant que le développement.
La deuxième façon est de suivre la ligne managériale: devenir un responsable QA, puis aller gérer le projet, etc. Ici, il est nécessaire de pomper des compétences déjà commerciales, d'apprendre à regarder différemment les projets et les tests en général.
Il n'y a pas de troisième voie - seulement au-delà de l'AQ. Si vous continuez à vous développer, vous ne resterez pas dans les tests manuels - vous vous reposerez contre le plafond des tâches. Oui, vous pouvez pomper, par exemple, en tant que spécialiste du test de la «boîte blanche». Mais avec une probabilité de 99% à un moment donné, il deviendra plus intéressant pour vous de faire quelque chose en dehors de la portée de la documentation de test. Et soit vous choisirez l'un des deux chemins mentionnés ci-dessus, soit vous quitterez complètement les tests. Par exemple, vous serez emporté par certaines tâches d'infrastructure, vous développerez donc déjà en devops. Et ceux qui ne remarquent pas ou ignorent en eux-mêmes ce désir d'aller de l'avant, selon mon expérience, «disparaissent rapidement».
Soit dit en passant, et les salaires, celui de l'automatisation, celui des managers, sont plus élevés (c'est si l'on se souvient du côté matériel de la question).
Cependant, personne ne dit que les tests manuels devraient être définitivement supprimés. Moi-même, j'aime parfois pousser quelque chose: lire les spécifications, travailler le bon vieux design de test - pour aider les gars de mon département. Comme je l'ai dit plus haut, nous sommes avant tout des testeurs.
Du «frein à main» à l'automatisation - le chemin vers udalenka
Étant donné que j'ai eu l'opportunité de travailler dans différents secteurs de tests complètement à distance, je veux partager mon expérience ici aussi. Le «frein à main» et l'automatisation ont un pool de tâches légèrement différent, ce qui les fait se sentir différents dans le format du travail à distance.
Les «hommes de main» sont probablement un peu plus difficiles à trouver un travail à distance. Il y a beaucoup de postes vacants, mais la concurrence pour eux est assez grande - il y a plus de bons testeurs manuels que de bons ingénieurs en automatisation. Mais même si le travail souhaité est obtenu, les tests manuels impliquent une communication constante avec les collègues. Lors de la rédaction de la documentation de test pour la spécification d'une personne, de nombreuses questions se posent: à l'analyste, aux développeurs, etc. Un testeur manuel doit rechercher des personnes et leur demander comment cela sera mis en œuvre. Il est plus facile de travailler à proximité pour pouvoir venir discuter en personne.
Le frein à main peut fonctionner à distance si le projet a des communications bien construites ou si une équipe est complètement répartie, lorsque personne n'a un avantage en communication. Sinon, il sera difficile de joindre quelqu'un au bureau. Les collègues de bureau peuvent simplement entrer dans la salle de réunion et revenir dans 2 heures. Vous allez essayer de les joindre tout ce temps. Il est beaucoup plus difficile d'oublier une personne en direct.
Automator dans ce sens est plus facile. Ses tâches sont décomposées: s'asseoir et boire du code. En fait, il peut travailler séparément de l'équipe, surtout si c'est le projet idéal où il reçoit des cas de test de testeurs fonctionnels.
Ainsi, le chemin du frein à main à l'automatisation est une route non seulement vers de gros revenus, mais aussi vers un endroit éloigné, si cela est nécessaire.
Avez-vous déjà changé de domaine informatique? Comment avez-vous choisi votre chemin?
Auteur de l'article: Ruslan Abdulin
Cet article est la troisième partie de notre série de publications sur les carrières informatiques.
La première partie est
ici .
La deuxième partie est
ici .
PS Nous publions nos articles sur plusieurs sites du Runet. Abonnez-vous à nos pages sur les
chaînes VK ,
FB ou
Telegram pour découvrir toutes nos publications et autres actualités Maxilect.
Aidez-nous à rendre les articles du blog plus intéressants:
veuillez répondre à trois questions .