Scientist, eine neue Methode zur Software-Qualitätssicherung

Dieser Artikel beschreibt eine Situation, in der wir uns beim Refactoring einer bestehenden, in Produktion befindlichen Anwendung befanden, die Implementierung einer neuartigen QA-Methode mit dem Namen "Scientist" sowie die Vor- und Nachteile dieses neuen Ansatzes. Ein zukünftiger Blogbeitrag wird die Architektur einer serverlosen Implementierung für diese neue QA-Methode im Detail beschreiben.

Einführung

Eine der schönen Seiten der Arbeit bei Xebia ist unser regelmäßiger Innovationstag alle zwei bis drei Monate. Alle Berater kommen in unserem Büro in Hilversum zusammen, um mit neuen Technologien zu experimentieren, Prototypen zu bauen, neue Produkte zu entwickeln oder ein Brainstorming über neue Beratungs- oder Schulungsdienstleistungen durchzuführen.

An einem dieser Tage vor zwei Jahren haben Gero Vermaas und ich eine Slack-Anwendung für die Verwendung innerhalb von Xebia entwickelt. Nach einer Weile stellte sich heraus, dass es ein recht nützliches Tool für Berater und Mitarbeiter war. Aber ein Jahr später waren wir mit einigen der Implementierungsentscheidungen, die wir früher getroffen hatten, nicht mehr ganz zufrieden - eine übliche Einschätzung von Dingen, die vor mehr als einem Jahr entwickelt wurden. Wir wollten den Code verbessern und refaktorisieren, während wir die Sache natürlich auch in der Produktion laufen lassen wollten.

Als wir darüber nachdachten, wie wir unser geplantes Refactoring testen könnten, kamen wir zu dem Schluss, dass herkömmliche QA-Methoden nicht wirklich anwendbar oder hilfreich waren, um sicher zu sein, dass die Verbesserungen wirklich besser waren als die ursprüngliche Implementierung. Glücklicherweise wurden wir von einem Konzept und einer Lösung von GitHub inspiriert, die wir mit unserer Anwendung ausprobieren wollten. Dies führte zur Einführung einer neuartigen Software-QS-Methode mit dem Namen "Scientist", die wir erfolgreich auf unseren Fall angewendet haben.

Unsere serverlose Anwendung

Unsere Slack-App heißt /whereis #everybody und verfolgt die von Benutzern übermittelten Standorte. Wenn Sie die App von Slack aus verwenden, registriert sie, wo Sie sich befinden, und Sie können frühere und aktuelle Standorte Ihrer Teammitglieder abfragen. Ein "Standort" ist in unserem Fall als Beratungsunternehmen oft ein Kunde, aber es kann auch eine Stadt, eine Abteilung oder ein Gebäude sein - alles, was Sie als "Standort" betrachten. Die App hat sich als sehr praktisch erwiesen, um den Aufenthaltsort einer Gruppe von Beratern zu verfolgen, die auf viele Kunden verteilt sind, und sie wird nun schon seit über zwei Jahren recht häufig verwendet.

/whereis #everybody ist eine vollständig serverlose Anwendung und wird derzeit bei AWS bereitgestellt. Sie verwendet das API Gateway, etwa 20 Lambda-Funktionen, einen DynamoDB-Datenspeicher und einige kleinere Dinge, wie hier beschrieben.

Aber wie wir schon sagten, waren wir mit unserer ursprünglichen Wahl der Sprache für unsere Lambda-Funktionen, nämlich JavaScript, nicht sehr zufrieden. Wir stellten fest, dass das Refactoring des Codes mühsam war, und wir hatten auch Vorbehalte, der Codebasis neue Funktionen hinzuzufügen. Der Code drängte uns zurück, weil wir vielleicht Änderungen befürchteten.

Wir dachten also daran, unsere Backend-Lambda-Funktionen in Python neu zu implementieren, aber...

