it-swarm.dev

Warum lassen Sie Entwickler ihre eigene Arbeit testen?

Ich möchte einige Argumente dafür sammeln, warum es eine schlechte Idee ist, einen Entwickler seine/ihre eigene Arbeit als letzten Schritt testen zu lassen, bevor das Produkt in Produktion geht, da mein Arbeitsplatz dies leider manchmal tut (das letzte Mal, als dies auftauchte) Das Argument lief darauf hinaus, dass die meisten Leute zu beschäftigt mit anderen Dingen waren und nicht die Zeit hatten, eine andere Person mit diesem Teil des Programms vertraut zu machen - es ist eine sehr spezialisierte Software.

In diesem Fall gibt es Testpläne (wenn auch nicht immer), aber ich bin sehr dafür, dass eine Person, die die getesteten Änderungen nicht vorgenommen hat, tatsächlich die endgültigen Tests durchführt. Ich frage Sie daher, ob Sie mir eine gute und solide Liste von Argumenten liefern könnten, die ich bei der nächsten Diskussion vorbringen kann. Oder um Gegenargumente zu liefern, falls Sie der Meinung sind, dass dies vollkommen in Ordnung ist, insbesondere wenn formale Testfälle zu testen sind.

82
pyvi

Wie andere (und Sie selbst) bemerkt haben, sollten Entwickler ihren eigenen Code einem Unit-Test unterziehen. Danach sollte jedes nicht triviale Produkt jedoch auch von unabhängigen Personen (QS-Abteilung und/oder vom Kunden selbst) getestet werden.

Entwickler arbeiten normalerweise mit der Entwickler-Denkweise von "Wie funktioniert das?" . Ein guter Tester denkt über nach, "wie man das bricht?" - eine ganz andere Denkweise. Unit-Tests und TDD lehren Entwickler, Hüte bis zu einem gewissen Grad zu ändern, aber Sie sollten sich nicht darauf verlassen. Darüber hinaus besteht, wie andere angemerkt haben, immer die Möglichkeit, Anforderungen falsch zu verstehen. Daher endgültige Abnahmetests sollten von jemandem durchgeführt werden, der dem Kunden so nahe wie möglich ist.

103
Péter Török

Der Entwickler weiß, wie sein Code funktioniert, und wird es sich zur Gewohnheit machen, seinen Code nach diesem Wissen zu testen.

Der Entwickler wird es schwierig finden, sich aus der Denkweise "wie es funktioniert" zu entfernen, im Gegensatz zu "wie es funktionieren sollte".

Aus diesem Grund ist es besser, jemanden mit einem hohen Maß an Objektivität zum Testen des Programms zu bewegen, z. B. QS oder Testingenieure

127
John Shaft

Testers Test to break, Simple. Diese Art von Voreingenommenheit wird benötigt, um die Show-Stopper wirklich herauszufinden.

30
Aditya P

Entwickler MÜSSEN ihre Arbeit testen. Es ist eine implizite Verantwortung.

Ich gehe davon aus, dass Sie kein Team haben, das die Tests basierend auf Ihrer Aussage durchführen soll. Ein Team, das sich dem Testen widmet, ist jedoch sehr hilfreich, da Entwickler dazu neigen, ihren Code so zu testen, wie sie ihn codiert haben. Dies bedeutet nicht, dass Sie, sobald Sie ein Qualitätssicherungsteam haben, bereits Tests in der Verantwortung der Entwickler durchführen können.

Entwickler verwenden normalerweise Netze mit großen Löchern, um Fehler zu erkennen. Infolgedessen entkommen kleinere Fehler.

15
setzamora

Weil Entwickler nicht gut darin sind, ihren eigenen Code zu brechen. Ihr Verstand folgt einfach dem richtigen Weg der Dateneingabe und Interaktion mit der Anwendung. Viele Fehler sind das Ergebnis der Interaktion mit dem System wie ein normaler Typ. Entwickler sind keine normalen Benutzer. Sie sind professionelle Benutzer.

15
Saeed Neamati

Es gibt einige gute Gründe, ein engagiertes Testteam zu haben. Erstens können Entwickler, wie oben erwähnt, sehr gut testen, ob ihr Code funktioniert, aber nicht brechen.

Wie Sie sagen, weiß ein Entwickler auch, was er geschrieben hat, aber ein Testteam weiß, was hätte geschrieben werden sollen. Manchmal stimmen diese beiden Konzepte nicht überein. Eine der Aufgaben des Testteams besteht darin, sicherzustellen, dass die Software den Anforderungen entspricht. In vielen Fällen kennt ein Entwickler nur einige Teile des Systems sehr gut, aber das QA-Team kennt das Ganze.

Was zum nächsten Grund führt, führen Testteams vollständige Integrationstests durch. Der Code, den Sie gerade geschrieben haben, funktioniert möglicherweise von alleine, kann jedoch andere Funktionen beeinträchtigen, von denen Sie nichts wussten.

Nachdem ich mit und ohne QS-Team gearbeitet habe, kann ich Ihnen sagen, dass ich die geleistete Arbeit zu 100% schätze und sagen werde, dass sie ein geschätzter Teil des Software-Teams sind. Wenn Sie ein QA-Team haben, erleichtert dies die Freigabe Ihres Codes erheblich. Sie wissen, dass er gründlich getestet wurde und Sie weniger Anrufe um 3 Uhr morgens erhalten.

10
Tyanna

Entwickler sollten ihren eigenen Code testen.

Unabhängige Tester testen nicht nur, um zu brechen, sie testen auch die nicht angegebenen und undefinierten Annahmen, die die Entwickler beim Codieren getroffen haben.

8

Ich würde erwarten, dass der Entwickler einige erste Tests durchführt, bevor er Änderungen festlegt, und sich davon überzeugt hat, dass der Code funktioniert. Ich würde dann erwarten, dass der Entwickler in die Testfälle jedes spezifische White-Box-Wissen einbringt, über das er verfügt. Zum Beispiel alle anderen Bereiche des Codes, die möglicherweise betroffen sind.

Der größte Einwand gegen Entwickler, die ihren eigenen Code testen, besteht darin, dass Sie nur einen Standpunkt testen. Der Entwickler hat die Spezifikation gelesen und interpretiert. Hoffentlich ist die Spezifikation klar, vollständig und eindeutig, aber dies ist nicht immer der Fall. Der Entwickler hat möglicherweise einen Teil der Spezifikation falsch verstanden. Wenn sie ihren eigenen Code testen, wird dieser nicht abgefangen, da sie feststellen, dass die Funktion wie erwartet funktioniert.

Unterschiedliche Personen neigen auch dazu, ein Produkt auf unterschiedliche Weise zu verwenden und als Ergebnis unterschiedliche Wege durch den Code zu gehen. Ein Entwickler hat sichergestellt, dass der Code für ihn funktioniert, hat jedoch möglicherweise keinen Edge-Fall berücksichtigt, den ein anderer Tester möglicherweise findet.

7
Luke Graham

Entwickler sollten testen ihre eigene Arbeit. Entwickler ungetestete Arbeit an ein QS-Team oder ihre Entwicklerkollegen senden zu lassen, ist eine wirklich schlechte Idee. Es verschwendet die Zeit von Entwicklern und Testern gleichermaßen und ruiniert Beziehungen.

Das reicht jedoch nicht immer aus. Entwickler folgen wahrscheinlich einem glücklichen Weg durch das System oder sind blind für einige Eigenheiten, denen sie während der gesamten Entwicklung immer wieder ausgesetzt waren.

Ein weiterer Punkt ist, dass es eine Reihe von Kommunikationsebenen zwischen Spezifikation und Bereitstellung geben kann. Dies kann zu einem chinesischen Flüstereffekt auf die endgültige Bereitstellung führen. Es ist am besten, wenn derjenige, der die Anforderung oder den Fehlerbericht definiert hat, testet, dass es so funktioniert, wie er es wollte.

5
Paul Butcher

Als Entwickler sind Sie für Ihren eigenen Code verantwortlich. Sie sollten ihn testen. Does the feature work as expected? Wenn die Antwort ja ist, sind Sie fertig.

Warum sollten Sie keine Testfälle machen?

  1. Sie sind subjektiv, da gefundene Fehler von Ihnen (oder Ihren Kollegen) geschrieben wurden.
  2. Sie sind zu teuer für das Unternehmen, um Falltests durchzuführen. (Ich hoffe).
3

In der Regel verwenden die Entwickler den Code in den meisten Fällen nur in bestimmten speziellen Fällen. Der letzte Testschritt vor der Umstellung auf ein Produktionssystem sollte daher der Benutzerakzeptanztest (UAT) sein. Sie sind im Allgemeinen besser mit dem vertraut, was sie von dem Paket erwarten. Und sind im Allgemeinen eher in der Lage, Dinge mit Eintrittsströmen zu brechen, die jemandem unbekannt sind, der sie nicht täglich verwendet.

Sind Ihre Projektpläne nicht für Benutzertests geeignet? Wenn Sie Benutzer dazu bringen, es zu testen, können Sie Fehler früher als nach der Implementierung erkennen, was in meiner Welt keine schlechte Sache ist.

3
temptar

Entwickler sollten ihren eigenen Code nicht testen, da dies mit der Beurteilung der Kunst Ihres eigenen Kindes vergleichbar ist. Es wird für Sie so oder so wunderschön aussehen, und Sie brauchen wirklich einen Fachmann, der auf die Mängel hinweist. Unit-Tests sind dagegen vergleichbar damit, dass Ihr Kind nicht versucht, mit Blei zu malen.

Für den Fall, dass Sie WIRKLICH keine Qualitätssicherung einstellen möchten, lassen Sie Entwickler Testcode für andere Entwickler schreiben. Dies ist ein guter erster Schritt. Bald werden Entwickler nach QS-Ressourcen fragen, da die meiste Zeit zusätzlich zum CR für das Testen des Codes anderer auf Probleme aufgewendet wird.

Es ist nicht nur so, dass Entwickler ihren Code schützen, wenn sie einen bestimmten Fall nicht erkennen oder eine Spezifikation in der Art und Weise, wie sie etwas entwickeln, falsch interpretieren, dann werden sie diese Fälle beim Testen ihres Codes übersehen.

Die Techniken und Fähigkeiten zum Testen sind ebenfalls sehr unterschiedlich.

Die meisten Tests durch ein Testteam sind funktionsfähig (ein Produkt funktioniert gemäß einer Spezifikation) und Black-Box (das Testteam sieht das Innenleben einer Anwendung nicht). Funktionstester müssen sich nicht darum kümmern, wie die Dinge funktionieren, sie müssen sich nur darauf konzentrieren, ob sie funktionieren.

3
StuperUser

Ein Programmierer sieht beim Testen ein Textfeld mit der Bezeichnung "Menge" und gibt "1" ein. Ein sehr erfahrener Programmierer führt dann einen Folgetest mit dem Wert "2" durch.

Ein Benutzer sieht ein Textfeld mit der Bezeichnung "Menge" und gibt "~~ Einhörner ROX !!! ~~" ein. Ein erfahrener Benutzer wird auch "-12 1/2" versuchen.

Hoffentlich ist irgendwo ein Tester da, um den Programmierer darüber zu informieren, was der Benutzer erleben wird, wenn er diese Dinge tut.

2

Nach meiner Erfahrung muss der Endbenutzer zumindest in meiner kleinen Organisation testen. Fast jedes Projekt, das wir erhalten, liefert nicht alle erforderlichen Informationen und lässt immer bestimmte Details aus. Der Entwickler hat immer einen Testnachteil, weil er nicht weiß, wie er die Arbeit des Benutzers erledigen soll. Obwohl er weiß, dass die Software gemäß den Informationen funktioniert, die er erhalten hat, weiß er nicht, ob dies dem Endbenutzer helfen wird mach ihren Job.

2
Kratz

Entwickler interpretieren Anforderungen falsch und interpretieren sie falsch, und diejenigen, die für die Anforderungen verantwortlich sind, geben häufig wichtige Dinge nicht an. Wenn niemand außer den Entwicklertests diese Trennungen findet, bevor sie live gehen. Wenn Entwickler testen, wissen sie zu viel darüber, wie es funktionieren soll, und probieren nicht die dummen Dinge aus, die Benutzer versuchen könnten. Entwickler schreiben ihre Tests auch auf der Grundlage ihrer eigenen Interpretation der Anforderung, was allzu oft nicht das ist, was wirklich gemeint war. Die Tests bestehen also, aber die Anforderung wurde nicht erfüllt. Wenn Sie verschiedene Personentests durchgeführt haben, hat diese Person möglicherweise eine unterschiedliche Vorstellung von den Anforderungen, und Sie finden häufig die Stellen, an denen die Anforderung schlecht ausgedrückt wurde, indem zwei unterschiedliche Personen sie unterschiedlich interpretieren. Es ist viel besser, dies beim Testen herauszufinden, als nachdem Sie live gegangen sind.

2
HLGEM

Der Entwickler sollte die ersten Tests durchführen, damit wir wissen, dass das von uns codierte Teil gemäß den Anforderungen, die wir haben, so funktioniert, wie es voraussichtlich funktioniert. Wir haben also die normalen Tests durchgeführt und Unit-Tests für den von uns geschriebenen Code geschrieben.

Der nächste Schritt ist die Aufgabe der QAs, herauszufinden, was die Entwickler beim Schreiben des Codes nicht sehen. Ein Entwickler denkt auf einer höheren Ebene, aber der Benutzer denkt möglicherweise nicht auf derselben Ebene. Wenn der Entwickler sein Stück testet und Text in ein Textfeld eingeben muss, gibt er möglicherweise immer einen vollständigen String ein, der denkt, dass der Benutzer dies auch tun würde. Möglicherweise tut der Benutzer dies auch, aber wenn er zufällig ein Sonderzeichen wie% & $ ^ in den Text eingibt und die Anwendung dadurch beschädigt wird, sieht es für den Endbenutzer nicht gut aus. Ein Entwickler kann und wird nicht über alle Möglichkeiten nachdenken, die sich ergeben könnten, weil er nicht dazu ausgebildet ist, so zu denken. Wenn es um eine Qualitätssicherung (Tester) geht, denken sie immer darüber nach, was der Benutzer tun könnte, um diese Anwendung zu beschädigen, und versuchen alles Dumme im Buch. Nicht die Benutzer sind dumm, aber wir sollten nichts dem Zufall überlassen.

Jetzt müssen wir auch verstehen, dass im Allgemeinen mehr als ein Stück gleichzeitig fertig ist und beide in Produktion gehen werden. Der Entwickler konnte nur sein Teil testen und dachte, dass dies gut funktioniert, aber der gesamte Regressionstest muss für alle Teile durchgeführt werden, die verschoben werden, und um herauszufinden, dass die Kombination von zwei verschiedenen Teilen die Anwendung beschädigen könnte und dies auch tut sieht auch nicht gut aus. Wir müssen auch die Lasttestszenarien und andere Dinge berücksichtigen, mit denen die Tester besser vertraut sind.

Schließlich müssen wir den UAT (User Acceptance Test) durchlaufen, um zu sehen, ob das Stück, das wir gemacht haben, das ist, was erwartet wird. Obwohl die Anforderungen durch BAs erfüllt werden, weiß die endgültige Person möglicherweise nicht genau, wie es aussieht, und sie/er denkt möglicherweise, dass es nicht das ist, was sie erwartet hat, oder sie möchte möglicherweise etwas anderes hinzufügen, damit es besser aussieht, oder aus irgendeinem Grund verschrotten sie das ganzes Stück, wie sie denken, das Stück würde nicht mit der bereits verfügbaren Funktionalität gehen.

Wie oben erläutert, sind diese sehr wichtig und können nicht vom Entwickler alleine ausgeführt werden. Sie sind unbedingt erforderlich, damit die Anwendung ordnungsgemäß funktioniert. Das Management kann sagen, dass dies ein konservativer Ansatz ist, aber es ist der bessere Ansatz. Wir können einige Änderungen an dem oben Gesagten vornehmen, aber nicht als Ganzes vermeiden.

2
Amar Jarubula

Die obigen Kommentare werfen großartige Punkte auf.

Eine zusätzliche, die zuvor nicht erwähnt wurde, besteht darin, dass ein separater individueller Testcode als zusätzliche Überprüfung der Anforderungen dient und ob das System sie korrekt implementiert.

Anforderungen und Dokumentation sind nicht perfekt, und häufig ist die Implementierung das Ergebnis der Interpretation der Anforderungen durch einen Entwickler.

Wenn die Tests von einer separaten Person durchgeführt werden, geben sie auch ihre eigene Interpretation der Anforderungen an, wenn sie den Testplan erstellen und die Tests ausführen.

Wenn die Testaktivitäten unabhängig von den Entwicklungsaktivitäten durchgeführt werden und die Ergebnisse beider "übereinstimmen", wird zusätzlich bestätigt, dass das System korrekt ist und wirklich der ursprünglichen Absicht der Anforderungen entspricht.

2
tschaible

Ein Grund dafür ist, dass Entwickler auch nahe an ihrem eigenen Code sind. Sie wissen, dass es Macken sind, es sind kleine seltsame Verhaltensweisen. Sie neigen dazu, m die kleinen Eigenheiten zu testen, die sie so gut kennen. Sie sind nicht objektiv genug. Testteams behandeln es wie eine Black Box. Sie schreiben Matrizen von Dutzenden oder Hunderten von Testfällen und durchlaufen sie methodisch, um zu sehen, was der Code tun wird. Oft entwickeln sie Szenarien, von denen das Entwicklungsteam niemals träumen würde.

Ein weiterer Grund ist die Zeit. Bei großen Projekten, die in Phasen erstellt werden, erstellt das Entwicklungsteam Phase 1. Anschließend testen die Tester diese Phase, während Phase 2 erstellt wird und die Fehler in Phase 1 behoben werden. Dies gilt für alle Stufen, sodass die getestete Stufe die vorherige ist, die gebaut wurde.

Es wird von jemandem getestet, der mit dem Code nicht vertraut ist, ob Sie ihn mögen oder nicht. Die Frage ist, ob Sie möchten, dass jemand Ihr Kunde ist.

1
Karl Bielefeldt

Menschen, die Menschen sind, neigen dazu, unter kognitiven Verzerrungen zu leiden - wo sich ihre Beurteilung in zwei nahezu identischen Szenarien einfach aufgrund einiger Dinge, die sich geändert haben, unterscheiden wird - eine Sache, die ich in 8 Jahren Entwicklung bemerkt habe, ist die eines Entwicklers ist mit dem Testen seines eigenen Codes konfrontiert, im Gegensatz zu Code, den ein Kollege geschrieben hat, sind die Tests, die mit seinem eigenen Code durchgeführt werden, von viel schlechterer Qualität.

Dies bedeutet nicht, dass der Entwickler direkt schuld ist - sein/ihr Gehirn wird die Voreingenommenheit, die es geschrieben hat, verwenden, um die Tatsache zu bekräftigen, dass es an sein Recht glaubt, und nur grundlegende Überprüfungen durchführen, im Gegensatz zu einem Entwickler, der dies tut Wenn Sie sich den Code eines anderen ansehen, werden Sie viel gründlichere Überprüfungen durchführen.

Es gibt Tausende von Beispielen, bei denen Verfahren eingeführt wurden, um kognitive Verzerrungen zu verhindern, oder allgemein als "The Human Factor" bekannt, wie beispielsweise computergestützte Systeme in der Flugsicherung, um zu verhindern, dass zwei verschiedene Flugzeuge gleichzeitig denselben Luftraum belegen Zeit, um medizinische Verfahren einzurichten, so dass mehr als ein Arzt eine Diagnose stellen muss.

Es ist an der Zeit, dass die IT-Branche eine professionellere Haltung einnimmt und Verfahren einführt, um das Testen Ihres eigenen Codes zu verhindern.

1
Surgical Coder

Gute Frage. In Ihrer Situation gibt es manchmal Testfälle, und die Software scheint so komplex zu sein, dass es nicht praktikabel ist, einen Anfänger mit dem Produkt vertraut zu machen. Sie sagen auch, dass der durchgeführte Test der letzte Test vor der Produktion ist

Gründe, warum es für den Entwickler in Ordnung sein könnte, den endgültigen Test durchzuführen

  • Es gibt genügend andere Testabdeckungen ... Es gibt Komponententests, eine Integrationstestumgebung ist vorhanden und wird verwendet, UI-Tests, Erkundungstests usw. wurden durchgeführt usw. Dann ist ein endgültiger Test weniger ein strenges Akzeptanzkriterium als ein endgültiger. " durchlaufen"
  • Es gibt eine Reihe von Testfällen, die von einem professionellen SQA/Tester geschrieben wurden und denen jemand (ein Entwickler) explizit folgen kann/muss
  • Das Risiko eines Ausfalls der Funktion/des Produkts/des Moduls wurde ansonsten auf ein niedriges Niveau reduziert (lassen Sie den Fachmann die Bereiche mit hohem Risiko testen und ein "Anfänger" das niedrigere Risiko testen).
  • Die Realität der Geschäftslage ist, dass die Freigabe eines Produkts mit potenziellen Mängeln besser ist als die Verzögerung der Freigabe
  • Der betreffende Entwickler ist eigentlich auch ein sehr qualifizierter Tester und kann den Rollenwechsel mental vornehmen
  • Die Änderung ist eine Fehlerbehebung, die der Entwickler vor Ort vorgenommen hat, wenn der Standort des Kunden heruntergefahren wird oder auf andere Weise Einnahmen verliert, weil das System offline ist (ein Patch, der ins Büro zurückgebracht und in einer kontrollierten Version so schnell wie möglich getestet/veröffentlicht wird )

Gründe, warum ein Entwickler die Tests nicht durchführen sollte

  • Noch etwas

Im Allgemeinen scheinen Sie auf dem richtigen Weg zu sein, um die reale Lösung anzugreifen. Lassen Sie den SQA-Experten die Testfälle erstellen ...

Hinweis: Ich bin generell dafür, Entwickler die Tests durchführen zu lassen, aber ich stelle verdammt sicher, dass der erste Aufzählungspunkt vorhanden ist.

