Wie bringt man Junior-Programmierer dazu, Tests zu schreiben? [geschlossen]

Wir haben einen Junior-Programmierer, der einfach nicht genug Tests schreibt.
Ich muss ihn alle zwei Stunden nörgeln. "Hast du Tests geschrieben?"
Wir haben versucht:

• Zeigen, dass das Design einfacher wird
• Das Zeigen verhindert Mängel
• Es zu einer Ego-Sache zu machen, die sagt, dass nur schlechte Programmierer dies nicht tun
• Dieses Wochenende mussten 2 Teammitglieder zur Arbeit kommen, weil sein Code eine NULL-Referenz hatte und er ihn nicht getestet hat

Meine Arbeit erfordert stabilen Code von höchster Qualität, und normalerweise "bekommt" jeder ihn und es besteht keine Notwendigkeit, Tests durchzusetzen. Wir wissen, dass wir ihn dazu bringen können, Tests zu schreiben, aber wir alle wissen, dass die nützlichen Tests diejenigen sind, die geschrieben wurden, wenn Sie daran interessiert sind.

Kennen Sie weitere Motivationen?

Dies ist eines der schwierigsten Dinge . Ihre Leute dazu bringen, es zu bekommen .

Manchmal ist es eine der besten Möglichkeiten, Programmierern auf Junior-Niveau zu helfen, die richtigen Techniken von den Senioren zu lernen, ein bisschen Paarprogrammierung zu machen.

Versuchen Sie Folgendes: Koppeln Sie bei einem bevorstehenden Projekt den Junior mit sich selbst oder einem anderen Senior-Programmierer. Sie sollten zusammenarbeiten und abwechselnd "fahren" (derjenige, der auf der Tastatur tippt) und "trainieren" (über die Schulter des Fahrers schauen und dabei auf Vorschläge, Fehler usw. hinweisen). Es mag wie eine Verschwendung von Ressourcen erscheinen, aber Sie werden feststellen:

1. Dass diese Leute zusammen Code schnell und von höherer Qualität produzieren können.
2. Wenn Ihr Junior genug lernt, um es mit einem Senior zu "bekommen", der ihn auf den richtigen Weg führt (z. B. "Ok, jetzt, bevor wir fortfahren, lassen Sie uns beim Testen für diese Funktion schreiben."), Lohnt sich die Ressource, die Sie haben verpflichten sich dazu.

Vielleicht soll auch jemand in Ihrer Gruppe das geben Unit Testing 101 geben Präsentation von Kate Rhodes halten. Ich denke, es ist eine großartige Möglichkeit, die Leute für das Testen zu begeistern, wenn sie gut geliefert werden.

Sie können Ihre Jr. Devs auch die Bowling Game Kata üben lassen, um die testgetriebene Entwicklung zu erlernen. Es ist in Java, kann aber leicht an jede Sprache angepasst werden.

Führen Sie vor jedem Commit eine Codeüberprüfung durch (auch wenn es sich um eine 1-minütige "Ich habe diesen Variablennamen geändert" handelt) und überprüfen Sie im Rahmen der Codeüberprüfung alle Komponententests.

Melden Sie das Commit erst ab, wenn die Tests durchgeführt wurden.

(Auch - wenn seine Arbeit nicht getestet wurde - warum war sie überhaupt in einem Produktionsgebäude? Wenn sie nicht getestet wurde, lassen Sie sie nicht herein, dann müssen Sie nicht am Wochenende arbeiten)

Für mich selbst habe ich darauf bestanden, dass jeder Fehler, den ich finde und behebe, als Test ausgedrückt wird:

1. "Hmmm, das stimmt nicht ..."
2. Mögliches Problem finden
3. Schreiben Sie einen Test und zeigen Sie, dass der Code fehlschlägt
4. Das Problem lösen
5. Zeigen Sie, dass der neue Code übergeben wird
6. Schleife, wenn das ursprüngliche Problem weiterhin besteht

Ich versuche dies auch zu tun, während ich Sachen rausschmeiße, und ich werde ungefähr zur gleichen Zeit fertig, nur mit einer bereits vorhandenen Teil-Testsuite.

(Ich lebe nicht in einer kommerziellen Programmierumgebung und bin oft der einzige Programmierer, der an einem bestimmten Projekt arbeitet.)

Stellen Sie sich vor, ich bin ein Scheinprogrammierer namens ... Marco. Stellen Sie sich vor, ich habe vor nicht allzu langer Zeit die Schule abgeschlossen und musste nie wirklich Tests schreiben. Stellen Sie sich vor, ich arbeite in einem Unternehmen, das dies nicht wirklich durchsetzt oder verlangt. OKAY? gut! Stellen Sie sich nun vor, dass das Unternehmen auf Tests umstellt und versucht, mich darauf aufmerksam zu machen. Ich werde auf die bisher erwähnten Punkte etwas scharfsinnig reagieren, als hätte ich diesbezüglich keine Nachforschungen angestellt.

Beginnen wir mit dem Schöpfer:

Zeigen, dass das Design einfacher wird.

