Comment inciter les programmeurs juniors à rédiger des tests ?[fermé]

https://stackoverflow.com/questions/7252

08-06-2019
|

Question

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

Montrer que le design devient plus simple
Le montrer évite les défauts
En faire une question 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 « comprend » et il n'est pas nécessaire de pousser les tests.Nous savons que nous pouvons lui faire passer des tests, mais nous savons tous que les tests utiles sont ceux écrits lorsque vous êtes dedans.

Connaissez-vous d’autres motivations ?

La solution

C'est l'un des les choses les plus difficiles faire.Amener vos collaborateurs à 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.

Essaye ça:sur un projet à venir, associez le jeune avec vous-même ou un autre programmeur senior.Ils doivent travailler ensemble, à tour de rôle « conduire » (être celui qui tape sur leur clavier) et « coacher » (regarder par-dessus l'épaule du conducteur et lui signaler les suggestions, les erreurs, etc. au fur et à mesure).Cela peut sembler un gaspillage de ressources, mais vous découvrirez :

Que ces gars-là ensemble peuvent produire du code très rapidement et de meilleure qualité.
Si votre junior en apprend suffisamment pour « comprendre » avec un senior qui le guide sur la bonne voie (par ex."Ok, maintenant avant de continuer, écrivons au test pour cette fonction.") Cela vaudra bien les ressources que vous y consacrerez.

Peut-être aussi demander à quelqu'un de votre groupe de donner le Tests unitaires 101 présentation de Kate Rhodes, je pense que c'est un excellent moyen d'enthousiasmer les gens pour les tests, s'ils sont bien exécutés.

Une autre chose que vous pouvez faire est de demander à votre Jr.Les développeurs pratiquent le Jeu de quilles Kata ce qui les aidera à apprendre le développement piloté par les tests.Il est en Java, mais pourrait facilement être adapté à n'importe quel langage.

Autres conseils

Effectuez une révision du code avant chaque validation (même s'il s'agit d'un "J'ai modifié ce nom de variable" d'une minute) et, dans le cadre de la révision du code, examinez tous les tests unitaires.

Ne signez pas le 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 ?S'il 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 bug que je trouve et corrige soit exprimé sous forme de test :

"Hmmm, ce n'est pas vrai..."
Trouver un problème possible
Écrivez un test, montrez que le code échoue
Résoudre le problème
Montrer que le nouveau code passe
Boucle si le problème d'origine persiste

J'essaie de le faire même en faisant des trucs, et j'ai fini à peu près en même temps, seulement avec une suite de tests partielle déjà en place.

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

Imaginez que je suis un faux programmeur, nommé...Marc.Imaginez que j'ai obtenu mon diplôme il n'y a pas si longtemps et que je n'ai jamais vraiment eu à passer des tests.Imaginez que je travaille dans une entreprise qui n'impose pas vraiment cela ou ne le demande pas.D'ACCORD?bien!Imaginez maintenant que l'entreprise se tourne vers l'utilisation de tests et qu'elle essaie de me mettre en conformité avec cela.Je vais donner une réaction quelque peu sarcastique 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 davantage peut-il 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 évite les défauts.

Je sais que.C'est pourquoi on les appelle des tests.Mon code est bon et je l'ai vérifié pour déceler les problèmes, donc je ne vois pas en quoi ces tests pourraient aider.

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

Ohh, alors vous pensez que je suis un mauvais programmeur simplement parce que je ne fais pas autant de tests utilisés.Je suis insulté et franchement ennuyé contre toi.Je préfère avoir de l'aide et du soutien plutôt que des paroles.

@Justin Standard:Au début d'un nouveau projet, associez le jeune 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 se font et que certains m'aideront sur la façon dont les choses sont faites.C’est utile et je pourrais peut-être commencer à le faire davantage.

@Justin Standard:Lire Tests unitaires 101 présentation par Kate Rhodes.

Ahh, c'était une présentation intéressante, et cela m'a fait penser aux tests.Cela a souligné certains points que je devrais prendre en compte, et cela aurait pu influencer un peu mon point de vue.

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

@Dominique Cooney:Passez du temps et partagez des techniques de test.

Ahh, cela m'aide à comprendre ce que l'on attend de moi en termes de techniques, et cela met plus d'éléments dans mon sac de connaissances, que je pourrais réutiliser.

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

Avoir une ou plusieurs personnes clés pour répondre aux questions 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 à chercher comme référence.Les livres qui s’y rapportent directement constituent une excellente référence.

@Adam Hayle:Revue surprise.

Dis quoi, tu as lancé quelque chose auquel je ne suis absolument pas préparé.Cela me met mal à l’aise, mais je ferai de mon mieux.Je vais maintenant avoir peur et une légère appréhension à l'idée que cela se reproduise, merci.Cependant, la tactique alarmiste aurait pu fonctionner, mais elle a un coût.Cependant, si rien d’autre ne fonctionne, cela pourrait bien être l’impulsion nécessaire.

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

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

@jmorris:Se débarrasser/Sacrifice.

des reflets, des reflets, des reflets - Il y a une chance que je puisse apprendre, et avec du soutien et de l'aide, je peux devenir un élément très important et fonctionnel des équipes.C'est un de mes handicaps actuellement, mais ce ne sera pas pour longtemps.Cependant, si je ne comprends pas, je comprends que j'irai.Je pense que je vais l'obtenir.

Au final, le soutien de mon équipe a joué un grand rôle dans tout cela.Avoir une personne qui prend son temps pour m'aider et me faire prendre de bonnes habitudes est toujours le bienvenu.Ensuite, avoir un bon réseau de soutien serait formidable.Il serait toujours apprécié que quelqu'un vienne quelques fois après, et révise un code, pour voir comment tout se déroule, pas dans une revue en soi, mais plutôt comme une visite amicale.

Raisonnement, Préparation, Enseignement, Suivi, Accompagnement.

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 je dois vraiment le faire rapidement », alors vous savez ce que je veux dire.Cependant, sur le plan émotionnel, ils ont le sentiment de ne faire quelque chose que lorsqu'ils écrivent le vrai code.

L’objectif devrait donc être de leur faire comprendre que les tests sont en fait le seulement moyen de mesurer quand quelque chose est « fait », et ainsi de leur donner la motivation intrinsèque pour passer 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 cela plus tard, puis ajouter les tests" -- et bien sûr, le suivi n'a jamais lieu car, étonnamment, ils 'concernant tout aussi occupé la semaine prochaine.

Voici ce que je ferais :

Première sortie..."nous allons faire ce projet conjointement.Je vais écrire les tests et vous allez écrire le code.Faites attention à la façon dont j'écris les tests, car c'est ainsi que nous faisons les choses ici et c'est ce que j'attends de vous.
D'après cela..."Vous avez terminé?Super!Examinons d'abord les tests qui pilotent votre développement.Ah, pas de tests ?Faites-moi savoir quand cela sera fait et nous reporterons l'examen de votre code.Si vous avez besoin d'aide pour formuler les tests, faites-le-moi savoir et je vous aiderai."

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

Il peut également être utile 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 cela seulement parce qu'en parcourant les réponses, je n'ai pas vu cela mentionné.

En effectuant 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 de améliorer le code. Parce que de cette façon, sa confiance risque moins d’être endommagée.Et c'est important.D’un autre côté, savoir à quel point vous en savez peu l’est aussi.

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

Modifier:[Justin Standard]

Ne vous rabaissez pas, ce que vous avez à dire est assez juste.

Sur votre point concernant les révisions de code :ce que vous constaterez, c'est que non seulement le développeur junior apprendra au cours du processus, mais aussi les réviseurs.Tout le monde lors d’une révision de code apprend si vous en faites un processus collaboratif.

Franchement, si vous devez mettre que Si vous faites beaucoup d'efforts pour l'amener à faire quelque chose, vous devrez peut-être accepter l'idée qu'il n'est peut-être tout simplement pas un bon candidat pour l'équipe et qu'il devra peut-être y aller.Maintenant, cela ne signifie pas nécessairement le renvoyer...cela peut impliquer de 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 un environnement d'entreprise.Des choses comme celles-là que la plupart d’entre nous pourraient s’en sortir à l’université.

Si c’est le cas, une chose que j’ai trouvée qui fonctionne est d’avoir une sorte d'"examen surprise des nouvelles recrues ». Peu importe si vous ne l’avez jamais fait auparavant... Il ne le saura pas.Asseyez-le simplement et dites-lui que vous allez passer en revue ses performances et lui montrer quelques 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 ressemble. officiel et lui montrer où il en est.Si vous lui montrez dans un cadre très formel que ne pas faire de tests affecte négativement sa note de performance au lieu de simplement le « harceler » à ce sujet, il comprendra, espérons-le.Vous devez lui montrer que ses actions l'affecteront réellement, que ce soit en termes de salaire ou autre.

Je sais, vous voudrez peut-être éviter de faire ça parce que ce n'est pas officiel...mais je pense que vous avez raison de le faire et cela coûtera probablement beaucoup moins cher que de devoir le licencier et recruter quelqu'un de nouveau.

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
Courez pour voir ce que ça fait
Écrivez le prochain morceau de code

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

Demander:"Et la semaine prochaine ?"

Lorsqu'il n'a pas de réponse, demandez :"Comment voudriez-vous que votre programme vous prévienne lorsqu'un changement interrompt quelque chose qui a fonctionné hier ?"

C’est à cela que servent les tests unitaires automatiques.

En tant que programmeur junior moi-même, je pensais révéler ce que c'était lorsque je me retrouvais dans une situation similaire à celle de votre développeur junior.

Quand je suis sorti de l’université, j’ai découvert que cela m’avait gravement déséquipé pour affronter le monde réel.Oui, je connaissais quelques bases de JAVA et un peu de philosophie (ne demandez pas) mais c'était tout.Lorsque j’ai obtenu mon emploi, c’était pour le moins un peu intimidant.Laissez-moi vous dire que j'étais probablement l'un des plus grands cowboys du monde, je piraterais ensemble une petite correction de bug/un algorithme sans commentaires/tests/documentation et je l'expédierais.

J'ai eu la chance d'être sous la surveillance d'une personne aimable et très programmeur senior patient.Heureusement pour moi, il a décidé de s'asseoir avec moi et de passer 1 à 2 semaines à parcourir mon code très piraté.Il m'expliquait où je m'étais trompé, les points les plus subtils de c et les pointeurs (bon, ça m'a dérouté !).Nous avons réussi à écrire un cours/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 du temps pour m'aider sur le bon chemin, je n'aurais probablement pas tenu très longtemps.

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

Ramenez des points à la maison

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

Affectez-les à des projets qui ne nécessitent pas de « code stable de qualité supérieure » si tel est votre problème et laissez le jr.le développeur échoue.Demandez-leur d'être ceux qui « viennent le week-end » pour corriger leurs bugs.Déjeunez beaucoup et parlez des pratiques de développement logiciel (pas de cours, mais de 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 meilleur que les techniques que votre équipe utilise actuellement.

Si le programmeur junior, ou n'importe qui d'autre, ne voit pas l'intérêt des tests, il sera alors difficile de le convaincre de le faire... point final.

J'aurais obligé le programmeur junior à sacrifier son week-end pour corriger le bug.Ses actions (ou son absence) ne l'affectent pas directement.Expliquez également clairement qu'il ne verra pas d'avancement et/ou d'augmentation de salaire s'il n'améliore pas ses compétences lors des tests.

En fin de compte, même avec toute votre aide, vos encouragements et votre mentorat, il se peut qu'il ne convienne pas à votre équipe, alors laissez-le partir et cherchez quelqu'un qui comprendra.

J'appuie le commentaire de RodeoClown sur le code révisant chaque commit.Une fois qu'il l'aura fait plusieurs fois, il prendra l'habitude de tester des trucs.

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

Note:toi vraiment veux le module complémentaire de différences colorées pour Thunderbird si vous envisagez de faire cela.

Mon patron ou moi-même (les 2 codeurs « seniors ») finiront par lire les commits, et s'il y a des trucs comme "vous avez oublié d'ajouter des tests unitaires", nous envoyons simplement un e-mail ou allons discuter avec la personne, expliquant pourquoi elle tests unitaires nécessaires 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 en disant périodiquement des choses comme "Hé, Bob, as-tu vu ce commit que j'ai fait ce matin, j'ai trouvé cette astuce intéressante où tu peux faire bla bla n'importe quoi, lire le commit et voir". Comment ça fonctionne!"

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

Intégrez la couverture du code aux révisions.
Faites de "écrire un test qui expose le bogue" une condition préalable à la correction d'un bogue.
Exiger un certain niveau de couverture avant que le code puisse être enregistré.
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, en toute honnêteté, cela se résume simplement à « passer 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, cela n'a pas d'importance.Mais le fait est que les programmeurs ne sont pas payés pour simplement rassembler du code et l'enregistrer - ils sont payés pour assembler soigneusement le code, puis assembler des tests, puis tester leur code, PUIS enregistrer le tout.(C'est du moins 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 en douceur, si vous pensez que c'est nécessaire, mais beaucoup de gens ont juste besoin d'une bonne claque dure. La vie dans le monde réel, et vous leur rendriez service en le leur donnant.

Bonne chance.

Changez sa description de poste pendant un certain temps pour qu'il rédige et maintienne uniquement des tests.J'ai entendu dire que de nombreuses entreprises font cela pour les nouvelles personnes inexpérimentées pendant un certain temps lorsqu'elles démarrent.

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 lorsqu'il réintégrera 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 délibérément le code alors que 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 manque d'expérience dans la rédaction de tests, il ou elle a peut-être des difficultés à tester au-delà de situations simples, ce qui se manifeste par des tests inadéquats.Voici ce que j'essaierais :

Passez du temps et partagez des techniques de test, telles que 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.
Faites des revues de code des tests pendant un certain temps.Demandez à votre collègue d’examiner vos modifications qui sont exemplaires d’un bon test.Regardez leurs commentaires pour voir s'ils lisent et comprennent vraiment votre code de test.
S'il existe des livres qui correspondent particulièrement bien à la philosophie de test de votre équipe, donnez-lui un exemplaire.Cela peut être utile si vos commentaires ou discussions sur la révision du code font référence au livre afin qu'il ou elle ait un fil de discussion à reprendre et à 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 « faire preuve de fermeté », alors instituez un système impartial ;personne n’aime se sentir exclu.Par exemple, votre équipe peut avoir besoin de code pour maintenir un certain niveau de couverture de test (pouvant être joué, mais au moins pouvant être automatisé) ;exiger que le nouveau code fasse l'objet de tests ;exiger que les réviseurs prennent en compte la qualité des tests lors de la révision du code ;et ainsi de suite.L’instauration de ce système devrait provenir d’un consensus d’équipe.Si vous modérez soigneusement la discussion, vous découvrirez peut-être d'autres raisons sous-jacentes pour lesquelles 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.Est-ce que vous programmez en binôme 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 certaine technique.Quelques expériences.Mais au final, tout Junior est POTENTIEL.Presque chaque fonctionnalité sur laquelle ils travaillent comportera quelque chose de nouveau qu'ils n'ont jamais fait auparavant.Bien sûr, le Junior a peut-être réalisé un simple modèle d'État pour un projet en classe, ouvrant et fermant des « portes », mais jamais une application réelle des modèles.

Il/elle ne sera aussi bon que la façon dont vous enseignez.S'ils étaient capables de "l'obtenir", pensez-vous qu'ils auraient accepté 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 ils sont simplement moins payés, puis ignorés lorsqu'ils commencent à faiblir.Pardonnez-moi si je semble amer, c'est parce que je le suis.

@jsmorris

Une fois, le développeur principal et "l'architecte" m'ont réprimandé, ainsi qu'un testeur (c'était mon premier emploi après l'université) par courrier électronique pour ne pas être resté tard et avoir terminé une tâche aussi "facile" la veille.Nous y avons travaillé toute la journée et avons arrêté à 19 heures. Je me débattais depuis 11 heures avant le déjeuner ce jour-là et j'avais harcelé chaque membre de notre équipe pour obtenir de l'aide au moins deux fois.

J'ai répondu et j'ai envoyé en copie à l'équipe :« Cela fait un mois que je suis déçu par toi.Je ne reçois jamais d’aide de l’équipe.Je serai au café d'en face si tu as besoin de moi.Je suis désolé de ne pas avoir pu déboguer la méthode à 12 paramètres et 800 lignes dont dépend à peu près tout."

Après m'être rafraîchi au café pendant une heure, je suis retourné au bureau, j'ai attrapé mes conneries et je suis parti.Au bout de quelques jours, ils m'ont appelé pour me demander si je venais, j'ai dit que je le ferais mais j'ai eu un entretien, peut-être demain.

"Alors tu as arrêté ?"

Sur votre dépôt source :utiliser des hooks avant chaque commit (hook de pré-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 des tests unitaires que vous pouvez facilement appliquer via un hook de pré-validation.

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

Seules les vérifications 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 tests couvrent 100% du code.De cette façon, s'il ne valide pas un code testé à 100 %, c'est sa propre faute, pas une faute "oups, désolé, j'ai oublié".

Souviens-toi :Les gens ne font jamais ce que vous attendez, ils font toujours ce que vous inspectez.

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

Si votre organisation est suffisamment grande pour avoir plus de 6 développeurs, je vous recommande fortement d'avoir un service d'assurance qualité (même s'il ne s'agit que d'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, c'est...ce sont des programmeurs, pas des testeurs.Je n'ai pas encore interviewé un programmeur à qui on a formellement enseigné les techniques d'assurance qualité appropriées.

La plupart des organisations commettent le défaut fatal d'attribuer les rôles de test au nouvel employé, la personne la moins exposée à votre code. Idéalement, les développeurs seniors devraient être transférés au rôle d'assurance 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 de défaillance qui peuvent survenir.

De plus, le programmeur qui a commis l'erreur ne trouvera probablement pas le défaut car il ne s'agit généralement pas d'une erreur de syntaxe (celles-ci sont détectées lors de la compilation), mais d'une erreur de logique - et la même logique est à l'œuvre lorsqu'il écrit le tester comme lorsqu'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 quiconque.

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 « Tests de logiciels dans le monde réel :Improving The Process", car il aura évidemment besoin d'une certaine 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 serait de laisser cette personne faire ce pour quoi elle est bonne (je suppose que cette personne a été embauchée parce qu'elle est réellement compétente dans la partie programmation du travail) et d'embaucher un ou deux testeurs pour effectuer les tests ( Les étudiants universitaires effectuent souvent des stages ou des stages coopératifs, aimeraient être exposés et sont bon marché.)

Remarque latérale :En fin de compte, vous souhaiterez que l'équipe d'assurance qualité relève d'un directeur d'assurance qualité, ou du moins pas d'un responsable du développement de logiciels, car le fait que l'équipe d'assurance qualité relève du responsable dont l'objectif principal est de réaliser le produit est un conflit d'intérêts.

Si votre organisation compte moins de 6 personnes ou si vous ne parvenez pas à créer une nouvelle équipe, je recommande la programmation en binôme (PP).Je ne suis pas totalement converti à toutes les techniques de programmation extrêmes, mais je crois définitivement à la programmation en binôme.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 « vous verrez » ou « faites-moi confiance » ni aucun signe de la main ne seront tolérés.

Je ne recommande le PP que si votre équipe en est capable, car, comme lors des tests, aucune acclamation ou menace ne persuadera un couple d'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 revues de code vs.programmation jumelée, le PP l'emporte généralement.

Si PP n'est pas pour vous, alors TDD est votre meilleur choix, mais seulement s'il est pris au pied de la lettre.Le développement piloté par les tests signifie que vous écrivez les tests EN PREMIER, que vous exécutez les tests pour prouver qu'ils échouent réellement, puis que vous é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 sont également du code, et sont tout aussi susceptibles 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 scénarios de test - certains tests valent mieux qu'aucun.Associez TDD avec PP pour une meilleure probabilité de couverture des tests et moins de bogues dans le script.

Si tout le reste échoue, donnez aux programmeurs l'équivalent d'un pot de jurons - chaque fois que le programmeur interrompt 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é!) organisme de bienfaisance.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, engagez un programmeur. Si vous voulez des tests, engagez un testeur.J'ai commencé comme programmeur junior il y a 12 ans en faisant 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 entretenu 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, précisez-le :refuser de suivre les pratiques de développement de la maison (y compris les tests d'écriture) et vérifier le code bogué que d’autres personnes doivent nettoyer finira par vous faire 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 est que la plupart des certifications CS ne l'exigent pas vraiment, de sorte que d'autres domaines de l'ingénierie sont abordés 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 donner l’habitude aux jeunes professionnels est de l’intégrer explicitement au 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 intégré dans cette estimation de temps.

Enfin, l'examen de la conception du script de test doit faire partie d'une revue de conception, et le code lui-même doit être examiné lors de la revue de code.Cela rend le programmeur responsable de tester correctement chaque ligne de code qu'il écrit, et l'ingénieur principal et ses pairs sont responsables de fournir des commentaires et des conseils sur le code et les tests écrits.

Sur la base de 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.Le tout avec 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 de nombreux cas particuliers et son code sera toujours merdique.

Votre meilleur pari est d'avoir un très développeur senior patient pour s'asseoir avec lui et faire de la programmation en binôme.Et continuez ainsi jusqu'à ce qu'il apprenne.Ou n'apprend pas, auquel cas vous devez le réaffecter à une tâche pour 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 l'équipe A sont ceux qui conçoivent la solution, écrivent tout le code de production non trivial et communiquent avec les propriétaires de l'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 bogues boiteux et les travaux de maintenance - tout le travail qui comporte des procédures strictes qui ont de légères conséquences en cas d'échec.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow