Wie soll ich in diesem Fall auf seine Frage antworten, ohne inkompetent zu wirken? Ehrlich gesagt habe ich nie 100% iges Vertrauen in die gesamte Site, 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 Kernänderungen hervorgehen.

Der Projektmanager versteht Software nicht gut genug und sicherlich auch nicht Ich verstehe das Testen nicht gut genug. Vielleicht muss er geschult werden.

Wenn Sie eine professionelle QS-Abteilung hätten, würde ich Sie bitten, die Unterstützung des QA-Managers in Anspruch zu nehmen, um diesem Projektmanager die Art der Software und die Art der Fehler zu erklären und die Art des Testens. Ich würde den QS-Manager angeben 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 Testergebnisse unterstützt wird, aber niemals durch perfekte Informationen.

Sie Vielleicht möchten Sie eine Kopie von Gerald Weinbergs ausgezeichnetem Buch " Perfect Software und andere Illusionen über das Testen " erhalten. In Kapitel 3 ("Warum nicht einfach alles testen?") Hat Weinberg einen Abschnitt mit dem Titel "Es gibt unendlich viele mögliche Tests."

Er spricht von einer Hintertür in einem hochsicheren Programm, bei der der normale Passwortschutz umgangen werden kann, indem W gefolgt von drei Leerzeichen, dann M gefolgt von drei Leerzeichen, dann J gefolgt von genau 168 weiteren Tastenanschlägen ohne eingegeben wird einmal mit dem Buchstaben L.

Dann schreibt er: "Verstehen Sie den Punkt jetzt? Wenn Sie nicht erraten haben, dass die Anzahl der Tests, die zum umfassenden Testen von Software erforderlich sind, unendlich ist, oder zumindest" a Zahl größer als ich in meinem Leben laufen konnte ", Sie haben den Sinn dieses Kapitels nicht verstanden. Jetzt tun Sie es."

Erklären Sie Ihrem Projektmanager, dass jeder Tag zusätzlicher Tests Ihr Vertrauen in Ihren Code etwas verbessern wird, jedoch niemals 100% erreichen kann. Sagen Sie ihm, dass Sie gerne auf Kosten Ihrer anderen produktiven Arbeit weiter testen würden. Fragen Sie ihn dann, wie viele Tage er noch für das Testen verwenden soll und welche Ihrer anderen Arbeiten verschoben werden sollen.

Wenn Ihr Projektmanager es immer noch nicht versteht und Sie sich ein wenig flippig fühlen Fragen Sie ihn, ob er zu 100% sicher ist, dass jede von ihm veröffentlichte Schätzung genau korrekt ist und die Fristen niemals versäumt werden. Fragen Sie ihn, ob er zu 100% sicher ist, dass keine E-Mail, die er von nun an für immer schreibt, jemals einen Tippfehler haben wird. Fragen Sie ihn, ob er zu 100% sicher ist, dass er niemals einen Fehler machen wird - jetzt und in Zukunft.

Boss: Sind Sie zu 100% sicher, dass dieses Update keine vorhandenen Funktionen beeinträchtigt oder die Benutzererfahrung beeinträchtigt?

Ich: Nein. Da wir keine 100% ige Abdeckungstestsuite haben, kann nicht überprüft werden, ob durch Codeänderungen Anwendungsbrüche oder nachteilige Auswirkungen vermieden werden. Ich habe jedoch die folgenden Aktionen ausgeführt, um sicherzustellen, dass eine unbeabsichtigte Ausführung unwahrscheinlich ist:

• Ich habe den Umfang der Änderung auf das Modul beschränkt, das li betrifft >
• Ich habe die Dokumentation entsprechend gelesen und aktualisiert.
• Ich habe die Komponententests für dieses Modul und die betroffenen Module ausgeführt.
• Ich habe Komponententests erstellt, um neue zu prüfen Funktionalität hinzugefügt und veraltete Tests aufgrund der Änderung nicht mehr relevant

Obwohl ich Ihnen nicht genau 100% ige Sicherheit geben kann, habe ich innerhalb des Zeitrahmens, den ich glaube, so viel Sicherheit wie möglich gegeben ist für die Implementierung dieser Funktionalität sinnvoll. Tatsächlich habe ich bereits den Punkt erreicht, an dem die Renditen sinken. Ich kann weitere 5 Stunden damit verbringen, Ihnen weitere 0,1% Sicherheit zu geben, aber es ist bereits eine so geringe Chance, dass solche Anstrengungen nicht gerechtfertigt sind. Sie sind jedoch für das Projekt und den Zeitrahmen verantwortlich. Lassen Sie mich wissen, wie viel Zeit ich für diese Funktion aufwenden sollte.

