Ist es eine schlechte Praxis, ein vollständig doppeltes System zur Qualitätssicherung (QS) eines anderen zu erstellen?

Bei der Arbeit haben wir ein ziemlich kompliziertes System. Nennen wir dieses System System_A. Unser QA-Team hat ein anderes System erstellt. Rufen Sie dieses System System_B auf, um System_A zu testen.

System_B wird wie folgt verwendet. Wir generieren Eingaben (unter Verwendung von System_B selbst), IN, verarbeiten solche Eingaben über System_B zurück und generieren Ausgaben, O_B. Der Prozess ist also wie folgt:

System_B(IN) -> O_B.

Wir machen dasselbe für System_A, um seine eigenen Ausgaben zu generieren, O_A:

System_A(IN) -> O_A.

Es wird jederzeit angenommen, dass O_B die erwartete Ausgabe und O_A die beobachtete / tatsächliche Ausgabe ist. Impliziert ist, dass O_B die "Gold" -Quelle ist (die Wahrheit). Wir sind jedoch auf eine Kombination von Problemen gestoßen.

• O_A ist falsch, O_B ist richtig
• O_A ist richtig, O_B ist richtig
• O_A ist falsch, O_B ist falsch
• O_A ist richtig, O_B ist falsch

Wer bestimmt, was richtig ist, wenn angenommen wird, dass O_B immer richtig ist (oder was erwartet wird)? Nun, es stellt sich heraus, dass O_B manchmal (oder oft) falsch mit der menschlichen Inspektion und Analyse ist. Mit diesem Prozess werden die Dinge die Qualitätssicherung bestehen, und echte Benutzer werden sich beschweren, und wir stellen wieder fest, dass O_B doch falsch war.

Die Frage ist: Ist es eine schlechte Praxis, ein "Testsystem" zu erstellen, um das reale System zu testen?

• Was ist mit dem rutschigen Hang? Können wir dann nicht argumentieren, dass wir noch ein anderes System brauchen, um das "Testsystem" zu testen?
• Die Kosten sind definitiv unerschwinglich, da Entwickler jetzt mindestens zwei Codebasen lernen müssen, wobei die Komplexität von System_B möglicherweise größer ist als die von System_A. Wie würden wir quantifizieren, wie gut oder schlecht es für die Organisation ist, System_B zu haben?
• Einer der ursprünglichen "zwingenden" Gründe für die Erstellung von System_B war die "Automatisierung" der Tests. Jetzt sind wir sehr stolz darauf, dass wir vollständig automatisiert sind (da System_B die Eingabe generiert, um den Prozess der Verwendung von sich selbst zur Generierung der Ausgabe zu booten). Aber ich denke, wir haben auf nicht quantifizierbare Weise mehr Schaden angerichtet und mehr Komplexität eingeführt. Soll die Aufgabe der Qualitätssicherung vollständig automatisiert werden? Ist das Grund genug, um die Schaffung eines parallelen Systems zu rechtfertigen?
• Meine eigentliche Sorge ist dies, obwohl wir alle wissen, dass System_B (ziemlich oft) falsch ist. Wenn System_B die Eingabe so gut verarbeitet und die Ausgabe die Goldquelle ist, warum nicht System_A durch System_B ersetzen? Darauf kann niemand bei der Arbeit eine zufriedenstellende Antwort geben.

Jede Anleitung zu diesem Thema wird geschätzt.

• O_A ist falsch, O_B ist richtig

Fix A.

• O_A ist richtig, O_B ist falsch

Fix B.

• O_A ist richtig, O_B ist richtig

Hoffentlich stimmen sie auch zu.

• O_A ist falsch, O_B ist falsch

Hoffentlich stimmen sie nicht überein, sodass Sie wissen, dass Sie etwas dagegen tun müssen.

Kein Prozess fängt alles auf. Sicher, Sie haben Ihren Code verdoppelt, aber denken Sie an die 2 in O (2n). Die automatisierte Qualitätssicherung bis hin zu den Integrationstests ist eine wunderbare Sache. Manuelles Testen ist eine Belastung für die Innovation. Besonders bei Querschnittsänderungen, die einen vollständigen Test erfordern würden. Da verschiedene Programmierer dasselbe implementieren, können Sie sie auch rennen lassen.

Es sollten verschiedene Leute sein, um die Wahrscheinlichkeit zu erhöhen, verschiedene Bugs zu bekommen. Ich rate nicht, System B durch Bewältigung von System A zu erstellen. Alles, was Sie erhalten, ist ein Regressionstest. Sie können das Gleiche erreichen, indem Sie einfach alte Kopien von O_A speichern, um sie mit neuen zu vergleichen.

Die Frage ist: Ist es eine schlechte Praxis, ein "Testsystem" zu erstellen, um das reale System zu testen?

Wenn ja, sind alle Tests schlecht.

• Was ist mit dem rutschigen Hang? Können wir dann nicht argumentieren, dass wir noch ein anderes System brauchen, um das "Testsystem" zu testen?

Ja, das können wir argumentieren. Wir werden dieses 3. System system_A nennen. : P.

• Die Kosten sind definitiv unerschwinglich, da Entwickler jetzt mindestens zwei Codebasen lernen müssen, wobei die Komplexität von System_B möglicherweise größer ist als die von System_A. Wie würden wir quantifizieren, wie gut oder schlecht es für die Organisation ist, System_B zu haben?

