Comment faire écrire des tests aux programmeurs juniors? [fermé]

Nous avons un programmeur junior qui n'écrit tout simplement pas assez de tests.
Je dois le harceler toutes les deux heures, "avez-vous des tests?"
Nous avons essayé:

• Montrer que le design devient plus simple
• Le montrer empêche les défauts
• En faire une chose d'ego en disant que seuls les mauvais programmeurs ne le font pas
• Ce week-end, 2 membres de l'équipe ont dû venir travailler car son code avait une référence NULL et il ne l'a pas testé

Mon travail nécessite un code stable de qualité supérieure, et généralement tout le monde le `` comprend '' et il n'est pas nécessaire de pousser les tests. Nous savons que nous pouvons lui faire écrire des tests, mais nous savons tous que les tests utiles sont ceux écrits lorsque vous y êtes.

Connaissez-vous d'autres motivations?

C'est l'une des choses les plus difficiles à faire. Amener vos employés à l' obtenir .

Parfois, l'un des meilleurs moyens d'aider les programmeurs de niveau junior à «comprendre» et à apprendre les bonnes techniques auprès des seniors est de faire un peu de programmation en binôme.

Essayez ceci: sur un projet à venir, associez le jeune avec vous ou un autre programmeur senior. Ils devraient travailler ensemble, à tour de rôle «conduire» (étant celui qui tape au clavier) et «encadrer» (regarder par-dessus l'épaule du conducteur et signaler les suggestions, les erreurs, etc. au fur et à mesure). Cela peut sembler un gaspillage de ressources, mais vous trouverez:

1. Que ces gars-là ensemble puissent produire beaucoup de code rapidement et de meilleure qualité.
2. Si votre jeune homme en apprend suffisamment pour "comprendre" avec un senior qui le dirige sur la bonne voie (par exemple, "Ok, maintenant avant de continuer, écrivons au test pour cette fonction.") Cela vaudra bien les ressources que vous s'engager à le faire.

Peut-être que quelqu'un de votre groupe donne également la présentation Unit Testing 101 de Kate Rhodes, je pense que c'est un excellent moyen de susciter l' intérêt des gens pour les tests, s'ils sont bien livrés.

Une autre chose que vous pouvez faire est de demander à vos développeurs juniors de pratiquer le jeu de bowling Kata, ce qui les aidera à apprendre le développement piloté par les tests. Il est en java, mais pourrait facilement être adapté à n'importe quelle langue.

Faites une révision du code avant chaque commit (même si c'est une minute "J'ai changé ce nom de variable"), et dans le cadre de la révision du code, passez en revue les tests unitaires.

Ne vous déconnectez pas du commit tant que les tests ne sont pas en place.

(Aussi - Si son travail n'a pas été testé - pourquoi était-il dans une version de production en premier lieu? Si ce n'est pas testé, ne le laissez pas entrer, vous n'aurez pas à travailler le week-end)

Pour ma part, j'ai commencé à insister pour que chaque bogue que je trouve et corrige soit exprimé sous forme de test:

1. "Hmmm, ce n'est pas juste ..."
2. Trouver un problème éventuel
3. Ecrire un test, montrer que le code échoue
4. Résoudre le problème
5. Montrer que le nouveau code passe
6. Boucle si le problème d'origine persiste

J'essaie de faire cela même en tapant des trucs, et j'arrive à peu près en même temps, seulement avec une suite de tests partiels déjà en place.

(Je ne vis pas dans un environnement de programmation commerciale et je suis souvent le seul codeur à travailler sur un projet particulier.)

Imaginez que je suis un programmeur simulé, nommé ... Marco. Imaginez que j'ai obtenu mon diplôme il n'y a pas si longtemps et que je n'ai jamais vraiment eu à passer de tests. Imaginez que je travaille dans une entreprise qui n'applique pas vraiment cela ou qui le demande. D'accord? bien! Imaginez maintenant que l'entreprise passe à l'utilisation de tests et qu'elle essaie de m'informer. Je vais donner une réaction quelque peu sournoise aux éléments mentionnés jusqu'à présent, comme si je n'avais fait aucune recherche à ce sujet.

Commençons par le créateur:

Montrer que le design devient plus simple.

Comment écrire plus, rendre les choses plus simples. Je devrais maintenant garder un œil sur l'obtention de plus de cas, etc. Cela rend les choses plus compliquées si vous me le demandez. Donnez-moi des détails solides.

Le montrer empêche les défauts.

Je le sais. C'est pourquoi ils sont appelés tests. Mon code est bon et je l'ai vérifié pour les problèmes, donc je ne vois pas où ces tests pourraient aider.

En faire une chose d'ego en disant que seuls les mauvais programmeurs ne le font pas.

Ohh, donc vous pensez que je suis un mauvais programmeur simplement parce que je ne fais pas autant de tests usagés. Je suis insulté et franchement énervé contre vous. Je préférerais avoir de l'aide et du soutien plutôt que des paroles.

@ Justin Standard : Au début de la nouvelle paire de propect, le junior avec vous-même ou un autre programmeur senior.

Ohh, c'est tellement important que des ressources seront dépensées pour m'assurer que je vois comment les choses sont faites, et que quelqu'un m'aide sur la façon dont les choses sont faites. Ceci est utile et je pourrais peut-être commencer à le faire davantage.

@ Justin Standard : Lisez la présentation des tests unitaires 101 de Kate Rhodes.

Ahh, c'était une présentation intéressante, et cela m'a fait penser aux tests. Il a martelé certains points que je devrais considérer, et cela aurait peut-être un peu influencé mon point de vue.

J'adorerais voir des articles plus convaincants et d'autres outils pour m'aider à penser que c'est la bonne façon de faire les choses.

@ Dominic Cooney : Passez du temps et partagez les techniques de test.

Ahh, cela m'aide à comprendre ce que l'on attend de moi en ce qui concerne les techniques, et cela met plus d'articles dans mon sac de connaissances, que je pourrais utiliser à nouveau.

@ Dominic Cooney : Répondez aux questions, aux exemples et aux livres.

Avoir une personne-ressource (personnes) pour répondre à la question est utile, cela pourrait me rendre plus susceptible d'essayer. Les bons exemples sont excellents, et cela me donne quelque chose à viser et quelque chose à rechercher comme référence. Les livres qui sont directement pertinents à ce sujet sont une excellente référence.

@ Adam Hayle : examen surprise.

Dites quoi, vous avez créé quelque chose pour lequel je ne suis pas du tout préparé. Je me sens mal à l'aise avec cela, mais je ferai de mon mieux. Je vais maintenant avoir peur et un peu d'appréhension à l'idée que cela se reproduise, merci. Cependant, la tactique de peur a peut-être fonctionné, mais elle a un coût. Cependant, si rien d'autre ne fonctionne, c'est peut-être simplement la poussée nécessaire.

@ Rytmis : Les éléments ne sont considérés comme terminés que lorsqu'ils ont des cas de test.

Ohh, intéressant. Je vois que je dois vraiment faire ça maintenant, sinon je ne termine rien. C'est logique.

@ jmorris : se débarrasser / sacrifier.

éblouissements, éblouissements, éblouissements - Il y a une chance que j'apprenne, et avec du soutien et de l'aide, je peux devenir une partie très importante et fonctionnelle des équipes. C'est l'un de mes handicaps maintenant, mais ce ne sera pas pour longtemps. Cependant, si je ne comprends tout simplement pas, je comprends que j'irai. Je pense que je l'obtiendrai.

Au final, le soutien de mon équipe a joué un grand rôle dans tout cela. Le fait qu'une personne prenne son temps pour m'aider et m'initier à de bonnes habitudes est toujours le bienvenu. Ensuite, avoir un bon réseau de soutien serait génial. Il serait toujours apprécié que quelqu'un vienne quelques fois par la suite, et passe en revue un peu de code, pour voir comment tout se passe, pas dans un examen en soi, mais plutôt comme une visite amicale.

Raisonnement, préparation, enseignement, suivi, soutien.

J'ai remarqué que beaucoup de programmeurs voient la valeur des tests à un niveau rationnel. Si vous avez entendu des choses comme "ouais, je sais que je devrais tester ça mais j'ai vraiment besoin de faire ça rapidement" alors vous savez ce que je veux dire. Cependant, sur le plan émotionnel, ils ont le sentiment d'accomplir quelque chose uniquement lorsqu'ils écrivent le vrai code.

Le but, alors, devrait être de leur faire comprendre d'une manière ou d'une autre que les tests sont en fait le seul moyen de mesurer quand quelque chose est «fait», et de leur donner ainsi la motivation intrinsèque d'écrire des tests.

J'ai bien peur que ce soit beaucoup plus difficile que cela ne devrait l'être. Vous entendrez beaucoup d'excuses du type "Je suis vraiment pressé, je vais réécrire / refactoriser ceci plus tard, puis ajouter les tests" - et bien sûr, le suivi ne se produit jamais car, étonnamment, ils sont tout aussi occupés la semaine prochaine .

Voici ce que je ferais:

• Première sortie ... "nous allons faire ce projet ensemble. Je vais écrire les tests et vous allez écrire le code. Faites attention à la façon dont j'écris les tests, car c'est comme ça que nous faisons les choses ici et c'est ce que j'attends de vous. "

• Après ça ... "Vous avez terminé? Génial! Voyons d'abord les tests qui conduisent votre développement. Oh, pas de tests? Faites-moi savoir quand cela sera fait et nous replanifierons en regardant votre code. Si vous" Vous avez besoin d’aide pour formuler les tests, faites le moi savoir et je vous aiderai. »

Il fait déjà ça. Vraiment. Il ne l'écrit tout simplement pas. Pas convaincu? Regardez-le parcourir le cycle de développement standard:

• Écrivez un morceau de code
• Compilez-le
• Cours pour voir ce qu'il fait
• Écrivez le morceau de code suivant

L'étape n ° 3 est le test. Il fait déjà des tests, il le fait simplement manuellement. Posez-lui cette question: "Comment savez-vous demain que le code d'aujourd'hui fonctionne toujours?" Il répondra: "C'est une si petite quantité de code!"

Demandez: "Et la semaine prochaine?"

Lorsqu'il n'a pas de réponse, demandez: "Comment aimeriez-vous que votre programme vous dise quand un changement rompt quelque chose qui a fonctionné hier?"

C'est ça le test unitaire automatique.

En tant que programmeur junior, j'essaie toujours de prendre l'habitude d'écrire des tests. Évidemment, ce n'est pas facile de prendre de nouvelles habitudes, mais en réfléchissant à ce qui ferait que cela fonctionne pour moi, je dois +1 les commentaires sur les révisions de code et le coaching / la programmation en binôme.

Il peut également valoir la peine de souligner l'objectif à long terme des tests: s'assurer que ce qui a fonctionné hier fonctionne toujours aujourd'hui, la semaine prochaine et le mois prochain. Je dis seulement cela parce qu'en parcourant les réponses, je n'ai pas vu cela mentionné.

En faisant des révisions de code (si vous décidez de le faire), assurez-vous que votre jeune développeur sait qu'il ne s'agit pas de le rabaisser, mais d' améliorer le code. Parce que de cette façon, sa confiance est moins susceptible d'être endommagée. Et c'est important. D'autre part, sachez à quel point vous en savez peu.

Bien sûr, je ne sais vraiment rien. Mais j'espère que les mots ont été utiles.

Edit: [ Justin Standard ]

Ne vous rabaissez pas, ce que vous avez à dire est à peu près juste.

En ce qui concerne les révisions de code, vous constaterez que non seulement les développeurs juniors apprendront au cours du processus, mais aussi les réviseurs. Tout le monde dans une révision de code apprend si vous en faites un processus collaboratif.

Franchement, si vous avez à mettre que beaucoup d' efforts pour lui faire faire quelque chose , alors vous pourriez avoir à composer avec la pensée qu'il peut tout simplement pas être un bon moyen pour l'équipe, et peut avoir besoin d'aller. Maintenant, cela ne signifie pas nécessairement le congédier ... cela peut signifier trouver ailleurs dans l'entreprise ses compétences sont plus adaptées. Mais s'il n'y a pas d'autre endroit ... vous savez quoi faire.

Je suppose qu'il est également un nouvel employé (<1 an) et probablement récemment sorti de l'école ... auquel cas il n'est peut-être pas habitué à la façon dont les choses fonctionnent dans une entreprise. Des choses comme ça, la plupart d'entre nous pourraient s'en tirer à l'université.

Si tel est le cas, une chose que j'ai trouvée fonctionne est d'avoir une sorte de «revue surprise des nouveaux employés». Ce n'est pas grave si vous ne l'avez jamais fait auparavant ... il ne le saura pas. Asseyez-le simplement et dites-lui que vous allez revoir sa performance et lui montrer des chiffres réels ... prenez votre feuille de révision normale (vous avez un processus de révision formel, n'est-ce pas?) Et changez le titre si vous le souhaitez pour qu'il en ait l'air officiel et montrez-lui où il en est. Si vous lui montrez dans un cadre très formel que ne pas faire de tests affecte négativement sa performance au lieu de simplement le «harceler» à ce sujet, il comprendra avec un peu de chance. Vous devez lui montrer que ses actions l'affecteront réellement, que ce soit en termes de rémunération ou autrement.

Je sais, vous voudrez peut-être éviter de faire cela parce que ce n'est pas officiel ... mais je pense que vous avez des raisons de le faire et que ce sera probablement beaucoup moins cher que de devoir le renvoyer et de recruter quelqu'un de nouveau.

En tant que programmeur junior moi-même, je pensais que je révélais ce que c'était quand je me suis retrouvé dans une situation similaire à votre développeur junior.

Quand je suis sorti pour la première fois de l'université, j'ai découvert que cela ne m'avait pas du tout équipé pour faire face au monde réel. Oui, je connaissais quelques bases de JAVA et une certaine philosophie (ne demandez pas) mais c'était à peu près tout. Quand j'ai eu mon travail pour la première fois, c'était un peu intimidant pour dire le moins. Permettez-moi de vous dire que j'étais probablement l'un des plus grands cow-boys du moment, je piraterais un petit correctif / algorithme de bogue sans commentaires / tests / documentation et l'expédierais à la porte.

J'ai eu la chance d'être sous la supervision d'un programmeur senior aimable et très patient. Heureusement pour moi, il a décidé de s'asseoir avec moi et de passer 1 à 2 semaines à parcourir mon code de groupe très piraté. Il expliquait où je m'étais trompé, les subtilités de c et des pointeurs (ce garçon m'a confondu!). Nous avons réussi à écrire une classe / module assez décent en une semaine environ. Tout ce que je peux dire, c'est que si le développeur senior n'avait pas investi le temps de m'aider sur la bonne voie, je n'aurais probablement pas duré très longtemps.

Heureusement, 2 ans plus tard, j'espère que certains de mes collègues pourraient même me considérer comme un programmeur moyen.

Ramenez des points à la maison

1. La plupart des universités préparent très mal les étudiants au monde réel
2. La programmation jumelée m'a vraiment aidé. Cela ne veut pas dire que cela aidera tout le monde, mais cela a fonctionné pour moi.

Attribuez-les à des projets qui ne nécessitent pas de "code stable de qualité supérieure" si c'est votre souci et laissez le jr. le développeur échoue. Demandez-leur de «venir le week-end» pour corriger leurs bogues. Déjeunez beaucoup et parlez des pratiques de développement logiciel (pas des conférences, mais des discussions). Avec le temps, ils acquerront et développeront les meilleures pratiques pour accomplir les tâches qui leur sont assignées.

Qui sait, ils pourraient même proposer quelque chose de mieux que les techniques que votre équipe utilise actuellement.

Si le programmeur junior, ou n'importe qui, ne voit pas la valeur des tests, alors il sera difficile de les amener à le faire ... point final.

J'aurais obligé le programmeur junior à sacrifier son week-end pour corriger le bogue. Ses actions (ou son absence) ne l'affectent pas directement. Aussi, faites-lui comprendre qu'il ne verra pas d'avancement et / ou d'augmentation de salaire s'il n'améliore pas ses compétences en test.

En fin de compte, même avec toute votre aide, vos encouragements et votre mentorat, il pourrait ne pas convenir à votre équipe, alors laissez-le partir et cherchez quelqu'un qui l'obtienne.

Je seconde le commentaire de RodeoClown sur le code qui examine chaque commit. Une fois qu'il l'a fait plusieurs fois, il prendra l'habitude de tester des choses.

Je ne sais pas si vous devez bloquer les commits comme ça. Sur mon lieu de travail, tout le monde a un engagement gratuit pour tout, et tous les messages de validation SVN (avec diffs) sont envoyés par courrier électronique à l'équipe.

Remarque: vous voulez vraiment l' addon thunderbird colour-diffs si vous prévoyez de le faire.

Mon patron ou moi-même (les 2 codeurs `` seniors '') finirons par lire les commits, et s'il y a des choses comme "vous avez oublié d'ajouter des tests unitaires", nous nous contentons de feuilleter un e-mail ou d'aller discuter avec la personne, expliquant pourquoi elle besoin de tests unitaires ou autre. Tout le monde est également encouragé à lire les commits, car c'est un excellent moyen de voir ce qui se passe, mais les développeurs juniors ne commentent pas beaucoup.

Vous pouvez encourager les gens à prendre l'habitude de cela en disant périodiquement des choses comme "Hey, bob, as-tu vu ce commit que j'ai fait ce matin, j'ai trouvé cette astuce où vous pouvez faire du bla bla quoi que ce soit, lire le commit et voir Comment ça fonctionne!"

NB: Nous avons 2 développeurs «seniors» et 3 juniors. Cela peut ne pas évoluer ou vous devrez peut-être ajuster un peu le processus avec plus de développeurs.

1. Intégrez la couverture du code aux révisions.
2. Faites de «écrire un test qui expose le bogue» un prérequis pour corriger un bogue.
3. Nécessite un certain niveau de couverture avant que le code puisse être enregistré.
4. Trouvez un bon livre sur le développement piloté par les tests et utilisez-le pour montrer comment le test d'abord peut accélérer le développement.

Beaucoup de psychologie et de techniques de «mentorat» utiles mais, honnêtement, cela se résume à «écrire des tests si vous voulez toujours avoir un emploi, demain».

Vous pouvez le formuler dans les termes que vous jugez appropriés, durs ou doux, peu importe. Mais le fait est que les programmeurs ne sont pas payés pour simplement rassembler le code et l'enregistrer - ils sont payés pour assembler soigneusement le code, puis mettre en place des tests, puis tester leur code, PUIS vérifier le tout. (Au moins c'est ce à quoi cela ressemble, d'après votre description.)

Par conséquent, si quelqu'un refuse de faire son travail, expliquez-lui qu'il peut rester à la maison demain et vous embaucherez quelqu'un qui fera le travail.

Encore une fois, vous pouvez faire tout cela doucement, si vous pensez que c'est nécessaire, mais beaucoup de gens ont juste besoin d'une grosse claque de Life In The Real World , et vous leur feriez une faveur en leur donnant.

Bonne chance.

Changez sa description de travail pendant un certain temps pour n'écrire que des tests et maintenir des tests. J'ai entendu dire que de nombreuses entreprises font cela pour de nouvelles personnes inexpérimentées pendant un certain temps lorsqu'elles commencent.

De plus, lancez un défi pendant qu'il occupe ce rôle: écrivez des tests qui a) échoueront sur le code actuel a) répondront aux exigences du logiciel. Espérons que cela l'amènera à créer des tests solides et approfondis (améliorant le projet) et le rendra meilleur dans l'écriture de tests pour sa réintégration dans le développement de base.

edit> répond aux exigences du logiciel, ce qui signifie qu'il n'écrit pas seulement des tests pour casser volontairement le code lorsque le code n'a jamais eu l'intention ou n'a jamais eu besoin de prendre en compte ce cas de test.

Si votre collègue n'a pas l'expérience de la rédaction de tests, il a peut-être des difficultés à tester au-delà de situations simples, et cela se manifeste par des tests inadéquats. Voici ce que j'essaierais:

• Passez du temps et partagez des techniques de test, comme l'injection de dépendances, la recherche de cas extrêmes, etc. avec votre collègue.
• Proposez de répondre aux questions sur les tests.
• Examinez le code des tests pendant un certain temps. Demandez à votre collègue de passer en revue les modifications que vous avez apportées qui sont des exemples de bons tests. Regardez leurs commentaires pour voir s'ils lisent et comprennent vraiment votre code de test.
• S'il y a des livres qui correspondent particulièrement bien à la philosophie de test de votre équipe, donnez-lui un exemplaire. Cela peut aider si vos commentaires ou discussions sur la révision de code font référence au livre afin qu'il ou elle ait un fil à suivre.

Je n'insisterais pas particulièrement sur le facteur honte / culpabilité. Il convient de souligner que les tests sont une bonne pratique largement adoptée et que rédiger et maintenir de bons tests est une courtoisie professionnelle afin que vos coéquipiers n'aient pas besoin de passer leurs week-ends au travail, mais je n'insisterais pas sur ces points.

Si vous avez vraiment besoin de «durcir», installez un système impartial; personne n'aime avoir l'impression d'être distingué. Par exemple, votre équipe peut avoir besoin d'un code pour maintenir un certain niveau de couverture de test (capable d'être joué, mais au moins capable d'être automatisé); exiger un nouveau code pour avoir des tests; exiger des examinateurs qu'ils tiennent compte de la qualité des tests lorsqu'ils effectuent des révisions de code; etc. La mise en place de ce système devrait découler d'un consensus d'équipe. Si vous modérez soigneusement la discussion, vous pourriez découvrir d'autres raisons sous-jacentes que les tests de votre collègue ne correspondent pas à vos attentes.

C'est la responsabilité de son mentor de lui enseigner. Dans quelle mesure lui apprenez-vous comment tester. Êtes-vous en train de programmer avec lui? Le Junior ne sait probablement pas COMMENT mettre en place un bon test pour xyz.

En tant que Junior fraîchement sorti de l'école, il connaît de nombreux concepts. Une technique. Quelques expériences. Mais au final, tout Junior est POTENTIEL. Presque toutes les fonctionnalités sur lesquelles ils travaillent, il y aura quelque chose de nouveau qu'ils n'ont jamais fait auparavant. Bien sûr, le Junior a peut-être fait un modèle d'état simple pour un projet en classe, ouvrant et fermant des «portes», mais jamais une application réelle des modèles.

Il / elle sera aussi bon que la façon dont vous enseignez. S'ils étaient capables de "Just get it", pensez-vous qu'ils auraient pris un poste junior en premier lieu?

D'après mon expérience, les juniors sont embauchés et se voient confier presque les mêmes responsabilités que les seniors, mais sont simplement payés moins et ignorés lorsqu'ils commencent à faiblir. Pardonne-moi si j'ai l'air amer, c'est parce que je le suis.

@ jsmorris

Une fois, j'ai eu le développeur principal et «l'architecte» me réprimander et un testeur (c'était mon premier travail à la sortie de l'université) par courrier électronique pour ne pas rester tard et avoir terminé une tâche aussi «facile» la nuit précédente. Nous y étions restés toute la journée et nous l'avions appelé à 19 heures, je me débattais depuis 11 heures avant le déjeuner ce jour-là et j'avais harcelé tous les membres de notre équipe pour obtenir de l'aide au moins deux fois.

J'ai répondu et j'ai envoyé un cc à l'équipe avec: "Je suis déçu de toi depuis un mois maintenant. Je ne reçois jamais d'aide de l'équipe. Je serai au café de l'autre côté de la rue si tu as besoin de moi. Je suis désolé, je n'ai pas pu déboguer la méthode des 12 paramètres, 800 lignes dont tout dépend à peu près. "

Après s'être refroidi au café pendant une heure, je suis retourné au bureau, j'ai attrapé ma merde et je suis parti. Après quelques jours, ils m'ont appelé pour me demander si j'arrivais, j'ai dit que je le ferais mais j'ai eu une interview, peut-être demain.

«Alors tu as arrêté de fumer alors?

Sur votre référentiel source: utilisez des hooks avant chaque commit (hook pre-commit pour SVN par exemple)

Dans ce hook, vérifiez l'existence d'au moins un cas d'utilisation pour chaque méthode. Utilisez une convention pour l'organisation de tests unitaires que vous pouvez facilement appliquer via un hook de pré-validation.

Sur un serveur d'intégration, compilez tout et vérifiez régulièrement la couverture de test à l'aide d'un outil de couverture de test. Si la couverture de test n'est pas de 100% pour un code, bloquez toute validation du développeur. Il devrait vous envoyer le cas de test qui couvre 100% du code.

Seuls les contrôles automatiques peuvent bien évoluer sur un projet. Vous ne pouvez pas tout vérifier à la main.

Le développeur doit avoir un moyen de vérifier si ses cas de test couvrent 100% du code. De cette façon, s'il ne commet pas un code testé à 100%, c'est sa propre faute, pas une faute "oups, désolé j'ai oublié".

N'oubliez pas: les gens ne font jamais ce que vous attendez, ils font toujours ce que vous inspectez.

Tout d'abord, comme la plupart des répondants le soulignent ici, si le gars ne voit pas la valeur des tests, vous ne pouvez pas faire grand-chose à ce sujet, et vous avez déjà souligné que vous ne pouvez pas le renvoyer. Cependant, l'échec n'est pas une option ici, alors qu'en est-il des quelques choses que vous pouvez faire?

Si votre organisation est assez grande pour avoir plus de 6 développeurs, je recommande fortement d'avoir un département d'assurance qualité (même si c'est une seule personne pour commencer). Idéalement, vous devriez avoir un ratio de 1 testeur pour 3 à 5 développeurs. Le truc avec les programmeurs est ... ce sont des programmeurs, pas des testeurs. Je n'ai pas encore interviewé un programmeur à qui on a officiellement enseigné les bonnes techniques d'assurance qualité.

La plupart des organisations font le défaut fatal d'attribuer les rôles de test au nouvel embauché, la personne avec le moins d'exposition à votre code - idéalement, les développeurs seniors devraient être déplacés vers le rôle de contrôle qualité car ils ont l'expérience du code. , et (espérons-le) ont développé un sixième sens pour les odeurs de code et les points d'échec qui peuvent surgir.

De plus, le programmeur qui a commis l'erreur ne trouvera probablement pas le défaut car ce n'est généralement pas une erreur de syntaxe (celles-ci sont détectées dans la compilation), mais une erreur logique - et la même logique est à l'œuvre quand ils écrivent le tester comme quand ils écrivent le code. Ne demandez pas à la personne qui a développé le code de tester ce code - elle trouvera moins de bogues que n'importe qui d'autre.

Dans votre cas, si vous pouvez vous permettre l'effort de travail redirigé, faites de ce nouveau venu le premier membre de votre équipe d'assurance qualité. Faites-lui lire "Test de logiciels dans le monde réel: améliorer le processus", car il aura évidemment besoin d'une formation dans son nouveau rôle. S'il n'aime pas ça, il arrêtera et votre problème sera toujours résolu.

Une approche légèrement moins vengeresse consisterait à laisser cette personne faire ce pour quoi elle est douée (je suppose que cette personne a été embauchée parce qu'elle est réellement compétente dans la partie programmation du travail), et à embaucher un testeur ou deux pour faire les tests ( Les étudiants universitaires ont souvent des stages ou des stages "coopératifs", aimeraient être exposés et sont bon marché)

Note latérale: Finalement, vous voudrez que l'équipe QA rende compte à un directeur QA, ou du moins pas à un responsable de développement logiciel, car le fait que l'équipe QA rende compte au responsable dont l'objectif principal est de faire le produit est un conflit de intérêt.

Si votre organisation est inférieure à 6 ou si vous ne pouvez pas vous en sortir avec la création d'une nouvelle équipe, je recommande la programmation par paires (PP). Je ne suis pas totalement converti à toutes les techniques de programmation extrêmes, mais je suis définitivement partisan de la programmation par paires. Cependant, les deux membres de l'équipe de programmation jumelée doivent être dévoués, sinon cela ne fonctionne tout simplement pas. Ils doivent suivre deux règles: l'inspecteur doit bien comprendre ce qui est codé à l'écran ou il doit demander au codeur de l'expliquer; le codeur ne peut coder que ce qu'il peut expliquer - aucun «tu verras» ou «fais-moi confiance» ou les gestes de la main ne seront tolérés.

Je ne recommande PP que si votre équipe en est capable, car, comme pour les tests, aucune quantité d'acclamations ou de menaces ne persuadera quelques introvertis remplis d'ego de travailler ensemble s'ils ne se sentent pas à l'aise de le faire. Cependant, je trouve qu'entre le choix d'écrire des spécifications fonctionnelles détaillées et de faire des révisions de code par rapport à la programmation par paires, le PP l'emporte généralement.

Si PP n'est pas pour vous, alors TDD est votre meilleur pari, mais seulement s'il est pris à la lettre. Le développement piloté par les tests signifie que vous écrivez les tests EN PREMIER, exécutez les tests pour prouver qu'ils échouent réellement, puis écrivez le code le plus simple pour le faire fonctionner. Le compromis est maintenant que vous (devriez) avoir une collection de milliers de tests, qui est aussi du code, et qui est tout aussi susceptible que le code de production de contenir des bogues. Je vais être honnête, je ne suis pas un grand fan de TDD, principalement pour cette raison, mais cela fonctionne pour de nombreux développeurs qui préfèrent écrire des scripts de test plutôt que des documents de cas de test - certains tests valent mieux que rien. Associez TDD à PP pour une meilleure probabilité de couverture de test et moins de bogues dans le script.

Si tout le reste échoue, demandez aux programmeurs l'équivalence d'un pot de jure - chaque fois que le programmeur rompt la construction, il doit mettre 20 $, 50 $, 100 $ (ce qui est modérément douloureux pour votre personnel) dans un pot qui va à votre favori ( enregistré!) charité. Jusqu'à ce qu'ils paient, évitez-les :)

Blague à part, la meilleure façon d'amener votre programmeur à écrire des tests est de ne pas le laisser programmer. Si vous voulez un programmeur, embauchez un programmeur - Si vous voulez des tests, engagez un testeur. J'ai commencé comme programmeur junior il y a 12 ans à faire des tests, et cela est devenu mon cheminement de carrière, et je ne l'échangerais contre rien. Un service d'assurance qualité solide, correctement nourri et doté du pouvoir et du mandat d'améliorer le logiciel, est tout aussi précieux que les développeurs qui écrivent le logiciel en premier lieu.

C'est peut-être un peu sans cœur, mais la façon dont vous décrivez la situation donne l'impression que vous devez renvoyer ce type. Ou du moins, dites-le clairement: refuser de suivre les pratiques de développement interne (y compris l'écriture de tests) et vérifier le code bogué que d'autres personnes doivent nettoyer vous fera éventuellement virer.

La principale raison pour laquelle les ingénieurs / programmeurs débutants ne prennent pas beaucoup de temps pour concevoir et exécuter des scripts de test, c'est que la plupart des certifications CS ne l'exigent pas fortement, de sorte que d'autres domaines de l'ingénierie sont couverts plus en détail dans les programmes universitaires, tels que les modèles de conception.

D'après mon expérience, la meilleure façon de faire prendre l'habitude aux jeunes professionnels est de l'inclure explicitement dans le processus. Autrement dit, lors de l'estimation du temps qu'une itération devrait prendre, le temps de conception, d'écriture et / ou d'exécution des cas doit être incorporé dans cette estimation de temps.

Enfin, la révision de la conception du script de test doit faire partie d'une révision de la conception, et le code réel doit être examiné dans la révision du code. Cela rend le programmeur responsable de tester correctement chaque ligne de code qu'il / elle écrit, et l'ingénieur principal et ses pairs sont tenus de fournir des commentaires et des conseils sur le code et le test écrit.

D'après votre commentaire, "Montrer que la conception devient plus simple", je suppose que vous pratiquez le TDD. Faire une révision du code après coup ne fonctionnera pas. Tout ce qui concerne TDD, c'est qu'il s'agit d'une conception et non d'une philosophie de test. S'il n'a pas écrit les tests dans le cadre de la conception, vous n'obtiendrez pas beaucoup d'avantages en écrivant des tests après coup, en particulier de la part d'un développeur junior. Il finira par manquer un grand nombre de cas de coin et son code sera toujours merdique.

Votre meilleur pari est d'avoir un développeur senior très patient pour s'asseoir avec lui et faire de la programmation en binôme. Et continuez jusqu'à ce qu'il apprenne. Ou n'apprend pas, auquel cas vous devez le réaffecter à une tâche à laquelle il est mieux adapté car vous finirez par frustrer vos vrais développeurs.

Tout le monde n'a pas le même niveau de talent et / ou de motivation. Les équipes de développement, même agiles, sont composées de personnes de la «A-Team» et de personnes de la «B-Team». Les membres de A-Team sont ceux qui conçoivent la solution, écrivent tout le code de production non trivial et communiquent avec les propriétaires d'entreprise - tout le travail qui nécessite de sortir des sentiers battus. La B-Team gère des tâches telles que la gestion de la configuration, l'écriture de scripts, la correction de bugs boiteux et le travail de maintenance - tout le travail qui a des procédures strictes qui ont de petites conséquences en cas d'échec.