• die App lief bereits in der Produktion;
• wir hatten keine umfangreiche Test-Suite - oder ehrlicher gesagt: keine Test-Suite;
• wir wussten nicht genau, wie die App genutzt wurde, denn die Benutzer sind immer kreativer als die Entwickler.

Also haben wir uns überlegt, ob wir unsere Funktionalität überarbeiten und neu implementieren sollten,

• Wie können wir sicher sein, dass der "verbesserte" Code tatsächlich besser ist als die aktuelle Implementierung?
• Welche QA-Methode eignet sich am besten für Codeänderungen an Software, die bereits in Produktion ist?

Welche QA-Methode eignet sich am besten für das Testen refaktorisierter Funktionen in der Produktion?

Kurz gesagt, wir hatten eine Reihe von Anforderungen an die Qualitätssicherung der überarbeiteten Software:

• wir wollen eine verbesserte Implementierung von etwas testen, das bereits in der Produktion läuft;
• wir wollen nicht alle Unit- oder Integrationstestfälle angeben;
• wir wollen uns nicht die Mühe machen, den Produktionsverkehr aufzuzeichnen und an eine neue Implementierung zu senden;
• wir wollen eine neue Implementierung nicht in der Produktion aktivieren, bevor wir nicht wirklich sicher sind, dass sie besser ist;
• wir wollen unsere Software in der Produktion nicht ändern, um Tests zu ermöglichen.

Uns ist auch aufgefallen, dass es bei den Methoden der Software-Qualitätssicherung eine große Spaltung gibt, insbesondere bei der Frage "Womit vergleichen Sie die Software?" Vergleichen Sie die Software mit einer Spezifikation oder den Erwartungen der Benutzer, z.B. bei Unit-Tests, Integrationstests, Leistungstests oder Benutzerakzeptanztests? Alle diese Methoden werden in der Regel durchgeführt, bevor neue oder geänderte Software in die Produktion gelangt. Oder vergleichen Sie eine neue Softwareversion mit einer früheren oder alternativen Version, z.B. bei Feature Flags, Blue/Green Deployments, Canary Releases, A/B-Tests.

Vergleich von Software QA Methoden

Wir haben also eine Reihe von Software-QS-Methoden in Bezug auf eine Reihe von Aspekten verglichen:

• Womit testen Sie Ihre Software?
• in welcher Phase des Lebenszyklus der Softwareentwicklung tritt sie normalerweise auf?
• woher bekommen Sie die Testdaten?

QA-Methode	Test gegen	Phase / Stufe	Wie Sie Testdaten erhalten
Unit-Tests	Testspezifikation	Dev	Handbuch / Testsuite
Integrationstests	Testspezifikation	Dev	Handbuch / Testsuite
Leistungstests	Test/Benutzerspezifikation	Tst	Produktionsverkehr/ Simulation abwerfen
Abnahmetest	Benutzerdefiniert	Acc	Handbuch
Merkmal Flaggen	Erwartungen der Benutzer	Prd	Segment des Produktionsverkehrs
A/B-Prüfung	Alternativen im Vergleich	Prd	Segment des Produktionsverkehrs
Blaue/grüne Einsätze	Erwartungen der Benutzer	Prd	Gesamter Produktionsverkehr
Kanarische Veröffentlichungen	Erwartungen der Benutzer	Prd	Frühes Segment des Produktionsverkehrs

In unserem Fall (und zugegebenermaßen haben wir nie in eine Testsuite investiert) wollten wir unsere Software in der Produktion testen... aber es gibt einen wichtigen Nachteil bei den QA-Methoden, die normalerweise in der Produktion eingesetzt werden: Feature-Flags, A/B-Tests, Blue/Green Deployments und Canary Releases:

