Sie haben die Geschichte schon gehört, oder?

Kohleabbau war eine gefährliche Arbeit. Jederzeit konnten sich Kohlebergwerke mit tödlichen, aber nicht wahrnehmbaren Gasen füllen. Also haben sich Bergleute einen ganz einfachen Trick ausgedacht, um am Leben zu bleiben: Sie nahmen einen Kanarienvogel mit nach unten. Die Kanarienvögel reagierten auf diese tödlichen Gase empfindlicher als Bergleute. Wären giftige Gase in die Mine eingedrungen, wären die Kanarienvögel als Erste gestorben. Die Bergleute wären somit gewarnt gewesen und hätten den Stollen verlassen, bevor ihnen dasselbe Schicksal widerfahren wäre.

Softwareentwickler nahmen sich diese Geschichte zu Herzen und entwickelten ihre eigene Methode, Gefahren in ihrer Arbeit aufzudecken, bevor es für ihre Applikation zu spät ist. So entwickelten sie „Canary Releases“ – eine bewährte Methode im Rahmen des Feature Releasemanagements, bei der eine neue Funktion einer kleinen User-Gruppe bereitgestellt wird, um sie in einer Live-Umgebung zu testen. Sollte etwas bei dem neuen Feature vollkommen falsch laufen, würden die Entwickler vom Canary Release gewarnt werden, bevor das Feature für die breite User Base freigeschaltet wird und dann wirklichen Schaden anrichten würde.

Softwareentwickler sollten nicht ihr eigenes Leben, sondern das Überleben der Software schützen, die sie entwickelten. Sie waren in der Lage, Probleme zu suchen und zu beheben, in der Realität genutzte Daten zu sammeln, die im Hinblick auf eine bessere Software umgesetzt werden, und allgemein das Risiko besonders kritischer Momente im Lebenszyklus der Softwareentwicklung und des Release zu minimieren.

Für Produktmanager sind Canary Releases mittlerweile zu einem „Must-do“ geworden. Selbst ein einziger Bug oder ein falsch ausgerichtetes Feature kann Monate harter Arbeit vernichten, wenn nicht sofort gegengesteuert wird, solange die Probleme noch gering sind und unter Kontrolle gehalten werden können.

Das sind die schlechten Nachrichten. Die gute Nachricht aber ist: Sie können diesem potenziellen Krisenszenario mit einem Canary Release vorbeugen, das sogar schnell, einfach und intelligent durchgeführt werden kann, wenn Sie sich die folgenden drei wichtigen Fragen stellen.

Frage 1: Welche User kommen für Ihr Canary Release in Frage?

Eine entscheidende Frage. Leider gibt es aber nicht die eine „richtige“ Antwort. Welche User-Gruppe Sie wählen, hängt konkret von der Art Ihres Canary Release ab und davon, was Sie sich von dem Release erhoffen.

Generell gibt es hier zwei Denkmodelle:

1. Release für eine „warme“ Zielgruppe.
2. Release für eine „kalte“ Zielgruppe.

Nach dem ersten „warmen“ Denkmodell müssten Sie Ihr Canary Release Erstanwendern bereitstellen, die Ihnen dann eine Frühwarnung geben. Prinzipiell kennen Sie diese User und wissen, dass sie Ihnen gegenüber positiv eingestellt sind und das Produkt schätzen, ja ständig verwenden. Nachdem Sie die User ausgewählt haben, informieren Sie sie im Voraus darüber, dass sie einige neue Features erhalten, die noch nicht perfekt sind, sodass sie mit kleinen Problemen rechnen müssen.

Der Vorteil hier ist simpel – Sie erhalten Feedback und Daten von Usern, die mit Ihren neuen Features in einer realen Umwelt herumexperimentieren. Allerdings scheuen Sie dabei möglichst jedes Risiko.

Der Nachteil ist etwas subtiler. Da Sie Ihr Feature für eine „warme“ Zielgruppe freigeben, können Sie sich nicht sicher sein, ein zu 100 % ehrliches Feedback zu erhalten. Und da diese Gruppe oft aus Erstanwendern und Power Usern besteht, ist es auch nicht sicher, dass sie genauso wie normale Durchschnittsnutzer mit den neuen Features herumspielen und technische Probleme umgehen.

Nach dem zweiten, dem „kalten“ Denkmodell sollten Sie User nach dem Zufallsprinzip auswählen, die Sie im Voraus benachrichtigen oder nicht, dass sie einige neue, potenziell fehlerhafte Features testen werden.

