Der Projektleiter bittet bei jeder Codeübergabe um vollständiges 100%iges Vertrauen

Wie soll ich in diesem Fall auf seine Frage antworten, ohne inkompetent zu wirken? Ehrlich gesagt habe ich niemals 100%iges Vertrauen in die gesamte Website, aber ich habe Vertrauen in meine Testmethoden. Und als Entwickler weiß ich auch, dass es nicht ungewöhnlich ist, dass unerwartete Fehler später aus diesen Kernveränderungen auftauchen.

Der Projektleiter versteht Software nicht gut genug und versteht das Testen sicherlich nicht gut genug. Vielleicht muss er geschult werden.

Wenn Sie eine professionelle QA-Abteilung hätten, würde ich Ihnen sagen, dass Sie die Unterstützung des QA-Managers in Anspruch nehmen sollten, um diesem Projektmanager die Art der Software, die Art der Fehler und die Art des Testens zu erklären. Ich würde mir vom QA-Manager erklären lassen, warum es einfach nicht möglich ist, jede Bedingung zu testen, und wie das Freigeben/Nicht-Freigeben eine Geschäftsaktivität ist, die durch die Erkenntnisse aus dem Testen, aber niemals durch perfekte Informationen unterstützt wird.

Vielleicht möchten Sie ein Exemplar von Gerald Weinbergs ausgezeichnetem Buch “* Perfect Software and other illusions about testing **” erhalten. In Kapitel 3 (“Warum nicht einfach alles testen?”) hat Weinberg einen Abschnitt mit dem Titel “Es gibt eine unendliche Anzahl möglicher Tests”.

Er spricht von einer Hintertür, die in ein hochsicheres Programm gesetzt wurde, wobei der gewöhnliche Passwortschutz umgangen werden konnte, indem man W gefolgt von drei Leerzeichen, dann M gefolgt von drei Leerzeichen, dann J gefolgt von genau 168 weiteren Tastenanschlägen tippte, ohne einmal den Buchstaben L zu verwenden.

Dann schreibt er: “Haben Sie den Punkt inzwischen verstanden? Wenn Sie nicht geahnt haben, dass die Anzahl der Tests, die erforderlich sind, um Software erschöpfend zu testen, unendlich ist, oder zumindest "eine Zahl, die größer ist, als ich in meinem Leben laufen könnte”, haben Sie den Sinn dieses Kapitels nicht verstanden. Jetzt verstehen Sie es"

Erklären Sie Ihrem Projektleiter, dass jeder Tag zusätzlicher Tests Ihr Vertrauen in Ihren Code etwas verbessern wird, dennoch kann es nie 100% erreichen. Sagen Sie ihm, dass Sie gerne auf Kosten Ihrer anderen produktiven Arbeit weiter testen würden. Fragen Sie ihn dann, wie viele Tage Sie seiner Meinung nach noch für das Testen aufwenden sollen und welche Ihrer anderen Arbeiten zurückgestellt werden sollen.

Wenn Ihr Projektleiter es immer noch nicht kapiert und Sie sich etwas leichtfertig fühlen, fragen Sie ihn, ob er 100%ig sicher ist, dass jede von ihm veröffentlichte Schätzung genau richtig ist und die Termine niemals verpasst werden. Fragen Sie ihn, ob er zu 100% sicher ist, dass keine E-Mail, die er von jetzt bis in alle Ewigkeit schreibt, jemals einen Tippfehler haben wird. Fragen Sie ihn, ob er sich zu 100% sicher ist, dass er niemals einen Fehler machen wird - jetzt und in Zukunft.

Boss: Sind Sie zu 100 % sicher, dass dieser Fix keine bestehenden Funktionen bricht oder nachteilige Auswirkungen auf die Benutzererfahrung hat?

Me: Nein. Da wir keine Testsuite mit 100-prozentiger Abdeckung haben, gibt es keine Möglichkeit, zu überprüfen, ob eine Codeänderung einen Anwendungsbruch oder nachteilige Auswirkungen verhindert. Ich habe jedoch die folgenden Maßnahmen durchgeführt, um sicherzustellen, dass sie wahrscheinlich nicht unbeabsichtigt durchgeführt wird:

• Ich habe den Umfang der Änderung auf das Modul beschränkt, auf das sie sich auswirkt
• Ich habe die Dokumentation entsprechend gelesen und aktualisiert
• Ich habe die Unit-Tests für dieses Modul und die betroffenen Module durchgeführt
• Ich habe Unit-Tests erstellt, um neu hinzugekommene Funktionalität zu überprüfen, und veraltete Tests, die aufgrund der Änderung nicht mehr relevant sind

Obwohl ich Ihnen nicht genau 100%ige Sicherheit geben kann, habe ich innerhalb des Zeitrahmens, den ich für die Implementierung dieser Funktionalität für angemessen halte, so viel Sicherheit wie möglich gegeben. Tatsächlich bin ich bereits an dem Punkt angelangt, an dem die Erträge abnehmen. Ich kann weitere 5 Stunden damit verbringen, Ihnen weitere 0,1% Sicherheit zu geben, aber die Wahrscheinlichkeit ist bereits so gering, dass ein solcher Aufwand nicht gerechtfertigt ist. Sie sind jedoch für das Projekt und den Zeitrahmen verantwortlich, also lassen Sie mich wissen, wie viel mehr Zeit ich für diese Funktion aufwenden soll.

Jetzt ist er am Zug. Wenn er wirklich will, dass ich meine persönliche Schätzung von, sagen wir, 95% sicher auf 95,1% sicher für ein paar Stunden mehr Arbeit verschiebe, dann hey - das kann ich tun.

Wenn er weiterhin unausstehlich dabei ist, werde ich mit ihm und dem “Eigentümer” des Projekts ein E-Mail-Gespräch über diese “100%-geprüfte” Anforderung führen und darüber, welche Ressourcen meiner Meinung nach erforderlich sind, um sie zu erfüllen.

Als Entwickler testen Sie als UNIT die Änderungen an Ihrem Code. Meiner Meinung nach (als Entwickler), d.h. zu überprüfen, dass es keine offensichtlichen Fehler gibt, alles kompiliert, alle Fehler sind gefangen. Sie haben keine Möglichkeit zu wissen, auf welche Szenarien Sie stoßen werden, wenn der Code live geht (schlechte Daten, unerwartete Eingaben, Änderungen in der Client-Software, die Liste ist endlos)

Um 100%ig sicher sein zu können, dass eine Änderung nichts beeinträchtigt, bräuchten Sie eine Testumgebung, die die Live-Umgebung GENAU widerspiegelt (Daten, Hardware, Berechtigungen, Konnektivität) und eine Reihe von Testskripten, die jedes einzelne Szenario abdecken. Dies ist bekanntlich aus verschiedenen Gründen eine praktisch unmöglich zu erstellende Umgebung

Wenn er 100% Vertrauen erwartet, dann muss er die Umgebung und die Arbeitskräfte bereitstellen, die seine Erwartungen unterstützen

Es ist ein wenig wie wenn Projektmanager und Kunden nach zukunftssicheren Dingen fragen!

Es klingt, als sei er einer schlechten Angewohnheit verfallen. Er stellt eine Frage, von der er weiß, dass sie auf irgendeiner Ebene dumm ist. Aber sie hat auch ein zwanghaftes Element. Ich vermute, dass er aus einer zugrunde liegenden Angst heraus handelt, und wenn er eine unangemessene Frage stellt, fühlt er sich besser unter Kontrolle.

In solchen Situationen versuche ich, die Dynamik zu zerstreuen, indem ich zuversichtlich bin und ein wenig Humor einbringe. Wenn Sie verstehen, dass seine Frage nicht aus der Argumentation kommt, sondern aus der Angst, dann können Sie das besser indirekt als direkt ansprechen.

In solchen Situationen zerstreue ich normalerweise die Ängste des Managements, indem ich alle Maßnahmen vorstelle, die ich zur Sicherung der Qualität ergriffen habe. Er ist schließlich der Kunde, und er muss wissen, dass Ihre Prioritäten mit seinen übereinstimmen. Schauen Sie sich diese Unit-Tests an. Schauen Sie sich diese Überwachung an. Sehen Sie sich an, wie der Code strukturiert ist, um Änderungen lokal und modular zu halten. usw. Wenn Sie ein Gefühl des Vertrauens und der Kontrolle vermitteln, wird das seine Ängste zerstreuen, und Sie werden wahrscheinlich in der Lage sein, ein rationaleres Gespräch zu führen.

Da kommt die Kunst dieses Geschäfts ins Spiel. Nicht nur “funktioniert es”, sondern der Kunde fühlt sich wohl dabei.

Letztendlich ist es aber eine Geschäftsbeziehung. Wenn die Vertragsgestaltung für Sie angenehm und gewinnbringend ist, dann lohnt es sich, diese Marotte in Kauf zu nehmen. Es klingt nicht so, als ob er es so ernst meint, nur irgendwie hartnäckig. Wie ich schon sagte, hat er eine lästige Angewohnheit entwickelt. Wenn er anfängt, feindselig zu reagieren, und der Ton noch feindseliger wird, dann könnte es sich aufgrund der Ausgewogenheit der geschäftlichen Vereinbarung für Sie nicht lohnen. Aber nach Ihrer kurzen Beschreibung klingt es für mich so, als könnten Sie die Beziehung immer noch effektiv managen.

Viele Leute haben dies als ein Bildungsproblem beschrieben, und ich sage nicht, dass sie sich irren.

Es ist auch möglich, dass es ein politisches Problem ist. Was die Frage eigentlich bedeuten könnte, ist, dass der Projektleiter von der Verantwortung für eventuelle Fehler freigesprochen werden möchte. Er bekommt von Ihnen eine eidesstattliche Erklärung, auf die er sich “vernünftigerweise” verlassen kann, und wenn etwas schief geht, sagt er, dass er alles getan hat, um es zu verhindern, aber Sie sind gescheitert.

Das ist kein gutes Management und es ist auch nicht hundertprozentig garantiert, dass er aus der Verantwortung entlassen wird, wenn es zu Schwierigkeiten kommt.

Ich gebe zu, dass dies Spekulation meinerseits ist, aber Übungen, die den Hintern bedecken, sind im Berufsleben überhaupt nicht ungewöhnlich, und man muss sich damit auseinandersetzen. Wenn das also wahr klingt, dann ist das, was man tun muss, um das Problem zu lösen, nicht nur die Erziehung des Managers, dass hundertprozentiges Vertrauen unmöglich ist. Sie müssen ihn auch davon überzeugen, dass ein Fehler keine Katastrophe ist - weder für ihn persönlich noch für das Unternehmen.

Das könnte zum Beispiel bedeuten, dass man Beispiele dafür liefert, wie Fehler zu vernünftigen Kosten und ohne herumfliegende Schuldzuweisungen behoben werden können. Es könnte bedeuten, dass er seine eigene Unternehmenskultur unter die Lupe nehmen muss, ob es im Unternehmen noch jemanden gibt, der sich darauf vorbereitet, ihm ungerechtfertigte Vorwürfe zu machen, wenn etwas schief geht. Es könnte auch bedeuten, Verfahren einzuführen, um zukünftige Fehler so schnell und kostengünstig wie möglich zu beheben. Wenn das Unternehmen wirklich 100 % Vertrauen in den Kodex hätte, dann wären solche Verfahren sinnlos, weil es bereit wäre, willkürlich große Geldbeträge darauf zu setzen, dass es keine zukünftigen Fehler gibt!