• Um Feature Flags oder A/B-Tests zu unterstützen, müssen Sie Ihren Produktionscode anpassen, damit diese Methoden funktionieren. Wie minimal und lokalisiert die Logik für Feature Flags oder A/B-Tests auch sein mag, sie befindet sich in der Regel irgendwo in Ihrer Software, und dieser Code existiert in der Produktion, bis Sie ihn wieder entfernen.
• Bei Canary-Versionen und blauen/grünen Deployments senden Sie einen Teil Ihres Produktionsverkehrs an die neue Software und können die gleichen Anfragen, die von Minern ohne Canary oder in der anderen Deployment-Farbe verarbeitet werden, nicht vergleichen. Der Produktionsverkehr landet entweder in einer der beiden Versionen, und ein Segment der Produktionsanfragen wird ausschließlich von einer Version bearbeitet.

GitHub hatte ein ähnliches Problem

Glücklicherweise stand GitHub schon viel früher als wir vor einer ähnlichen Herausforderung. Sie beschreiben ihren Ansatz und ihre Lösung in zwei sehr interessanten Artikeln.

GitHub wollte einen kritischen und komplexen Teil seiner Software zur Durchführung von Zusammenführungen ersetzen. Der neue Code versprach schnellere Zusammenführungen, eine einfachere Checkout-Logik und einiges mehr. Sie argumentierten jedoch, dass ihre normale Qualitätssicherung (Code-Review, interne Tests) nicht genug Vertrauen für die "Produktionsreife" bot, da viele Eckfälle in der Produktion von der normalen Qualitätssicherung nicht abgedeckt wurden.

Die Lösung von GitHub bestand darin, den gesamten Produktionsverkehr sowohl an den ursprünglichen als auch an den neuen Code zu leiten, die Ergebnisse zu vergleichen und nur die Antwort des ursprünglichen Codes zurückzusenden. (Auf diese Weise wussten die ursprünglichen Anfrager nicht, dass die Funktionalität von zwei Methoden parallel ausgeführt wurde und dass die Ergebnisse verglichen wurden. Sie konnten nicht wissen, dass eine neue Implementierung einer QA unterzogen wurde). Sobald GitHub davon überzeugt war, dass der neue Code nach ihrer Einschätzung tatsächlich "besser" war als der ursprüngliche Code, wurde die alternative Implementierung in der Produktion aktiviert.

Vorschlag: neue Software-QS-Methode, "Scientist"

Im Nachhinein betrachtet war das, was GitHub tat, der Vorschlag einer neuen Software-QS-Methode, die auf dem wissenschaftlichen Ansatz basiert, empirische Erkenntnisse durch Experimente zu gewinnen. Diese QS-Methode, die wir als "Scientist" bezeichnen, funktioniert folgendermaßen:

• Sie haben eine bestehende Softwarekomponente, die in der Produktion läuft, als Kontrolle;
• haben Sie als Kandidat eine andere, hoffentlich bessere, Implementierung.

Dann führen Sie Experimente durch, indem Sie den Produktionsverkehr sowohl an die Kontrolle als auch an den Kandidaten senden und die Ergebnisse vergleichen, um zu dem Schluss zu kommen

• ob sich der Kandidat korrekt verhält;
• ob der Kandidat besser abschneidet als die Kontrolle, wobei "besser" eine geringere Latenzzeit, bessere Stabilität, geringere Speichernutzung oder eine andere Leistungskennzahl bedeutet.

Es lohnt sich, darauf hinzuweisen, dass diese "wissenschaftliche" QS-Methode die gleichen Schritte durchläuft wie der wissenschaftliche Ansatz der Wissensgewinnung:

• eine Hypothese aufzustellen;
• eine Vorhersage zu treffen, z.B. "bei Verwendung des Produktionsverkehrs wird der Kandidat besser sein als unsere Kontrolle";
• ein Experiment vorbereiten;
• Durchführung des Experiments und Vergleich der Ergebnisse zwischen der Kontrolle und den Kandidaten unter Verwendung des Produktionsverkehrs;
• die Hypothese zu akzeptieren oder zu verwerfen und eine Schlussfolgerung über die Qualität der Software zu ziehen.