Bei dieser User-Gruppe bestehen deutlich größere Risiken, wenn neue Features getestet werden. Allerdings erhalten Sie auch Daten, die vertrauenswürdiger, realistischer und nutzbarer nicht sein könnten. Sie werden sehen, wie eine Vielzahl von Usern Ihr Feature nutzt. Sie werden deutlich größeres, glaubwürdiges Feedback generieren (vor allem, wenn etwas nicht richtig funktioniert) und insgesamt werden Sie eine deutlich klarere Vorstellung davon erhalten, was tatsächlich passiert, wenn Sie heute Ihr neues Feature freischalten würden.

Welche User-Gruppe sollten Sie also wählen?

In der Praxis werden Sie vermutlich eine User Base wählen, die zwischen diesen beiden Extremen liegt. Sie werden wahrscheinlich eine etwas erweiterte Segmentierung und Personalisierung vornehmen, mit denen Ihre neuen Features für eine Zielgruppe freigegeben werden, die für diese getesteten Features besonders relevant und geeignet ist, aber auch hinreichend untergliedert ist, damit Sie nicht Gefahr laufen, unter dem Strich Ihrem Produkt dauerhaft zu schaden, sollte das Release schlecht sein.

Genau genommen können Sie sich mit dem richtigen Ansatz an beide Gruppen wenden – Tests mit mehreren Zielgruppen durchführen, die Ihnen jeweils verschiedene Formen von wertvollem Feedback und Daten bieten. Sie können sogar mehrere Tests mit mehreren Zielgruppen für mehrere Features deutlich einfacher als zuvor durchführen.

Hier die Gründe, weshalb.

Frage 2: Welche Features werden Sie in Ihrem Canary Release testen?

Diese Frage müsste sich einfach beantworten lassen. Sie konnten ein Canary Release eigentlich nur für eine relativ begrenzte Anzahl von Feature-Tests bereitstellen. Aber in den letzten Jahren sind Ihre Möglichkeiten regelrecht explodiert. Hier, was sich geändert hat.

In der Vergangenheit waren für den Launch von Canary Releases relativ viele Ressourcen notwendig. Sie konnten Ihre Codebasis gefährden und Sie viel Zeit, Aufmerksamkeit und Mühe kosten. Und sie konnten den Entwicklungsprozess insgesamt drastisch verlangsamen. Immer wenn Sie ein Canary Release durchführen wollten, mussten Sie sicherstellen, dass sich dieser Aufwand auch 100 % lohnt – und das schränkte die Art von Funktionen, die Sie testen konnten, stark ein.

Größtenteils lohnten sich Canary Releases nur für besonders sichtbare High-Touch-Funktionen, die für die Applikation grundlegend waren, d. h. Dinge wie die umfassende Überarbeitung einer ganzen Funktionsreihe oder funktionaler Eckpunkte Ihrer Anwendung. Im Großen und Ganzen lohnte es sich nicht, Ressourcen im Rahmen eines Canary Release für den Test einer einzigen, kleinen, isolierten Funktion einzusetzen.

Dadurch waren Ihre Möglichkeiten begrenzt und Sie konnten nicht schnell, agil und reaktiv vorgehen. Sie mussten abwarten, bis genügend Funktionen bereitgestellt wurden, bevor Sie auch nur eine von ihnen testen konnten. Sie konnten nach einem Feedback oder nach dem Erhalt von Daten aus Ihrem Release nicht jede Funktion auf die Schnelle erneut in Angriff nehmen. Kurz gesagt – Ihr Canary Release war nicht besonders agil.

Aber heute sind Sie mit dem richtigen Ansatz deutlich flexibler, wenn Sie entscheiden müssen, welche Funktionen während Ihres Canary Release getestet werden sollen. Jetzt können Sie eine einzige, kleine, isolierte Funktion testen, sobald sie bereitgestellt werden kann – in einer realen Umgebung, ohne substanziellen Mehraufwand für Ihr Team.

Und so wird‘s gemacht

Frage 3: Wie führen Sie Ihr Canary Release faktisch durch?

Canary Releases waren derart ressourcenintensiv, weil alle damit verbundenen Vorgehensweisen mehr oder weniger manuell verliefen.

Sie mussten einen Weg finden, die aktualisierte Version Ihrer Applikation nur bestimmten Usern bereitzustellen. Sie mussten sowohl kurz- als auch langfristige Änderungen an Ihrem Code vornehmen, konfigurieren und überwachen. Sie mussten jede einzelne User-Gruppe im Rahmen verschiedener Tests manuell verfolgen und die Nutzung, das Feedback und jeden KPI dokumentieren, der von den Tests direkt betroffen war. Und all dies mussten Sie abwickeln, während die Funktionen der Standardversion Ihrer Anwendung perfekt aufrecht gehalten werden mussten.