Jetzt ist der Ball auf seinem Platz. Wenn er wirklich möchte, dass ich meine persönliche Einschätzung von 95% sicher auf 95,1% sicher für ein paar Stunden Arbeit verschiebe, dann hey - ich kann das tun.

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

Als Entwickler testen Sie mit UNIT die Änderungen an Ihrem Code. Meiner Meinung nach (als Entwickler) bedeutet dies, dass keine offensichtlichen Fehler vorliegen, alles kompiliert wird und alle Fehler abgefangen werden. Sie können nicht wissen, welche Szenarien auftreten werden, wenn der Code live geschaltet wird (schlechte Daten, unerwartete Eingaben, Änderungen in der Client-Software, die Liste ist endlos).

Um 100% ige Sicherheit zu haben, dass eine Änderung nicht erfolgt Wenn Sie etwas beeinflussen möchten, benötigen 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ögliche Umgebung.

Wenn er 100% iges Vertrauen erwartet, muss er die Umgebung und die Arbeitskräfte bereitstellen, um seine Erwartungen zu untermauern.

Es ist ein bisschen so, als würden Projektmanager und Kunden nach zukunftssicheren Dingen fragen!

Es hört sich so an, als hätte er eine schlechte Angewohnheit. Er stellt eine Frage, von der er weiß, dass sie auf einer bestimmten Ebene albern ist. Aber es gibt ein zwanghaftes Element. Ich vermute, dass er auf eine zugrunde liegende Angst reagiert und durch das Stellen einer unvernünftigen Frage mehr Kontrolle hat.

In solchen Situationen versuche ich, die Dynamik zu verbreiten, indem ich selbstbewusst bin und ein wenig Humor einbringe. Wenn Sie verstehen, dass seine Frage nicht aus Argumenten, sondern aus Angst stammt, können Sie dies indirekt besser als direkt ansprechen.

In solchen Situationen zerstreue ich normalerweise die Ängste des Managements, indem ich alle vorstelle Maßnahmen, die ich ergriffen habe, um die Qualität sicherzustellen. 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, 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 dies seine Angst lindern und Sie werden wahrscheinlich in der Lage sein, ein rationaleres Gespräch zu führen.

Hier kommt die Kunst dieses Geschäfts ins Spiel. Nicht nur "funktioniert es", sondern der Kunde fühlt sich auch gut dabei.

Letztendlich handelt es sich jedoch um eine Geschäftsbeziehung. Wenn die Vertragsvereinbarung für Sie komfortabel und rentabel ist, lohnt es sich, diese Eigenart in Kauf zu nehmen. Es hört sich nicht so an, als ob er es so ernst meint, nur irgendwie hartnäckig. Wie ich schon sagte, er hat eine nervige Angewohnheit entwickelt. Wenn er anfängt, negativ zu reagieren, und der Ton feindseliger wird, kann es sein, dass sich die Ausgewogenheit der Geschäftsvereinbarung für Sie nicht lohnt. Aus Ihrer kurzen Beschreibung geht hervor, dass Sie die Beziehung immer noch effektiv verwalten können.

Viele Leute haben dies als Bildungsproblem beschrieben, und ich sage nicht, dass sie falsch liegen.

Es ist auch möglich, dass es ein politisches Problem ist. Was die Frage tatsächlich bedeuten könnte, ist, dass der Projektmanager von der Verantwortung für etwaige Fehler befreit werden möchte. Er erhält eine eidesstattliche Erklärung von Ihnen, auf die er sich "vernünftigerweise" verlassen kann. Wenn also etwas schief geht, sagt er, dass er alles getan hat, um dies zu verhindern, aber Sie sind gescheitert.

Dies ist kein gutes Management und es ist auch nicht zu 100% garantiert, dass er klar wird, wenn es zu Problemen kommt.

Ich gebe zu, dass dies Spekulationen meinerseits sind, aber Übungen zur Abdeckung des Hinterns sind im Berufsleben keine Seltenheit, und Sie haben es getan mit ihnen umgehen. Wenn dies zutrifft, müssen Sie zur Lösung des Problems nicht nur den Manager darüber informieren, dass 100% iges Vertrauen unmöglich ist. Sie müssen ihn auch davon überzeugen, dass ein Fehler keine Katastrophe ist - für ihn persönlich oder für das Unternehmen.

Dies kann beispielsweise bedeuten, Beispiele für Fehler bereitzustellen, die zu angemessenen Kosten und ohne Schuldzuweisungen behoben werden um. Es könnte bedeuten, sich mit seiner eigenen Unternehmenskultur zu befassen, ob sich jemand anderes im Unternehmen darauf vorbereitet, ihm ungerechtfertigte Schuld zu geben, wenn etwas schief geht. Dies kann auch bedeuten, dass Verfahren eingeführt werden, um zukünftige Fehler so schnell und kostengünstig wie möglich zu beheben. Wenn das Unternehmen wirklich zu 100% vom Code überzeugt wäre, wären solche Verfahren sinnlos, da 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) auffordert, ihm eine Zusicherung zu verkaufen, die Sie nicht über Ihre Arbeit abgeben können, und nichts seine Meinung in diesem Punkt ändert, können Sie nur etwas tun Stellen Sie klar, dass Sie diese Zusicherung nicht geben können und dass er gerne jemanden anstellen kann, wenn er glaubt, dass es jemanden gibt, der dies kann. Natürlich ist das ein langer Weg, aber Sie können Ihre BATNA genauso gut kennen, bevor Sie anfangen.

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

Selbst wenn alle Arten von Tests möglich sind (Unit-Tests, Integration, Komponente, System, Handbuch, Benutzeroberfläche, Fuzz, Sicherheit, Penetration (Sie nennen es). Dies ist auf ein Stoppproblem zurückzuführen. Ein relevanter Auszug aus der Wikipedia folgt unten:

In der Berechenbarkeitstheorie kann das Stoppproblem wie folgt angegeben werden: "Entscheiden Sie anhand einer Beschreibung eines beliebigen Computerprogramms, ob das Programm beendet wird oder fortgesetzt wird für immer laufen ". Dies ist gleichbedeutend mit dem Problem, bei einem Programm und einer Eingabe zu entscheiden, ob das Programm schließlich angehalten wird, wenn es mit dieser Eingabe ausgeführt wird, oder für immer ausgeführt wird.

Alan Turing bewies 1936, dass ein allgemeiner Algorithmus zu Das Problem des Anhaltens für alle möglichen Programm-Eingabe-Paare kann nicht gelöst werden. Ein wesentlicher Teil des Beweises war eine mathematische Definition eines Computers und eines Programms, die als Turing-Maschine bekannt wurde. Das Problem des Anhaltens ist bei Turing-Maschinen nicht zu entscheiden.

Wenn sich Ihr PM um Wert und stabile vorhersehbare Zustellung kümmert, können Sie ihn möglicherweise davon überzeugen, sich das SCRUM-Framework anzusehen

Andere haben viele interessante Ratschläge zur Interaktion mit Ihrem PM gegeben. Persönlich würde ich empfehlen, ein Meeting mit Ihrem PM und dem Team zu vereinbaren, in dem Sie Ihre Prozesse besprechen können. Ich bin stark für SCRUM, daher würde dies weitgehend mit dem SCRUM zusammenhängen.

Ich würde versuchen zu erklären, dass ein Ziel von 100% schwer zu erreichen ist. Es kann nicht erreicht werden. Noch nie. Im ganzen Universum. In der Geschichte gab es viele solcher Beispiele, Demo der Veröffentlichung von Windows 95. Vor langer Zeit? Sehen Sie, wie viele rote Builds auf einem öffentlichen CI-Server für Open Source-Projekte vorhanden sind. Melden Sie sich als Gast an, wenn Sie dort kein Konto haben. Ein Ergebnis davon - Software wird fehlschlagen.

Zweitens würde ich empfehlen, eine Praxis anzuwenden, bei der Sie Wert liefern können, anstatt das Vertrauen eines Commits. Etwas, das Kunden interessiert. Iterativ, wiederholt und zuverlässig. Jetzt können Sie die Perspektive Ihres PM von der 100% igen Sicherheit auf etwas verschieben, das tatsächlich wichtig ist. Das heißt: Software wird verwendet, Ihr Produkt verbessert sich und das Team liefert dem Kunden einen Mehrwert.

Drittens sollte dies eine Definition von erledigt sein. Etwas, das sich ein Entwicklungsteam einfallen lässt. Dies kann Folgendes umfassen: Dokumentation, Implementierung, Tests, Qualitätsgatter usw. Dies ist sehr wichtig, da Sie jetzt die Subjektivität (dh "Sind Sie zu 100% sicher?") Auf Objektivität verschieben können (das heißt, alle Aufzählungspunkte der Definition von erledigt sind abgeschlossen).

Es gibt andere sehr wichtige Schritte, die SCRUM fördert. Aber alle würden es Entwicklern ermöglichen, solche Frustrationen abzumildern und objektiv quantifizierbare Ergebnisse im Vergleich zur subjektiven Sicherheit zu liefern.

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

1) Legen Sie nichts für den Produktionscode fest, bis nicht nur der Autor, sondern auch ein oder mehrere andere Programmierer Lassen Sie es auf seine Richtigkeit prüfen, um sicherzustellen, dass es nur das ändert, was erforderlich ist, dass es alle vereinbarten Kriterien für eine gute Codierungspraxis erfüllt und dass es einen Test enthält, der Ihnen gute Chancen bietet, festzustellen, ob eine spätere Änderung die Logik verletzt erneut und so weiter.