Wie kann man mehr schreiben, die Dinge einfacher machen? Ich müsste jetzt mehr Fälle usw. überwachen. Dies macht es komplizierter, wenn Sie mich fragen. Gib mir solide Details.

Das Zeigen verhindert Mängel.

Ich weiß das. Deshalb werden sie Tests genannt. Mein Code ist gut und ich habe ihn auf Probleme überprüft, sodass ich nicht sehe, wo diese Tests helfen würden.

Es zu einer Ego-Sache zu machen, die sagt, dass nur schlechte Programmierer dies nicht tun.

Ohh, du denkst also, ich bin ein schlechter Programmierer, nur weil ich nicht so viele Tests mache. Ich bin beleidigt und positiv verärgert über dich. Ich hätte lieber Hilfe und Unterstützung als Sprüche.

@ Justin Standard : Zu Beginn des neuen Propect-Paares ist der Junior mit sich selbst oder einem anderen Senior-Programmierer zusammen.

Ohh, das ist so wichtig, dass Ressourcen aufgewendet werden, um sicherzustellen, dass ich sehe, wie die Dinge gemacht werden, und dass einige mir helfen, wie die Dinge gemacht werden. Dies ist hilfreich, und ich könnte einfach anfangen, mehr zu tun.

@ Justin Standard : Lesen Sie die Präsentation von Unit Testing 101 von Kate Rhodes.

Ahh, das war eine interessante Präsentation, und ich musste über das Testen nachdenken. Es hat einige Punkte getroffen, die ich berücksichtigen sollte, und es könnte meine Ansichten ein wenig beeinflusst haben.

Ich würde gerne überzeugendere Artikel und andere Tools sehen, die mir dabei helfen, mit dem Gedanken in Einklang zu kommen, dass dies der richtige Weg ist, Dinge zu tun.

@ Dominic Cooney : Verbringen Sie einige Zeit und teilen Sie Testtechniken.

Ahh, das hilft mir zu verstehen, was von mir in Bezug auf Techniken erwartet wird, und es bringt mehr Gegenstände in meine Wissenstasche, die ich möglicherweise wieder verwenden werde.

@ Dominic Cooney : Beantworte Fragen, Beispiele und Bücher.

Es ist hilfreich, eine Person (Personen) zu haben, die Fragen beantwortet. Dies könnte mich eher dazu veranlassen, es zu versuchen. Gute Beispiele sind großartig, und es gibt mir etwas zum Zielen und etwas zum Nachschlagen. Bücher, die direkt dafür relevant sind, sind eine gute Referenz.

@ Adam Hayle : Überraschungsbericht.

Sag was, du hast etwas hervorgebracht, auf das ich völlig unvorbereitet bin. Ich fühle mich damit unwohl, werde aber mein Bestes geben. Ich werde jetzt Angst haben und leicht besorgt darüber sein, dass es wieder auftaucht, danke. Die Angst-Taktik mag zwar funktioniert haben, hat aber Kosten. Wenn jedoch nichts anderes funktioniert, ist dies möglicherweise nur der erforderliche Push.

@ Rytmis : Elemente gelten nur dann als erledigt, wenn sie Testfälle haben.

Ohh, interessant. Ich sehe, dass ich das jetzt wirklich tun muss, sonst erledige ich nichts. Das macht Sinn.

@ jmorris : Befreien Sie sich / opfern Sie.

Blendungen, Blendungen, Blendungen - Es besteht die Möglichkeit, dass ich etwas lerne, und mit Unterstützung und Unterstützung kann ich ein sehr wichtiger und funktionaler Teil der Teams werden. Dies ist jetzt eines meiner Handicaps, aber es wird nicht lange dauern. Wenn ich es jedoch nicht verstehe, verstehe ich, dass ich gehen werde. Ich denke, ich werde es bekommen.

Am Ende spielt dabei die Unterstützung meines Teams eine große Rolle. Es ist immer willkommen, wenn sich eine Person Zeit nimmt, um mir zu helfen und mich in gute Gewohnheiten zu versetzen. Danach wäre es großartig, ein gutes Unterstützungsnetz zu haben. Es wäre immer dankbar, wenn jemand ein paar Mal später kommen und einen Code durchgehen würde, um zu sehen, wie alles fließt, nicht in einer Bewertung an sich, sondern eher als freundlicher Besuch.

Argumentation, Vorbereitung, Lehre, Nachverfolgung, Unterstützung.

Ich habe festgestellt, dass viele Programmierer den Wert des Testens auf einer rationalen Ebene sehen. Wenn Sie Dinge wie "Ja, ich weiß, ich sollte das testen, aber ich muss das wirklich schnell erledigen" gehört haben, dann wissen Sie, was ich meine. Auf emotionaler Ebene haben sie jedoch das Gefühl, dass sie etwas nur dann erledigen, wenn sie den echten Code schreiben.

Das Ziel sollte es also sein, sie irgendwie dazu zu bringen, zu verstehen, dass das Testen tatsächlich die einzige Möglichkeit ist, zu messen, wann etwas "getan" wird, und ihnen somit die intrinsische Motivation zu geben, Tests zu schreiben.