Wenn er (der Arbeitgeber) Sie (den Auftragnehmer) bittet, ihm eine Zusicherung zu verkaufen, dass Sie ihm keine Zusicherung bezüglich Ihrer Arbeit geben können, und nichts wird seine Meinung in diesem Punkt ändern, dann können Sie nur klar sagen, dass Sie nicht in der Lage sind, diese Zusicherung zu geben, und dass er gerne jemand anderen einstellen kann, wenn er glaubt, dass es jemanden gibt, der das kann. Natürlich ist das noch ein langer Weg, aber Sie könnten genauso gut Ihre BATNA kennen, bevor Sie anfangen.

** Streng genommen kann man nie 100% sicher sein, dass ein Commit ein Programm nicht kaputt macht.**

Sogar mit allen möglichen Arten von Tests (Unit-Test, Integration, Komponente, System, Handbuch, UI, Fuzz, Sicherheit, Penetration … Sie nennen es). Dies ist auf ein Halteproblem zurückzuführen. Ein relevanter Auszug aus der Wikipedia folgt unten:

In der Berechenbarkeitstheorie kann das Halteproblem wie folgt angegeben werden: “Bei der Beschreibung eines beliebigen Computerprogramms ist zu entscheiden, ob das Programm zu Ende läuft oder für immer weiterläuft”. Dies ist äquivalent zu dem Problem, bei einem Programm und einer Eingabe zu entscheiden, ob das Programm schließlich stoppt, wenn es mit dieser Eingabe läuft, oder ob es ewig weiterläuft.

Alan Turing bewies 1936, dass ein allgemeiner Algorithmus zur Lösung des Halteproblems für alle möglichen Programm-EingabePaare nicht existieren kann. Ein wichtiger Teil des Beweises war eine mathematische Definition von Computer und Programm, die als Turingmaschine bekannt wurde; das Halteproblem ist über Turingmaschinen unentscheidbar.

Wenn Ihrem PM Wert und stabile vorhersagbare Lieferung wichtig sind, können Sie ihn vielleicht überzeugen, einen Blick auf SCRUM framework zu werfen.

Andere haben viele interessante Ratschläge gegeben, wie man mit Ihrem PM interagiert. Ich persönlich würde empfehlen, ein Treffen mit Ihrem Premierminister und dem Team zu arrangieren, bei dem Sie Ihre Prozesse besprechen können. Ich spreche mich nachdrücklich für SCRUM aus, so dass dies weitgehend mit dem SCRUM zusammenhängen würde.

Ich würde versuchen zu erklären, dass ein Ziel von 100% schwer zu erreichen ist. Es kann nicht erreicht werden. Es kann nicht erreicht werden. Im ganzen Universum. Die Geschichte hat viele solcher Beispiele gesehen, Demo der Veröffentlichung von Windows 95 zum Beispiel. Vor langer Zeit? Nun, schauen Sie sich an, wie viele rote Builds auf einem öffentlichen CI-Server für Open-Source-Projekte erstellt wurden; loggen Sie sich als Gast ein, wenn Sie dort kein Konto haben. Zweitens würde ich Ihnen raten, eine Praxis einzuführen, bei der Sie einen Wert liefern können, anstatt das Vertrauen eines Commits. Etwas, das den Kunden wichtig ist. Iterativ, wiederholt und zuverlässig. Jetzt können Sie die Perspektive Ihres Premierministers von der 100-prozentigen Zusicherung auf etwas umstellen, das wirklich zählt. Das heißt: Software ist im Einsatz, Ihr Produkt verbessert sich, und das Team liefert dem Kunden einen Mehrwert.

Drittens: Das sollte eine Definition von erledigt sein. Etwas, das sich ein Entwicklungsteam einfallen lässt. Dazu können gehören: Dokumentation, Implementierung, Testen, Quality Gates usw. Dies ist sehr wichtig, da Sie nun die Subjektivität (d.h. “Sind Sie 100% sicher?”) auf Objektivität (d.h. alle Aufzählungspunkte der Definition von “fertig” sind abgeschlossen) verschieben können.

Es gibt weitere sehr wichtige Schritte, die SCRUM fördert. Aber alle diese Schritte würden es den Entwicklern ermöglichen, eine solche Frustration zu mildern und im Vergleich zur subjektiven Gewissheit ein objektiv quantifizierbares Ergebnis zu liefern.

