Warum lassen / nicht lassen Entwickler ihre eigene Arbeit testen

81

Ich möchte einige Argumente zusammenfassen, warum es eine schlechte Idee ist, einen Entwickler als letzten Schritt, bevor das Produkt in Produktion geht, seine eigene Arbeit testen zu lassen, da dies leider manchmal an meinem Arbeitsplatz der Fall ist (das letzte Mal, als dies geschah) Das Argument bestand darin, dass die meisten Leute zu beschäftigt mit anderen Dingen sind und nicht die Zeit haben, 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, eine Person zu ernennen, die nicht die Änderungen vorgenommen hat, die getestet wurden, um die endgültigen Tests durchzuführen. Ich frage Sie daher, ob Sie mir eine gute und solide Liste von Argumenten zur Verfügung stellen können, die ich beim nächsten Mal zur Sprache bringen kann. Oder um Gegenargumente zu liefern, falls Sie denken, dass dies vollkommen in Ordnung ist, insbesondere wenn formelle Testfälle zu testen sind.

Pyvi
quelle
6
Ihre Frage scheint darauf hinzudeuten, dass Entwickler keine Tests durchführen sollten. Ich würde sicherstellen, dass Entwickler die Software tatsächlich testen, um sicherzustellen, dass sie funktioniert (und nicht nur kompiliert), um den Testern keine Zeit zu verschwenden.
dnolan
4
@dnolan: Ich spreche hier von den abschließenden Tests, den Tests, bevor der Code in die Produktion geht. Natürlich sollte der Entwickler während der Entwicklung testen.
Pyvi

Antworten:

103

Wie andere (und Sie selbst) bemerkt haben, sollten Entwickler ihren eigenen Code testen. Danach sollte jedoch jedes nicht-triviale Produkt auch von einer unabhängigen Person (QS-Abteilung und / oder dem Kunden selbst) getestet werden.

Entwickler arbeiten normalerweise mit der Denkweise der Entwickler, wie diese funktionieren sollen. . Ein guter Tester denkt darüber nach, "wie man das kaputt macht". - eine ganz andere Denkweise. Unit-Tests und TDD bringen Entwicklern bei, die Hüte in gewissem Maße 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 sollten Endabnahmetests von jemandem durchgeführt werden, der dem Kunden so nah wie möglich ist .

Péter Török
quelle
3
Genau. Nach Stunden, Tagen oder sogar Wochen, in denen versucht wurde, "diese Arbeit zu leisten", kann es SEHR schwierig (vielleicht sogar unmöglich) sein, diese Denkweise zu durchbrechen. Es könnte möglich sein, objektiv zu testen, ob Sie Zeit hatten, Ihre Arbeit beiseite zu legen und nach einer Pause darauf zurückzukommen, aber das ist selten machbar.
PeterAllenWebb
Black Hat Tester ...?
Mateen Ulhaq
7
? +1 für „Entwickler normalerweise mit der Entwickler Mentalität der Arbeit‚ wie diese Arbeit zu machen‘. Ein guter Tester denkt darüber nach ‚ wie dies zu brechen‘?“
Wipqozn
Eine zusätzliche Anmerkung hier; Während das Testen wichtig ist, helfen Codeüberprüfungen beim Auffinden von Fehlern und stellen sicher, dass die richtigen Komponententests geschrieben werden. Entwickler können mit ihren Komponententests auf verschiedene Fehler testen, was es äußerst wichtig macht, dass mehr als eine Person die Software testet.
Rudolf Olah
127

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 von der Denkweise, wie es funktioniert, zu lösen und nicht, wie es funktionieren soll.

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