2) Legen Sie nichts für den Produktionscode-Stream fest, bis ALLE Regressionstests erneut ausgeführt wurden und nachgewiesen wurde, dass nichts beschädigt wird, wofür der Test durchgeführt wurde. Wenn während dieses Tests ein Fehler auftritt, muss die Änderung zurückgesetzt werden, bis eindeutig festgestellt werden kann, dass das Problem nicht verursacht wurde.

3) Alpha- und Betatest früh und häufig in der Praxis Kundenszenarien. Kunden werden mit Ihrem Code Dinge tun, die Sie nie erwartet haben.

Keiner davon ist 100%, noch ist ihre Kombination. Aber sie bringen dich erheblich näher. Sie erfordern eine nicht triviale Investition zusätzlicher Ressourcen. Sie verlangsamen die Entwicklung im Vergleich zu Skunkworks. "Mach es einfach und wir werden es reparieren, wenn es kaputt geht". Aber wenn Sie wirklich fehlerfreien Code wollen, kann es diese Kosten mehr als wert sein, zu erkennen, dass Menschen fehlbar sind, und Praktiken einzuführen, um Fehler zu erkennen, bevor sie die Kunden erreichen.

Das wurde mir dort gesagt war nie ein Fehler, der in dem Code gemeldet wurde, den IBM für die NASA geschrieben hat - weil er während des Designs, während der Entwicklung und vor der Veröffentlichung einer Peer-Review unterzogen und zu Tode getestet wurde.

Wenn Sie etwas Lebenskritisches tun, lohnt sich diese Investition offensichtlich. Wenn Sie eine Infrastruktur für große Unternehmen betreiben, lohnt sich diese Investition. Sie möchten nicht derjenige sein, dessen Fehler die Geschäftsprozesse eines Milliarden-Dollar-Unternehmens beeinträchtigt.

Ja, es macht gute Programmierer verrückt. Bis zum ersten Mal rettet es ihre Hinterbacken.

Die Wahrheit ist, dass es schlechte Tests sind. Die Realität ist, dass ein Unternehmen, das nicht bereit ist, in ein QS-Team zu investieren, schlechte Tests haben wird. Gutes Testen ist teuer und braucht Zeit. Das Unternehmen hat das Risiko übernommen, indem es Zeit und Geld nicht autorisiert hat.