Ich fürchte, das ist viel schwieriger als es sein sollte. Sie werden viele Ausreden hören, die lauten: "Ich habe es wirklich eilig, ich werde dies später umschreiben / umgestalten und dann die Tests hinzufügen" - und natürlich passiert das Follow-up nie, weil sie überraschenderweise auftreten Ich bin in der nächsten Woche genauso beschäftigt .

Folgendes würde ich tun:

• Erstes Mal ... "Wir werden dieses Projekt gemeinsam durchführen. Ich werde die Tests schreiben und Sie werden den Code schreiben. Achten Sie darauf, wie ich die Tests schreibe, denn so machen wir die Dinge hier in der Nähe und das werde ich von dir erwarten. "

• Danach ... "Sie sind fertig? Großartig! Schauen wir uns zuerst die Tests an, die Ihre Entwicklung vorantreiben. Oh, keine Tests? Lassen Sie mich wissen, wann das erledigt ist, und wir planen die Überprüfung Ihres Codes neu. Wenn Sie ' Wenn Sie Hilfe bei der Formulierung der Tests benötigen, lassen Sie es mich wissen und ich werde Ihnen helfen. "

Er macht das schon. Ja wirklich. Er schreibt es einfach nicht auf. Nicht überzeugt? Beobachten Sie, wie er den Standardentwicklungszyklus durchläuft:

• Schreiben Sie einen Code
• Kompilieren Sie es
• Laufen Sie, um zu sehen, was es tut
• Schreiben Sie den nächsten Code

Schritt 3 ist der Test. Er testet bereits, er macht es nur manuell. Stellen Sie ihm diese Frage: "Woher wissen Sie morgen, dass der Code von heute noch funktioniert?" Er wird antworten: "Es ist so eine kleine Menge Code!"

Fragen Sie: "Wie wäre es mit nächster Woche?"

Wenn er keine Antwort hat, fragen Sie: "Wie soll Ihr Programm Ihnen sagen, wenn eine Änderung etwas kaputt macht, das gestern funktioniert hat?"

Darum geht es beim automatischen Unit-Test.

Als Junior-Programmierer versuche ich immer noch, mir angewöhnen, Tests zu schreiben. Natürlich ist es nicht einfach, neue Gewohnheiten zu erlernen, aber wenn ich darüber nachdenke, was diese Arbeit für mich bedeuten würde, muss ich die Kommentare zu Codeüberprüfungen und Coaching / Paarprogrammierung +1 geben.

Es kann auch sinnvoll sein, den langfristigen Zweck des Testens hervorzuheben: sicherzustellen, dass das, was gestern funktioniert hat, auch heute, in der nächsten Woche und im nächsten Monat noch funktioniert. Ich sage das nur, weil ich beim Überfliegen der Antworten das Erwähnte nicht gesehen habe.

Stellen Sie bei Codeüberprüfungen (wenn Sie sich dazu entschließen) sicher, dass Ihr junger Entwickler weiß, dass es nicht darum geht, ihn niederzulegen, sondern den Code zu verbessern. Weil auf diese Weise sein Vertrauen weniger wahrscheinlich beschädigt wird. Und das ist wichtig. Auf der anderen Seite wissen Sie auch, wie wenig Sie wissen.

Natürlich weiß ich nichts wirklich. Aber ich hoffe, die Worte waren nützlich.

Bearbeiten: [ Justin Standard ]

Lass dich nicht nieder, was du zu sagen hast, ist ziemlich richtig.

Zu Ihrem Punkt über Code-Überprüfungen: Sie werden feststellen, dass nicht nur der Junior-Entwickler dabei lernt, sondern auch die Überprüfer. Jeder in einer Codeüberprüfung lernt, ob Sie es zu einem kollaborativen Prozess machen.

Ehrlich gesagt, wenn Sie zu setzen haben , dass viel Mühe in immer ihm etwas zu tun , dann können Sie sich mit dem Gedanken kommen müssen , dass er nicht nur eine gute Passform für das Team sein kann, und kann gehen müssen. Das bedeutet nicht unbedingt, ihn zu entlassen ... es kann bedeuten, einen anderen Ort im Unternehmen zu finden, an dem seine Fähigkeiten besser geeignet sind. Aber wenn es keinen anderen Ort gibt ... wissen Sie, was zu tun ist.

Ich gehe davon aus, dass er auch ein ziemlich neuer Mitarbeiter ist (<1 Jahr) und wahrscheinlich vor kurzem die Schule verlassen hat. In diesem Fall ist er möglicherweise nicht daran gewöhnt, wie die Dinge in einem Unternehmen funktionieren. Solche Dinge könnten die meisten von uns im College durchstehen.