John Shaft
quelle
3
Einigermaßen wird ein Entwickler den Weg des geringsten Widerstandes einschlagen, um ihre Anwendung zu "testen", Randfälle werden selten untersucht.
dnolan
68
@dnolan, es "schützt" nicht nur ihren Code, sondern auch alles, woran sie beim Codieren nicht gedacht haben, woran sie beim Testen nicht denken.
StuperUser
4
Entwickler testen auch mit den gleichen Vorurteilen als geführt ihre Arbeit. Tester teilen sie mit geringerer Wahrscheinlichkeit.
Programmierer
4
@ Jörg W Mittag eigentlich nicht. So wie nicht jeder Tester an jeden Testfall denkt und auch nicht jeder Entwickler. Daher Paarprogrammierung usw. und getrennte QA-Teams. Zwei Köpfe sind immer besser als einer.
StuperUser
18
An einem Ort, an dem ich arbeitete, sollte ich nicht nur neue Funktionen implementieren, sondern auch Testpläne erstellen. Dies bedeutete, dass, wenn ich etwas missverstand, es falsch implementiert wurde, aber nicht von der Testabteilung abgefangen wurde.
David Thornley
30

Tester Test zu brechen, einfach. Diese Art von Voreingenommenheit ist erforderlich, um die Show-Stopper wirklich herauszufinden.

Aditya P
quelle
15

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

Ich gehe davon aus, dass Sie kein Team haben, das für die Durchführung der Tests auf der Grundlage Ihrer Aussage zuständig ist. Ein spezielles Testteam ist jedoch sehr hilfreich, da Entwickler dazu neigen, ihren Code so zu testen, wie sie ihn codiert haben. Es bedeutet nicht, dass Sie, sobald Sie ein Qualitätssicherungsteam haben, das Testen bereits in der Verantwortung der Entwickler durchführen können.

Entwickler verwenden normalerweise Netze mit riesigen Löchern, um Fehler zu erkennen. Dadurch entkommen kleinere Bugs.

Setzamora
quelle
+1 für "Entwickler MÜSSEN ihre Arbeit testen. Dies ist eine implizite Verantwortung."
Wenn
15

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 Anwender.

Saeed Neamati
quelle
3
Generell machen Entwickler einen schrecklichen Job beim Testen ihres eigenen Codes, und ich schließe mich dieser Gruppe an. Für ein Unternehmen, das Software herstellt, ist eine solide QS-Abteilung unersetzlich.
Adam Crossland
3
Bei hochkomplexer, spezialisierter Software sind Entwickler möglicherweise nicht einmal professionelle Benutzer der Software. Ich kann nicht immer genau vorhersagen, wie sich eine Änderung an einer Schlüsselkomponente auf andere Teile des Systems auswirkt. Wenn jemand anderes darüber nachdenkt, hat dies in etwa den gleichen Zweck wie die Paarbildung: Es zwingt Sie nicht nur dazu, im Vorfeld etwas mehr darüber nachzudenken, sondern verringert auch drastisch die Wahrscheinlichkeit, dass ein Fehler unbemerkt bleibt, bis ein Kunde darauf stößt. Ab diesem Zeitpunkt ist die Reparatur erheblich teurer.
ein Lebenslauf vom
Wir haben in der Vergangenheit festgestellt, dass Sie keine speziellen Tester benötigen. In der Regel reicht es aus, wenn ein anderer Entwickler die von Ihnen geschriebenen Funktionen überprüft. Der Grund dafür ist, dass unsere Firma glaubt, dass sie Affen für Tester mieten können. Aber ich stimme zu, gute Tester sind sehr wichtig.
c_maker
10

Es gibt einige gute Gründe, ein engagiertes Testteam zu haben. Erstens sind Entwickler, wie oben erwähnt, sehr gut darin, zu testen, ob ihr Code funktioniert, ohne ihn zu beschädigen.

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 die Anforderungen erfüllt. In vielen Fällen kennt ein Entwickler nur wenige Teile des Systems sehr gut, aber das QS-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 sich aus, kann jedoch andere Funktionen beeinträchtigen, die Sie nicht kennen.

Nachdem ich mit einem QA-Team gearbeitet habe und ohne, kann ich Ihnen sagen, dass ich die Arbeit, die sie leisten, zu 100% schätze und sagen werde, dass sie ein geschätzter Teil des Software-Teams sind. Wenn Sie ein QA-Team haben, wird die Veröffentlichung Ihres Codes dadurch viel einfacher, da Sie wissen, dass er gründlich getestet wurde und Sie weniger Anrufe um 3 Uhr morgens erhalten.

Tyanna
quelle
Mir gefällt der Punkt, dass die Qualitätssicherung im Wesentlichen das Ergebnis überprüft, um sicherzustellen, dass es den Anforderungen entspricht. Es ist gut, wenn mindestens 2 Personen zustimmen, dass es so funktioniert, wie es "sollte".
Andy Wiesendanger
+1 für a testing teams knows what should have been written. Das ist so sehr wahr.
ein Lebenslauf
8

Entwickler sollten ihren eigenen Code testen.

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

Gilbert Le Blanc
quelle
+1: Dies sollte höher eingestuft werden. Hier geht es nicht nur um die Faulheit des Entwicklers. Ein Entwickler, der seinen eigenen Code testet, hat eine Reihe von Annahmen im Hinterkopf - die gleichen, die er beim Codieren im Hinterkopf hatte. Er hat also einen blinden Fleck beim Testen. Er wird nicht so erfinderisch sein, wie ein unabhängiger Tester, der mit völlig anderen Annahmen an seinen Code herantritt.
Ken Bloom
7

Ich würde erwarten, dass der Entwickler einige erste Tests durchführt, bevor er Änderungen festlegt und sich davon überzeugt, dass der Code funktioniert. Ich würde dann erwarten, dass der Entwickler in die Testfälle das spezifische Wissen einfließen lässt, über das er verfügt. Geben Sie zum Beispiel weitere Bereiche des Codes an, die möglicherweise betroffen sind.

Das Hauptproblem für Entwickler, die ihren eigenen Code testen, ist, dass Sie nur einen Standpunkt testen. Der Entwickler hat die Spezifikation gelesen und interpretiert. Hoffentlich ist die Spezifikation klar, vollständig und eindeutig, aber das 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 erwartungsgemäß funktioniert.

Verschiedene Personen tendieren auch dazu, ein Produkt auf unterschiedliche Art und Weise zu verwenden und infolgedessen unterschiedliche Wege durch den Code zu gehen. Ein Entwickler hat sichergestellt, dass der Code für ihn funktioniert, hat jedoch möglicherweise keinen Edge-Case in Betracht gezogen, den ein anderer Tester möglicherweise findet.

Luke Graham
quelle
5

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

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

Ein weiterer Punkt ist, dass es eine Reihe von Kommunikationsebenen zwischen Spezifikation und Bereitstellung geben kann. Dies kann zu einem Chinese Whispers-Effekt auf das endgültige Deployable führen. Es ist am besten, wenn jeder, der die Anforderung definiert oder einen Fehlerbericht erstellt, testet, dass er so funktioniert, wie er es wollte.

Paul Butcher
quelle
3

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 Fallstudien durchzuführen. (Ich hoffe).
Wesley van Opdorp
quelle
2
Diese Vorstellung, dass Entwickler zu wertvoll sind, um <Aufgabe einfügen, die Sie hier nicht ausführen möchten>, kann meiner Erfahrung nach ziemlich ätzend sein.
Jeremy
3

In der Regel verwenden die Entwickler den Code nur in bestimmten Spezialfällen. Der letzte Testschritt vor dem Umstieg auf ein Produktionssystem sollte daher der Benutzerakzeptanztest UAT sein. Sie kennen sich im Allgemeinen besser mit dem aus, was sie von dem Paket erwarten. Und sind im Allgemeinen besser in der Lage, Dinge mit Zugangsströmen zu brechen, die jemandem unbekannt sind, der sie nicht täglich nutzt.