1
Al Biglan
  • Jeder sollte testen - Entwickelt Testcode, QA-Testfunktionalität, Marketing-Testnachrichten. Auf diese Weise haben alle teilen die gleichen Philosophien und die Sprache rund um das Testen, was die halbe Miete ist.

  • Testen ist Routinewartung und ich normalerweise benutze Analogien zum Vergleichen. Zum Beispiel die Autoölwechsel-Analogie. Sie müssen Ihr Öl nie wechseln. Aber du machst es trotzdem regelmäßig. Gleiches gilt für das Zähneputzen. Es gibt einen Grund, warum Sie sie täglich warten - sie werden nicht "heute" brechen, es geht nur um morgen und zukünftige Tage und darum, eine Investition zu tätigen.

  • Jeder sollte an der Verantwortung teilhaben testen. Ein QA-Team ist wichtig, aber "Testen" als etwas, das nur das QA-Team tut, macht es zu einer "separaten" Aktivität, die nicht in die Produktentwicklung und den Workflow integriert ist, was keine gute Sache ist.

  • Wenn irgendetwas in der Produktion jemals kaputt geht, machen Sie zwei Dinge:

    1. Sagen Sie als ersten Kommentar "hmm, haben wir einen Test dafür ".
    2. Machen Sie eine Korrektur , die Tests für das Problem enthält, die zuerst reproduziert werden sollen, und dann die Korrektur.
1
Michael Durrant

Ich möchte einige Argumente dafür sammeln, warum es eine schlechte Idee ist, einen Entwickler seine/ihre eigene Arbeit als letzten Schritt testen zu lassen, bevor der Test in die Produktion geht, da mein Arbeitsplatz dies leider manchmal tut (das letzte Mal, als dies auftauchte) Das Argument lief darauf hinaus, dass die meisten Leute zu beschäftigt mit anderen Dingen waren und nicht die Zeit hatten, eine andere Person mit diesem Teil des Programms vertraut zu machen - es ist eine sehr spezialisierte Software.

Tests sind für Entwickler nicht optional. Ein Entwickler muss den von ihm geschriebenen Code testen. Wie kann er sonst sicher sein, dass die Aufgabe erfolgreich erfüllt wurde? Sie müssen entweder eine Art automatisierten Tests (Unittests) schreiben oder die Aufgabe ausführen, zu überprüfen, ob der Computer das tut, was ich möchte (manuell) (indem Sie die GUI verwenden, den Befehl in der Befehlszeile aufrufen oder was auch immer).

Alles, was danach getestet wird, ist "nur" zusätzliche Prüfung durch andere Personen (Mitarbeiter, Qualitätssicherung, ...). Es gibt keine Alternative zum direkten Testen durch einen Entwickler. Jeder, der mir sagt, dass ein Entwickler den von ihm geschriebenen Code/die von ihm geschriebene Funktion nicht testen muss (oder darf), hat einfach kein Verständnis dafür, wie Software entwickelt wird.

1
perdian

In meinem Unternehmen erstellen wir einige ziemlich komplexe Finanzanwendungen. Unsere allgemeine Richtlinie lautet, dass der Entwickler sicherstellen sollte, dass keine technischen Fehler auftreten. Versuchen Sie im Grunde alles, um es zu brechen, angesichts der Ressourcen des Benutzers. Wenn Sie keinen Laufzeitfehler finden können, senden Sie ihn zum Testen an die BAs weiter. Wir hatten einige Entwickler, die sich beim Testen der Geschäftsanforderungen bis zum Burn-out verirrt haben, aber nur, weil all diese Tests nicht in ihrer Verantwortung lagen. Sofern kein offensichtlicher Fehler erkennbar ist, senden wir ihn an die Personen weiter, die dafür bezahlt werden, dass sie die Ausgabe verstehen. Außerdem sollten Benutzer eine echte Rolle bei der Überprüfung der Ergebnisse spielen. Der Verkäufer in einem Einzelhandelsgeschäft probiert die Kleidung nicht für Sie an, sondern hilft Ihnen nur bei den "technischen Details" wie der Suche nach Kleidung der richtigen Größe.

0

Ein Problem ist, dass Entwickler wenig Anreiz haben, ihren eigenen Code zu brechen - nur wenige Menschen sind bereit, nach Fehlern in ihren eigenen Werken zu suchen oder Fehler zu machen. Ein separates Team sorgt dafür, dass die Dinge kaputt gehen.

0
Wyatt Barnett