Vorteile des wissenschaftlichen Ansatzes

Der Ansatz des Wissenschaftlers hat einige Vorteile:

• es ist eine Drop-in QA ohne Änderung des Produktionscodes, um alternative Implementierungen testen zu können;
• Sie brauchen keinen Testverkehr zu erzeugen oder historische Daten aus der Produktion zu anonymisieren;
• Es gibt keine separate Test-Suite und Sie müssen die erwarteten Ergebnisse nicht im Voraus festlegen - der vorhandene Code in der Produktion dient als Referenz;
• es gibt die Möglichkeit, Kandidaten iterativ in Richtung "gut genug" oder "noch besser als die Kontrolle" zu verbessern, ohne dass die Benutzer dies jemals bemerken;
• Sie haben die Möglichkeit, den Datenverkehr zu den Kandidatenimplementierungen langsam zu erhöhen (und zu verringern), um ein größeres Segment des Produktionsverkehrs für Ihre neue Implementierung zu erschließen;
• es gibt eine sehr schnelle (d.h. sofortige) Rückkopplungsschleife mit sehr begrenzten Risiken;
• ein Projekt ist in der Lage, Eckfälle abzufangen, die nur in der Produktion vorkommen und von denen Sie nichts wissen.

Nachteile des wissenschaftlichen Ansatzes

Natürlich gibt es auch einige Überlegungen zum Scientist-Ansatz, die Sie beachten sollten, bevor Sie ihn anwenden:

• es könnte eine zusätzliche Latenzzeit beim Senden der Antwort auf die Kontrollen an den ursprünglichen Anfrager entstehen. Die Antwortzeit könnte durch den asynchronen Aufruf von Kandidatenfunktionen verkürzt werden, aber die Verwendung der Mechanik eines Experiments führt wahrscheinlich zu einem etwas höheren Anfrageumlauf;
• insgesamt gibt es mehr Funktionsaufrufe und damit eine höhere Ressourcenauslastung, solange das Experiment mit einem oder mehreren Kandidaten läuft. Dies könnte zu einer höheren Rechnung für das Hosting der Recheninfrastruktur führen;
• Der Abgleich von anhaltenden Änderungen durch die Kontrolle mit den Kandidaten, die die ursprünglichen Anfragen an die Kontrolle verpasst haben könnten, kann eine Herausforderung für sich sein - es muss sichergestellt werden, dass die Kandidaten auch auf korrekte Daten achten.

Wann ist ein Wissenschaftler weniger geeignet für die QS?

Schließlich gibt es eine Reihe von Fällen, in denen der Ansatz des Wissenschaftlers für die Software-QS weniger geeignet ist:

• wenn sich die Schnittstelle eines Dienstes ändert - die ursprüngliche Anfrage kann nicht ohne zusätzliche Änderungen an den Kandidaten gesendet werden;
• wenn kein Live-Produktionsverkehr in Echtzeit verfügbar ist;
• wenn der Produktionsverkehr nicht den Umfang der in Control und Candidates implementierten Funktionen abdeckt, wenn also einige Codeteile im Produktionsverkehr erheblich vernachlässigt werden;
• wenn eine Kontrolle (noch) nicht verfügbar ist, wenn Sie eine erste Implementierung entwickeln. Die Scientist-Methode erfordert eine Kontrolle, mit der Sie einen Kandidaten vergleichen können.

Sind Sie neugierig auf diese wissenschaftliche QA-Methode? Untersuchen Sie die Anwendung dieser Methode in Ihrem Projekt? Oder haben Sie bereits solche Experimente in der Produktion laufen und Sie haben bereits Erfahrungen damit gesammelt?

In jedem Fall können Sie sich gerne an uns wenden. Wir würden uns freuen, von Ihnen zu hören.