Ist in Ihren Projektplänen kein Benutzertest vorgesehen? Wenn Sie Benutzer dazu bringen, es zu testen, können Sie Fehler früher als nach der Implementierung entdecken, was in meiner Welt keine schlechte Sache ist.

Versuchung
quelle
3

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

Falls ihr wirklich keine QA einstellen wollt, solltet ihr Entwickler dazu bringen, Testcode für andere Entwickler zu schreiben. Dies ist ein guter erster Schritt. Bald werden Entwickler nach QA-Ressourcen fragen, da die meiste Zeit zusätzlich zu CR für das Testen des Codes anderer Benutzer aufgewendet wird.

Subu Sankara Subramanian
quelle
Ja, andere Entwickler, die den Code testen, sind eine minimale / vorübergehende Lösung, da keine anderen Ressourcen zur Verfügung stehen. (Vorausgesetzt, Sie haben natürlich mehrere Entwickler zur Verfügung!)
Tao
3

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

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

Die meisten Tests durch ein Testteam sind funktional (dh ein Produkt funktioniert gemäß einer Spezifikation) und Black-Box-Tests (das Testteam erkennt nicht die inneren Abläufe einer Anwendung). Funktionstester müssen sich nicht mit der Funktionsweise befassen, sondern sich nur darauf konzentrieren, ob sie dies tun.

StuperUser
quelle
2

Meiner Erfahrung nach muss der Endbenutzer zumindest in meiner kleinen Organisation Tests durchführen. Fast jedes Projekt, das wir erhalten, liefert nicht alle benötigten 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 ihm gegebenen Informationen funktioniert, weiß er nicht, ob dies dem Endbenutzer helfen wird mach ihren Job.

Kratz
quelle
1
Absolut. Arbeitscode ist nicht dasselbe wie der richtige Code für die Situation.
HLGEM
2

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

HLGEM
quelle
Ja, exzellenter Punkt. Die Tatsache, dass Geschäftsanalysen häufig fehlen, führt dazu, dass Anforderungen häufig fehlerhaft oder unvollständig sind, was die Entwickler dazu veranlasst, entweder zeitaufwändige Anforderungen zu erfüllen (in Ordnung, aber zeitaufwändig) oder Annahmen zu treffen (oftmals falsche), wenn der Entwickler unerfahren ist Domain).
Bernard Dy
2

Der Entwickler sollte die ersten Tests durchführen, damit wir wissen, dass das von uns codierte Teil den Anforderungen entsprechend so funktioniert, wie es erwartet wird. Also haben wir die normalen Tests durchgeführt und Unit Tests für den Code geschrieben, den wir geschrieben haben.

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 eine Zeichenfolge ein, die denkt, dass der Benutzer dies auch tun würde. Möglicherweise macht der Benutzer das 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 eintreten könnten, weil er nicht dazu ausgebildet ist, so zu denken. Wenn es um einen QA (Tester) geht, denken sie immer darüber nach, was der Benutzer tun könnte, um diese Anwendung zu beschädigen, und versuchen jedes dumme Ding 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 zur gleichen Zeit hergestellt wird und beide in Produktion gehen. Der Entwickler konnte nur sein Teil testen und denkt, dass dies gut funktioniert, aber der allgemeine Regressionstest muss für alle Teile durchgeführt werden, die verschoben werden, und er muss herausfinden, dass die Kombination von zwei verschiedenen Teilen die Anwendung beschädigen kann 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 UAT (User Acceptance Test) durchgehen, um zu sehen, ob das Stück, das wir gemacht haben, das ist, was erwartet wird. Obwohl die Anforderungen durch die BAs gehen, weiß die endgültige Person möglicherweise nicht genau, wie es aussieht, und sie denkt möglicherweise, dass es nicht den Erwartungen entspricht, oder sie möchte möglicherweise etwas anderes hinzufügen, damit es besser aussieht, oder aus irgendeinem Grund ganzes Stück, da 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 Anpassungen an dem oben Gesagten vornehmen, aber insgesamt nicht vermeiden.

