Belassen Sie absichtliche Fehler im Code, die Tester finden können

Wir machen das in unserer Firma nicht, aber einer meiner Freunde sagt, dass sein Projektmanager jeden Entwickler gebeten hat, vorsätzliche Fehler hinzuzufügen, bevor das Produkt an die Qualitätssicherung geht. So funktioniert es:

1. Kurz bevor das Produkt an die Qualitätssicherung geht, fügt das Entwicklungsteam an zufälligen Stellen im Code einige absichtliche Fehler hinzu. Sie sichern den ursprünglichen Arbeitscode ordnungsgemäß, um sicherzustellen, dass diese Fehler nicht mit dem Endprodukt geliefert werden.
2. Hierüber werden auch die Tester informiert. Deshalb werden sie hart testen, weil sie wissen, dass es Fehler gibt und dass das Nichtfinden als Zeichen von Inkompetenz angesehen werden kann.
3. Wenn ein Fehler (absichtlich oder auf andere Weise) gefunden wurde, wird dieser gemeldet, damit das Entwicklungsteam ihn beheben kann. Das Entwicklungsteam fügt dann einen weiteren absichtlichen Fehler in einen verwandten Abschnitt des Codes ein, bevor das Produkt zur QS der zweiten Ebene übergeht. Der Projektmanager sagt, ein Tester sollte wie ein Entwickler denken und in Abschnitten, in denen Änderungen vorgenommen wurden, mit neuen Fehlern rechnen.

Nun, so geht es. Sie sagen, dass dieser Ansatz folgende Vorteile hat.

1. Tester werden immer auf Trab sein und sie werden wie verrückt testen. Das hilft ihnen, versteckte (unbeabsichtigte) Fehler zu finden, damit Entwickler sie beheben können.
2. Tester ernähren sich von Fehlern. Wenn keine Bugs gefunden werden, wirkt sich dies auf die Moral aus. Wenn Sie ihnen also eine leicht zu findende geben, hilft dies ihrer Moral.

Wenn Sie das Szenario ignorieren, in dem einer dieser absichtlichen Fehler mit dem Endprodukt ausgeliefert wird, welche weiteren Nachteile sollten wir berücksichtigen, bevor wir überhaupt daran denken, diesen Ansatz zu übernehmen?

Einige Klarstellungen:

1. Sie sichern ordnungsgemäß den ursprünglichen Code in der Quellcodeverwaltung.
2. Wenn ein Tester den beabsichtigten Fehler findet, ignoriert das Entwicklungsteam ihn einfach. Wenn der Tester einen unbeabsichtigten (ursprünglichen) Fehler feststellt, prüft das Entwicklungsteam zunächst, ob er durch einen der beabsichtigten Fehler verursacht wurde. Das heißt, das Entwicklungsteam versucht zunächst, diesen Fehler im ursprünglichen Arbeitscode zu reproduzieren und zu beheben, wenn dies möglich ist.
3. Ignorieren Sie einfach die Beziehungsprobleme zwischen QS und Entwicklungsteam. Ich habe diese Frage speziell für Programmierer gestellt , nicht für The Workplace . Bedenken Sie, dass es ein gutes Verhältnis zwischen der Qualitätssicherung und dem Entwicklungsteam gibt und dass sie nach der Arbeitszeit zusammen feiern. Der Projektmanager ist ein netter, alter Herr, der immer bereit ist, beide Teams zu unterstützen (Godsend).

Das klingt absolut verrückt. Es ist mit viel Aufwand verbunden, um einen sehr fragwürdigen Nutzen zu erzielen, und die Praxis scheint auf einigen fehlerhaften Prämissen zu beruhen:

• Diese Qualitätssicherung wird nicht hart arbeiten, wenn sie nicht wissen, dass sie jeden Tag getestet werden (was nicht gut für die Moral ist)

• Es gibt nicht genügend ungewollt eingeführte Fehler in der Software, die von der Qualitätssicherung gefunden werden können

• Die Aufgabe von QA ist es, Fehler zu finden - das ist es nicht. Es soll sicherstellen, dass die Software in Produktionsqualität ist

• Dass ein solcher Kampf zwischen Entwicklung und Qualitätssicherung in gewisser Weise gesund für das Unternehmen ist - ist es nicht; alle mitarbeiter sollten gegen die mitbewerber des unternehmens zusammenarbeiten und nicht gegeneinander.

Es ist eine schreckliche Idee und der betreffende Projektmanager ist ein Idiot, der nichts von Menschen und Motivation versteht. Und es ist schlecht fürs Geschäft.

Um meine Beschreibung des Jobs von "QA" zu erweitern: QA sollte definitiv Fehler finden - sowohl im Code als auch in den Testsuiten - als Artefakt bei der Erledigung ihrer Aufgaben, aber die Rolle sollte nicht als "Sie müssen finden" definiert werden Käfer. " Es sollte sein, "dass Sie die Testsuiten auf dem neuesten Stand halten müssen, um neue Funktionen zu berücksichtigen und eine hohe Testabdeckung sicherzustellen. Wenn dies nicht zu Fehlern führt, sind die Testverfahren für das Produkt nicht ausreichend ausgefeilt.

Nun, basierend auf dem, was ich gelernt habe:

1. Es ist weder eine Schule noch ein Vorstellungsgespräch.
2. Die Tester sind keine Kinder;
3. Es ist kein Spiel;
4. Es verschwendet das Geld des Unternehmens.

Die QA werden dort nicht nur zu finden , Bugs , sondern auch darum zu kümmern , wie intuitiv das System ist, was ist die Lernkurve für die Benutzer, Benutzerfreundlichkeit und Zugänglichkeit im Allgemeinen. Zum Beispiel: "Ist das System hässlich ?", "Ist der Benutzer farbenblind und das Zeug ist rot und grün?" Sie sollten sich auch beschweren.

Die Mindestanforderungen an ein System zum Bestehen der Qualitätssicherung werden in der Regel in einer User Story für diese bestimmte Funktion oder in der Frage beschrieben, wie magisch die PO wollte, dass das System in seinem Kopf ist.

tl; dr

Es sind nicht nur Bugs, Tester sollten aus dieser engen Sicht herauswachsen.

Schlechte Idee.

Aus der Sicht des Testers: "Sie werden also harte Tests durchführen, weil sie wissen, dass Fehler vorhanden sind, und wenn sie diese nicht finden, kann dies als ihre Inkompetenz angesehen werden." Grundsätzlich fangen die Entwickler den Code ab. Nur wenige Menschen tun gerne Arbeit, die letztendlich sinnlos ist (weil die Fehler im Voraus bekannt sind), die aber immer noch die Art und Weise beeinflussen, wie sie wahrgenommen werden. Wenn es greifbare Strafen gibt, wenn die Sprengfallen nicht gefunden werden, umso mehr. Und wissen Sie, dass Tester auf der Suche nach Fehlern gedeihen? Das klingt nach einer giftigen konfrontativen Umgebung. Eine Qualitätssicherung sollte sich freuen, wenn der untersuchte Code von hoher Qualität ist. Obwohl, wenn sie durch den Fehler bezahlt werden ... http://thedailywtf.com/articles/The-Defect-Black-Market

Aus der Sicht des Entwicklers: Die QAs werden dazu angeregt, die Fehler zu finden, von denen Sie wissen, dass sie vorhanden sind. Dies kann die Wahrscheinlichkeit erhöhen, dass echte Bugs aus der Tür gehen. Die QAs verbringen zumindest einen Teil ihrer Zeit damit, nach der Art von Käfer zu suchen, die sich leicht pflanzen lässt und nicht wirklich subtil ist. Außerdem besteht eine geringe Chance, dass eine Sprengfalle es aus der Tür schafft.

Ich stimme den obigen Antworten voll und ganz zu, warum dies schlecht für die Motivation und das allgemein schreckliche Personalmanagement ist. Es gibt jedoch wahrscheinlich gute technische Gründe, dies nicht zu tun:

Kurz bevor das Produkt an die QS geht, fügt das Entwicklerteam an zufälligen Stellen im Code einige absichtliche Fehler hinzu. Sie sichern den ursprünglichen Arbeitscode ordnungsgemäß, um sicherzustellen, dass diese Fehler nicht mit dem Endprodukt geliefert werden.

1. Basierend auf der ersten Anweisung testen Sie in diesen beiden Durchläufen niemals Ihren beabsichtigten Produktionscode.

2. Ich kann mir vorstellen, dass Sie die Wahrscheinlichkeit, versehentlich einen "vorsätzlichen" Fehler in Ihren freigegebenen Produktionscode einzufügen, erheblich erhöhen, wenn Sie versuchen, eine Änderung für einen Kunden durchzuführen. Kann irgendwann ein paar rote Wangen verursachen.

3. Ich würde mir vorstellen, dass dies Ihre Tester dazu bringt, so zu denken wie Ihre Entwickler (dh wie würde Tom hier einen Fehler hinzufügen), wodurch sie wahrscheinlich weniger wahrscheinlich die Fehler finden, an die Tom nicht gedacht hat.

Bearbeiten

Ich möchte klarstellen, dass es in dieser Antwort nur um das Konzept des Testens Ihres QS-Prozesses geht, und ich verteidige nicht die in der Frage dargestellte spezifische Methodik.

Bearbeiten beenden

Es gibt einen gültigen Grund zu prüfen, ob Ihre Prüfung tatsächlich funktioniert. Lassen Sie mich ein Beispiel aus der Fertigung geben, aber das Prinzip ist dasselbe.

Es ist typisch, wenn Material durch eine Maschine zugeführt wird, dass die Zuführung das Material möglicherweise nicht weit genug durchdrückt. Dies wird als "Kurzvorschub" bezeichnet. Um dies zu verhindern, wird möglicherweise ein "Kurzvorschubsensor" (normalerweise ein Einweglichtschrankensensor, der durch das Material blockiert wird) installiert. Dieser Sensor erkennt das Ende des Materials, wenn es die volle Vorschublänge erreicht. An einem bestimmten Punkt im Maschinenzyklus prüfen wir, ob der Sensor blockiert ist, und stoppen die Maschine, wenn die Prüfung fehlschlägt.

Nun müssen Sie darüber nachdenken, wie der Test selbst fehlschlagen kann. Zum Beispiel können Schmutz oder andere Ablagerungen den Sensor blockieren und es wird immer "OK" gemeldet und die Maschine niemals angehalten. Außerdem schaltet sich der Empfänger ein, wenn der Strahl auf ihn trifft. Abhängig von der Art des installierten Sensors erhalten Sie also elektrisch einen "EIN" -Eingang, wenn der Sensor nicht blockiert ist . Das bedeutet, wenn das Kabel unterbrochen wurde oder die Stromversorgung für diesen Sensor unterbrochen wurde oder die Eingabe fehlschlug, lautete die Logik Ihres Programms "AUS" und dies bedeutete "blockiert" oder "OK".

Um diese Fehlermodi des Tests abzufangen, führen Sie normalerweise eine zweite Überprüfung durch, um sicherzustellen, dass der Sensor während eines zweiten Teils des Zyklus tatsächlich entsperrt ist . Auf diese Weise überprüfen wir, ob der Test tatsächlich noch funktioniert (so gut wir können).

Ebenso gibt es viele Möglichkeiten, wie eine QA-Abteilung ausfallen kann. Möglicherweise liefen die automatisierten Tests nicht und der Bericht zeigt eine alte Kopie der Testdaten an. Vielleicht macht jemand seinen Job nicht richtig. Es ist sinnvoll, die QS-Abteilung zu testen.

Offensichtlich ist der Nachteil, dass ein "Testfehler" es durch die QS-Abteilung und in das fertige Produkt schaffen könnte. In der Fertigungsindustrie gibt es manchmal Fälle, in denen ein bekanntes fehlerhaftes Teil, manchmal als "rotes Kaninchen" bezeichnet, in den Prozess eingefügt wird (normalerweise von jemandem aus der Qualitätssicherung) und dieser Teil den Prozess durchläuft und misst, wie lange es dauert Finde das Teil und entferne es. Normalerweise ist dieser Teil hellrot (oder orange) lackiert, damit er leicht nachverfolgt werden kann. Da jemand beobachtet, wie das Teil während dieses Tests den Prozess durchläuft, ist die Chance, dass es in das Endprodukt gelangt, praktisch gleich Null. Es gibt natürlich apokryphe Geschichten von jemandem, der einen bekannten schlechten Teil in den Prozess einbringt, um zu sehen, ob das System ihn finden kann.

Ehrlich gesagt, würde ich dieses Verhalten als offensichtlich unethisch und unpraktisch bezeichnen. Der Ministerpräsident muss dringend umgeschult werden, wenn nicht sogar gekündigt werden.

• Es zeigt einen grundlegenden Mangel an Verständnis für das Konzept der Qualitätssicherung . Tester sollten nicht wie Entwickler denken, sondern wie Endbenutzer. Der gesamte Grund für QA-Teams liegt darin, dass Entwickler dem Code von Natur aus zu nahe sind. QA soll genügend Abstand zum Code haben, um zu erfassen, was die Entwickler vermissen.
• Es verschwendet Qualitätssicherungsaufwand . Unter der Annahme, dass diese Fehler nicht trivial sind - siehe unten, wenn sie auftreten -, bedeutet dies, dass die Qualitätssicherung Zeit und Ressourcen für die Untersuchung bereits bekannter Dinge verwendet, wenn sie diese Anstrengungen auf die Suche nach Unbekanntem verwenden könnten.
• Es verschwendet Entwickleraufwand . Damit QA-Mitarbeiter diese nicht trivialen Fehler erkennen können, müssen sie zuerst von den Entwicklern geschrieben werden. Dies erfordert noch mehr Aufwand, da nicht nur die Programmierfehler, sondern auch die Softwareanforderungen und das Design berücksichtigt werden müssen.
• Dies gefährdet die Produktion unnötig . Es ist nur eine Frage der Zeit, bis die Änderungen nicht ordnungsgemäß übernommen werden.
• Wenn dies nicht der Fall ist, ist es sinnlos . Wenn alle bekannten Fehler trivial sind, werden sie keine minderwertigen Arbeiter fangen: Sie werden nur Leute fangen, die überhaupt keine Arbeit tun. Dafür gibt es bessere Möglichkeiten.
• Es vergiftet die Arbeitsumgebung . Ihre QS-Tester sind Profis. Man sollte darauf vertrauen, dass sie professionell sind, bis es einen tatsächlichen Grund gibt, etwas anderes zu vermuten. Wenn es ist Grund anders zu vermuten, sollte es statt dieser Gedankenspiele eine richtige Untersuchung sein. Alles andere tötet die Moral.

Ernsthaft. Auch wenn sich die Paranoia des Premierministers in diesem speziellen Fall als begründet herausstellt, ist dies nicht jemand, der irgendwelche geschäftsführenden Tester hat.

Persönlich fühle ich mich mit diesem Ansatz unwohl.

Die Hauptsache, die mich beschäftigt, ist die Praktikabilität des Einfügens von absichtlichen Fehlern. Dies scheint mir auf eine vorhersehbare Weise schwierig zu sein.

