Comment convaincre un sponsor de projet que toutes les fonctions de votre code doivent avoir des tests unitaires [fermé]

Question

Dans la plupart des cas, les personnes non techniques ne voient aucune valeur à écrire des tests unitaires.Ils veulent juste que le code de base soit terminé et ne dépensent pas d'argent ni de temps sur des choses comme les tests unitaires.Plus tard, chaque jour, ils demandent simplement de corriger un bug supplémentaire.Les projets ne respectent pas les délais et ne voient toujours pas l'intérêt de bons tests automatisés.

Answer 1

Le meilleur moyen est de ne pas devenir aussi technique avec des personnes « non techniques ».Intégrez-le simplement au délai de livraison sans entrer dans les détails.

D’un autre côté, il semble que les délais du projet n’étaient pas réalistes pour le construire.

Answer 2

je viens de écrit longuement sur ce même sujet.

Pour résumer mes arguments contre les plaintes courantes :

Le nettoyage est invisible pour les utilisateurs ;nous devons ajouter de nouvelles fonctionnalités.Les bogues constamment produits par un code désordonné sont également visibles pour les utilisateurs.Le temps passé à corriger ces bugs aurait pu être consacré à l'ajout de fonctionnalités.Plus nous restons longtemps dans une dette de qualité, plus il faut de temps pour ajouter chaque nouvelle fonctionnalité.

Nous n'avons pas le temps de faire le ménage.Vous préférez passer votre temps à corriger les bugs générés par le problème plutôt que de régler le problème ?C'est comme détruire les mauvaises herbes chaque week-end au lieu de les arracher par les racines.La prévention est seize fois plus précieuse que la guérison.

Les développeurs se sont retrouvés dans ce pétrin ;ils devraient s'en sortir à leur rythme.Si les développeurs n'avaient pas publié les versions aussi rapidement qu'ils l'ont fait, s'ils n'avaient pas répondu aussi rapidement aux commentaires des premiers utilisateurs, même lorsque le produit s'est transformé en une bête très différente de sa conception originale, nous n'aurions pas nos clients et nos revenus actuels. .Nous travaillerions pour une autre entreprise, sans nous plaindre du logiciel que nous avons créé.

À l'attention des PDG :Le fait de pointer du doigt entrave la résolution.Mettez plutôt vos développeurs au défi de réduire les rapports de bogues.Ceci est facilement mesurable, vous pouvez donc suivre le temps passé par rapport aux résultats.N'oubliez pas que les développeurs préfèrent implémenter de nouvelles fonctionnalités plutôt que corriger les bugs, donc s'ils demandent du temps pour corriger les bugs, c'est sérieux.

Answer 3

Essayez d'utiliser un analogue.Demandez-leur s'ils aimeraient que leurs enfants conduisent des Volvo ou des voitures Kit fabriquées par un type dans la rue.La réponse devrait toujours être la Volvo.Alors demandez pourquoi ?La réponse est qu’elle est plus fiable et plus sûre.Comment le savent-ils.La réponse est de tester.Toutes les automobiles sont testées à l’extrême et le coût le reflète.S'ils veulent que leur logiciel soit aussi fiable que possible, ils ont besoin de tests.(Ou ils deviennent les mannequins des crash tests)

Answer 4

Eh bien, je pense que le problème est que vous dites "toutes les fonctions".Toutes les fonctions n'ont pas besoin de tests unitaires, et certains diraient que les tests unitaires de fonctions individuelles sont carrément erronés dans de nombreux scénarios.

Au lieu de cela, je recommande de tester les véritables « unités de fonctionnalité ».Au lieu d'écrire un seul test pour chaque fonction, écrivez un test pour chaque scénario ou fonctionnalité.En plus de vous faire gagner beaucoup de temps et de vous permettre de passer les tests sous le radar, il est souvent beaucoup plus précis car il teste littéralement les fonctions telles qu'elles sont utilisées.Trop souvent, les tests unitaires fonction par fonction ne testent pas la bonne chose, ou pire encore, des tests simulés.

Je vous recommande d'éviter à tout prix d'utiliser des simulations lors des tests.L'utilisation d'une simulation invalide essentiellement le test car vous testez son fonctionnement dans des circonstances idéalisées au lieu de son fonctionnement dans le monde réel.

Un avantage secondaire est que vous bénéficiez également d’une meilleure détection des codes morts.Tout code qui n'est pas couvert par un test de haut niveau n'est probablement pas utilisé et peut être supprimé.Ne sous-estimez jamais la valeur de l’élimination du code mort.

Answer 5

Vendre des tests unitaires complets une fois le développement déjà commencé est très dur.J'irais même jusqu'à dire que c'est souvent impossible.Si vous n'obtenez pas l'adhésion de toutes les parties prenantes du projet pour des tests unitaires complets dès le départ, vous devriez alors être satisfait des tests unitaires auxquels vous pouvez participer.

Answer 6

Ce n'est pas le cas.Les tests ne doivent pas être écrits séparément, il n'est donc pas plus nécessaire d'en tenir compte dans le calendrier que de planifier spécifiquement la "compilation" ou la "saisie du code".Tout temps passé à rédiger les tests doit de toute façon être compensé par le temps qu'ils vous font gagner.

Answer 7

Fais-le c'est tout.Vous serez plus lent au début à mesure que vous écrivez plus de code et que vous réfléchissez d'abord au problème.Mais vous passerez rapidement les autres sur le projet car vous avez moins d'erreurs/bugs et votre conception est meilleure.

Si vous concevez le système en pensant aux tests, il s'agira d'une conception intrinsèquement plus flexible qu'une conception non testable.Il sera alors plus rapide d’ajouter des fonctionnalités à l’avenir.

Answer 8

@Craig, j'ai aussi pensé à l'analogue de la voiture, mais je pense que l'analogie s'effondre car il semble qu'il y ait déjà des tests présents dans le projet et c'est simplement une question de degré.Dans ce cas, l'analogie avec la voiture devient « Cela vous importe-t-il si le plafonnier de la voiture est testé tant que les systèmes critiques (freins, phares, transmission, etc.) sont testés ».En tant que sponsor de projet pressé qui voit le projet dépasser sa date de fin, je m'en fiche vraiment de savoir si le plafonnier est testé ou non.

Answer 9

Un bon moyen de vendre la valeur des tests unitaires est du point de vue du support : si vous utilisez un framework de tests unitaires dont le runtime peut être déployé (nUnit en est un), vous pouvez avoir un élément de menu "Exécuter les tests unitaires". dans votre menu d'aide.Cela peut exécuter tous les tests unitaires et les résultats peuvent être envoyés au support technique pour aider à déboguer les problèmes des clients.

Évidemment, il existe de nombreuses façons de vendre la stabilité accrue, mais le support technique est un coût « en argent réel » que la plupart des gestionnaires voudraient réduire.