Für den gesamten Prozess waren viele Stunden notwendig. Ein fehlerträchtiger Prozess. Und es war nicht möglich, schnelle, komplexe Tests durchzuführen, auch nicht mit den besten Teams an Ihrer Seite.

Was hat sich also geändert?

Mit einem Wort: die Software.

Jetzt können Sie viele Prozesse im Rahmen eines Canary-Tests und jedes Experiment mit einem einzigen Dashboard auf einer einzigen zentralen Plattform durchführen.

Mit der richtigen Plattform können Sie:

• den gesamten Test gestalten und konfigurieren
• mehrere Funktionen unabhängig voneinander testen
• mehrere besonders personalisierte Segmente erstellen und Testroutinen erstellen
• alle Tests mit einem Button-Klick starten
• die Leistung jeder Funktion und User-Gruppe in Echtzeit überwachen
• alles selbst durchführen, ohne viel Zeit zu investieren

Das Beste von allem: Mit der richtigen Plattform wird das Risiko im Zusammenhang eines Canary Release sogar noch weiter reduziert. Mit einem einfachen Feature-Flagging können Sie die einzelnen getesteten Funktionen als Reaktion auf ihre Echtzeit-Leistung jederzeit aktivieren und deaktivieren. Sie müssen nicht Ihr gesamtes Release zurückschrauben, wenn nur eine Funktion in nur einer Funktionsgruppe falsch funktioniert – Sie können diese Funktion für eine bestimmte User-Gruppe ausschalten und die restlichen Funktionen weiterhin testen.

Wir haben diese Funktionalität und weitere Elemente auf unserer eigenen Plattform – Flagship – gebündelt. Wir sind der Überzeugung, dass Canary Releases ein kritisches Element jedes agilen Produktentwicklungsplans sind. Und wir haben getan, was wir konnten, damit diese Releases so simpel, einfach und kostengünstig wie möglich durchgeführt werden können.

Klicken Sie einfach  hier, um  mehr über unsere Plattform zu erfahren und SOFORT mit Ihrem ersten Canary Release zu beginnen.

Teilen auf

LinkedIn Facebook Twitter

Testing während der Produktionsphase…

Es ist ein einfaches Konzept…

Aber es ist auch eines der heikelsten Themen da draußen, und es spaltet die Entwicklungswelt in zwei Lager – diejenigen, die sagen, dass man bei der Produktion immer testen sollte und diejenigen, die sagen, dass man es nie tun sollte.

In diesem Beitrag untersuchen wir diese beiden verschiedenen Lager, wir zeigen, zu welchem Lager wir gehören (und warum), und wir bieten eine praktische Perspektive auf Tests in der Produktion.

First Thing’s First: Was bedeutet Testing während der Produktion?

Um es kurz und einfach zu halten: das Testen in der Produktionphase bedeutet, verschiedene Tests an Ihrem Produkt durchzuführen, wenn es sich in einer echten Umgebung befindet.

Anstatt diese Tests durchzuführen, während sich Ihr Produkt noch in der Entwicklung befindet oder sicher in einer Staging-Umgebung versteckt ist, führen Sie diese Tests stattdessen erst dann durch, wenn Ihr Produkt in der realen Welt in den Händen realer Benutzer ist.

Warum testet man in der Produktionsphase?

Wenn sie richtig durchgeführt werden, bieten Tests in der Produktion einige große Vorteile, die man mit keiner anderen Methode erreichen kann.

Mit Tests in der Produktion können Sie:

•   Daten aus der realen Welt sammeln, die Sie während der Entwicklung niemals generieren können.
•   Bestätigen, dass Ihr Produkt tatsächlich das bietet, was Ihre Kunden sich wünschen.
•   Neue Funktionen kennenlernen, die Ihre Kunden wünschen und an die Sie vielleicht nie gedacht haben.
•   Sehen, ob Ihr Produkt in der weniger vorhersehbaren realen Welt zuverlässig funktioniert.
•   Eine größere Strategie der inkrementellen – oder sogar kontinuierlichen – Markteinführung unterstützen.

Das sind starke Vorteile und sie reichen aus, um ein erstes Lager von Entwicklern und Produktmanagern zu schaffen, die „Ja, immer!“ zum Testen in der Produktionsphase sagen.

