Transcription de l'épisode 22: Conversion des tests manuels en tests automatisés

Ceci est la transcription de Test & Code, épisode 22: Conversion des tests manuels en tests automatisés

Épisode 22: Remplacement des tests manuels par des tests automatisés.

[music] Bienvenue dans Test and Code, un podcast sur le développement et les tests de logiciels. Alors j’ai eu une question récemment, je ne me souviens plus d’où je l’ai tirée, mais c’est essentiellement: j’ai des tests manuels et je veux les convertir en tests automatisés, mais quand je cherche toutes les informations sur les tests et des tests automatisés, cela signifie que vous devriez avoir une assertion par test, et comment cela vous aide-t-il à convertir les tests manuels en tests automatisés? Bien sûr, ce qui suit sera mes opinions basées sur mon expérience. Je veux décrire le processus que j'aime utiliser pour convertir des tests manuels en tests automatisés, mais avant de commencer, je souhaite casser un peu la question. Les tests manuels sont par nature des tests système exécutés via l'interface utilisateur. Les tests automatisés peuvent être à différents niveaux. Toutefois, si vous convertissez un test manuel, vous devez le convertir en test de l’interface utilisateur automatisée, via Selenium ou quelque chose du genre, ou bien en test de l’API ou sous-cutané. La notion selon laquelle les tests devraient avoir une affirmation et une affirmation seulement par test est, je crois, erronée. Il provient de nombreux tutoriels de développement pilotés par des tests mockist. Je pense que c’est un bon objectif que chaque test vérifie une chose, mais cette vérification peut impliquer plus d’une affirmation. Le meilleur moyen de vérifier une chose est d’essayer de respecter une stratégie «quand-puis-alors», selon laquelle les affirmations s’appliquent à la fin du test. Je veux mettre quelque chose en place, faire quelque chose, vérifier si cela a fonctionné correctement. Cependant, ne soyez pas dogmatique à ce sujet. Une procédure automatisée est souvent préférable à une procédure manuelle.

[1:50] Que sont les tests manuels? Ils sont un mélange de choses. Il y a souvent des composants d'interface utilisateur qui doivent être vérifiés, difficiles à vérifier automatiquement. Il existe également de nouvelles fonctionnalités que nous n’avons pas encore eu la possibilité d’automatiser. Les tests manuels sont configurés pour que les personnes puissent les exécuter, et non les ordinateurs. Avec les tests manuels, nous ne voulons pas d’un testeur qui s’ennuie, le temps est précieux; nous configurons donc souvent des tests et des listes de contrôle en tant que workflow, avec des éléments à vérifier en cours de route. C’est plus rapide et moins fastidieux, bien que cela ne fasse évidemment pas partie d’une intégration continue.

[2:27] Les problèmes avec les tests manuels:

• Difficile à répéter: si vous donnez la même liste de contrôle à deux personnes différentes, vous obtenez deux résultats différents.
• Ils sont lents: ils ne fournissent pas de retour rapide sur le processus de développement.
• Et parfois, ils sont laissés à faire à la fin du processus de développement.
• Comme cela n’aligne pas directement les modifications de code, il n’est pas facile de suivre les problèmes.

[2:51] Les raisons de convertir en système automatisé sont les suivantes: résoudre tout cela, résoudre tous les problèmes et réduire le temps de traitement. Et pour les exécuter plus tôt et plus fréquemment. Je pense qu’il est toujours bon d’avoir des tests manuels, en particulier avant les points de contrôle de versions définitives, mais ces derniers étant concentrés et courts, vous pouvez les exécuter plus fréquemment.

