Le titre dit tout. Certains employés de notre entreprise pensent que les tests automatisés sont "faciles" et que "cela devrait prendre une journée" pour écrire des suites de tests COM et UI. Que peut-on faire pour contrer cela?
Remarque: je ne demande pas comment promouvoir l'automatisation. Ce n'est pas ça le problème. Les tests et processus automatisés sont promus et demandés tout le temps ici. Le problème est que certaines personnes ne comprennent pas que l'automatisation n'est ni "facile" ni "rapide".
project-management
quality
automation
joshin4colours
la source
la source
Réponses:
La prochaine fois que vous recevrez une demande, essayez de décomposer autant de processus d'automatisation en morceaux de temps. Je pense que quand ils réalisent que cela prend 5 minutes par champ de texte ou bouton, ils commencent à réaliser combien de temps cela prend.
Par exemple, peut-être que cela prend si longtemps, c'est qu'ils commencent à introduire l'interdépendance entre les champs: par exemple, ne leur permettez de continuer que si cela est rempli mais pas si ce n'est pas le cas, sauf quand ...
Essayez de les éduquer sur POURQUOI cela prend si longtemps, mais pas autant que vous les perdez à travers le processus "d'apprentissage".
la source
Dans mes rôles, j'ai rencontré de nombreuses personnes "x is easy" en particulier sur des projets de développement. Dans mon esprit, il y a trois raisons à cela:
1) Ils ne comprennent vraiment pas de quoi ils parlent, mais aiment beaucoup sonner comme ils le font.
2) Ils ont lu quelques livres et pensent savoir de quoi ils parlent
3) Enfin, les gens supposent qu'un ordinateur fait les tests rapidement, parce que les ordinateurs sont rapides.
Le seul moyen sûr de lutter contre cela est d'engager régulièrement les utilisateurs, les stratégies de communication pour les projets sont essentielles, expliquant certainement les tenants et les aboutissants des tests automatisés aux utilisateurs non techniques va être futile, mais leur faire prendre conscience des processus impliqués peut être bénéfique. Vous pouvez le faire via la documentation, des ateliers ou simplement une conversation amicale la prochaine fois que vous passerez.
J'ai même vu un BA célibataire parmi les plus bruyants de ces gens "x c'est facile" et je les ai simplement invités à passer une journée dans le département, en pensant qu'ils s'en iraient pour mieux comprendre ce que vous faites OU ils simple come away en pensant "dieu, je ne sais vraiment pas de quoi je parle, je pense que j'avais tort".
la source
Le logiciel consiste à automatiser les choses.
Nous écrivons des logiciels pour nous faciliter les tâches ennuyeuses, répétitives et exigeantes en main-d'œuvre. Nous écrivons des logiciels pour automatiser la création de rapports, la collecte de données, la communication avec les autres, etc. L'écriture de tests automatisés est vraiment juste de l'écriture de logiciels pour nous assurer que nos autres logiciels fonctionnent comme nous l'attendons.
Si vos collègues comprennent que l'écriture de logiciels est difficile et prend du temps, il devrait être assez facile de leur montrer que l'écriture de plus de logiciels doit être difficile et prendre du temps. Ce serait bien d'obtenir tous les avantages de l'automatisation gratuitement, mais, comme toujours, nous devons mettre le travail en avant pour obtenir les avantages plus tard.
S'ils ne comprennent pas cela, vous devez soit travailler à leur enseigner cela, soit travailler à peaufiner votre CV.
la source
writing software is hard and takes time. L'écriture d'une petite application en ligne de commande est rapide. Il est difficile d'écrire l'IA skynet. Dire de telles déclarations générales ne convaincra personne.La plupart des employés passent leur temps dans la partie «avant» (client-patron-partie prenante) de l'entreprise ou dans «l'arrière» (où se fait le «vrai» travail). Ces deux fonctions sont différentes, presque opposées. (Et très peu de gens ont travaillé dans les deux). En conséquence, il y a souvent des malentendus entre les deux groupes.
La meilleure façon d'éduquer, par exemple, les gens du «front», est d'avoir un ou quelques-uns d'entre eux passent une journée dans le «dos». S'ils terminaient "Une journée dans la vie de ...", ils auraient une idée plus réaliste de ce qui peut être fait en une journée, et pourquoi cela prend plus de temps et d'efforts pour exécuter des tests automatisés. De même, les personnes «de dos» pourraient bénéficier d'un jour ou deux au «front».
Dans «Comment être riche», John Paul Getty (un magnat de son temps) a préconisé une telle «formation croisée». À son avis, un vendeur qui passait du temps sur la chaîne de montage où le produit était fabriqué ferait un bien meilleur travail de vente, et de même un ingénieur qui passait une journée avec des clients ferait un meilleur travail de «débogage».
la source
Je ne suis pas d'accord avec votre prémisse ici.
Je suis un grand partisan des tests automatisés, qu'il s'agisse de tests unitaires, de tests d'intégration ou de tests d'interface utilisateur. Il existe de nombreux excellents outils disponibles pour implémenter des tests automatisés.
Comparons les tests automatisés aux tests manuels sur la base de l'exemple suivant:
Dans une application Web, testez la fonctionnalité "Changer le mot de passe" d'un utilisateur existant à l'aide d'un navigateur.
Test manuel :
Facile? Pas vraiment. Il existe de nombreux pièges possibles dans le processus.
Vite? Non. Le travail manuel prend du temps.
Maintenant, essayons d'écrire un test automatisé :
Facile? Non! Nous devions rechercher les outils, les implémenter, corriger quelques bugs dans nos tests.
Vite? Non! Cela prend encore plus de temps que de faire un test manuel.
Mais, il y a une grande différence ici: pour les tests futurs, il vous suffit d'écrire le test lui - même , le dernier point de la liste - qui a été fait rapidement et de manière comparable. Il n'est pas nécessaire d'effectuer toutes les recherches et tous les scripts d'initialisation pour d'autres tests.
Et après avoir passé le test, vous pouvez commencer facilement. En quelques secondes (ou peut-être quelques minutes, si le démarrage de la base de données et de l'application Web prend du temps), vous voyez si la routine "Changer le mot de passe" fonctionne ou non. S'il y a un bug, corrigez-le et relancez le test - vous verrez immédiatement si le bug est corrigé. Rapide et facile .
Écrire des tests automatisés n'est ni facile ni rapide en premier lieu, mais les exécuter l'est.
Et c'est le moment où le temps investi revient.
la source
Les tests en général ne sont pas faciles et ne devraient pas l'être. Si Boeing ou Mercedes ne testaient pas leurs produits aussi rigoureusement qu'ils le feraient, ils seraient soit en faillite en raison de poursuites judiciaires, soit feraient faillite pour vendre des articles de si mauvaise qualité. Diriez-vous une voiture à 70 miles à l'heure en sachant que le volant peut ou non tomber en morceaux?
Il est très difficile de suggérer des moyens de faire face à l'état d'esprit sans comprendre qui sont ces personnes ou leurs raisons. La plupart des gestionnaires et administrateurs pensent aux coûts et sont jugés par ce qui est produit. En utilisant ces critères, il leur est très difficile de justifier de passer du temps sur des tests. Si tel est le cas avec vous, vous devrez trouver des moyens de présenter cette tâche comme étant bénéfique à long terme, ce qui est bien sûr le cas.
Le fait que les logiciels ne soient pas tangibles ne signifie pas que nous pouvons nous en sortir sans penser aux implications des systèmes que nous construisons ne fonctionnent pas. Je parie qu'Amazon a des tests automatisés et je parie qu'il y a des gens qui ne connaissent que trop bien les implications financières de l'échec de leurs sites Web / services.
la source
2 +2 = 4 est l'un des morceaux de code les plus simples que tout le monde comprend; Et vous pouvez voir comment est facilement compris. Mais cela ne signifie pas que c'est une équation «facile». Le niveau d'abstraction nécessaire pour atteindre l'équation simple est assez complexe. Il en va de même avec les logiciels et les méthodologies de test de logiciels. Le niveau d'abstraction qui nécessite un morceau de code demande beaucoup de travail.
Il est vrai qu'une bonne pratique conduit à réutiliser des classes et des objets mais également, pour atteindre cet état il faut investir du temps et des efforts .
la source
Il y a deux côtés à cette question.
De votre côté, vous semblez penser que vous faites du bon travail et que le groupe «L'automatisation est facile» ne sait pas de quoi il parle.
De leur côté, d'après ce que vous dites, ils voient des tests automatisés prendre (selon eux) beaucoup de temps à produire.
De cette distance, avec le peu que nous devons continuer, nous ne savons pas qui a "raison", ou si quelqu'un a "raison".
Comment gérer l'automatisation est un état d'esprit facile
Parlez-leur. Demandez-leur honnêtement leurs idées sur la façon de mieux faire. Faites-les participer et participer. C'est la seule façon de savoir s'ils ont vraiment quelque chose de positif à offrir. Peut-être qu'ils ont des contributions intéressantes à apporter, et vous pouvez gagner / gagner.
S'ils n'ont aucune idée réelle du fonctionnement de la programmation et des tests automatisés, ni d'idées réalistes sur la façon d'améliorer la productivité, alors après les avoir engagés positivement, vous pouvez montrer comment cela se fait et où va le temps. Soyez humble et positif, en les remerciant pour leurs contributions / idées. Pensez à ce qu'ils ont dit: peut-être que leurs suggestions déclencheront une façon de penser différente pour vous. Si oui, donnez-leur cette rétroaction. En étant humble et positif, vous pouvez également en faire un gagnant / gagnant.
Avant de leur parler, réfléchissez à la façon dont vous créez, exécutez et gérez vos tests. Quel (s) cadre (s) utilisez-vous? Y en a-t-il d'autres qui pourraient être meilleurs? Avez-vous un passe-partout "standard" que vous adaptez? La construction des tests pourrait-elle être plus automatisée? Qu'est-ce qui vous retient?
la source