Schnelle Fehlerbehebung: Ein neuer Ansatz für Qualitätssicherung und Tests

Dieser Beitrag basiert auf der Präsentation „Accelerating QA and Testing” von Greg Qualls, Director of Product Marketing, auf der SymfonyCon 2024. Wir haben KI-Tools für die Transkription und zur Verbesserung der Struktur und Verständlichkeit des Inhalts verwendet.

Bevor wir einsteigen, möchte ich erwähnen, dass ich über 18 Jahre Erfahrung im Vertrieb habe. Wenn es manchmal so klingt, als würde ich Ihnen etwas verkaufen wollen, bitte ich Sie um Nachsicht. Das ist wirklich nicht meine Absicht. Ich möchte lediglich Ideen vorstellen, die Ihnen helfen könnten, anders über Tests und Qualitätssicherung zu denken, insbesondere wenn Sie mit Upsun arbeiten oder dies in Erwägung ziehen.

Außerdem möchte ich ganz offen sagen: Ich bin wirklich gut in zwei Dingen: Dinge kaputt machen und Fragen stellen, die manche als „dumme Fragen” bezeichnen würden. Heute werden wir untersuchen, warum beide Fähigkeiten in der Softwareentwicklung tatsächlich wertvoll sind.

Die Kosten des Wartens

Beginnen wir mit einer ernüchternden Statistik: Es ist 30 Mal teurer, einen Fehler zu beheben, nachdem er in die Produktivumgebung gelangt ist, als ihn früher im Entwicklungsprozess zu entdecken.

Das ist keine erfundene Zahl. Der Grund für diese dramatische Kostensteigerung liegt darin, dass Produktionsfehler weit über das Programmieren selbst hinaus Auswirkungen haben. Sie wirken sich auf Ihre Kunden aus, schaden dem Ruf Ihrer Marke, untergraben das Vertrauen der Nutzer und zwingen Ihr Team, wertvolle Zeit mit der Fehlerbehebung zu verbringen, anstatt neue Features zu entwickeln.

Deshalb sind Tests so wichtig. Aber jetzt wird es interessant.

Die Philosophie, Dinge schnell zu zerstören

Im Jahr 2012 teilte Mark Zuckerberg einen Kernwert seiner „Hacker Way”-Philosophie: „Bewege dich schnell und zerstöre Dinge. Wenn du nichts zerstörst, bewegst du dich nicht schnell genug.”

Ich möchte dies für unseren Kontext adaptieren: Bewegen Sie sich schnell und zerstören Sie Dinge. Wenn Sie nichts zerstören, testen Sie nicht wirklich und bewegen sich nicht schnell.

Das Ziel des Testens sollte sein, Dinge so schnell wie möglich zu zerstören, um festzustellen, ob etwas funktioniert, damit wir es entweder reparieren oder mit der Entwicklung der nächsten Funktion fortfahren können. Das ist es, was wir wirklich gerne tun: Features erstellen, Funktionalitäten entwickeln, wichtigen Code programmieren.

Zwei grundlegende Fragen

Wenn man darüber nachdenkt, lassen sich alle Tests auf zwei grundlegende Fragen reduzieren:

1. Ist es kaputt?

Dies umfasst Ihre Unit-Tests, Funktionstests, Systemtests und explorativen Tests. Sie fragen sich: Funktioniert das so, wie es soll?

2. Wann wird es kaputtgehen?

Dies umfasst Lasttests, Penetrationstests, Skalierbarkeitstests und Spike-Tests. Sie fragen sich: Was sind die Grenzen dieses Systems?

In beiden Fällen versuchen Sie, diese Fragen so schnell wie möglich zu beantworten.

Das Problem mit traditionellen Workflows

Die meisten Entwicklungs-Workflows folgen einem bekannten Muster: lokale Entwicklung → Entwicklungsumgebung → Staging → Produktion. Sie testen in jeder Phase, iterieren, beheben Probleme und sehen schließlich die grünen Häkchen, die bedeuten, dass Sie bereit für die Bereitstellung sind.

Dieser Prozess kann jedoch sehr langsam sein.

Meine Erfahrungen mit Tests

Lassen Sie mich eine persönliche Geschichte erzählen. In den Jahren 2002–2003 war ich „Webmaster” an der Eastern New Mexico University. Alles war reines HTML – kein JavaScript, kein CSS (CSS kam später, und ich hielt es für revolutionär).

Mein Testprozess war wunderbar einfach: Ich programmierte den Code, übertrug ihn per FTP auf den Server, besuchte die Seite auf enmu.edu und schaute, ob alles funktionierte. Wenn nicht, behob ich den Fehler und lud den Code erneut hoch. Heute würden wir das als „Testen in der Produktivumgebung” bezeichnen, aber damals gab es keinen Unterschied – alles war Produktion. Es gab keine Entwicklungsumgebungen, keine Staging-Umgebungen. Nur meinen Computer und den Live-Server.

Die versteckten Vorteile des Testens in der Produktivumgebung