Wenn dies der Fall ist, habe ich festgestellt, dass es eine Art "überraschende Überprüfung neuer Mitarbeiter" gibt. Es ist egal, ob du es noch nie gemacht hast ... das wird er nicht wissen. Setzen Sie sich einfach hin und sagen Sie ihm, dass Sie seine Leistung überprüfen und ihm einige reelle Zahlen zeigen werden. Nehmen Sie Ihr normales Überprüfungsblatt (Sie haben einen formellen Überprüfungsprozess, oder?) Und ändern Sie die Überschrift, wenn Sie möchten, dass es so aussieht offiziell und zeigen ihm, wo er steht. Wenn Sie ihm in einer sehr formellen Umgebung zeigen, dass das Nichtdurchführen von Tests seine Leistungsbewertung nachteilig beeinflusst, anstatt ihn nur darüber zu "nörgeln", wird er hoffentlich den Punkt bekommen. Sie müssen ihm zeigen, dass seine Handlungen ihn tatsächlich beeinflussen, sei es in Bezug auf die Bezahlung oder auf andere Weise.

Ich weiß, vielleicht möchten Sie sich davon fernhalten, weil es nicht offiziell ist ... aber ich denke, Sie sind in einem vernünftigen Rahmen und es wird wahrscheinlich viel billiger sein, als ihn zu entlassen und jemanden neu zu rekrutieren.

Als Junior-Programmierer dachte ich, ich würde zeigen, wie es war, als ich mich in einer ähnlichen Situation befand wie Ihr Junior-Entwickler.

Als ich zum ersten Mal aus der Uni herauskam, stellte ich fest, dass es mich völlig unfähig gemacht hatte, mit der realen Welt umzugehen. Ja, ich kannte einige JAVA-Grundlagen und eine Philosophie (frag nicht), aber das war es auch schon. Als ich meinen Job bekam, war es gelinde gesagt ein wenig entmutigend. Lassen Sie mich Ihnen sagen, dass ich wahrscheinlich einer der größten Cowboys war. Ich würde einen kleinen Bugfix / Algorithmus ohne Kommentare / Tests / Dokumentation zusammen hacken und ihn aus der Tür schicken.

Ich hatte das Glück, unter der Aufsicht eines freundlichen und sehr geduldigen Senior-Programmierers zu stehen. Zum Glück entschied er sich, sich zu mir zu setzen und 1-2 Wochen damit zu verbringen, meinen sehr gehackten Togethor-Code durchzugehen. Er würde erklären, wo ich falsch gelaufen war, die Feinheiten von c und Zeiger (Junge hat mich verwirrt!). Wir haben es geschafft, in ungefähr einer Woche eine ziemlich anständige Klasse / ein Modul zu schreiben. Ich kann nur sagen, dass ich wahrscheinlich nicht lange durchgehalten hätte, wenn der leitende Entwickler nicht die Zeit investiert hätte, um mir auf dem richtigen Weg zu helfen.

Glücklicherweise würde ich 2 Jahre später hoffen, dass einige meiner Kollegen mich sogar als durchschnittlichen Programmierer betrachten.

Nehmen Sie Punkte mit nach Hause

1. Die meisten Universitäten sind sehr schlecht darin, Studenten auf die reale Welt vorzubereiten
2. Die gepaarte Programmierung hat mir wirklich geholfen. Das heißt nicht, dass es allen helfen wird, aber es hat bei mir funktioniert.

Weisen Sie sie Projekten zu, für die kein "stabiler Code von höchster Qualität" erforderlich ist, wenn dies Ihr Anliegen ist, und lassen Sie den jr. Entwickler scheitern. Lassen Sie sie diejenige sein, die am Wochenende hereinkommt, um ihre Fehler zu beheben. Essen Sie viel zu Mittag und sprechen Sie über Softwareentwicklungspraktiken (keine Vorträge, sondern Diskussionen). Mit der Zeit werden sie die Best Practices erwerben und entwickeln, um die ihnen zugewiesenen Aufgaben zu erledigen.

Wer weiß, vielleicht haben sie sogar etwas Besseres als die Techniken, die Ihr Team derzeit verwendet.

Wenn der Junior-Programmierer oder irgendjemand den Wert beim Testen nicht sieht, wird es schwierig sein, ihn dazu zu bringen, es zu tun ... Punkt.

Ich hätte den Junior-Programmierer dazu gebracht, sein Wochenende zu opfern, um den Fehler zu beheben. Seine Handlungen (oder deren Fehlen) wirken sich nicht direkt auf ihn aus. Machen Sie auch deutlich, dass er keine Fortschritte und / oder Gehaltserhöhungen sehen wird, wenn er seine Testfähigkeiten nicht verbessert.

Trotz all Ihrer Hilfe, Ermutigung und Betreuung passt er möglicherweise nicht zu Ihrem Team. Lassen Sie ihn also los und suchen Sie jemanden, der es bekommt.

Ich stimme dem Kommentar von RodeoClown zum Code zu, der jedes Commit überprüft. Sobald er es ein paar Mal geschafft hat, wird er es sich zur Gewohnheit machen, Sachen zu testen.

Ich weiß allerdings nicht, ob Sie solche Commits blockieren müssen. An meinem Arbeitsplatz kann jeder kostenlos alles festschreiben, und alle SVN-Festschreibungsnachrichten (mit Unterschieden) werden per E-Mail an das Team gesendet.

Hinweis: Sie möchten wirklich das Thunderbird Coloured-Diffs-Addon, wenn Sie dies vorhaben .