Jegliche Änderungen am Code (absichtlich oder nicht) Risiko mit Nebenwirkungen. Diese Nebenwirkungen können zwar während des Testens aufgedeckt werden, es ist jedoch möglicherweise nicht offensichtlich (selbst für den Entwickler, der den Fehler bepflanzt hat), woran die Ursache liegt. Es fühlt sich nicht "sicher" an, wenn Sie wissen, was ich meine (ich spreche hier aus meinem Bauch heraus).

Außerdem verschwendet der Tester viel Zeit mit dem Testen von Code, der nicht veröffentlicht wird. Sobald die absichtlichen Bugs beseitigt sind, sollte meiner Meinung nach trotzdem ein vollständiger Re-Test durchgeführt werden. Das ist der springende Punkt beim Testen. Etwas ändert sich, irgendetwas , und Sie testen alles erneut . Ok, ich weiß, dass das in der Praxis nie passiert, aber darum geht es beim Regressionstest.

Also insgesamt nicht überzeugt.

Auf der anderen Seite neigen wir dazu, die Kunden die Arbeit der QA-Teams überprüfen zu lassen, was möglicherweise nicht ideal ist. Es ist jedoch eine sehr leistungsfähige Rückkopplungsschleife.

Aus den bereits genannten Gründen ist dies eine schlechte Idee, aber Bug-Seeding ist ein nützliches Werkzeug für einen anderen Zweck. Sie können es verwenden, um einen groben Überblick über die Effektivität des QS-Prozesses zu erhalten.

Nehmen wir im einfachsten Fall an, Sie setzen 100 Bugs ein, die für die gesamte Bandbreite der echten Bugs repräsentativ sind (ich weiß, unwahrscheinlich, aber ich vereinfache). Sie sagen QA nicht, dass Sie dies tun , um das Experiment nicht zu verderben. Am Ende des QA-Prozesses haben sie 60 der 100 gesetzten Bugs (und andere echte Bugs) gefunden. Jetzt wissen Sie, dass die Qualitätssicherung 60% der Fehler findet.

Sie können dies weiter ausbauen, indem Sie die Anzahl der tatsächlich gefundenen Fehler-QS zählen und die Fehlerquote anwenden. In unserem Beispiel, wenn QA 200 echte Bugs gefunden hat, können Sie daraus schließen, dass sie nur 60% von ihnen gefunden haben, so dass 133 übrig bleiben.

Dies ist natürlich nur eine grobe Schätzung mit großen Fehlerbalken. Es ist schwer, realistische, repräsentative Bugs zu schreiben. Die von Ihnen geschriebenen Fehler sind für die Qualitätssicherung wahrscheinlich leichter zu finden, da die Entwickler darin geschult sind, keine Fehler zu schreiben. Es ist möglicherweise besser, eine Klasse von Fehlern wie einzelne Fehler, Unicode-Fehler, Pufferüberläufe usw. zu simulieren.

Dies sollte auf den gesamten QS- Prozess angewendet werden, der das Testen von Entwicklereinheiten, die kontinuierliche Integration und, sofern verfügbar, ein dediziertes QS-Team umfasst.

Dies ist eine Metrik und sollte nicht als Motivationsinstrument für das Management missbraucht werden.

Schlechte Idee.

Dies ist der logische, binäre Ansatz, den Entwickler häufig verwenden, der jedoch die QEs demotiviert. Es zeigt einfach einen Mangel an Vertrauen. QEs werden in diesen Situationen oft ohne viel Input von ihnen platziert, und es wird angenommen, dass sie damit einverstanden sind, und es ist nicht ihre Aufgabe, etwas anderes vorzuschlagen.

Diese Art des Denkens führt dazu, dass QEs nur manuelle Tester sind und nicht dazu motiviert sind, den tatsächlich getesteten Code zu verstehen.

Ich bin ein erfahrener QE und dies ist ein bekanntes Problem in den meisten Organisationen, in denen ich gearbeitet habe.

Ich würde schlechte Idee sagen.

Erstens: Programmierer werden viel Zeit damit verbringen, absichtliche Fehler in den Code einzufügen, und sich bemühen, die gute Version zu retten. Während die Tester vermutlich alles testen sollten, einschließlich der Funktionen mit dem eingepflanzten Fehler, müssen sie, wenn sie einen finden, vermutlich zurückgehen und diesen Test erneut ausführen, um zu überprüfen, ob dies tatsächlich ein Fehler war (und nicht, dass der Tester verwirrt war irgendwie). Zumindest werden Tester Zeit damit verbringen, die eingepflanzten Käfer aufzuschreiben. Dann müssen die Programmierer Zeit damit verbringen, den Fehler zu beheben, den sie gepflanzt haben. Dies ist eine Menge Aufwand, der aufgewendet werden könnte, um guten Code zu schreiben und echte Bugs aufzuschreiben.