Aber es gibt auch ein zweites Lager von Entwicklern und Produktmanagern, die „Nein, niemals!“ zu Tests in der Produktion sagen. Sie räumen all die großen Vorteile ein, die das Testen in der Produktion bieten kann. Aber sie haben einfach das Gefühl, dass die Praxis zu viele potenzielle Nachteile mit sich bringt und dass ihre Vorteile es einfach nicht wert sind, die Risiken einzugehen, die die Praxis mit sich bringen kann.

Zu welchem Lager gehören wir?

Es sollte wohl keine große Überraschung sein – wir gehören zum ersten Lager.

Wir glauben, dass das Testen in der Produktion ein Grundpfeiler für jeden in der Entwicklungswelt ist. Und wir glauben, dass es besonders wichtig für Produktmanager ist, da es ihnen eine leistungsfähige Methode zur Generierung von Feedback und Leistungsdaten aus der realen Welt bietet, die sie benötigen, um sicherzustellen, dass sie stets eine tragfähige Produktpipeline aufbauen. 

Aber auch wenn wir für Tests in der Produktion einstehen, wollen wir dem „Nein, niemals!“-Lager dennoch ihren Respekt zollen. Wenn wir sie anhören, können wir einige der größten potenziellen Gefahren erfahren, die beim Testen in der Produktion auftreten können. Und wenn wir diese Probleme erst einmal kennen, können wir damit anfangen, Möglichkeiten aufzuzeigen, um diese Nachteile zu reduzieren und die Vorteile von Tests in der Produktion risikofrei zu nutzen.  

Was sind die großen Risiken von Tests während der Produktion?

Um ehrlich zu sein: Vieles kann schief gehen, wenn man in der Produktion testet.

• Sie können schlechte Codes einsetzen…
• Sie können sensible Daten durchsickern lassen…
• Sie können Ihre Infrastruktur überlasten…
• Sie können Ihr Tracking & Analytics vermasseln…
• Sie können ein schlecht gestaltetes Produkt oder eine schlecht gestaltete Funktion freigeben…

Die Liste geht weiter. Alles, was schief gehen kann, könnte schief gehen.

Und das Schlimmste ist, wenn beim Testen in der Produktion etwas schief geht, wird Ihr Fehler Konsequenzen in der realen Welt haben. Ihr Produkt könnte in einem kritischen Moment der realen Nutzung abstürzen. Sie könnten ungenaue KPIs sammeln und Probleme mit Ihren Stakeholdern verursachen. Ihr schlecht gestaltetes Produkt oder Feature könnte dazu führen, dass mehrere zahlende Kunden ein Konkurrenzprodukt vorziehen.

Das Lager der Leute, die „Nein, niemals!“ zu Tests in der Produktion sagen, hält das für höchst riskant und wir verstehen, warum sie sich davon fernhalten.

Und dennoch, auch wenn wir diese Bedenken durchaus anerkennen, befürworten wir es, während der Produktion zu testen.

Und wir sagen Ihnen auch, warum.

Warum sollten Sie dennoch in der Produktionsphase testen?

Erstens, weil das Testen während der Produktion Sie nicht daran hindert, auch vor der Produktion zu testen.

Die meisten der technischen Probleme, die während eines schlechten Produktionstests auftreten können, lassen sich vermeiden, wenn Sie während der Entwicklung und Qualitätssicherung eine ganze Reihe von technischen Tests durchführen, um sicherzustellen, dass Ihre neuen Produkte und Funktionen stabil sind und einem hohen Volumen des realen Einsatzes gewachsen sind.

Und wenn Sie eine Strategie der iterativen Entwicklung verfolgt haben, dann ist die Chance, ein falsch ausgerichtetes Produkt oder Feature – aus der Perspektive Ihrer Benutzer – zu veröffentlichen, sehr gering. Sie werden nicht jedes Mal einen Homerun erzielen, aber auch die Wahrscheinlichkeit eines Strikeouts ist weitaus geringer.

Zweitens, weil vieles, was in einer Produktionsumgebung schief gehen könnte, in einer Entwicklungs- oder Staging-Umgebung ohnehin nicht richtig getestet werden kann.

Es gibt bestimmte technische Probleme, die sich erst dann zeigen, wenn Sie Ihr Produkt oder Feature vor Anwendern aus der realen Welt präsentieren. Tatsächlich gibt es bestimmte technische Probleme, die erst dann auftauchen, wenn Sie Ihr Produkt oder Ihre Funktion vor vielen Benutzern aus der realen Welt präsentieren. Es kommt auf den Umfang an, ebenso wie auf die unvorhersehbaren Nutzungsmuster, die nur Benutzer aus der realen Welt mitbringen können.