Die übliche Antwort für diese Art von Ziel ist Peer-Review und Regressionstests.

1) Übergeben Sie nichts an den produktiven Code-Stream, bis nicht nur der Autor, sondern auch ein oder mehrere andere Programmierer ihn auf Gesundheit überprüft haben, um sicherzustellen, dass er nur das ändert, was notwendig ist, dass er alle vereinbarten Kriterien für gute Programmierpraxis erfüllt, dass er mit einem Test kommt, der Ihnen anständige Chancen gibt, zu erkennen, ob eine spätere Änderung die Logik erneut bricht, und so weiter.

2) Übergeben Sie nichts an den produktiven Code-Stream, bis ALLE Regressionstests wiederholt wurden und nachgewiesen wurde, dass es nichts bricht, wofür der Test durchgeführt wurde. Wenn während dieses Tests ein Fehler auftritt, muss die Änderung zurückgenommen werden, bis eindeutig festgestellt werden kann, dass sie das Problem nicht verursacht hat.

3) Alpha- und Betatest frühzeitig und oft mit realen Kundenszenarien. Kunden werden mit Ihrem Code Dinge tun, die Sie nie erwartet hätten.

Keines dieser Szenarien ist 100%ig, auch nicht deren Kombination. Aber sie bringen Sie einander erheblich näher. Sie erfordern eine nicht triviale Investition zusätzlicher Ressourcen. Sie verlangsamen die Entwicklung im Vergleich zur Skunkwork-Codierungspraxis “mach es einfach, und wir reparieren es, wenn es kaputt geht”. Aber wenn Sie wirklich fehlerfreien Code wollen, sind die Erkenntnis, dass Menschen straucheln können, und die Einführung von Praktiken, die helfen, Fehler aufzufangen, bevor sie die Kunden erreichen, diese Kosten mehr als wert.

Mir wurde gesagt, dass es nie einen Fehler in dem Code gab, den IBM für die NASA geschrieben hat - weil er während des Entwurfs, während der Entwicklung und vor der Veröffentlichung von Experten begutachtet und bis zum Tode getestet wurde.

Wenn Sie etwas Lebenskritisches tun, ist es diese Investition offensichtlich wert. Wenn Sie etwas tun, das die Infrastruktur für große Unternehmen darstellt, ist es diese Investition wert; Sie wollen nicht derjenige sein, dessen Fehler die Geschäftsprozesse eines Milliarden-Dollar-Unternehmens zum Scheitern bringt.

Ja, es macht gute Programmierer verrückt. Bis es ihnen das erste Mal den Hintern rettet.

Die Wahrheit ist, dass die Tests schlecht sind. Die Realität ist, dass ein Unternehmen, das nicht bereit ist, in ein QS-Team zu investieren, schlechte Tests haben wird. Gute Tests sind teuer und brauchen Zeit. Das Unternehmen hat das Risiko in Kauf genommen, indem es die Zeit und das Geld nicht genehmigt hat.

Selbst ein QA-Team kann nicht garantieren, dass jede Möglichkeit getestet wird, weil die möglichen Wege durch ein komplexes Programm im Grunde unendlich sind. Sie werden Sie jedoch viel näher bringen, als Sie es im Moment sind. Ein Grund dafür ist, dass es für einen Entwickler unmöglich ist, seinen eigenen Code angemessen zu testen. Sie wissen, was er tut, also neigen sie dazu, Tests um das herum zu entwerfen, was sie glauben, dass er tun soll. Sie übersehen Randfälle, sie übersehen dumme Dinge, die Benutzer tun, die ein Entwickler niemals tun würde, weil sie wissen, wie es funktioniert, sie interpretieren manchmal die Anforderung falsch, aber alle ihre Tests werden ihre ursprüngliche falsche Interpretation widerspiegeln. Sie übersehen oft Fehler in der Anforderung und tun das, was von ihnen verlangt wird, nicht das, was sie hätten tun sollen (dies ist die Ursache für eine große Anzahl von Fehlern, die erst gefunden werden, nachdem die tatsächlichen Benutzer [die allzu oft nicht bei der Definition der Anforderung konsultiert werden] versuchen, die Software zu benutzen). Sie übersehen Auswirkungen auf Teile der Anwendung, an denen sie nie Grund hatten zu arbeiten, insbesondere auf Teile, die von Spezialisten durchgeführt werden (wie z.B. eine Tabellenänderung, die für die Anwendung sinnvoll ist, aber einen automatisierten Importprozess oder einen Bericht unterbricht)