Selbst ein QS-Team kann nicht garantieren, dass jede Möglichkeit getestet wird, da die möglichen Wege durch ein komplexes Programm im Grunde unendlich sind. Sie bringen Sie jedoch weit näher als jetzt. Ein Grund dafür ist, dass es für einen Entwickler unmöglich ist, seinen eigenen Code angemessen zu testen. Sie wissen, was es tut, und neigen daher dazu, Tests zu entwerfen, die ihrer Meinung nach funktionieren sollen. Sie vermissen Randfälle, sie vermissen dumme Dinge, die Benutzer tun würden, die ein Entwickler niemals tun würde, weil sie wissen, wie es funktioniert, sie interpretieren die Anforderung manchmal falsch, aber alle ihre Tests spiegeln ihre ursprüngliche falsche Interpretation wider. Sie übersehen häufig Fehler in der Anforderung und tun, was sie tun sollen, nicht das, was sie hätten tun sollen (dies ist die Ursache für eine große Anzahl von Fehlern, die erst nach den tatsächlichen Benutzern gefunden werden [die allzu oft bei der Definition nicht konsultiert werden die Anforderung] versuchen, die Software zu verwenden). Sie vermissen Auswirkungen auf Teile der Anwendung, für die sie noch nie Grund hatten, in bestimmten Teilen zu arbeiten, die von Spezialisten ausgeführt werden (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 will, muss er dafür Zeit und Geld bezahlen. Selbst bei vollständiger Qualitätssicherung können Sie nicht 100% erreichen, obwohl die NASA und ihre Auftragnehmer sicherlich nahe beieinander liegen. Sie geben auch viel mehr Geld aus, als Ihr Unternehmen ausgibt. Selbst dann gelang es ihnen, MARS einmal komplett zu verpassen.

Wenn er die Gewissheit haben möchte, dass Probleme den Kunden keinen Schaden zufügen, sprechen Sie über Ihren Testprozess (Zeigen Sie ihm die Liste der Tests, die Sie durchgeführt haben.), was Ihrer Meinung nach davon betroffen wäre und wie Sie haben dies überprüft, Ihren Prozess, um festzustellen, wie Sie einen fehlerhaften Push zurücksetzen würden, und Ihren Prozess, um Fehler zu protokollieren, damit Sie sie sehen, bevor die meisten Clients sie bemerken. Geben Sie ihm das Vertrauen, dass selbst wenn es ein Problem gibt, es behoben werden kann. Sprechen Sie über den Wert, den Code (neue Funktion oder Korrektur) schnell herauszubekommen, und über die zusätzliche Zeit, die für einen gründlicheren Test erforderlich wäre. Sprechen Sie über das Risiko, dass es nicht schnell herauskommt.

Sie können ihn auch bitten, bei jeder Änderung einen gründlichen Regressionstest des Systems durchzuführen, da es einem Entwickler nicht möglich ist, sein System vollständig zu testen eigene Arbeit (Sie wissen, was Ihre Annahmen waren, wenn sie nicht richtig sind, würden Sie das niemals testen.) Stellen Sie sicher, dass er weiß, dass er jede einzelne Seite der Anwendung und jede einzelne Sache, die auf einer gemacht werden könnte, testen muss Seite in jeder möglichen Reihenfolge. Oh ja, testen Sie auch alle Importe / Exporte, Berichte und automatisierten Jobs. Und alle verwandten Anwendungen, die betroffen sein könnten. Sobald er einmal versucht hat, das System gründlich zu trainieren, wird er erkennen, warum Sie diese Zusicherung nicht machen können.

Eine andere Sache, die Sie versuchen sollten, ist ihm im Voraus zu sagen, dass Sie diese Garantie nicht geben können. Wenn er jedoch X Teststunden autorisiert, können Sie dieser Garantie näher kommen. Geben Sie ihm eine detaillierte Liste der zusätzlichen Tests und der Stunden, die für das Entwerfen und Ausführen der einzelnen Tests erforderlich sind. Sagen Sie ihm, welchen Prozentsatz an Vertrauen Sie nach Durchführung all dieser Tests haben würden und welchen Prozentsatz an Vertrauen Sie gerade haben.

Sagen Sie ihm, wie lange es dauern würde, alle aktuellen Unit-Tests durchzuführen, unabhängig davon, ob sie mit diesem Problem zusammenhängen oder nicht. Wenn Sie derzeit 1000 Unit-Tests haben und jeder fünf Minuten benötigt, um die Ergebnisse einzurichten, auszuführen und auszuwerten, wären dies 83 Stunden. Bitten Sie ihn um die Erlaubnis, diese Zeit zu verbringen.

Das Produkt enthält viele miteinander vermischte Teile (nicht nur in sich geschlossene Seiten), etwa 40.000 Codezeilen, die über einen Zeitraum von 4 Jahren geschrieben wurden, und manchmal passieren unerwartete Dinge, die uns nicht einmal bewusst waren. Ich spüre, dass er dies als schlechtes Testen ansieht.

Dies ist Ihr Problem, aber bis jetzt ist es nicht Ihre Schuld. Wenn Sie das Problem nicht beheben, müssen Sie irgendwann die Verantwortung übernehmen. Besprechen Sie mit Ihrem Chef, dass Sie niemals 100% sein werden, bis dies behoben ist. Refactoring vorschlagen. Außerdem ist 100% im Kopf von nicht-technischen Leuten nicht dasselbe wie das eines Programmierers. Vielleicht sollten Sie angeben, dass Sie "100% sicher sind, dass der Kunde es wahrscheinlich nicht bemerkt".

Es gibt kein QA-Team Dies ist ein Luxus, den sich Ihr Unternehmen nicht leisten kann du bist es. Stellen Sie sich vor, es gäbe ein QS-Team (Sie) und bestimmen Sie, wie lange es dauern würde, Ihren Code zu testen, und geben Sie dies dann in Ihre Schätzung ein. Es gibt keine Möglichkeit, Code und Qualitätssicherung gleichzeitig zu codieren, sodass Sie dies nicht parallel tun können.

Hören Sie auf, so sehr darauf bedacht zu sein, Code einzuchecken, und erfüllen Sie die scheinbar unangemessenen Anforderungen. Gib ihnen was sie wollen. Sobald sie die Kosten herausgefunden haben (übermäßige Codierungszeit), kann er seine Meinung ändern.

Wenn er Sie tatsächlich mikro-verwaltet und Ihnen während des gesamten Projektaufbaus über die Schulter schaut, können Sie auf einfache Weise sicherstellen, dass Sie 100% iges Vertrauen garantieren können, ohne dass er Sie später darüber informiert.

Lassen Sie ihn es selbst genehmigen

Um klar zu sein, sollten Sie dies nicht als Forderung, sondern als Vorschlag machen, wenn er es wirklich tut Wenn er 100% perfekten Code möchte, sollte er sich ansehen, was Sie selbst tun, und jede Änderung genehmigen, die Sie unterwegs vornehmen. Das soll nicht heißen, dass er den Code buchstäblich lesen sollte, sondern ihn in Aktion sehen und bestätigen: "Ja, so sollte er sich verhalten".

Wenn Sie der einzige Tester Ihres eigenen Codes sind, ist dies nicht unangemessen. Sie konzentrieren sich bereits voll und ganz auf das Projekt. Wenn er Perfektion wünscht, sollte er die Verantwortung dafür übernehmen, diese Perfektion selbst sicherzustellen.

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

Wenn aus irgendeinem Grund Sie glauben nicht, dass dies gut ankommen würde (wenn Sie beispielsweise wissen, dass es katastrophal ist, ihn zu bitten, mehr Arbeit zu leisten), können Sie nur so viele harte Fehlertests wie möglich durchführen und in Ihre Berichte schreiben Alles, was Sie wissen, funktioniert korrekt und gibt ihm 100% ige Sicherheit, dass ich im Rahmen meiner Tests zu 100% von diesen Änderungen überzeugt bin.

Leider sind Sie möglicherweise in der Lage, einen „Chef“ zu haben, dessen Verständnis für Ihre Arbeit begrenzt ist. Dies ist immer ein Problem, wenn Sie versuchen zu erklären, wie eine Fehlerkorrektur nicht mit 100% iger Sicherheit aufrechterhalten werden kann. Zusammenfassend lässt sich sagen, dass Ihre beste Wette darin besteht, das Beste zu tun, alles aufzuzeichnen und zu verstehen, dass Sie innerhalb Ihrer eigenen Grenzen tun, was Sie können.

Einige nette Antworten hier, der PM muss auf jeden Fall geschult werden und ein bisschen darüber lernen, was es bedeutet, Software zu schreiben.

Ich möchte nichts davon wiederholen, sondern einen anderen einwerfen, eher ungewöhnliche Idee. Diese Methode ist ziemlich riskant und hängt sehr davon ab, wie hoch Ihr Ruf ist, wie gut Ihre Fähigkeiten sind (oder wie sie wahrgenommen werden) und sowohl Ihre Persönlichkeit als auch die Ihres PM. Ich gehe davon aus, dass Sie ihn nicht missverstanden haben, und er meint wirklich 100% (ich sehe oft Leute, die 100% sagen, aber wirklich "das Beste tun, was Sie können" bedeuten)

Es hat einmal für mich funktioniert, und Das ist der einzige Grund, warum ich es hier erwähne. Du wurdest gewarnt. Dies ist meistens eine Möglichkeit, einen PM zu erziehen, wenn alle anderen Mittel fehlschlagen.

Manchmal möchte ein PM (oder ein anderer Manager) einfach nicht zuhören, also müssen Sie ihn irgendwo dazu bringen (oder den Team) gegen eine Wand stoßen, um einen Moment innezuhalten und nachzudenken. In diesem Szenario bedeutet dies: Arbeiten Sie so gut wie möglich und versuchen Sie, so gut wie möglich zu testen. Geben Sie Ihr Bestes und sagen Sie dann "Ja, ich bin 100% sicher, dass dies funktionieren wird".

Wenn Sie extrem viel Glück haben, wird niemals ein Fehler auftreten und alle sind glücklich. In Wirklichkeit wird jedoch Folgendes passieren: Es gibt einen Fehler. Was sollst du jetzt tun? Sie geben zu, dass Sie einen Fehler gemacht haben. Stellen Sie eine Verbindung mit Fehlern und dem Fehler her, 100% sicher zu sein. Menschen sind unvollkommen und können Fehler in der Software verursachen. Menschen sind unvollkommen und verursachen Fehler in Tests. Folglich sind Menschen unvollkommen und können "Fehler verursachen", wenn sie 100% sicher sind, dass es keinen Fehler gibt.

Präsentieren Sie dies gut und 100% wasserdicht (haha, j / k, die 100% nochmal). Stellen Sie sicher, dass nach all dem die Meldung "Ich kann bei meinen Tests nicht 100% sicher sein" lautet. Wenn der PM dann nicht den logischen Schritt "Dies wird für alle Entwickler gleich sein" ausführen kann, ist wahrscheinlich alle Hoffnung verloren ...

Aber bitte versuchen Sie zuerst andere Dinge!

Ich würde es auf mathematischste Weise beantworten, wenn man bedenkt, dass er mit 100% iger Sicherheit nach einer Wahrscheinlichkeit fragt und den Effekt, den statistische Verteilungen auf eine solche Zahl haben würden, völlig ignoriert: Sie sollten ihm 2 oder 3 Zahlen geben, mit damit verbundenem Vertrauen: 1 Woche bei 90%, 2 Wochen bei 95%, 6 Monate bei 100%. Die letzte Zahl war übertrieben, aber ich bin sicher, Sie haben den Punkt verstanden.

Weitere Informationen finden Sie im Wikipedia-Artikel zu Konfidenzintervallen.

Der Schlüsselindikator ist, dass es sich um eine kürzlich vorgenommene Änderung handelt. Etwas (oder jemand) hat Ihrem PM wahrscheinlich eine schlechte Erfahrung gemacht, 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 über das Getränk seiner Wahl), können Sie mitfühlen, und er wird möglicherweise empfänglich für "Innovationen" "aka solide Software-Engineering-Praxis.

