Je prépare une présentation sur les tests unitaires aux gestionnaires. Mon équipe a écrit des tests unitaires depuis des années, mais d'autres domaines de la société semblent avoir du mal à l'adopter. Je peux obtenir des développeurs excités à ce sujet, mais s'il n'y a pas de buy-in de la direction, il ne deviendra pas une norme.
Est-ce que vous avez des suggestions sur la meilleure gestion de l'approche à ce sujet? Quelles sont les choses que vous avez essayées dans le passé qui fonctionnait? Quelles sont les choses qui n'ont pas fonctionné?
12 Réponses :
Dites-leur que cela rend le code plus maintenu et les sauvera de l'argent à long terme. Il réduit également les bugs, si cela est fait correctement.
Ainsi, en d'autres termes, il réduit les coûts et augmente la fiabilité du logiciel.
Pour construire sur @HVGotCodes Réponse, ne leur disons pas comment cela rend les choses meilleures, compilez des statistiques de votre propre équipe de la façon dont il a
Surtout les coûts, les entreprises aiment économiser de l'argent :)
Bien que je suis d'accord avec la suggestion en principe, cela pourrait être une vente difficile si vous n'avez pas de bonnes données des deux avant et après la mise en œuvre des tests de l'unité.
@Greenmatt - assez vrai. Une fois, j'ai fait la même chose que l'OP et quand j'étais à mi-chemin, je me suis arrêté pour des questions. La direction a déclaré 'sonne fantastique. Avez-vous des chiffres? Je ne l'ai pas fait, et non seulement ils tuèrent l'élan d'une autre équipe, mais nous avons fait de l'échelle américaine temps passé sur les tests de développeurs. Finalement, nous sommes passés à la pleine sur 'Laissez QA Trouver des bugs' et je suis parti :)
test unitaire, s'il est bien fait, est censé
Y a-t-il des statistiques pertinentes recueillies au sein de votre entreprise qui peuvent baser ces réclamations concrètement? C'est à dire. Nombre de bogues trouvés par QA / utilisateurs dans différents produits, ou des coûts moyens de la mise en œuvre de la bugFix / Feature, ...
Ne pas induire en erreur.
Lorsque vous citez les coûts réduits, vous impliquez que le coût de l'assurance qualité et un refactoring plus facile est supérieur au prix de la création et de la maintenance des tests. Il serait bon de signaler cela et d'essayer de mettre en place des métriques pour renforcer votre point.
Le problème est que vous ne pouvez pas mettre de valeur en dollars sur le chemin non pris ("nous avons évité de 1 000 défauts qui auraient coûté 1 million de dollars à réparer!").
Mais vous devriez être à la hauteur du fait qu'il y a un coût pour créer les tests, et ils doivent être maintenus. Si vous les créez et que vous les laissez tomber dans le disrapir, vous êtes tout aussi mauvais.
Votre argument recevra un coup de pouce lorsque vous allez ajouter de nouvelles fonctionnalités et il est plus facile, car vous avez conservé le code propre.
Pour les responsables non-technologiques, je suis tombé sur une analogie de la construction d'une maison. Seraient-ils en construisant un sans planprints, en prenant des briques d'une pile et de mettre un au sommet de l'autre avec une vague idée en forme de maison? Sinon, pourquoi ne accepteront-ils pas de documentation appropriée avant de coder, de design de conception, etc.
Pour le test de l'unité, vous pouvez essayer de comparer celui-ci à la qualité testant les différentes composantes de la maison individuellement avant de les mettre ensemble (briques, ciment, portes, fenêtres, plomberie)
Pour ceux qui possèdent du tout une tâche technologique, je mentionne que 30% à 50% gère les conditions d'erreur et la récupération (dans des systèmes intégrés critiques de mission) et que vous ne pouvez tout simplement pas tester sans tester unité. Par exemple, si vous avez uniquement le test d'intégration Blackbox, alors comment pouvez-vous - de manière contrôlée et répétable, ce qui se passe lorsque le module A ne peut pas allouer de la mémoire à un point donné, ou un délai d'expiration expire profondément dans le module C lorsque vous attendez un message de réponse de quelque part ou une base de données lu qui réussira normalement. Expliquez cela en sortant des modules d'interfaçage, vous pouvez simuler leur comportement erroné à volonté.
Et, bien sûr, je dessine mon graphique favoriite avec un symbole $ sur un axe et une horloge de l'autre. J'ai battu la direction sur la tête avec cela à chaque occasion pour montrer que le coût d'obtenir des bugs augmente plus tard, ils sont découverts ultérieurement (changez une ligne dans une exigence spécifique - 5 minutes; Quelques paras dans une conception DOC-heures; plusieurs 100 Lignes de code (à la révision du code ou étape de test de l'unité) - Jours; trouver l'aiguille dans un bogue de foin et le corriger au test système - semaines).
Ce n'est pas simplement un test unitaire - vous devez convaincre la direction - et vos collègues développeurs - que les «frais généraux inutiles» de la documentation, des critiques, des tests ... S / W sont en général (et cela inclut l'apprentissage de nouveaux outils). .. réellement économise du temps plutôt que d'ajouter du temps à un projet. En d'autres termes, il faut plus de temps et coûte plus cher pour le faire mal. Mesurer deux fois, couper une fois, etc
Pour le test de l'unité, dites-leur de Intégration continue . Je recommande vivement Jenkins, mais j'utilise tout ce qui fonctionne pour vous. Expliquez qu'une construction régulière, que ce soit de la soirée ou de chaque enregistrement, pouvez-vous tirer automatiquement des tests d'unité de votre VCS et de les exécuter, d'envoyer des courriels ou d'alerter autrement au nouveau code qui a rompu des tests existants presque dès que cela se produise.
Si rien de cela ne fonctionne, recherchez un nouvel emploi (si vous êtes à Singapour ou que vous voulez être, parlez-moi; -)
J'ai maintenant commuté mon allégeance de Hudson à Jenkins Jenkins-ci.org
Je pense que les statistiques feraient le meilleur des affaires en ce qui concerne les gestionnaires non techniques. Code complet, 2e éd. a un résumé de Quelques études montrant que les tests d'unités entraînent une moyenne de taux de détection de défaut de 30% (tableau 20-2, P 470). Je pense qu'il devrait être facile de le prendre à partir de là et de faire en sorte que moins de bugs se traduisent par plus d'argent économisé.
Dans certains cas, j'ai constaté que l'attente de la bonne opportunité est la clé.
Par exemple, dans un cas, j'ai attendu jusqu'à ce qu'il y ait un site chaud avec un client. C'était très douloureux (pense $$$). L'une des questions inévitables posées par la direction de la haute direction était la manière d'éviter le même problème à l'avenir. Et c'est lorsque j'ai présenté des tests unitaires à la gestion ...
Donc, je suppose que cela dépend beaucoup des circonstances.
montrez-leur un exemple de l'endroit où les tests ont déjà pris un problème et sauvé la journée.
De même, j'ai écrit une nouvelle fonctionnalité il y a quelques années qui était l'une de ces zones comportant de nombreuses affaires de coin très fidèques, de sorte que la fixation de celle-ci constituerait probablement une partie des autres. J'ai utilisé une méthode de test de l'unité / TDD pour elle et dans 5 ans, pas un seul bogue n'en a été trouvé car ils étaient tous pris au développement. Comparez cela avec d'autres fonctionnalités qui n'étaient pas testées de l'unité et devaient être fixées de temps après.
Je peux trouver Beaucoup de cas lorsque nous avons presque perdu des clients de plusieurs millions de dollars pour des cas d'angle simples qui auraient pu être testés en quelques minutes avant même le développement de gauche. Je pourrais même essayer de déterrer le code de SVN et d'écrire un test pour cela et de le voir échouer. Bien sûr, ce code sera probablement un gâchis donc du test unitaire. Je vais toujours creuser un peu à faire quelque chose comme ça. Cela montrerait vraiment le contraste entre la facilité d'accueil auparavant par rapport à la difficulté et à la coûteuse.
J'ajouterai à cela que vous pouvez également leur montrer un cas où le test de contrôle de l'unité a énuméré énormément le développement de code. Mon exemple est de retour quand je travaillais un système de rapport. Vers la fin du développement, le produit a soudainement décidé que tout devait être fait dans l'Est au lieu de GMT (GMT facilite le code). Comme nous avions eu un code bien testé, nous pourrions faire les changements dont nous avions besoin avec beaucoup moins de peur que nous avons manqué un morceau de code quelque part qui devait être mis à jour.
Si possible, j'essaierais de fournir des exemples du monde réel de la difficulté que votre entreprise a été confrontée dans le passé lors de la prise en charge du code en direct sans tests. Ensuite, continuez à mettre en évidence avec des exemples spécifiques que la réduction des coûts de soutien des mises à jour et des correctifs avait été mise en place.
bonne chance et laissez-nous savoir comment vous allez sur. :)
BDD et TDD ont des hauts utiles qui sont facilement comprises par des non-techniciens. En fait, l'un de leurs principaux avantages est qu'ils se concentrent sur le non technique.
Test unitaire, d'autre part, est un concept technique qui peut être très abstrait au non-programmeur. Testez votre code? Tu ne fais-tu pas ça en se développant? Pourquoi payons-nous pour le personnel de test? Et ainsi de suite.
1 - Est-ce qu'ils ont besoin de savoir, ou même d'approuver? Vous êtes l'ingénieur et vous savez mieux que d'eux comment construire des choses qui fonctionne, elles ne doivent donc vraiment pas interférer. Souhaitez-ils-ils des outils et quelles méthodes d'assurance qualité / de sécurité avez-vous utilisées si c'était un nouveau modèle de voiture que vous avez construit pour eux? Ne le penserais pas.
2 - Le coût des défauts est très élevé. La qualité médiocre, les défauts et la dette technique sont un risque de projet très grave susceptible de compromettre l'ensemble des investissements d'un projet logiciel. La prévention des défauts est facilement plus rentable que la détection des défauts (de nombreux multiples selon des études). Les tests d'unités ont la boucle de rétroaction la plus courte possible, évite ainsi la faible qualité de projet systématique et réduit considérablement le risque de projet.
3 - Vous ne pouvez pas aller vite sur une longue période sans faible taux de défaut - AKA, investissant des battements dépenses / spéculations (celles-ci devraient obtenir).
Dessinez une analogie à quelque chose que les gestionnaires utilisent probablement régulièrement - comme un vérificateur orthographique dans leur client de messagerie ou son éditeur de documents ....
Comme pour toute persuasion - montrez-leur pourquoi ce que vous suggère de suggérer est dans leur inète.