Zweitens: Es sendet eine klare Botschaft an die Tester, dass die Programmierer und / oder das Management der Meinung sind, dass sie ihre Arbeit nicht machen und als Kinder behandelt werden müssen. Ich kann mir nicht vorstellen, dass das gut für die Moral ist. Wenn ich als Programmierer mehrdeutige oder widersprüchliche Spezifikationen für ein Programm erhalten habe und einige Zeit damit verbringen musste, diese zu klären, sagte mir mein Chef, nachdem ich Stunden oder Tage verschwendet hatte: "Oh, ja, ich habe absichtlich widersprüchliche Aussagen gemacht "Die Angaben nur, um sicherzugehen, dass Sie sie wirklich gelesen haben." Ich würde mich wirklich ärgern. Wenn das regelmäßig passiert, könnte das ausreichen, um mich nach einem anderen Job umzusehen.

Im wirklichen Leben werden alle bis auf die trivialsten Codeänderungen Fehler haben. Ich hatte noch nie ein Problem damit, dass Tester selbstgefällig wurden, weil der erste Entwurfscode, den sie erhielten, so oft zu 100% perfekt war. Ich musste mich mit faulen Testern auseinandersetzen, die keinen angemessenen Job machen, aber sie kamen nicht so zurecht, weil die Programmierer so perfekt waren. Der beste Tester, mit dem ich je zusammengearbeitet habe, sagte mir, dass er sich für ein neues Software-Release ein persönliches Ziel gesetzt habe, 100 Fehler zu finden. Okay, ob 100 eine realistische Zahl ist, hängt davon ab, wie groß das Produkt ist und wie umfangreich die Änderungen sind, aber in unserem Fall hat er es fast immer geschafft, dieses Ziel zu erreichen. Manchmal musste er Dinge strecken, wie das Nennen eines falsch geschriebenen Wortes in einer Nachricht als "Fehler", aber hey, es musste behoben werden.

Postskriptum: Wenn Sie dies tun, wette ich, dass die Programmierer früher oder später absichtlich einen Fehler auslösen, die Tester diesen nicht finden und die Programmierer vergessen, den guten Code zurückzusetzen. Jetzt wird ein absichtlich gepflanzter Käfer an den Kunden versendet.

Ich halte das nicht wirklich für eine schlechte Idee. Es gibt nur eine Menge Dinge, über die ich besser spekulieren würde:

1. Machen Sie die Qualitätssicherung nach Möglichkeit für die Qualität verantwortlich. Zum Beispiel, indem sie ihre Verantwortung auch unterstützen. Dies erhöht ihre Motivation, um sicherzustellen, dass die gelieferten Produkte eine höhere Qualität haben. Es ist immer weniger anstrengend, eine Unzulänglichkeit (Fehler, offensichtlich fehlende Funktion, kontraintuitives Verhalten) selbst zu entdecken, als zu versuchen, zu verstehen, was der verärgerte Benutzer zu erklären versucht. Und selbst den Entwicklern einen Teil dieser Verantwortung zu übertragen, könnte ihre Motivation erhöhen, der Qualitätssicherung dabei zu helfen, ihre Arbeit so gut wie möglich zu erledigen.

2. Haben Sie mehrere QA-Teams, die antreten können. Sie müssen natürlich eine vernünftige Metrik finden. Auf jeden Fall nicht nur die Anzahl der Probleme. Die Berücksichtigung der Schwere des Fehlers oder des Geschäftswerts (wie von den Stakeholdern bestimmt) der vorgeschlagenen Verbesserungen sollte hilfreich sein.

Es ist schwer zu sagen, ob die Qualitätssicherung "gut genug" ist. Es ist auf lange Sicht einfacher und möglicherweise sogar besser, Wege zu finden, wie die Qualitätssicherung "immer besser" wird.