[3:14] Donc, j'ai cette procédure que j'ai écrite pour ce que je pense est un bon moyen de convertir des tests manuels en tests automatisés. Tout d’abord, lisez la procédure manuelle une fois complètement. Ensuite, lisez-le et faites-le. Sans comprendre ce qui se passe là-bas, il est difficile de l’automatiser bien sûr. Maintenant, je veux que vous lisiez à nouveau le tout. C’est donc la troisième fois que vous le lisez. Maintenant, vous allez marquer différentes sections comme des choses qui devraient être automatisées, des choses qui devraient être laissées manuellement et pourquoi. Maintenant, pour les choses qui devraient être automatisées, il faut essayer et essayer – c’est vraiment important d’essayer de comprendre ce que vous essayez de tester. Quelle est la raison sous-jacente de cette présence? Et ça va vous aider à écrire vos tests. Maintenant, certains seront plus faciles à convertir en un test bien ciblé, alors que d’autres seront des processus longs et difficiles à diviser. Notez simplement ceux que vous voulez faire. C’est peut-être le bon moment pour commencer à rédiger comme un petit document pour chacune des choses à automatiser, et à peu près un pseudocode pour savoir comment il va être vérifié. Si vous écrivez des choses, c’est le bon moment pour réécrire les procédures manuelles, celles qui le resteront, et rédigez de petites procédures pour lesquelles les choses devraient être automatisées et le type de déroulement du test. C'est une bonne idée de les noter, car s'il s'agit d'un projet de taille raisonnable avec plusieurs personnes, le moment est propice pour juste réviser le code de ce pseudocode, il suffit de le vérifier sous une forme quelconque, peut-être la docstring en haut du fichier de test. , ou même juste un fichier texte, peu importe, faites en sorte que plus de gens le regardent. Ou envoyez un courriel aux gens en leur disant: «Hé, est-ce que cela a l'air raisonnable? Maintenant, nous voulons commencer à écrire ces tests. Passez simplement en revue et commencez à garder trace de ceux que vous avez convertis et de ceux que vous n’avez pas encore convertis, puis convertissez-les en tests et faites-les fonctionner. Espérons que vos tests automatisés détectent des choses similaires à celles de votre procédure manuelle. Lorsque je le fais, je constate toujours que les ordinateurs sont plus pointilleux que les utilisateurs et que plus de tests échouent lors d’un balayage automatisé que si la même procédure est exécutée manuellement. Et parfois, c’est parce que le test est en fait trop difficile, et nous devons parler au concepteur, à l’architecte ou à une autre personne pour essayer de déterminer s’il s’agit ou non d’un véritable échec. Peut-être avons-nous une exigence que nous ne comprenons pas tout à fait.

[5:49] La procédure que j’ai décrite prend un peu de temps. Voici donc une autre solution: continuez et allez faire les deux premières lectures de la même façon, et annotez les choses. Maintenant, pour tout ce qui devrait être automatisé, ne vous inquiétez pas d’essayer de le diviser en tests ciblés, écrivez-les simplement en tant que gros processus automatisés. L’inconvénient est que ce sera difficile à maintenir, vous ne voulez donc pas en rester là pendant longtemps. Cela ne va pas être granulaire, donc si un test échoue, ça va être quelque chose qui a échoué mais je ne sais pas trop quoi. Et il sera plus difficile de déboguer pour cette raison, les choses échoueront davantage, ce sera un de ceux que les gens décrivent comme des tests fragiles. Je pense que si c’est plus rapide, allez-y, allez-y. Vous découvrirez rapidement des domaines faciles à automatiser et difficiles à automatiser, et vous pourriez vous dire: «Ce que j’imaginais automatiser est trop difficile, laissez-le comme manuel pour le moment. Si vous pouvez faire cela plus rapidement, alors vous avez le temps que vous auriez passé à exécuter ces procédures pour les automatiser en plus petites. La procédure alternative consiste généralement à écrire correctement les gros tests géants, puis à les décomposer plus tard. Il vous donnera des informations, mais s’il est difficile de fonctionner correctement, il est peut-être temps de concentrer ces tests un peu plus.

[7:08] Certaines fonctionnalités critiques de votre système peuvent nécessiter des tests automatisés et manuels. Je pense que c’est tout à fait raisonnable. Les tests manuels doivent être suffisamment courts pour pouvoir être effectués régulièrement au cours du développement, et pas seulement une fois à la fin. Gardez cela à l'esprit pour ceux qui restent. Gardez à l'esprit les coûts par rapport aux avantages des tests automatisés et des tests manuels. Écrire des tests, c'est écrire un logiciel. Les logiciels doivent être maintenus et ils ont des coûts et des avantages.