Mein Chef oder ich (die 2 "älteren" Programmierer) werden am Ende die Commits durchlesen, und wenn es Dinge wie "Sie haben vergessen, Komponententests hinzuzufügen" gibt, schnippen wir einfach eine E-Mail oder gehen und unterhalten uns mit der Person und erklären, warum sie benötigte Unit-Tests oder was auch immer. Alle anderen werden ermutigt, auch die Commits zu lesen, da dies eine großartige Möglichkeit ist, um zu sehen, was los ist, aber die Junior-Entwickler kommentieren nicht so viel.

Sie können dazu beitragen, die Menschen zu ermutigen, sich daran zu gewöhnen, indem Sie regelmäßig Dinge sagen wie "Hey, Bob, haben Sie das Commit gesehen, das ich heute Morgen gemacht habe? Ich habe diesen tollen Trick gefunden, mit dem Sie bla bla was auch immer tun können, das Commit lesen und sehen können wie es funktioniert!"

NB: Wir haben 2 Senior-Entwickler und 3 Junior-Entwickler. Dies ist möglicherweise nicht skalierbar, oder Sie müssen den Prozess möglicherweise mit mehr Entwicklern etwas anpassen.

1. Machen Sie die Codeabdeckung zu einem Teil der Überprüfungen.
2. Machen Sie "Schreiben Sie einen Test, der den Fehler aufdeckt" zur Voraussetzung für die Behebung eines Fehlers.
3. Erfordern eine bestimmte Abdeckung, bevor der Code eingecheckt werden kann.
4. Finden Sie ein gutes Buch über testgetriebene Entwicklung und zeigen Sie damit, wie Test-First die Entwicklung beschleunigen kann.

Viel Psychologie und hilfreiche "Mentoring" -Techniken, aber ehrlich gesagt läuft dies nur darauf hinaus, "Tests zu schreiben, wenn Sie morgen noch einen Job haben wollen".

Sie können es in allen Begriffen auslegen, die Sie für angemessen halten, hart oder weich, es spielt keine Rolle. Tatsache ist jedoch, dass Programmierer nicht dafür bezahlt werden, nur Code zusammen zu werfen und einzuchecken - sie werden dafür bezahlt, Code sorgfältig zusammenzustellen, dann Tests zusammenzustellen, dann ihren Code zu testen und dann das Ganze einzuchecken. (Zumindest So hört es sich nach Ihrer Beschreibung an.)

Wenn sich jemand weigert, seine Arbeit zu erledigen, erklären Sie ihm, dass er morgen zu Hause bleiben kann, und Sie werden jemanden einstellen, der die Arbeit erledigt.

Auch hier können Sie dies alles sanft tun, wenn Sie dies für notwendig halten, aber viele Menschen brauchen nur einen großen, harten Schlag auf das Leben in der realen Welt , und Sie würden ihnen einen Gefallen tun, indem Sie es ihnen geben.

Viel Glück.

Ändern Sie seine Stellenbeschreibung für eine Weile, um ausschließlich Tests zu schreiben und Tests aufrechtzuerhalten. Ich habe gehört, dass viele Unternehmen dies für eine Weile für neue, unerfahrene Leute tun, wenn sie anfangen.

Stellen Sie außerdem eine Herausforderung, während er in dieser Rolle ist: Schreiben Sie Tests, die a) mit dem aktuellen Code fehlschlagen, a) die Anforderungen der Software erfüllen. Hoffentlich wird er dadurch einige solide und gründliche Tests erstellen (das Projekt verbessern) und besser Tests schreiben können, wenn er sich wieder in die Kernentwicklung integriert.

Bearbeiten Sie> die Anforderungen der Software vollständig, was bedeutet, dass er nicht nur Tests schreibt, um den Code absichtlich zu brechen, wenn der Code diesen Testfall nie berücksichtigen wollte oder musste.

Wenn Ihr Kollege keine Erfahrung mit dem Schreiben von Tests hat, hat er oder sie möglicherweise Schwierigkeiten, Tests über einfache Situationen hinaus durchzuführen, und dies äußert sich in unzureichenden Tests. Folgendes würde ich versuchen:

• Verbringen Sie einige Zeit und teilen Sie Testtechniken wie Abhängigkeitsinjektion, Suche nach Randfällen usw. mit Ihrem Kollegen.
• Bieten Sie an, Fragen zum Testen zu beantworten.
• Führen Sie für eine Weile Codeüberprüfungen von Tests durch. Bitten Sie Ihren Kollegen, Ihre Änderungen zu überprüfen, die beispielhaft für gute Tests sind. Sehen Sie sich ihre Kommentare an, um festzustellen, ob sie Ihren Testcode wirklich lesen und verstehen.
• Wenn es Bücher gibt, die besonders gut zur Testphilosophie Ihres Teams passen, geben Sie ihm eine Kopie. Es kann hilfreich sein, wenn Ihr Code-Review-Feedback oder Ihre Diskussionen auf das Buch verweisen, damit er oder sie einen Thread zum Aufnehmen und Verfolgen hat.