Dies ist Ihre Chance, über menschliches Versagen und die Art und Weise zu sprechen, wie diese Branche das Vertrauen in unsere Designs und unseren Code erhöht. Um über die Kompromisse in Bezug auf Vertrauen, Qualität, Ressourcen und Zeitplan zu sprechen, die sich aus verschiedenen Ansätzen für Tests, Peer-Code-Überprüfung und formale Methoden ergeben (auch bekannt als Korrektheit durch Konstruktion).

Sprechen Sie seine Sprache: Verwenden Sie eine Metapher, um die Größe des Problems zu veranschaulichen. Sind es 40.000 Codezeilen? Sagen Sie ihm, es ist wie ein 600-seitiges Krimi in einer Fremdsprache. Wenn Sie in der Mitte von Kapitel 12 etwas ändern möchten, wie stellen Sie sicher, dass die Kontinuität mit dem Rest der Geschichte nicht unterbrochen wird?

Suchen Sie nach Buy-ins für Möglichkeiten zur Steigerung Vertrauen in ein akzeptables Ziel innerhalb angemessener wirtschaftlicher Grenzen. Sie können das SEI Capability Maturity Model Level 5 nicht über Nacht implementieren. Möglicherweise können Sie jedoch von der aktuellen Frage zu "Besteht die automatisierte Regressionstestsuite?" Wechseln. und "Wie drücken wir diese neue Anforderung im Regressionstestsystem aus?"