Durch die Anzahl der zufriedenen Kunden, die uns dafür bezahlen, mit Nerf-Waffen zu spielen. Sie haben sich von den Kosten für manuelle Tests befreit. Sie haben etwas erstellt, dessen Nützlichkeit jedes Mal bewiesen wird, wenn ein Fehler von ihm entdeckt wird. Früh gefangene Fehler kosten weit weniger als spät gemeldete Fehler.

• Einer der ursprünglichen "zwingenden" Gründe für die Erstellung von System_B war die "Automatisierung" der Tests. Jetzt sind wir sehr stolz darauf, dass wir vollständig automatisiert sind (da System_B die Eingabe generiert, um den Prozess der Verwendung von sich selbst zur Generierung der Ausgabe zu booten). Aber ich denke, wir haben auf nicht quantifizierbare Weise mehr Schaden angerichtet und mehr Komplexität eingeführt. Soll die Aufgabe der Qualitätssicherung vollständig automatisiert werden? Ist das Grund genug, um die Schaffung eines parallelen Systems zu rechtfertigen?

Die Komplexität von System_B ist wunderbar von System_A isoliert. Das Hinzufügen von Funktionen zu System_A ist nicht schwieriger, da System_B vorhanden ist. Es ist tatsächlich einfacher, weil System_B ihnen das Vertrauen gibt, schnell zu gehen.

• Meine eigentliche Sorge ist dies, obwohl wir alle wissen, dass System_B (ziemlich oft) falsch ist. Wenn System_B die Eingabe so gut verarbeitet und die Ausgabe die Goldquelle ist, warum nicht System_A durch System_B ersetzen? Darauf kann niemand bei der Arbeit eine zufriedenstellende Antwort geben.

Ist das ein Tippfehler? System_B ist ziemlich oft falsch, also ist es der Goldstandard, den Sie verwenden möchten, um System_A zu ersetzen?

Ich gehe davon aus, dass Sie gemeint haben, dass System_A oft falsch ist. Es spielt keine Rolle, welches am häufigsten falsch ist. Was falsch ist, braucht Arbeit. Diese Systeme entscheiden nicht richtig und falsch, Entwickler tun es. Was die Tests bewirken, ist eine Meinungsverschiedenheit, die bedeutet, dass etwas nicht stimmt. Entwickler finden heraus, was das ist. Denken Sie daran, dass hier kein Goldstandard hergestellt wird. Es gibt nur Übereinstimmung oder Uneinigkeit. Meinungsverschiedenheiten erfordern, dass Arbeit geleistet werden muss. Ein Teil dieser Arbeit besteht darin, herauszufinden, wo.

Wenn Sie ein System in der Produktion haben, das tatsächlich von Kunden verwendet wird, ist ein QS-System zur Überprüfung von Bugfixes und neuen Funktionen ein absolutes Muss. Unter Qualitätsgesichtspunkten sollte es sich um eine möglichst genaue Nachbildung des Produktionssystems handeln. Auf diese Weise sollte, wenn Sie sicherstellen, dass das Produktionssystem und das QS-System identisch sind, das, was auf dem einen funktioniert, auf dem anderen funktionieren. Ist dies nicht der Fall, sind die Systeme nicht identisch, die Eingänge waren nicht identisch und / oder die Ausgänge wurden falsch interpretiert.

Dies gilt in zweifacher Hinsicht, wenn Ihr System geschäftskritisch ist und rund um die Uhr verfügbar sein muss. Sie können dann nicht den Luxus genießen, kein QS-System zu haben, da Sie die Ausfallzeiten des Produktionssystems unbedingt minimieren müssen. Und wenn es sich um ein 24/7-System handelt, ist die genaue Nachbildung des Produktionssystems eine sehr, sehr starke Empfehlung.

Der offensichtliche Nachteil dieses Ansatzes sind nun die Kosten. Es verdoppelt die Hardwarekosten und erhöht die Bereitstellungs- und Wartungskosten. Außerdem müsste eine kontinuierliche Replikation von Daten aus dem Produktionssystem in die Qualitätssicherung implementiert werden, damit die Möglichkeit unterschiedlicher Ergebnisse aufgrund der unterschiedlichen Daten, mit denen die Systeme arbeiten, minimiert wird.

Ein gewisses Gleichgewicht kann normalerweise gefunden werden, indem einige der Komponenten des QS-Systems relativ zum Produktionssystem verkleinert werden, so dass die meisten Funktionen ordnungsgemäß getestet werden können. Dies sind normalerweise redundante Server, Servergröße oder Anzahl der Workstations. Ich habe jedoch die Erfahrung gemacht, dass ein Fehler immer genau in dem Teil gefunden wird, der verkleinert wurde. Dann ist es ein Albtraum, das Problem zu reproduzieren und das Update zu implementieren, während die minimal zulässigen Ausfallzeiten im Produktionssystem beibehalten werden.

Jedes Mal, wenn Sie ein System testen, müssen Sie wissen, was Ihr erwartetes Ergebnis ist.

Das Problem, wenn ein System dieses erwartete Ergebnis generiert, ist offensichtlich, wie ich dieses System teste.

Trotzdem ist es nicht üblich, dass Menschen Tabellenkalkulationen verwenden, um beispielsweise Sätze erwarteter Ergebnisse zu generieren.

Am Ende des Tages brauchen Sie jedoch wirklich einen Menschen, der die Anforderungen des Systems interpretiert und das erwartete Ergebnis manuell erzeugt. Wenn Sie ein System haben, das dies tut und nur die Unterschiede überprüft, überspringen Sie Ihre Tests.