Ich würde den Scham- / Schuldfaktor nicht besonders hervorheben. Es ist erwähnenswert, dass das Testen eine weit verbreitete und bewährte Methode ist und dass das Schreiben und Aufrechterhalten guter Tests eine professionelle Höflichkeit ist, damit Ihre Teamkollegen ihre Wochenenden nicht bei der Arbeit verbringen müssen, aber ich würde diese Punkte nicht näher erläutern.

Wenn Sie wirklich "hart werden" müssen, dann richten Sie ein unparteiisches System ein. niemand mag das Gefühl, herausgegriffen zu werden. Beispielsweise benötigt Ihr Team möglicherweise Code, um eine bestimmte Testabdeckung aufrechtzuerhalten (spielbar, aber zumindest automatisierbar). für Tests neuen Code benötigen; verlangen, dass Prüfer bei der Durchführung von Codeüberprüfungen die Qualität der Tests berücksichtigen; und so weiter. Die Einrichtung dieses Systems sollte aus dem Teamkonsens resultieren. Wenn Sie die Diskussion sorgfältig moderieren, können Sie andere Gründe aufdecken, aus denen die Tests Ihres Kollegen nicht Ihren Erwartungen entsprechen.

Es liegt in der Verantwortung seines Mentors, ihn / sie zu unterrichten. Wie gut bringen Sie ihm / ihr das Testen bei? Programmierst du mit ihm? Der Junior weiß höchstwahrscheinlich nicht, wie er einen guten Test für xyz erstellen soll.

Als Junior Freshout of School kennt er viele Konzepte. Eine Technik. Etwas Erfahrung. Aber am Ende ist alles, was ein Junior ist, POTENZIAL. Bei fast allen Funktionen, an denen sie arbeiten, wird es etwas Neues geben, das sie noch nie zuvor gemacht haben. Sicher, der Junior hat vielleicht ein einfaches Zustandsmuster für ein Projekt im Unterricht erstellt und "Türen" geöffnet und geschlossen, aber niemals eine reale Anwendung der Muster.

Er / sie wird nur so gut sein, wie Sie unterrichten. Wenn sie in der Lage wären, "Just get it" zu bekommen, hätten sie wohl überhaupt eine Junior-Position eingenommen?

Nach meiner Erfahrung werden Junioren eingestellt und haben fast die gleiche Verantwortung wie Senioren, werden aber nur weniger bezahlt und dann ignoriert, wenn sie ins Stocken geraten. Vergib mir, wenn ich bitter bin, weil ich es bin.

@ jsmorris

Ich hatte einmal den leitenden Entwickler und "Architekten", der mich und einen Tester (es war mein erster Job außerhalb des College) in einer E-Mail beschimpfte, weil ich nicht lange geblieben war und am Abend zuvor eine so "einfache" Aufgabe erledigt hatte. Wir waren den ganzen Tag dabei und haben es um 19 Uhr beendet. Ich hatte seit 11 Uhr vor dem Mittagessen an diesem Tag verprügelt und jedes Mitglied unseres Teams mindestens zweimal um Hilfe belästigt.

Ich antwortete und sagte dem Team: "Ich bin jetzt seit einem Monat von dir enttäuscht. Ich bekomme nie Hilfe vom Team. Ich werde im Café auf der anderen Straßenseite sein, wenn du mich brauchst. Ich bin Entschuldigung, ich konnte die Methode mit 12 Parametern und 800 Zeilen, von der fast alles abhängig ist, nicht debuggen. "

Nachdem ich mich eine Stunde im Café abgekühlt hatte, ging ich zurück ins Büro, schnappte mir meinen Mist und ging. Nach ein paar Tagen riefen sie mich an und fragten, ob ich reinkommen würde. Ich sagte, ich würde es tun, aber ich hatte ein Interview, vielleicht morgen.

"Also hörst du dann auf?"

In Ihrem Quell-Repository: Verwenden Sie Hooks vor jedem Commit (z. B. Pre-Commit-Hook für SVN).

Überprüfen Sie in diesem Hook, ob für jede Methode mindestens ein Anwendungsfall vorhanden ist. Verwenden Sie eine Konvention für die Organisation von Komponententests, die Sie problemlos über einen Pre-Commit-Hook durchsetzen können.

Kompilieren Sie auf einem Integrationsserver alles und überprüfen Sie regelmäßig die Testabdeckung mit einem Testabdeckungstool. Wenn die Testabdeckung für einen Code nicht 100% beträgt, blockieren Sie alle Festschreibungen des Entwicklers. Er sollte Ihnen den Testfall senden, der 100% des Codes abdeckt.

Nur automatische Überprüfungen können für ein Projekt gut skaliert werden. Sie können nicht alles von Hand überprüfen.

Der Entwickler sollte ein Mittel haben, um zu überprüfen, ob seine Testfälle 100% des Codes abdecken. Auf diese Weise ist es seine eigene Schuld, wenn er keinen zu 100% getesteten Code festschreibt, keine "Ups, sorry, ich habe es vergessen" -Fehler.