Amar Jarubula
quelle
2

Die obigen Kommentare werfen gute Punkte auf.

Ein weiterer, bisher nicht erwähnter Punkt ist, dass ein separater individueller Testcode als zusätzliche Überprüfung der Anforderungen und der korrekten Implementierung durch das System dient.

Anforderungen und Dokumentation sind nicht perfekt, und die Implementierung resultiert häufig aus der Interpretation der Anforderungen durch einen Entwickler.

Wenn die Tests von einer separaten Person durchgeführt werden, geben sie auch eine 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.

tschaible
quelle
2

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

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

Hoffentlich ist irgendwo ein Tester dabei, um den Programmierer darauf aufmerksam zu machen, was der Benutzer erleben wird, wenn er diese Dinge tut.

Jeffrey L Whitledge
quelle
2

Ein Grund dafür ist, dass Entwickler zu nahe an ihrem eigenen Code sind. Sie wissen, dass es Macken sind, es sind kleine seltsame Verhaltensweisen. Sie neigen dazu , zu testen , um die kleinen Idiosynkrasien 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 bewirken wird. Oft entwickeln sie Szenarien, von denen das Entwicklerteam 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 werden behoben. Dies gilt für alle Phasen, sodass die getestete Phase die vorherige ist, die gebaut wurde.

FrustratedWithFormsDesigner
quelle
1

Ich möchte einige Argumente zusammenfassen, warum es eine schlechte Idee ist, einen Entwickler als letzten Schritt vor dem Start des Tests seine / ihre eigene Arbeit testen zu lassen, da dies leider manchmal an meinem Arbeitsplatz der Fall ist (das letzte Mal, als dies geschah) Die meisten Leute waren zu beschäftigt mit anderen Dingen und hatten nicht die Zeit, 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 erledigt wurde? Entweder müssen Sie eine Art automatisierter Tests (Unittests) schreiben oder die Aufgabe der Überprüfung ausführen, ob die Maschine das tut, was ich will (über die GUI, den Befehl in der Befehlszeile oder was auch immer).

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

perdian
quelle
3
Das OP fragt nicht, ob die Entwickler testen sollen oder nicht. Das OP fragt, ob es eine gute Idee ist, dass der Entwickler der einzige ist, der die Tests durchführt.
Lie Ryan
1

Es wird von jemandem getestet, der mit dem Code nicht vertraut ist, ob es Ihnen gefällt oder nicht. Die Frage ist, ob Sie möchten, dass jemand Ihr Kunde ist.

Karl Bielefeldt
quelle
1

Gute Frage. In Ihrer Situation gibt es - manchmal - Testfälle, und die Software scheint so komplex zu sein, dass es nicht praktikabel ist, 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 Abschlusstest durchzuführen

  • Es gibt genügend andere Testabdeckungen ... Unit-Tests existieren, eine Integrationstestumgebung existiert und wird verwendet, UI-Tests, Erkundungstests usw. wurden durchgeführt usw. Dann ist ein endgültiger Test weniger ein strenges Annahmekriterium 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 gesenkt (lassen Sie den Fachmann die Bereiche mit hohem Risiko und einen "Anfänger" das geringere Risiko testen).
  • In der Realität ist es besser, ein Produkt mit potenziellen Mängeln freizugeben, als die Freigabe zu verzögern
  • 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 durchführt, wenn die Site des Kunden heruntergefahren wird oder anderweitig Einnahmen einbüßt, weil das System offline ist (ein Patch, der in einer kontrollierten Version so schnell wie möglich ins Büro zurückgebracht und getestet / veröffentlicht wird )

Gründe, warum ein Entwickler den Test nicht durchführen sollte

  • Noch etwas

Im Allgemeinen scheinen Sie auf dem richtigen Weg zu sein, die eigentliche Lösung anzugreifen - Lassen Sie die Testfälle vom SQA-Experten generieren ...

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

