Les approches de développement au cours des dix dernières années ont subi des changements majeurs, les exigences des testeurs (QA, QE, ingénieurs qualité) ont également changé. Mais tous les testeurs ne sont pas prêts à franchir un tout nouveau niveau. Hier, il était possible de venir de la rue pour entrer dans la profession. Pour devenir aujourd'hui un spécialiste recherché, vous devez être ingénieur.
Lors du démarrage d'une carrière, une présentation a été montrée lors des cours justifiant la nécessité des tests. La signature de la diapositive indiquait: "Plus vous détectez rapidement un bogue dans le cycle de vie du produit, moins il est cher à corriger." Les taux de tests sont inférieurs à ceux des programmeurs. Nous embauchons des testeurs → garantissons la qualité et économisons sur le développement. Profit!
Les testeurs étaient des chasseurs d'insectes. Les programmeurs écrivent des fonctionnalités, une version est en cours de préparation, la version passe par l'étape QA. À cette époque, le testeur «a mis le chapeau» d'un vrai utilisateur et a commencé à exécuter des scénarios typiques. On croyait qu'une personne sans formation technique conviendrait à ce poste.
La vitesse de développement des projets modernes a augmenté. Le concept de CI / CD est apparu. Personne n'est surpris par les projets de sortie quotidiens. Les entreprises ont réalisé que les contrôles manuels ne sont pas évolutifs. Les testeurs étaient engagés dans l'automatisation des tests d'acceptation à l'aide de sélénium ou de cadres similaires. Le changement à l'intérieur est caché, si seulement le frontend reste avec les localisateurs nécessaires.
Et il en fut ainsi. Pour les managers, l'automatisation des tests est associée à une compétence: travailler avec Selenium. À la recherche d'une balle d'argent, ils ont vu en lui la réponse à toutes les questions. Le marché s'est adapté à la demande.
Nous recherchons depuis longtemps l'automatisation de l'assurance qualité pour tester les services Web. J'ai parcouru quelques centaines de CV et réalisé des dizaines d'interviews. Si pour résumer les impressions, on peut distinguer trois problèmes principaux, qui empêchent souvent l’embauche d’une personne.
1. Les testeurs n'ont aucune idée de l'architecture du projet
Ici, par architecture, je veux dire une description de haut niveau des interactions des composants du système. Classiquement, par quel «canal» les flux de données, où ils sont stockés et comment ils sont utilisés.
Lors de l'entretien, le candidat peut s'opposer, disent-ils, nous n'avons pas besoin de connaissances en architecture. Nous travaillons avec une boîte noire. Pourquoi prendre soin de la structure interne?
Je ne pense pas qu'avec une telle approche l'ingénieur va proposer tous les scénarios de test possibles. Si vous connaissez la structure interne du produit et lisez le code, vous pouvez éviter la duplication des tests à des niveaux élevés de la pyramide des tests.
Variante pyramide de Martin Fowler
Dans les tests de boîte noire, il y a le même piège que dans la sécurité par l'obscurité . Vous ne pouvez pas compter uniquement sur ce type de test. Le produit peut répondre aux exigences énoncées, tout en incluant un grand nombre de bogues cachés. Ensuite, par analogie avec la sécurité par l'obscurité, la seule garantie de qualité sera notre ignorance de l'organisation du système à l'intérieur.
L'avantage des tests en boîte noire est que les tests sont indépendants de la mise en œuvre. Ouah. Mais cette restriction artificielle ne devrait pas interférer avec la compréhension de l'intérieur. Lorsque le testeur sait comment fonctionne le produit:
- Face à un bug, il est capable de localiser le problème, et non de construire des hypothèses.
- Lors de la discussion d'une nouvelle fonctionnalité, il est prêt à donner son avis, car il comprend comment la nouvelle fonctionnalité s'intègre aux composants existants.
Malevich s'agite pour tester la boîte noire
Le même amour pour la boîte noire a probablement conduit au deuxième problème.
2. Les testeurs ne comprennent pas ce qui se passe à l'intérieur du navigateur
Il y a souvent une situation où un candidat dont le sélénium est indiqué comme l'outil principal dans le curriculum vitae ne comprend pas comment le navigateur et le protocole HTTP fonctionnent. Le test de tels automatiseurs consiste principalement à créer des scripts avec des actions utilisateur. Une approche superficielle qui crée des restrictions inutiles.
La plupart des candidats citent des exemples de codes HTTP et de types de requêtes HTTP. La question suivante est souvent déroutante.
Il y a une page de connexion. L'utilisateur entre les données correctes pour l'autorisation et clique sur le bouton de connexion. Que se passe-t-il dans le navigateur en ce moment? Pourquoi les actions suivantes avec le site ne nécessitent-elles pas de nouvelle autorisation?
Si le testeur n'a pas répondu à ces questions, un doute sur sa compétence s'introduit. Cela suggère que le candidat:
- ne peut pas tester un produit sans interface utilisateur;
- Ne sait pas comment utiliser les outils de développement dans un navigateur;
- Je n'ai pas l'habitude de trouver la cause du bug (frontend ou backend).
Il sera plus facile pour le développeur de corriger le bogue s'il est décrit avec des détails techniques.
3. Attitude négligente envers le code de test
"Mon code n'entrera pas en production, pourquoi se soucier de la qualité?"
Je vois cela comme une tentative de diviser les bacs à sable. Laissez les développeurs prendre soin de la propreté du code, mais nous le pouvons.
Rappelez-vous, dans le modèle en cascade après le développement, il y avait une étape de vérification? Pendant la période de la méthodologie Waterfall, la responsabilité de la qualité a été transférée au département de test. Cela n'a conduit à rien de bon. Les programmeurs n'ont pas pensé à l'état de préparation de la fonctionnalité, s'attendant à ce que le contrôle qualité signale des problèmes. Le ping-pong entre les départements a entraîné un ralentissement du développement. C'est le prix du partage des responsabilités.
Avec l'avènement d'Agile, les équipes se sont consolidées. Il manque «nous» et «eux». L'équipe est responsable du résultat final. Et comme les pratiques d'ingénierie sont devenues courantes, les exigences relatives au code de test doivent être présentées de la même manière que pour le code produit.
Pour abandonner les candidats, nous avons envoyé une tâche de test sans délai:
Java http://todomvc.com/examples/react/
Liste des erreurs courantes
Complications supplémentaires
Un tas d'abstractions, de wrappers sur les classes et de code passe-partout dans les tests.
Les méthodes d'essai doivent être aussi courtes que possible. Les fonctions d'assistance et la séparation de la configuration des actions sur les objets et les contrôles vous aideront à cet égard.
Violation des conventions de dénomination des classes, méthodes, variables
CamelCase mélangé avec des traits de soulignement. Donc, ils ne le portent pas maintenant. Les conseils Linter et IDE sont enregistrés.
Chemins d’assistance Hardcode
String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath);
Le classique "fonctionne sur ma machine".
Stockage de fichiers binaires à l'intérieur du référentiel
Il existe des git-lfs pour résoudre ce problème.
Manque de cohérence dans les méthodes
Dans une solution, le candidat a décrit des méthodes pour supprimer et marquer «terminé» comme ceci:
public void DeleteTask(String task) ... public void CompleteTask(int taskno)
Dans la première méthode, le texte de la tâche est transmis, dans la seconde, l'index dans la liste. L'utilisation d'une telle API est pénible.
System.out.println() pour la journalisation
Il ne fournit pas d'informations de support dans quelle classe l'événement s'est produit.
Utilisation de Thread.sleep
Pour résoudre ce problème, il existe une bibliothèque d’ attente . Il permet d'ajouter des commentaires à l'attente de la réalisation de la condition nécessaire.
Exceptions générales au lieu de asert
Exemple: un test ajoute plusieurs éléments à la liste des tâches et marque tous les éléments comme terminés. L'idée est qu'en cas de problème, la méthode findElement retournera une NoSuchElementException et le test NoSuchElementException . Si vous regardez plus tard les résultats du test, NoSuchElementException sera trompeur: il n'est pas clair si le test a vraiment chuté ou le code de la courbe de test. Il est nécessaire d'utiliser un asert avec un message d'erreur clair en cas d'échec du test.
Abus des acides bertiques
assertTrue ou assertFalse est utilisé pour tout dans une rangée:
assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1);
Il est préférable d'utiliser assertEquals ici pour avoir du contexte lorsque le test se bloque.
Il n'y a pas de paramétrage pour l'exécution des tests
Exemple: l'URL du site pour les tests est clouée dans le code.
Il faut aussi mentionner travailler avec git . Le plus souvent, la tâche a été envoyée en un seul commit. Écrire des messages de validation compréhensibles et diviser une tâche importante en plusieurs tâches distinctes est une compétence nécessaire, en particulier dans le travail d'équipe.
Conclusions
Les problèmes décrits ci-dessus sont mon expérience personnelle et mes impressions après les entretiens. Selon les observations, l'expérience du candidat n'est pas en corrélation avec le nombre de lacunes. Évitez les testeurs homéopathiques, investissez du temps dans le pompage des compétences techniques des employés. Les testeurs ont quelque chose à apprendre des développeurs et vice versa. Que la force vienne avec ceux qui construisent la culture de l'ingénierie et nagent à contre-courant.
Je serai heureux de me tromper et heureux si tout est différent dans votre entreprise embauchée.
UPD 11/02/20 : Lors du webinaire «Portrait d'un testeur», je partage mon avis sur la façon dont je vois le métier de l'intérieur.
- Pourquoi une entreprise a-t-elle besoin de testeurs?
- Le rĂ´le du testeur dans l'Ă©quipe
- Test automatisé VS manuel
- Aspects attractifs du métier et prix de l'expérience
- Compétences matérielles / techniques nécessaires
- Erreurs dans le curriculum vitae des professionnels novices
- Devops dans les tests
- Croissance de carrière