Denken Sie daran: Die Leute tun nie das, was Sie erwarten, sie tun immer das, was Sie inspizieren.

Zunächst einmal, wie die meisten Befragten hier betonen, können Sie nicht viel dagegen tun, wenn der Kerl den Wert beim Testen nicht sieht, und Sie haben bereits darauf hingewiesen, dass Sie den Kerl nicht feuern können. Allerdings ist Scheitern keine Option hier, also was ist mit den wenigen Dingen , die Sie können tun?

Wenn Ihre Organisation groß genug ist, um mehr als 6 Entwickler zu haben, empfehle ich dringend, eine Abteilung für Qualitätssicherung einzurichten (auch wenn es sich nur um eine Person handelt). Idealerweise sollten Sie ein Verhältnis von 1 Tester zu 3-5 Entwicklern haben. Die Sache mit Programmierern ist ... sie sind Programmierer, keine Tester. Ich habe noch keinen Programmierer interviewt, dem offiziell die richtigen QS-Techniken beigebracht wurden.

Die meisten Organisationen machen den fatalen Fehler, die Testrollen dem neuen Mitarbeiter zuzuweisen, der Person, die am wenigsten mit Ihrem Code in Berührung kommt. Idealerweise sollten die leitenden Entwickler in die QS-Rolle versetzt werden, da sie über die Erfahrung im Code verfügen und haben (hoffentlich) einen sechsten Sinn für Codegerüche und Fehlerstellen entwickelt, die auftreten können.

Darüber hinaus wird der Programmierer, der den Fehler gemacht hat, den Fehler wahrscheinlich nicht finden, da es sich normalerweise nicht um einen Syntaxfehler handelt (diese werden beim Kompilieren erfasst), sondern um einen Logikfehler - und dieselbe Logik ist beim Schreiben des Fehlers am Werk Test als wenn sie den Code schreiben. Lassen Sie die Person, die den Code entwickelt hat, diesen Code nicht testen - sie wird weniger Fehler finden als jeder andere.

Wenn Sie sich in Ihrem Fall den umgeleiteten Arbeitsaufwand leisten können, machen Sie diesen neuen Mitarbeiter zum ersten Mitglied Ihres QS-Teams. Lassen Sie ihn "Softwaretests in der realen Welt: Verbesserung des Prozesses" lesen, da er offensichtlich eine Schulung in seiner neuen Rolle benötigt. Wenn er es nicht mag, wird er aufhören und Ihr Problem ist immer noch gelöst.

Ein etwas weniger rachsüchtiger Ansatz wäre, diese Person das tun zu lassen, was sie kann (ich gehe davon aus, dass diese Person eingestellt wurde, weil sie tatsächlich im Programmierbereich des Jobs kompetent ist) und ein oder zwei Tester für die Tests einzustellen ( Universitätsstudenten haben oft Praktikums- oder "Koop" -Begriffe, würden die Belichtung lieben und sind billig)

Randnotiz: Schließlich möchten Sie, dass das QA-Team einem QA-Direktor oder zumindest nicht einem Softwareentwickler-Manager Bericht erstattet, da es ein Konflikt ist, wenn das QA-Team dem Manager Bericht erstattet, dessen Hauptziel es ist, das Produkt fertigzustellen Interesse.

Wenn Ihre Organisation kleiner als 6 ist oder Sie nicht mit der Erstellung eines neuen Teams durchkommen können, empfehle ich Paired Programming (PP). Ich bin kein totaler Konvertit aller extremen Programmiertechniken, aber ich glaube definitiv an gepaarte Programmierung. Beide Mitglieder des gepaarten Programmierteams müssen jedoch engagiert sein, sonst funktioniert es einfach nicht. Sie müssen zwei Regeln befolgen: Der Inspektor muss vollständig verstehen, was auf dem Bildschirm codiert wird, oder er muss den Codierer bitten, dies zu erklären. Der Codierer kann nur codieren, was er erklären kann - kein "du wirst sehen" oder "mir vertrauen" oder Handwinken wird toleriert.

Ich empfehle PP nur, wenn Ihr Team dazu in der Lage ist, da wie beim Testen kein Jubel oder keine Drohung ein paar introvertierte Ego-Introvertierte zur Zusammenarbeit überreden wird, wenn sie sich dabei nicht wohl fühlen. Ich finde jedoch, dass zwischen der Wahl des Schreibens detaillierter Funktionsspezifikationen und der Durchführung von Codeüberprüfungen im Vergleich zur gepaarten Programmierung das PP normalerweise gewinnt.

Wenn PP nichts für Sie ist, ist TDD die beste Wahl, aber nur, wenn es wörtlich genommen wird. Testgesteuerte Entwicklung bedeutet, dass Sie die Tests ZUERST schreiben, die Tests ausführen, um zu beweisen, dass sie tatsächlich fehlschlagen, und dann den einfachsten Code schreiben, damit sie funktionieren. Der Nachteil ist, dass Sie jetzt (sollten) eine Sammlung von Tausenden von Tests haben, die auch Code sind und genauso wahrscheinlich wie Produktionscode Fehler enthalten. Ich bin ehrlich, ich bin kein großer Fan von TDD, hauptsächlich aus diesem Grund, aber es funktioniert für viele Entwickler, die lieber Testskripte als Testfalldokumente schreiben möchten - einige Tests sind besser als keine. Koppeln Sie TDD mit PP, um die Wahrscheinlichkeit einer Testabdeckung und weniger Fehler im Skript zu erhöhen.