Wenn er eine höhere Qualität wünscht, muss er dafür Zeit und Geld bezahlen. Selbst mit vollständiger QA kann man nicht zu 100% erreichen, obwohl die NASA und ihre Auftragnehmer sicherlich nahe dran sind. Sie geben auch ein großes Geschäft mehr Geld aus, als Ihr Unternehmen ausgibt. Selbst dann haben sie es einmal geschafft, MARS komplett zu verpassen.

Wenn er die Gewissheit haben will, dass ihm keine Probleme mit den Kunden schaden, dann sprechen Sie über Ihren Prozess für die Tests (Zeigen Sie ihm die Liste der Tests, die Sie durchgeführt haben.), darüber, was Ihrer Meinung nach betroffen wäre und wie Sie das überprüft haben, über Ihren Prozess, wie Sie einen schlechten Push rückgängig machen würden und über Ihren Prozess für die Protokollierung von Fehlern, so dass Sie sie sehen, bevor die meisten Kunden sie bemerken. Geben Sie ihm das Vertrauen, dass selbst wenn es ein Problem gibt, es behoben werden kann. Sprechen Sie darüber, wie wertvoll es ist, den Code (neue Funktion oder Fehlerbehebung) schnell herauszubekommen, anstatt die zusätzliche Zeit, die ein gründlicherer Test erfordern würde, in Kauf zu nehmen. Sie können ihn auch bitten, bei jeder Änderung einen gründlichen Regressionstest des Systems durchzuführen, da es für einen Entwickler nicht möglich ist, seine eigene Arbeit vollständig zu testen (Sie wissen, was Ihre Annahmen waren, wenn sie nicht richtig sind, würden Sie nie darauf testen). Stellen Sie sicher, dass er weiß, dass er jede einzelne Seite der Anwendung und jede einzelne Sache, die auf einer Seite gemacht werden könnte, in jeder möglichen Reihenfolge testen muss. Oh ja, testen Sie auch alle Importe/Exporte, Berichte, automatisierte Jobs. Und alle verwandten Anwendungen, die davon betroffen sein könnten. Wenn er einmal versucht hat, das System gründlich zu üben, wird ihm klar werden, warum Sie diese Zusicherung nicht machen können.

Eine andere Sache, die Sie versuchen sollten, ist, ihm von vornherein zu sagen, dass Sie diese Zusicherung nicht machen können, aber wenn er X Teststunden genehmigt, können Sie näher an diese Zusicherung herankommen. Geben Sie ihm eine aufgeschlüsselte Liste der zusätzlichen Tests und der Stunden, die es dauern würde, jeden einzelnen Test zu entwerfen und durchzuführen. Sagen Sie ihm, wie viel Prozent des Vertrauens Sie nach der Durchführung all dieser Tests haben würden und wie viel Prozent des Vertrauens Sie im Moment haben.

Sagen Sie ihm auch, wie lange es dauern würde, nur alle aktuellen Einheitstests durchzuführen, die Sie haben, unabhängig davon, ob sie mit diesem Thema zu tun haben oder nicht. Wenn Sie also derzeit 1000 Unit-Tests haben und jeder einzelne fünf Minuten für die Einrichtung, Durchführung und Auswertung der Ergebnisse benötigt, wären das 83 Stunden. Bitten Sie ihn um die Genehmigung, diese Zeit in Anspruch zu nehmen.