Bevor Sie jetzt in Panik geraten, hören Sie mir bitte zu. Was wäre, wenn Sie in der Produktivumgebung testen könnten? Denken Sie an die Vorteile:

• Sofortiges Feedback – Sie wissen sofort, ob etwas funktioniert
• Reale Daten – Sie verwenden echte Server, Datenbanken und Dienste
• Keine Datenbereinigung erforderlich – Alles ist bereits dort, wo es sein sollte
• Schnelle Erkennung – Umgebungsbezogene Probleme werden sofort sichtbar
• Ordnungsgemäße Performance-Tests – Sie testen unter realen Bedingungen

Das einzige große Problem

Natürlich gibt es ein großes Problem beim Testen in der Produktivumgebung: die Benutzer.

Diese lästigen Benutzer, die sich beschweren, wenn die Website ausfällt. Dann erfährt es Ihr Chef. Dann müssen Sie in einer Performance-Beurteilung erklären, was passiert ist. Und ehe Sie sich versehen, posten Sie auf LinkedIn „Auf der Suche nach einer neuen Stelle“.

Daher können wir nicht einfach in der Produktivumgebung testen. Oder doch?

Die Lösung: Replikation der Produktion

Die Antwort lautet, die Produktion so genau zu replizieren, dass das Testen dort im Wesentlichen dasselbe ist wie das Testen in der Produktivumgebung, nur ohne die Benutzer.

Die korrekte Replikation der Produktion ist jedoch ein unglaublich komplexer Prozess. Sie müssen:

• Nicht nur das Programmieren, sondern auch die Datenebenen und Dienste klonen
• Netzwerkkomponenten wie DNS und SSL-Zertifikate verwalten
• Infrastruktur als Code und Git-basierte Workflows verwenden
• Zugriffskontrolle und Berechtigungen verwalten
• sicherstellen, dass alles perfekt synchronisiert ist

Viele Unternehmen haben damit zu kämpfen. Ich habe einmal mit einer großen Universität gesprochen, die drei Wochen brauchte, um eine Entwicklungsumgebung aufzubauen. Drei Wochen! Bis sie alles konfiguriert und die Daten synchronisiert hatten, hatte sich die Produktion bereits erheblich verändert.

Full-Stack-Vorschauumgebungen

Hier wird der Ansatz von Upsun interessant. Die Plattform bietet Full-Stack-geklonte Umgebungen – vollständige Repliken der Produktivumgebung, die Sie sofort einrichten können.

Wenn Sie in Upsun einen Branch erstellen, verzweigen Sie nicht nur das Programmieren. Hinter den Kulissen repliziert die Plattform:

• Die gesamte Codebasis
• Alle Datenbanken und Daten
• Services und Konfigurationen
• Netzwerkeinstellungen
• Infrastruktur-Setup

Alles außer den Benutzern. 

Schnelle Fehlerbehebung in der Praxis

Vor kurzem gab es auf der SymfonyCon eine Live-Demo, bei der zwei Entwickler versuchten, eine monolithische Symfony-Anwendung in ein Next.js-Frontend mit einem Symfony-Backend zu entkoppeln. Es war eine 30-minütige Demonstration, bei der es richtig zur Sache ging – eine Live-Demo, bei der die Dinge zunächst nicht ganz funktionierten.

Sie führten die Bereitstellung durch. Es funktionierte nicht. Sie änderten etwas und führten die Bereitstellung erneut durch. Es funktionierte immer noch nicht. Sie wiederholten den Vorgang schnell, testeten und brachen Dinge so schnell wie möglich. Schließlich fanden sie das Problem: In der Konfigurationsdatei hatten sie „npm” statt „npx” geschrieben – ein Zeichen Unterschied.

Das Bemerkenswerte daran: Dank ihrer Fähigkeit, schnell zu iterieren, gelang ihnen innerhalb von 30 Minuten der Übergang von einer monolithischen Anwendung zu einer vollständig entkoppelten Architektur. Sie wussten, dass es in der Produktivumgebung funktionieren würde, wenn es in ihrer Entwicklungsumgebung funktionierte, da die Umgebungen identisch waren.

Die Herausforderung der Zusammenarbeit

Natürlich ist Entwicklung selten eine Einzelleistung. Sie haben Kollegen, andere Entwickler, die, seien wir ehrlich, nie ganz so gut sind wie Sie.

In traditionellen Arbeitsabläufen sind Merge-Konflikte unvermeidlich, wenn mehrere Entwickler auf dieselbe Entwicklungsumgebung zugreifen. Jemand hat etwas geändert, und jetzt funktioniert Ihr Programm nicht mehr. Es kommt zu folgendem Gespräch: „Greg, was machst du da? Ich arbeite daran! Du musst zuerst diesen Dienst installieren!“

Mehrere isolierte Umgebungen

Die bessere Lösung besteht darin, jedem Entwickler eine eigene produktionsähnliche Umgebung zur Verfügung zu stellen. Sie programmieren an Ihrem Code, sie programmieren an ihrem, völlig isoliert voneinander.