Dennoch gibt es ein Problem, das Sie beachten sollten, wenn Sie absichtliche Fehler einführen: Woher wissen Sie, dass der "richtige" Code überhaupt überhaupt richtig war? Nach der 2. Qualitätssicherung entfernen Sie alle absichtlichen Fehler, die nicht entdeckt wurden. Es gibt keine Möglichkeit zu wissen, dass Sie sie nicht einfach durch Code ersetzen, der auf andere Weise beschädigt wurde, oder dass Sie kein fehlerhaftes Verhalten aktivieren, das zuvor nicht erreichbar war (übertriebenes Beispiel: Einige Dialogfelder wurden aufgrund eines beabsichtigten Fehlers nicht geöffnet. Aber der Dialog selbst ist kaputt - man findet es einfach nicht heraus, weil die Tester es nicht gesehen haben.

Wie bereits erwähnt, sollten die Entwickler der Software keine absichtlichen Fehler hinzufügen. Es ist jedoch eine legitime Strategie für Ihre Testsuite , im Rahmen des Testprozesses Fehler in die Software einzufügen.

Es heißt Mutationstests . Die Idee ist, Software zu verwenden, um die Erstellung kleiner Änderungen im Quellcode (Mutanten genannt) zu automatisieren. Die Änderungen sollen zu einem anderen Verhalten führen, das wir beispielsweise ändern könnten

if x < 10:
    print "X is small!"

in

# we flipped the inequality operator
if x > 10:
    print "X is small!"

und ein guter Komponententest sollte feststellen, dass das mutierte Codefragment nicht mehr wie erwartet funktioniert und die Mutante tötet . Wenn der ursprüngliche Code den Test besteht und alle Mutanten (die nicht funktionell äquivalent sind) den Test nicht bestehen, wissen Sie, dass Ihr Code und Ihre Tests stark sind .

Ich mag die Idee. War es General Patton, der sagte: "Je mehr Sie in Frieden schwitzen, desto weniger bluten Sie im Krieg."

Das Setzen von absichtlichen Fehlern "verschwendet Zeit" der Tester. Das macht sie aber auch härter, was bedeutet, dass sie auch besser darin sind, unbeabsichtigte Fehler zu finden. (Und Sie haben eine Kopie des "Originals", damit Sie nicht mit dem leben müssen, was Sie getan haben.)

Das Auffinden von mehr ungewollten Fehlern erspart Ihnen wahrscheinlich auf lange Sicht mehr Kummer als die Kosten des Umgangs mit den beabsichtigten Fehlern.

Außerdem können Sie sich ein Bild davon machen, wie gut Ihre Tester sind, was an sich kein geringer Vorteil ist.

Es gibt keine Grundlage für eine Belohnung oder Bestrafung nach eigenem Verdienst, sondern nach dem Ergebnis des Verhaltens, auf das Sie zielen. Und manchmal gibt es unbeabsichtigte Konsequenzen. Ist das Ziel, das QA-Team davon abzuhalten, nachzulassen oder einem Manager das Gefühl zu geben, tatsächlich etwas beizusteuern, ohne zu bemerken, dass er nur im Weg ist.

Positives Ergebnis - Das QA-Team arbeitet härter daran, Fehler zu finden. Wer weiß, vielleicht sehen sie das als Herausforderung. Es ist ein Freundschaftsspiel. Oder sie tun nur, weil sie beobachtet werden (Hawthorne-Effekt?).

Negatives Ergebnis - Sie arbeiten möglicherweise nicht härter und finden den Fehler trotzdem. QA sieht dies als geringfügig und kontrovers an. Jetzt machen sie sich auf die Suche nach Hyper-Bugs und geben alle möglichen kleinen Probleme zurück. Diese Schriftart wird nicht richtig gerendert, wenn ich einen Screenshot mache, ihn in ein PDF konvertiere und ihn mit 500% ansehe.

No Impact - für mich macht das keinen Unterschied, warum also? Sie riskieren nur, Zeit zu verschwenden und Menschen zu ärgern.

Wir sind uns alle einig, dass dies in 90% der Fälle nicht funktioniert. Den anderen 10% tut das nicht viel. Testen Sie die Dinge selbst. Sind Kunden zufriedener mit einer Version, die die beabsichtigten Codefehler aufweist? Beeinträchtigt es die Arbeitsmoral und die Produktivität in anderen Bereichen? Umsatz steigern? Du erzählst uns.

Aus einer Welt kommend, in der Entwickler die Tests selbst schreiben und ausführen sollen, erschreckt und verwirrt mich dieses "Test" -Silo, das Sie meinen, und ich werde versuchen, aus dieser Perspektive zu antworten. Abgesehen davon sollten sich qualifizierte QS-Ingenieure aus meiner Sicht (wie in der Antwort von @ SparK ausführlich beschrieben) auf die größeren Probleme konzentrieren, um sicherzustellen, dass die Software die User Storys vollständig erfüllt und eine allgemeine "Qualität" aufweist (in Bezug auf die Domain, für die die Software bestimmt ist), anstatt nach Fehlern zu suchen.

Was mich hierher zog, ist @ JamesMcleods Erwähnung der "Defektinjektion" in den Kommentaren zur Frage. Ich denke tatsächlich, dass es eine großartige Idee ist, die Entwickler zu überlegen, wie sie Bugs in das System einschleusen können, um das Konzept der Verteidigung genauer zu untersuchen. Kein einziger Fehler sollte jemals ausreichen, um das gesamte System auf unkontrollierte Weise herunterzufahren (ohne eindeutige, umsetzbare Protokollierung), Daten zu beschädigen oder eine Sicherheitsanfälligkeit aufzudecken.

Wenn die Entwickler jeder Komponente absichtliche Fehler verursachen, mit denen anderer Komponenten umgehen und insgesamt widersprüchlicher mit ihrer Software umgehen, kann dies möglicherweise viel zur Verbesserung der Robustheit der Software beitragen. Sogar der unmittelbare Nutzen könnte erheblich sein - ich würde verlangen, dass der Entwickler bei jeder Injektion einer neuen Art von Defekt (der bisher nicht getestet wurde) sofort einen neuen Test durchführt, der mit einem entsprechenden Flag versehen wird Lassen Sie den Fehler für kurze Zeit ungestört in der Codebasis verbleiben und schalten Sie ihn dann vor der Auslieferung ein (und entfernen Sie den Fehler), um einen regelmäßigen Test durchzuführen, der die Testsuite umfassender macht.

Eine verwandte Option ist die Verwendung von Feature-Flags, um Features in bestimmten Komponenten absichtlich zu deaktivieren und zu untersuchen, wie andere Komponenten damit umgehen. Ich möchte auch wärmstens empfehlen, das kostenlose Buch / den kostenlosen Artikel "Lernen von Ersthelfern: Wenn Ihre Systeme funktionieren müssen" zu lesen, in dem ein derart umfassender Test der Software-Infrastruktur beschrieben wird, die das Obama-Team für die Wahl 2012 verwenden soll.

Wie andere bereits gesagt haben, ist es nicht die Aufgabe der Qualitätssicherung, ausschließlich Fehler zu finden. Ich würde noch weiter gehen und sagen, dass es technisch gesehen überhaupt nicht ihre Aufgabe ist. Entwickler sollten dafür verantwortlich sein, ihren eigenen Code fehlerfrei zu halten. Testsuiten sollten ausgeführt werden, bevor überhaupt neuer Code festgeschrieben wird, und wenn die Testsuiten fehlschlagen, sollte es niemals zuerst zur Qualitätssicherung kommen. Das absichtliche Einführen von Fehlern bedeutet, dass Sie Ihre Testsuiten definitiv nicht bestehen können. Warum wird Ihr Code für die Qualitätssicherung verwendet?

Die Aufgabe der Qualitätssicherung besteht darin, die Anwendung anhand der von ihr implementierten User Storys zu validieren. Sie sollten den Ablauf, die Benutzeroberfläche usw. testen und sicherstellen, dass der Benutzer alles tun kann, was er tun kann, und zwar auf möglichst benutzerfreundliche und zugängliche Weise. Dabei können sie natürlich über Fehler stolpern, aber das ist ein Nebeneffekt von dem, was sie tun, und nicht von dem, was sie tun. Denken Sie daran, QS bedeutet Qualitätssicherung, nicht fehlerfreie Sicherung.

Das ist nicht unbedingt so verrückt, wie es sich anhört. Es kommt eher auf deine Motivation an. Wenn Sie nach einem Schläger suchen, mit dem Sie Ihr Testteam schlagen können, wäre das verrückt. Auf der anderen Seite ist es eines der schwierigsten Dinge in der Softwareentwicklung zu wissen, wie effektiv Ihr Testansatz ist.

Wenn Sie es also richtig strukturieren, können Sie mit dieser Technik abschätzen, wie viele nicht entdeckte Fehler in dem Produkt verbleiben, das Sie versenden möchten. Stellen Sie sich vor, Sie haben 100 Bugs in Ihrem Test-Build künstlich ausgesät und die Tester finden 50 davon. Dann können Sie schließen, dass es eine gewisse Wahrscheinlichkeit gibt, dass, wenn sie auch 50 nicht gesäte Bugs gefunden haben, vielleicht noch 50 zu finden sind.

Dies ist natürlich mit vielen Problemen behaftet. Sie könnten anhand dieser Statistiken entscheiden, ob Sie versenden möchten, aber im wirklichen Leben könnten Sie ein sehr schlimmes Problem oder tausend kleinere Irritationen feststellen.

Still - Wissen ist Macht, und ohne diese Technik haben Sie noch weniger Ahnung von der Qualität Ihrer Codebasis. Wenn Sie es respektvoll und aus den richtigen Gründen umsetzen können, würde ich sagen "Warum nicht?"

Eine Sache hat noch niemand erwähnt: Mutationstests .

Hier nimmt ein automatisiertes Tool Ihren Quellcode und fügt absichtlich Fehler ein. (Löschen Sie beispielsweise eine zufällig ausgewählte Anweisung, ändern Sie ein UND in ein ODER oder was auch immer.) Anschließend wird Ihre vollständige Testsuite ausgeführt und geprüft, ob die Tests bestanden wurden.

Wenn alle Tests bestanden sind, gibt es zwei Möglichkeiten:

• Die Sache, die geändert wurde, macht nichts. Mit anderen Worten, Sie haben toten Code.
• Die Änderung führte zu einem Fehler, den Ihre Testsuite nicht abfängt. Du brauchst mehr Tests.

Beachten Sie, dass im Gegensatz zu Ihrem Vorschlag alles, was ich oben beschrieben habe, automatisiert ist . Sie verschwenden nicht die Zeit der Entwickler damit, sinnlose Bugs von Hand einzufügen. Und Sie verschwenden keine Zeit damit, bekannte Fehler zu finden. Das einzige, was Sie verbrauchen, ist Maschinenzeit, die viel billiger ist. (Maschinen langweilen sich nicht, wenn sie den gleichen Test 20.000 Mal durchführen. Die Menschen hören nach einer Weile auf, sich darum zu kümmern!)

Ich würde vorschlagen, dass automatisierte Mutationstests ein weitaus besserer Ansatz sind als das manuelle Szenario, von dem Sie sprechen.

Beachten Sie, dass, wenn Sie einen Entwickler bitten, Fehler manuell einzufügen, die Art des Fehlers, den Sie erhalten, wahrscheinlich nicht für die Art der versehentlichen Fehler repräsentativ ist, die Menschen möglicherweise machen. (Wenn Sie beispielsweise nicht wissen, dass es eine mögliche Rennbedingung gibt, ist es unwahrscheinlich, dass Sie eine absichtliche einfügen.) Ob ein automatisiertes Tool objektiver ist, bleibt natürlich abzuwarten ...

Obwohl es im Allgemeinen eine schlechte Idee ist (die anderen Antworten erklären perfekt, warum), gibt es einige spezielle Situationen, in denen es sinnvoll sein kann, Fehler gezielt und vorübergehend in den Produktionscode einzufügen.

Wenn Sie den Testcode überarbeiten - und dies sollte auch so sein -, sollten Sie wissen, ob der Testcode immer noch die Fehler findet, die er finden soll.

Anschließend können Sie den Produktionscode absichtlich unterbrechen, um zu überprüfen, ob die Tests noch funktionieren.

Es gibt mehrere Ebenen, auf denen dies möglich ist:

• Ein Entwickler, der gerade einen Komponententest überarbeitet hat, kann den Produktionscode brechen, um sicherzustellen, dass der Komponententest immer noch das findet, was er finden soll.
• Ein Tester, der gerade einen Abnahmetest überarbeitet hat, kann den Produktionscode brechen, um zu überprüfen, ob der Abnahmetest noch überprüft, was er überprüfen soll.
• Wenn die Schnittstelle stabil und robust genug ist (dh protokollbasiert), möchte das Unternehmen möglicherweise eine Reihe bekannter fehlerhafter Produktversionen aufbewahren und Tests mit diesen durchführen, um den Test als Regression zu testen.

Ob diese Dinge sinnvoll sind, hängt davon ab. Wenn ich ein Entwickler bin und es nur eine Minute dauert, bis ich einen Fehler eingeschleust habe, testen Sie den Komponententest, entfernen Sie den Fehler - warum dann nicht. Aber ich sollte meinen Editor, meinen Zyklus und mein Versionskontrollsystem so unter Kontrolle haben, dass ich den Fehler nicht versehentlich begehen / ausliefern / einchecken / weiterleiten würde. Gleiches gilt für den Tester und den Abnahmetest.

Ob es für ein Unternehmen sinnvoll ist, eine Reihe bekannter fehlerhafter Produktversionen und einen Regressionstest beizubehalten, hängt vom Test ab. Für einen Online-Shop würde ich nicht. Für Automotive Embedded, Aerospace Embedded, Bankkarten oder Pay-TV-Karten würde ich.

Wie viel Aufwand dies ist, hängt stark davon ab, wie entkoppelt die Tests vom Seriencode sind. Je mehr die Tests vom Produktionscode entkoppelt sind, desto weniger Aufwand ist erforderlich, je kohärenter die Tests mit dem Produktionscode sind, desto größer ist der Aufwand.

Der Grund ist einfach folgender: Wenn Ihre Tests und Ihr Produktionscode kohärent sind, müssen die Tests häufig geändert werden, um den Produktionscode zu ändern. Dies würde die Abhängigkeit zwischen den Tests und den fehlerhaften Produktionsmustern aufheben. Sie müssten dann auch die fehlerhaften Fertigungsmuster pflegen. In seltenen Fällen lohnt sich sogar der Aufwand, und das Verspotten sowie die intelligente Verwendung eines Versionskontrollsystems können den Aufwand erheblich reduzieren, erfordern jedoch weitaus mehr als erfahrene Entwickler.

Das Konzept des absichtlichen Injizierens von Fehlern im Produktionscode heißt Sabotage , der injizierte Fehler heißt Saboteur .

Ein Tester, der den zu testenden Code nicht direkt aus dem Repository entnimmt, macht es falsch. (1)

Ein Entwickler, der bekanntermaßen fehlerhaften Code in das Repository eincheckt, macht es falsch. (2)

In diesem Stadium gibt es also bereits keine Möglichkeit für dieses Programm, ohne dass eine oder beide Seiten grundlegende Voraussetzungen für die Durchführung von Entwicklung und Tests verletzen.

(1) Da Sie dokumentieren müssen, welche Version Sie getestet haben. Eine Version, die mit einem Git-Hash oder einer SVN-Versionsnummer versehen ist, können Sie testen. "Der Code, den Joe mir gegeben hat", ist das nicht.

(2) Weil Sie es einfach nicht tun, abgesehen von einem Testfahrer, der einen Ausfall erwartet .

Dies ist ein Versuch, einen möglichst kurzen "Höhenunterschied" zu finden, der Entwicklern, Testern und dem Management gleichermaßen Sinn machen sollte.

Ich empfehle, in JEDEN Build, den Sie an QA senden, keine Bugs absichtlich einzubauen.

Von Zeit zu Zeit können Sie beispielsweise einmal im Jahr ein verdecktes "QA-Audit" durchführen. Nehmen Sie eine "getestete und funktionierende" Codebasis und so viele kleine neue Funktionen wie möglich aus Ihrer Todo-Liste. Implementieren Sie sie "etwas schlampiger" als gewöhnlich. Denken Sie an die Randfälle, schreiben Sie sie auf, aber korrigieren Sie Ihren Code nicht, um sie zu berücksichtigen. Senden Sie es an QA.

Wenn sie mehr nicht funktionierende Fehler finden, als Sie notiert haben, ist es sicherlich nicht Ihre Qualitätssicherung, die beaufsichtigt werden muss ... ;-)