Wenn er Sie tatsächlich während des gesamten Prozesses der Erstellung des Projekts auf dem Mikromanager hat und Ihnen über die Schulter schaut, gibt es einen einfachen Weg, um sicherzustellen, dass Sie 100 % Vertrauen “garantieren” können, ohne dass er Sie später damit verhökert.

Bitte ihn, es selbst zu genehmigen

Um es klar zu sagen, Sie sollten dies nicht als Forderung, sondern als Vorschlag formulieren, dass, wenn er wirklich 100 % perfekten Code will, er sich selbst ansehen sollte, was Sie tun, und jede Änderung, die Sie auf dem Weg dorthin vornehmen, genehmigen sollte. Das soll nicht heißen, dass er den Code wörtlich lesen soll, sondern eher, dass er ihn in Aktion sehen und bestätigen soll, ‘ja, so sollte er sich verhalten’.

Wenn Sie der einzige Tester Ihres eigenen Codes sind, ist das nicht unvernünftig - Sie sind bereits voll auf das Projekt konzentriert, und wenn er Perfektion will, sollte er selbst die Verantwortung dafür übernehmen, diese Perfektion sicherzustellen.

Machen Sie sich auch Notizen über alles, was er genehmigt, damit Sie später, wenn es unweigerlich kaputt geht, auf Ihre Dokumentation verweisen können, aus der hervorgeht, dass er es genehmigt hat.

Wenn Sie aus irgendeinem Grund der Meinung sind, dass dies nicht gut ankommen würde (z.B. wenn Sie bereits wissen, dass es katastrophal wäre, ihn zu bitten, mehr Arbeit zu erledigen), dann können Sie wirklich nur so viele harte Fehlertests wie möglich durchführen, schreiben Sie in Ihre Berichte alles, von dem Sie wissen, dass es korrekt funktioniert, und geben Sie ihm die hundertprozentige Zusicherung, dass ‘ich innerhalb der Grenzen meiner Tests zu 100 % von diesen Änderungen überzeugt bin’.

Leider sind Sie vielleicht in der Lage, einen ‘Chef’ zu haben, dessen Verständnis für Ihre Arbeit begrenzt ist, was immer eine Qual ist, wenn es darum geht, zu erklären, dass eine Fehlerkorrektur nicht mit 100%iger Sicherheit möglich ist. Zusammenfassend kann man also sagen, dass Sie am besten einfach Ihr Bestes tun, alles aufzeichnen und zu verstehen geben, dass Sie innerhalb Ihrer eigenen Grenzen tun, was Sie können.

Einige nette Antworten hier, der Premierminister muss definitiv aufgeklärt werden und ein wenig darüber lernen, was es bedeutet, Software zu schreiben.

Ich möchte nichts davon wiederholen, sondern eine weitere, eher ungewöhnliche Idee einwerfen. Diese Methode ist ziemlich riskant und hängt sehr stark davon ab, wie hoch Ihr Ansehen ist, wie gut Ihre Fähigkeiten sind (oder mehr noch, wie sie wahrgenommen werden), und sowohl von Ihrer Persönlichkeit als auch von der Ihres Premierministers. Ich gehe davon aus, dass Sie ihn nicht missverstanden haben, und er meint wirklich 100 % (ich sehe oft Leute, die 100 % sagen, aber in Wirklichkeit meinen, “tue das Beste, was du kannst”)

Bei mir hat es einmal funktioniert, und das ist der einzige Grund, warum ich es hier erwähne. Sie sind gewarnt worden. Das ist meistens eine Möglichkeit, einen Premierminister zu erziehen, wenn alle anderen Mittel versagen.

Manchmal will ein Premierminister (oder jeder andere Manager) einfach nicht zuhören, also muss man ihn (oder das Team) irgendwo gegen eine Wand schlagen lassen, damit er für einen Moment innehält und nachdenkt. In diesem Szenario bedeutet das: Arbeiten Sie so gut Sie können, versuchen Sie, so gut Sie können zu testen. Geben Sie Ihr Bestes und sagen Sie dann: “Ja, ich bin 100% sicher, dass das funktionieren wird”.

