Fehler bewusst hinzufügen, um QA-Prozesse zu bewerten

Question

Woher wissen Sie, dass so viele Fehler wie möglich in einem Programm entdeckt und gelöst wurden? Vor ein paar Jahren habe ich ein Dokument über Debugging gelesen (ich glaube, es war eine Art Howto). In diesem Dokument wurde unter anderem eine Technik beschrieben, bei der das Programmierer-Team absichtlich Fehler in den Code einfügt und diese an das QA-Team weitergibt. Der QA-Prozess gilt als abgeschlossen, wenn alle absichtlich bekannten Fehler entdeckt wurden.

Leider kann ich dieses Dokument oder ein ähnliches Dokument mit Beschreibung dieses Tricks nicht finden. Kann mich jemand bitte auf ein solches Dokument hinweisen?

EDIT

Um Evgeny glücklich zu machen, lassen Sie mich den letzten Satz des ersten Absatzes paraphrasieren:

„Der QA-Prozess nicht abgeschlossen ist, bevor alle absichtlichen Fehler gefunden werden“

Answer 1

Ein Name für die Technik ist "Fault Injection". Eines der älteren Bücher zu diesem Thema ist 'Software Fault Injection: Inoculating Programs Against Errors' von Jeffrey Voas und Gary McGraw.

Answer 2

Ich habe noch nie ein solches Dokument gesehen, aber ich würde vorsichtig sein zu sagen, dass der QA-Prozess "abgeschlossen" ist, nur weil Ihre absichtlichen Fehler gefunden wurden. Es ist ein guter Weg, um sicherzustellen, dass Ihr QA-Team nicht zu faul wird, aber Sie können nicht wirklich sicherstellen, dass sie genug testen.

Es ist grundsätzlich unmöglich zu wissen, dass alle Bugs (oder "so viele Bugs wie möglich") entdeckt wurden. Alles, was Sie tun können, ist einem gründlichen, gut durchdachten Testansatz zu folgen, um sich selbst eine gute Chance zu geben.

Answer 3

Normalerweise finde ich, dass es viele Bugs für QA zu finden gibt, ohne dass irgendwelche absichtlich injiziert werden müssen! Ich hätte lieber, dass mein QA-Team weiterhin Fehler findet, von denen ich nie gedacht habe, dass sie im System vorhanden sein könnten.

Wie Evgeny würde ich sehr vorsichtig sein, den QA-Prozess als abgeschlossen zu bezeichnen, wenn eine Reihe bekannter Fehler gefunden wurde. Ich bevorzuge Ausgangskriterien wie:

• Sind alle für diese Version definierten Funktionen abgeschlossen?
• Wurden alle geplanten Testfälle ausgeführt?
• Ist die offene Anzahl der Fehler innerhalb der zulässigen Grenzen (zum Beispiel keine kritischen oder hohen Priorität Fehler, weniger als 10 niedriger Priorität Bugs, etc.)