Wenn Sie fertig sind, übertragen Sie Ihre Änderungen in die Produktivumgebung. Dann ruft Ihr Kollege Ihre Änderungen ab – nicht nur den Code, sondern alle Daten, Datenbankaktualisierungen, Dienstkonfigurationen und Caching. Alles wird automatisch synchronisiert. Sie testen ihren Code anhand dieses neuen Zustands, und der Zyklus geht weiter.

Jeder arbeitet separat, aber kooperativ, und alles läuft reibungslos, da Sie alle in der Produktivumgebung entwickeln.

Die Vorteile in der Praxis

Wenn Sie Probleme schneller beheben können – insbesondere mit Plattformen wie Upsun – profitieren Sie von folgenden Vorteilen:

• Schnellere Testzyklen – Sie können ambitionierte Änderungen, wie die Entkopplung einer gesamten Anwendung, in weniger als einer Stunde versuchen.
• Schnellere Entwicklungszyklen – Wenn die Geschäftsleitung etwas „so schnell wie möglich“ verlangt, können Sie schnell iterieren und neue Sprachen, Frameworks, Dienste oder Machine-Learning-Bibliotheken ausprobieren, um zu sehen, was funktioniert.
• Höhere Codequalität – Sie testen und iterieren so lange, bis Sie sicher sind, dass es funktioniert, denn Sie wissen: Wenn es hier funktioniert, funktioniert es auch in der Produktivumgebung.
• Geringeres Risiko – Sie erkennen Probleme, bevor die Benutzer sie bemerken, und vermeiden so unangenehme Bewertungen der Performance aufgrund von Website-Ausfällen und Umsatzverlusten.

Und hier ist etwas für die geschäftliche Seite: Es hat sich gezeigt, dass ordnungsgemäße Test- und QA-Umgebungen zu einer 40-prozentigen Steigerung der Kundenzufriedenheit führen. Wenn Sie Ihren Tests vertrauen, liefern Sie besseren Code, was zu zufriedeneren Kunden führt.

Drei praktische Erkenntnisse

Unabhängig davon, ob Sie Upsun verwenden oder nicht, hier sind drei Grundsätze, um Probleme schneller zu beheben:

1. Ändern Sie Ihre Denkweise

Zu viele Entwickler glauben, dass sie beim ersten Versuch alles perfekt machen müssen. Betrachten Sie Fehler stattdessen als Lernprozess. Probieren Sie es aus. Sehen Sie, ob es funktioniert. Versuchen Sie es erneut. Sie lernen mehr aus Fehlern als aus sofortigen Erfolgen.

Aus der Live-Demo von vorhin werde ich nie vergessen: Wenn Sie Ihre Next.js-App mit npx erstellen, stellen Sie sicher, dass Sie den Befehl auch mit npx und nicht mit npm ausführen. Das habe ich gelernt, indem ich jemand anderem beim Scheitern zugesehen habe – und diese Lektion ist mir im Gedächtnis geblieben.

2. Nutzen Sie Testumgebungen

Bitte gehen Sie nicht mit dem Gedanken „Greg hat gesagt, wir sollten einfach in der Produktivumgebung testen!“ aus diesem Raum. Wenn Sie das Ihrer Führungsetage erzählen, werden sie fragen: „Wer ist Greg?“ und Sie werden Ärger bekommen.

Sie brauchen Testumgebungen. Diese müssen jedoch so nah wie möglich in der Produktivumgebung sein. Denken Sie alle Variablen durch: Infrastruktur, Daten, Dienste, Netzwerk und Zugriffskontrolle. Decken Sie so viele wie möglich ab.

3. Automatisieren Sie alles

Es geht nicht nur darum, Dinge zu zerstören, sondern darum, Dinge schnell zu zerstören. Automatisieren Sie die Erstellung Ihrer Umgebung. Richten Sie CI/CD-Pipelines ein. Sorgen Sie dafür, dass Testumgebungen sofort hochgefahren werden und Bereitstellungen automatisch erfolgen, wenn die Tests bestanden sind.

Je schneller Sie Fehler finden und beheben können, desto eher können Sie sich wieder der Entwicklung neuer Features und der Weiterentwicklung Ihres Produkts widmen.

Abschließende Gedanken

Testen muss keine lästige Pflicht sein. Mit den richtigen Tools und der richtigen Einstellung wird es Teil des kreativen Prozesses, eine Möglichkeit, Möglichkeiten zu erkunden, Grenzen zu verschieben und schnell zu lernen.

Das Ziel ist nicht, Fehler zu vermeiden. Das Ziel ist, sie so schnell wie möglich in einer sicheren Umgebung zu machen, aus diesen Fehlern zu lernen und Programme zu liefern, denen Sie vertrauen können.

Also los: Brechen Sie Dinge. Brechen Sie sie nur schnell, brechen Sie sie sicher und lernen Sie aus jedem Bruch etwas.

Haben Sie Fragen zu Upsun oder zur Umsetzung dieser Praktiken? Besuchen Sie die Upsun-Website oder testen Sie unsere kostenlose Testversion, um Full-Stack-Vorschauumgebungen in Aktion zu sehen.