Wenn Sie extrem viel Glück haben, wird niemals ein Fehler auftreten und alle sind glücklich; aber in Wirklichkeit passiert folgendes: Es gibt einen Fehler. Was werden Sie jetzt tun? Sie geben zu, dass Sie einen Fehler gemacht haben. Stellen Sie einen Zusammenhang her mit Bugs und dem Fehler, 100% sicher zu sein. Menschen sind unvollkommen und können Fehler in Software erzeugen. Menschen sind unvollkommen und können Fehler in Tests erzeugen. Folglich sind Menschen unvollkommen und können “Fehler erzeugen” in ihrer Wahrnehmung, 100% sicher zu sein, dass es keinen Fehler gibt.

Präsentieren Sie dies gut und 100% wasserdicht (haha, j/k, wieder die 100%). Stellen Sie sicher, dass nach all dem die Botschaft “Ich kann nicht 100%ig sicher in meinen Tests sein” übermittelt wird. Wenn der Premierminister dann nicht den logischen Schritt “Dies wird für alle Entwickler das Gleiche sein” machen kann, dann ist wahrscheinlich alle Hoffnung verloren…

Aber bitte, versuchen Sie zuerst andere Dinge!

Der Schlüsselindikator ist, dass es sich um eine kürzlich erfolgte Änderung handelt. Etwas (oder jemand) hat Ihrem Premierminister wahrscheinlich eine schlechte Erfahrung beschert, und jetzt ist er jedes Mal nervös, wenn sich etwas ändert. Oder vielleicht hat er etwas in einem Buch oder einer Zeitschrift gelesen.

Wenn Sie den Premierminister dazu bringen können, Ihnen seine Geschichte zu erzählen (vielleicht bei einem Getränk seiner Wahl), dann können Sie mit ihm sympathisieren, und er wird vielleicht empfänglich für “Innovation”, d.h. eine solide Software-Engineering-Praxis.

Dies ist Ihre Chance, über menschliches Versagen zu sprechen und über die Wege, die diese Industrie gefunden hat, um das Vertrauen in unsere Designs und unseren Code zu erhöhen. Sprechen Sie über die Kompromisse in Bezug auf Vertrauen, Qualität, Ressourcen und Zeitplan, die sich aus den verschiedenen Ansätzen für Tests, Peer-Code-Review und formale Methoden (alias “correctness-by-construction”) ergeben.

Sprechen Sie seine Sprache: Verwenden Sie eine Metapher, um die Größe des Problems zu veranschaulichen. Sind es 40.000 Zeilen Code? Sagen Sie ihm, es ist wie ein 600-seitiges Kriminalrätsel in einer fremden Sprache. Wenn Sie in der Mitte von Kapitel 12 etwas ändern wollen, wie stellen Sie sicher, dass es nicht zu einem Bruch in der Kontinuität mit dem Rest der Geschichte führt?

Suchen Sie nach Möglichkeiten, das Vertrauen in ein akzeptables Ziel innerhalb vernünftiger wirtschaftlicher Grenzen zu erhöhen. Sie werden das SEI Capability Maturity Model Level 5 nicht über Nacht implementieren können. Aber vielleicht können Sie von der aktuellen Frage zu “Besteht die automatisierte Regressionstest-Suite?” und “Wie drücken wir diese neue Anforderung im Regressionstestsystem aus?

Ich würde sie auf die mathematischste Art und Weise beantworten, wenn man bedenkt, dass er nach einer Wahrscheinlichkeit mit 100-prozentiger Sicherheit fragt und den Effekt, den statistische Verteilungen auf eine solche Zahl haben würden, völlig ignoriert: Sie sollten ihm 2 oder 3 Zahlen mit der zugehörigen Sicherheit geben: 1 Woche bei 90%, 2 Wochen bei 95%, 6 Monate bei 100%. Die letzte Zahl war eine Übertreibung, aber ich bin sicher, Sie haben den Punkt verstanden.

Siehe Wikipedias Artikel über Konfidenzintervalle für weitere Lektüre.