Und wenn es um neue Produkte und Features geht – selbst das robusteste Programm zur iterativen Entwicklung auf der Grundlage des Feedbacks Ihrer Benutzer aus der realen Welt kann immer noch nur eine Vermutung darüber abgeben, was Ihre Benutzer als nächstes wollen. Sie können Vermutungen anstellen, die fundierter sind als andere, aber letztendlich werden Sie nie wissen, ob Sie die Rückmeldungen Ihrer Benutzer richtig interpretiert haben, bis Sie diese Funktionen in der freien Wildbahn veröffentlichen und sehen, wie sie aufgenommen werden.

Drittens, und das ist am wichtigsten… weil Sie bereits in der Produktion testen, auch wenn Sie es nicht wussten!

Die meisten der bewährten Verfahren der Agilen Entwicklung und des Produktmanagements sind Formen des Testings in der Entwicklung. Wir sprechen hier von sehr verbreiteten Praktiken wie:

•     CI/CD
•     A/B Testing
•     Phased Rollouts
•     Canary Releases
•     User Monitoring
•     Usability Testing
•     Smoke & Sanity Testing

Wenn Sie eine dieser Methoden – und noch viele andere – anwenden, dann führen Sie bereits Tests mit Benutzern aus der realen Welt in einer Live-Produktionsumgebung durch. Sie testen bereits in der Produktion, ob Sie es nun so nennen oder nicht, selbst wenn Sie die ganze Zeit dachten, Sie wären im „Nein, niemals!“-Camp.  

Eine praktische Perspektive auf Tests in der Produktion

Lassen Sie uns den Tatsachen ins Auge sehen: Das Testen während der Produktion ist heute ein wesentliches Element des Produktmanagements. Stellen Sie sich vor, Sie versuchen, Ihre Arbeit ohne A/B-Tests zu erledigen. Oder ohne schrittweise Rollouts. Oder ohne die Möglichkeit, unmittelbare Rückmeldungen aus der realen Welt oder technische Nutzungsdaten zu Ihren neuen Produkten und Features zu sammeln. Das können Sie nicht. Sie müssen in der Produktion testen.

Und deshalb bleiben wir standhaft im „Ja, immer!“-Lager, obwohl wir uns der Risiken dieser Handlungsweise bewusst sind. Wenn Tests in der Entwicklung heutzutage unvermeidlich sind, dann sollten Sie weniger Zeit damit verbringen, die Vor- und Nachteile zu debattieren, und mehr Zeit darauf verwenden, den effektivsten und verantwortungsvollsten Weg zu finden, diese Praxis anzuwenden.

Wir glauben so sehr an diese Perspektive des Testens in der Entwicklung, dass wir eine ganze Produktsuite aufgebaut haben, um Produktentwicklern zu helfen, alle Vorteile der Praxis zu nutzen und gleichzeitig ihre Risiken zu minimieren. Unsere Produktsuite heißt Flagship, und ihre Kernfunktion ist das Feature Flag.

Durch den durchdachten Einsatz von Feature-Flags können Sie alle erforderlichen Tests in der Produktion sicher durchführen. Mit Feature-Flags – kombiniert mit dem Rest von Flagship – können Sie:

• Setzen Sie kleinere Releases ein, die die Auswirkungen eines Ausfalls minimieren.
•  Testen Sie Ihre neuen Funktionen nur an Ihren treuesten und verständnisvollsten Benutzern.
•  Personalisieren Sie ihre Tests, damit sie wissen, dass sie mit ein paar Schwierigkeiten bei der Veröffentlichung rechnen müssen.
•     Schalten Sie unterdurchschnittliche Features sofort mit einem einzigen Klick aus.

Mit Feature-Flags und ein wenig Planung können Sie das Risiko drastisch reduzieren und die Komplexität der Tests während der Produktion, die Sie bereits durchführen, erhöhen. Und das bedeutet mehr reale Benutzerdaten, zuverlässigere Produkte und Funktionen und weniger Sorgen darüber, wie sich Ihre harte Arbeit außerhalb der sicheren Grenzen von Entwicklungs- und Staging-Umgebungen verhält.  

Wenn Sie mehr über Flagship, Feature-Flags oder einfach nur darüber erfahren möchten, wie Sie bessere Tests in der Produktion durchführen können, wenden Sie sich noch heute an uns.

Teilen auf

LinkedIn Facebook Twitter