Tests automatisés: expliquer sa valeur commerciale

Pour commencer, je ne pense pas que ce soit une répétition d' autres questions sur les tests unitaires . Ce que je recherche, c'est exprimer sa valeur à une équipe de programmeurs, d'analystes, de gestionnaires et de testeurs. Par des tests automatisés, je ne pense pas avoir besoin de faire une distinction entre les tests unitaires (par exemple JUnit), BDD (par exemple JBehave, Fitness) et UI (Selenium, Watir) parce que je pense qu'ils fournissent tous une valeur similaire (mais n'hésitez pas à écrivez une réponse qui n'est pas d'accord :))

Ce qui suit est une liste que j'ai identifiée, je cherche des réponses qui aident à développer ou à affiner:

1. Économies de temps et d'argent : l'écriture de tests automatisés peut prendre plus de temps que les cas de test écrits. Cependant, étant donné que les tests sont exécutés plusieurs fois, le travail marginal (c.-à-d. Coût / temps) pour exécuter des tests automatisés est de plusieurs ordres de grandeur de moins. Le fait que les tests automatisés soient peu coûteux à exécuter facilite le changement du système au fil du temps.
2. Documentation : il n'y a pas de moyen plus vrai de savoir comment fonctionne un système que ses tests. Toute autre documentation est généralement obsolète au moment où elle est écrite, mais les tests (au moins ceux qui réussissent) révèlent comment les choses fonctionnent réellement. Cela est vrai pour la documentation de l'utilisateur final et de l'API.
3. Qualité du code : l'écriture de test vous oblige à:
   • considérer les clients parce que les tests sont un client
   • rompt les dépendances où rendre le code testable signifie souvent trouver comment rendre ce code ne nécessitant pas qu'un autre grand système soit disponible

Quelques réflexions:

1. Soyez honnête, l'écriture de tests automatisés prendra plus de temps. Si vous effectuez un TDD au niveau de l'unité (que je recommanderais comme point de départ si vous envisagez d'investir dans des tests automatisés), vous pouvez vous attendre à environ 30% de temps supplémentaire nécessaire pour coder une fonctionnalité. La clé ici est d'expliquer que ces 30% supplémentaires (qui sont probablement supérieurs à 30% au début lorsque votre équipe apprend à écrire de bons tests) est un investissement conçu pour réduire les coûts au fil du temps. Au moins avec le TDD au niveau de l'unité, la conception de votre système est faiblement couplée et hautement cohésive, ce qui rend votre système adaptable pour évoluer dans le temps. Les nouvelles exigences et les bogues inattendus nécessitent toujours des modifications de votre système,
2. Il y a beaucoup de débats sur la valeur des tests de niveau d'acceptation et de niveau d'interface utilisateur compte tenu du temps qu'il faut pour écrire ces tests, du temps qu'il faut pour les exécuter et de la quantité de maintenance dont ils ont besoin. Je recommanderais de lire cet article de James Shore à ce sujet.
3. Dans le monde des tests automatisés, il existe de bonnes et de mauvaises façons de le faire. Si vous présentez des tests automatisés à votre direction, je dirais à côté de quoi vous prévoyez de former votre équipe à la rédaction de bons tests. L'Art des tests unitaires de Roy Osherove, Working Effectively With Legacy Code de Michael Feathers et The Art of Agile Development de James Shore sont tous d'excellents livres qui traitent de ces sujets directement ou indirectement. Vous devriez également envisager une sorte d'entraîneur ou de formation officielle. C'est un grand changement.
4. En termes de valeur commerciale, les points 2 et 3 de vos points ci-dessus servent en fait votre premier point, alors je martellerais le point n ° 1 et parlerais de la façon dont les points 2 et 3 servent ce point plus important. La documentation rend votre système plus compréhensible, ce qui accélère le travail de votre équipe. La qualité du code rend votre système adaptable au changement, ce qui accélère le travail de votre équipe. Pour les gens d'affaires, il s'agit de maximiser le flux de valeur entre le moment où une idée est présentée et le moment où l'idée est livrée en tant que logiciel de travail.

Une chose d'une valeur certaine est que les tests d'automatisation peuvent être exécutés en continu; comme toutes les heures sur une reconstruction ou similaire. Cela force les bogues ou les régressions à sortir rapidement en quelques heures ou jours après qu'un programmeur travaille sur le code incriminé, ce qui facilite le changement de contexte. Le deuxième avantage des tests continus est qu'ils vous obligent à maintenir vos tests dans un état de fonctionnement; rien n'est plus fastidieux que de passer la première semaine d'un cycle de test à corriger tous les tests obsolètes. Si vous pouvez les automatiser, vous pouvez les exécuter à tout moment et en les exécutant régulièrement, vous pouvez détecter rapidement des bogues dans vos tests ou votre code.

Dépenses de test

Une fois qu'un test automatique est écrit, il peut être exécuté par un ordinateur au prix de quelques joules. Le test manuel équivalent exige qu'une personne sur la liste de paie rédige une liste d'instructions.

Fiabilité des tests

On peut faire confiance à l'ordinateur pour exécuter fidèlement la même procédure de test, à chaque fois. L'homme est susceptible de commettre des erreurs et de devenir paresseux.

Les modes d'échec des tests de l'ordinateur sont également beaucoup plus évidents - il s'est écrasé (les rapports de test cessent d'apparaître), il y avait une petite erreur qui a provoqué un faux résultat de test (exécutez à nouveau un test déterministe et le résultat diffère). Si un humain manque une étape et coche la case "OK", comment le savoir?

Durabilité du test

Un test automatisé doit être un artefact concret (par exemple un morceau de code) pour être exécuté et est naturellement inclus avec les autres artefacts de développement logiciel - le référentiel source. Un test manuel peut être développé sur une feuille de papier par un testeur, et jamais formalisé. L'entreprise est plus susceptible d'avoir besoin de processus en place pour garantir que cela ne se produise pas.

Valeur de test

L'ordinateur peut être programmé pour produire des résultats de test sous une forme cohérente et facilement analysable. La personne procède soit à la saisie de données pour les générer, soit enregistre des notes de forme libre qui nécessitent la digestion d'un analyste, d'un développeur ou d'un gestionnaire.

Surtout (en fonction de votre couverture de test) du code sans bogue, et je dirais que l'un des plus gros arguments est lorsque vous dites à votre responsable que vous pouvez écrire un test pour un bogue découvert, en vous assurant que vous saurez toujours à l'avenir si ce bug revient :)