Al Biglan
quelle
1

Als Mensch neigen Menschen dazu, unter kognitiven Abweichungen zu leiden - wobei sich ihre Einschätzung in zwei nahezu identischen Szenarien einfach aufgrund einiger geänderter Dinge unterscheidet -. Eine Sache, die ich in 8 Jahren Entwicklung bemerkt habe, ist, dass Entwickler sind Im Gegensatz zu Code, den ein Kollege geschrieben hat, ist das Testen seines eigenen Codes von schlechterer Qualität.

Dies soll nicht heißen, dass der Entwickler direkt ein Verschulden trifft - sein Gehirn wird die Voreingenommenheit, die es geschrieben hat, verwenden, um die Tatsache zu bekräftigen, dass es seiner Meinung nach richtig ist, und wird nur grundlegende Überprüfungen durchführen, im Gegensatz zu einem Entwickler, der dies tut Wenn Sie sich den Code einer anderen Person ansehen, werden Sie eine Menge gründlicherer Überprüfungen durchführen.

Es gibt Tausende von Beispielen, bei denen Verfahren eingeführt wurden, um kognitive Verzerrungen zu verhindern, oder allgemein als "Human Factor" bezeichnet, wie beispielsweise Computersysteme in der Flugsicherung, um zu verhindern, dass zwei verschiedene Flugzeuge denselben Luftraum gleichzeitig einnehmen Zeit, um medizinische Verfahren eingeführt, so dass mehr als ein Arzt eine Diagnose geben müssen.

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.

Chirurgischer Kodierer
quelle
1
  • Jeder sollte testen - Entwickler-Testcode, QA'ers-Testfunktionalität, Marketing-Testnachrichten. Auf diese Weise teilen alle die gleiche Philosophie und Sprache beim Testen, was die halbe Miete ist.

  • Testen ist Routinewartung und ich verwende normalerweise 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 pflegen - sie werden nicht "heute" brechen, es geht nur um morgen und zukünftige Tage und um eine Investition.

  • Jeder sollte sich an der Verantwortung beteiligen, zu testen. Ein QA-Team ist wichtig, aber "Testen" als etwas zu machen, 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 kaputt geht, machen Sie zwei Dinge:

    1. Sagen Sie "hmm, haben wir einen Test dafür " als ersten Kommentar.
    2. Nehmen Sie vor, dass alle Fixes Tests für das Problem enthalten , die zuerst reproduziert werden sollen, und schließen Sie dann Fixes ein.
Michael Durrant
quelle
0

In meiner Firma erstellen wir einige ziemlich komplexe Finanzanwendungen. Nach unserer allgemeinen Richtlinie sollte der Entwickler sicherstellen, dass keine technischen Fehler auftreten. Versuchen Sie im Grunde alles, um es zu brechen, angesichts der Ressourcen des Benutzers. Wenn Sie einen Laufzeitfehler nicht finden können, senden Sie ihn zum Testen an die BAs. Wir hatten ein paar Entwickler, die sich beim Testen von Geschäftsanforderungen bis zum Burnout verirrt haben, aber nur, weil all diese Tests nicht in ihrer Verantwortung lagen. Sofern keine offensichtlichen Fehler erkennbar sind, leiten wir sie 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 eines Einzelhandelsgeschäfts probiert die Kleidung nicht für Sie an, sondern hilft Ihnen nur bei den "technischen Details" wie der Suche nach Kleidung in der richtigen Größe.

Morgan Herlocker
quelle
0

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

Wyatt Barnett
quelle
-1

Eine Rolle in der Qualitätssicherung ist unter anderem wichtig, damit jemand überprüfen kann, ob der Entwickler die Anforderungen verstanden hat. Der Entwickler kann diese Prüfung nicht selbst durchführen, da er bei Missverständnissen eine Klärung wünscht.

Stephen Paulger
quelle