[7:38] Si un test échoue, qu'est-ce que cela signifie? J'espère que cela vous donne une idée de ce qui ne va pas avec votre logiciel. Les tests logiciels sont supposés être là pour: mon logiciel fonctionne-t-il correctement? Désormais, la simple réponse «non, cela ne fonctionne pas correctement» n’est pas très utile. Je vais utiliser une analogie avec une voiture. Il y a un tas de petites lumières et autres choses sur mon tableau de bord. Maintenant, un peu de lumière qui me montre que je suis presque en panne d’essence, je sais exactement ce qui ne va pas: je suis presque en panne d’essence. Vérifiez la lumière du moteur, ce n’est pas si bon. Je pense qu’il fait beaucoup de contrôles et qu’il en fait trop. Je ne sais pas comment vous simplifieriez les choses, mais cela ne me dit pas ce qui ne va pas. Tout ce que je sais, c’est que l’essence est probablement bonne et que le moteur a un problème; je dois le confier à un mécanicien, car je n’ai aucun de ces bricoles qui se fixe à l’ordinateur de bord. Quoi qu’il en soit, il faut faire attention à ce genre de choses. Vous souhaitez rédiger des tests ciblés qui vous indiquent ce qui ne va pas avec votre logiciel et non pas un problème.

[8:37] C’est le double avantage de convertir des tests manuels en tests automatisés. Laissez-moi savoir ce que vous pensez. Les notes d’affichage peuvent être consultées sur pythontesting.net/22. Je fais des transcriptions car j'ai de l'argent. Quand je reçois assez d’argent des ventes de livres et des supporters de Patreon pour les convertir. Alors, s'il vous plaît, envisagez de devenir un partisan de Patreon, même un dollar peut aider à obtenir plus d'épisodes et plus de transcriptions. Une histoire amusante à propos des transcriptions, j’avais initialement mis en place la campagne Patreon pour tenter d’obtenir l’accès rapide aux abonnés à 2 $ et plus aux transcriptions. Lorsque j’ai reçu cette première transcription, je ne l’avais pas encore publiée sur le site Web, mais je l’ai envoyée à tous les partisans de Patreon. Je voulais l’envoyer à tout le monde parce que je suis vraiment reconnaissant à tout le monde, alors j’ai vérifié auprès de tous les partisans de deux dollars et plus et je me suis dit que ça allait si je l’envoyais à tout le monde. Et chacun d'entre eux a déclaré: «Je ne me suis pas inscrit au niveau à deux dollars pour obtenir les avantages, je me suis inscrit parce que je veux que vous donniez plus d'émissions." Et, vous savez, sérieusement, il est difficile pour moi de relayer ceci informations sans être submergé par le support. Je sais que ce n'est pas une tonne de gens, et beaucoup de gens gagnent plus d'argent que moi en podcasting, mais avoir des gens qui veulent vraiment me donner quelques dollars à chaque fois que je fais un épisode, c'est trop cool! . Si vous souhaitez en savoir plus, vous pouvez accéder à pythontesting.net/support ou directement à patreon.com/testpodcast.

[10:12] Aussi, je veux mettre une autre prise pour le canal Slack. Hier, nous avons eu une question ou quelques jours plus tôt, nous avons demandé comment utiliser le modèle d’objet de page au sélénium dans pytest. Je ne savais pas du tout, mais il y avait d’autres personnes sur la chaîne qui avaient des informations, et c’est plutôt cool. C’est vraiment génial, c’est ce pour quoi je l’ai mis ici, pour que nous puissions avoir une petite communauté qui s’entraide. Si vous souhaitez en faire partie, accédez à pythontesting.com/slack pour obtenir une invitation. Sur Twitter, je suis @brianokken et l'émission est @testpodcast. En tout cas, merci de votre attention, je vous parlerai plus tard.