Mon opinion est que les tests unitaires / d'intégration sont les plus importants, alors que si vous appliquez un modèle d'interface utilisateur comme MVC, cela suffit pour la plupart des projets. Je teste généralement toutes les actions sur mes contrôleurs / présentateurs et laisse la liaison de données aux vues.

Bien sûr, les tests automatisés ne remplacent pas le bon vieux point et cliquez sur l'aventure autour de votre application en essayant de comprendre les choses les plus folles que votre utilisateur pourrait faire.

Il y a aussi un point d' intégration continue .

Encore une chose - il faut s'efforcer que la qualité du code mène à la qualité du produit, à la valeur commerciale et à la maintenabilité - sinon cela ne sert à rien.

Je pense que vous devriez diriger avec les points magiques de "moindre coût" et "plus de fonctionnalités / temps unitaire" / temps de cycle plus petit.

Cependant, avant de présenter un dossier, je vous conseille de réfléchir à votre situation. Votre question m'a amené à écrire un article de blog sur les inconvénients potentiels des tests automatisés.

La facilité de refactoring est un facteur important ici. Ayant une bonne couverture par un test unitaire agréable et LISIBLE (!!!), vous pouvez refactoriser votre système sans être inquiet de compromettre les fonctionnalités existantes.

Vous devez vendre le concept - vous devez éviter de leur dire que cela améliorera le code. S'ils ont un investissement dans le code, ils seront immédiatement mis à l'essai contre vous / auto. S'ils sont bons, ils comprendront également GIGO et ne comprendront donc pas pourquoi vous pensez que cela ne s'applique pas.

Je laisserais aussi le vendre comme aspect de la documentation, des choses comme Fitnesse peuvent le faire bien, mais jusqu'à ce qu'ils le ressentent, il pourrait être difficile de le visualiser.

Des domaines qui pourraient avoir de la chance de le vendre

1. Les tests unitaires peuvent remplacer de nombreux faisceaux de développeurs - où vous créez une application juste pour accéder à la zone à déboguer / tester sans passer par tous les identifiants / menus.

2. Les tests vous permettent de configurer et de répéter facilement les situations problématiques - sans passer beaucoup de temps à configurer les données de test (en particulier en utilisant un système de simulation correct)

3. Lorsque vous créez des suites de tests BDD et d'interface utilisateur - vous obtenez une réponse beaucoup plus rapide s'il y a de simples interruptions que d'attendre la prochaine fois que le testeur l'examine

4. Les tests BDD et UI peuvent vous éviter d'appuyer plusieurs fois sur les boutons pour vérifier tous les aspects qui pourraient avoir été affectés par votre modification et vous éviter d'avoir à vous souvenir de tous les domaines.

5. Les builds automatiques mettent souvent en évidence quand quelqu'un a oublié de vérifier le code

6. Les tests vous aident à éviter la réapparition des bogues.

7. Les tests unitaires et les moqueries décentes signifieront moins de code interconnecté et seront plus faciles à résoudre

N'oubliez pas que vous essayez de le vendre, pas de les convertir en religion - alors acceptez les petits pas et essayez de ne pas les faire vous empêcher. Il leur faudra également du temps pour s'adapter et apprendre à écrire de bons tests.