Wenn alles andere fehlschlägt, lassen Sie die Programmierer einem Schwurglas gleichwertig sein - jedes Mal, wenn der Programmierer den Build bricht, müssen sie 20, 50, 100 US-Dollar (was für Ihre Mitarbeiter mäßig schmerzhaft ist) in ein Glas geben, das an Ihren Favoriten geht ( registriert!) Wohltätigkeitsorganisation. Bis sie zahlen, meide sie :)

Abgesehen von allen Scherzen ist der beste Weg, Ihren Programmierer dazu zu bringen, Tests zu schreiben, ihn nicht programmieren zu lassen. Wenn Sie einen Programmierer wünschen, stellen Sie einen Programmierer ein - Wenn Sie Tests wünschen, stellen Sie einen Tester ein. Ich habe vor 12 Jahren als Junior-Programmierer angefangen, Tests zu machen, und es wurde zu meinem Karriereweg, und ich würde es nicht gegen irgendetwas eintauschen. Eine solide QS-Abteilung, die ordnungsgemäß gepflegt wird und die Befugnis und das Mandat zur Verbesserung der Software erhält, ist genauso wertvoll wie die Entwickler, die die Software überhaupt erst schreiben.

Das mag ein bisschen herzlos sein, aber so wie Sie die Situation beschreiben, klingt es so, als müssten Sie diesen Kerl feuern. Oder machen Sie es zumindest klar: Wenn Sie sich weigern, die Hausentwicklungspraktiken (einschließlich des Schreibens von Tests) zu befolgen, und wenn Sie fehlerhaften Code einchecken, den andere Leute bereinigen müssen, werden Sie schließlich entlassen.

Der Hauptgrund, warum Nachwuchsingenieure / Programmierer nicht viel Zeit für das Entwerfen und Ausführen von Testskripten benötigen, liegt darin, dass die meisten CS-Zertifizierungen dies nicht unbedingt erfordern. Daher werden andere Bereiche des Ingenieurwesens in College-Programmen weiter behandelt, z. B. Konstruktionsmuster.

Nach meiner Erfahrung besteht der beste Weg, um die Nachwuchskräfte zur Gewohnheit zu machen, darin, sie explizit in den Prozess einzubeziehen. Das heißt, wenn die Zeit geschätzt wird, die eine Iteration dauern sollte, sollte die Zeit des Entwurfs, des Schreibens und / oder der Ausführung der Fälle in diese Zeitschätzung einbezogen werden.

Schließlich sollte die Überprüfung des Testskriptdesigns Teil einer Entwurfsüberprüfung sein, und der tatsächliche Code sollte in der Codeüberprüfung überprüft werden. Dies macht den Programmierer dafür verantwortlich, jede von ihm geschriebene Codezeile ordnungsgemäß zu testen, und der leitende Ingenieur und seine Kollegen sind verpflichtet, Feedback und Anleitungen zu dem geschriebenen Code und Test zu geben.

Basierend auf Ihrem Kommentar "Zeigen, dass das Design einfacher wird" gehe ich davon aus, dass Sie TDD üben. Eine Codeüberprüfung nachträglich durchzuführen, wird nicht funktionieren. Das Ganze an TDD ist, dass es ein Design und keine Testphilosophie ist. Wenn er die Tests nicht als Teil des Entwurfs geschrieben hat, werden Sie nicht viel davon profitieren, wenn Sie Tests nachträglich schreiben - insbesondere von einem Junior-Entwickler. Er wird am Ende eine ganze Reihe von Eckfällen verpassen und sein Code wird immer noch beschissen sein.

Ihre beste Wette ist es, einen sehr geduldigen Senior-Entwickler zu haben, der sich zu ihm setzt und ein paar Programme programmiert. Und bleib dran, bis er es lernt. Oder lernt nicht, in welchem ​​Fall Sie ihn einer Aufgabe zuweisen müssen, für die er besser geeignet ist, weil Sie am Ende nur Ihre echten Entwickler frustrieren.

Nicht jeder hat das gleiche Talent und / oder die gleiche Motivation. Entwicklungsteams, auch agile, bestehen aus Personen im "A-Team" und Personen im "B-Team". A-Team-Mitglieder sind diejenigen, die die Lösung entwerfen, den gesamten nicht trivialen Produktionscode schreiben und mit den Geschäftsinhabern kommunizieren - all die Arbeiten, die ein Umdenken erfordern. Das B-Team kümmert sich um Dinge wie Konfigurationsmanagement, das Schreiben von Skripten, das Beheben lahmer Fehler und das Durchführen von Wartungsarbeiten - all diese Arbeiten haben strenge Verfahren, die kleine Konsequenzen für den Ausfall haben.