Quelqu'un doit croire qu'il y a un problème avant d'accepter une proposition de solution à ce problème.

Les tests automatisés peuvent réduire les coûts de résolution de bogues, donc si vos collègues ne croient pas que les coûts de résolution de bogues sont importants ou excessifs, ils seront difficiles à convaincre. Si ces coûts sont élevés ou excessifs, mais que les gens ne le croient pas, vous devrez peut-être d'abord obtenir des données convaincantes sur ces coûts.

Ce que les entreprises aiment, c'est augmenter la valeur et réduire les coûts. Vous devez expliquer comment les tests automatisés augmenteront la valeur car ils ajoutent un coût supplémentaire.

Si votre code est modulaire, il sera possible de le réutiliser. Ce qui signifie que les tests n'ont pas à être réécrits à nouveau et vous pouvez simplement travailler au-dessus de ce code existant.

S'il existe des projets hérités, les tests automatisés facilitent la refactorisation. La dette technique doit être remboursée à un moment donné.

L'argument de documentation que vous fournissez n'est pas très bon. La différence entre maintenir les tests à jour et la documentation à jour n'est qu'une habitude.

"Ce que je recherche, c'est exprimer sa valeur à une équipe de programmeurs, d'analystes, de gestionnaires et de testeurs. Par des tests automatisés, je ne pense pas avoir besoin de faire une distinction entre les tests unitaires (par exemple JUnit), BDD ( par exemple JBehave, Fitness) et UI (Selenium, Watir) parce que je pense qu'ils offrent tous une valeur similaire (mais n'hésitez pas à écrire une réponse qui n'est pas d'accord :)) "

OK je vais relever ce défi;)

Je travaille principalement avec des programmeurs et QA et mes outils sont rubis, rails, testunit, rspec, jasmine et sélénium.

Les outils BDD / TDD de rspec et testunit font partie de la programmation. Vous ne les décomposez pas et n'en parlez pas séparément à la direction, vous ne les remettez pas par manque de temps, vous les incluez dans toutes vos estimations de temps. Si vraiment poussé, vous avez demandé combien de temps les gens ont pour vous leur expliquer l'informatique et la programmation. Je n'utilise pas ces tests pour le front-end

GUI / UI / Jasmine / Selenium. Ce sont différents. Je les ai faites par des gens de QA qui ont des antécédents de programmeur. Nous nous assurons que les tests sont écrits pour être aussi robustes que possible et basés sur le contenu et non sur la présentation. Le coût (éventuellement nouveau) de cela devrait être expliqué comme un coût décalé . Au lieu de payer avec un logiciel cassé, des clients perdus et des correctifs coûteux plus tard, vous payez beaucoup moins (relativement) maintenant avec quelques pratiques simples.

Je pense que la clé est de parler de catégories spécifiques de tests que vous allez créer, et non de «tests automatisés» dans leur ensemble. Ce dernier peut être un peu nébuleux et inquiétant, et il est trop facile de trouver des exemples où ce serait une perte de temps.

Je recommande toujours de diviser vos tests en 4 groupes (plus de détails ici ). Restez avec moi ici, je vais voir comment cela vous aide à vendre des tests à d'autres dans un instant.

1. Tests de votre fonctionnalité principale . C'est-à-dire que pour un outil de surveillance de site Web, il s'agirait de tests d'alertes qui devraient se déclencher pour les sites Web que vous surveillez. Ces tests s'assurent que ce truc ne casse jamais.
2. Tests de fumée de toute votre application . Par exemple, utiliser Selenium pour parcourir tous les liens / boutons dans une application Web et vous assurer qu'il n'y a aucune erreur du serveur. Ces tests vous évitent de perdre du temps avec des versions évidemment cassées.
3. Tests de tout code fragile . C'est-à-dire, pour cet ancien module que personne ne veut jamais toucher, ou le morceau de code complexe qui semble toujours contenir des bogues.
4. Tests que les développeurs voulaient écrire pour soutenir leur travail . Parce que parfois les tests sont utiles lorsque vous écrivez quelque chose, mais ne tombez pas dans les catégories ci-dessus.

En répartissant vos tests dans ces catégories, vous pouvez maintenant avoir une discussion différente. Prenez les trois premiers groupes (le quatrième est à la discrétion des individus de toute façon) et demandez si les gens pensent que des tests pour ces morceaux de code en valent la peine? Si vous ne parvenez pas à un accord, peut-être que vous n'incluez pas ces tests pour l'instant. Si vous le pouvez, c'est-à-dire si les gens conviennent que les tests sur les fonctionnalités de base qui sont exécutées sur chaque commit sont utiles, alors commencez à les ajouter.

L'autre groupe qui peut être utile est celui des tests qui sont difficiles ou longs à faire manuellement . Il devrait y avoir un avantage assez facile à expliquer ici en termes de gain de temps de test manuel, ou de faire tester des choses qui sont ignorées par manque de temps.