Wie ich mich auf meine Releases vorbereite und sie teste
Releases und Release-Management sind ein wesentlicher Bestandteil unserer Arbeit. Das richtige Produkt für die Kunden bereitzustellen, macht sie glücklich. Ein reibungsloser Release macht uns, die am Release Beteiligten, glücklich.
Wie können wir einen reibungslosen Release erreichen?
Nach der Teilnahme an einer Vielzahl von Releases kann ich sagen, dass es ein paar Schlüsselpunkte gibt, die dabei helfen können, ein erfolgreiches Release-Management zu erreichen.
Ich erkläre euch, worum es dabei geht.
Ein erfolgreicher Release beginnt schon während der Entwicklung.
Testfälle identifizieren
Gutes Release-Management beginnt lange vor dem Tag des eigentlichen Releases, nämlich schon dann, wenn das zu veröffentlichende Feature in der Entwicklungsphase ist. Während dieser Zeit muss das Feature durch die Qualitätssicherung abgenommen werden. Das bedeutet, dass wir alle denkbaren und für das jeweilige Feature relevanten Szenarien testen müssen, um zu gewährleisten, dass das Feature den Anforderungen entspricht. Einige dieser Szenarien werden durch automatisierte Tests überprüft, während sich für andere die Automatisierung entweder als zu aufwendig oder nicht sinnvoll erweist.
Wenn wir ermitteln, welche Art von Tests für ein bestimmtes Feature notwendig sind, sollten wir Folgendes beachten: Geht dieses Feature zum ersten Mal in Produktion, müssen wir es vollständig testen. Wir müssen sichergehen, dass keine kritischen Probleme bei den Kunden auftreten. Wir müssen die Anforderungen validieren und für eine gute Performance des Features sorgen.
Verzögerungen und Probleme beim Testen können die Zeitpläne bei der Vorbereitung von Software-Releases stark beeinflussen. Die Integration von effizienten Release-Management-Praktiken hilft, die Tests und die Auslieferung zuverlässig und vorhersehbar zu gestalten.
Aber sobald das Feature live ist, muss es – sofern keine Aktualisierungen dafür erforderlich sind – nicht mehr bei jedem weiteren Release derselben Codebasis so umfassend getestet werden. Das Verhalten des Features ändert sich nur, wenn der zugrunde liegende Code verändert wurde oder wenn sich eine vom Feature genutzte externe Abhängigkeit geändert hat. Ansonsten reicht ein sogenannter Sanity-Check, bei dem natürlich die wichtigsten Testfälle abgedeckt werden.
Daher sollte man bereits während der Entwicklung des Features bewerten: Wie viele Testfälle müssen geprüft werden? Wie viel Zeit steht für das Testen zur Verfügung? Welche Testfälle sind kritisch? Welche Testfälle werden bei jedem Release ausgeführt?
So lassen sich jene Testfälle erkennen, die automatisiert werden sollten. Der Fokus sollte darauf liegen, zumindest die kritische Funktionalität per Automatisierung abzudecken. Für alle anderen Tests sollten schriftliche Testfälle in eurem Projekt-Tracking-System (z. B. Jira) oder im verwendeten Testmanagement-Tool festgehalten werden. Auf diese Weise gehen sie nicht verloren, werden nicht vergessen und können jederzeit ausgeführt werden, wenn ein Release es erfordert.
Tests im CI-System ausführen
Wenn die automatisierten Tests einmal stehen, sollten sie regelmäßig über das CI-System in den Entwicklungsumgebungen ausgeführt werden. Während weitere Features entwickelt werden, noch bevor das Release stattfindet, ist es sinnvoll sicherzustellen, dass das zur Veröffentlichung vorgesehene Feature weiterhin ordnungsgemäß funktioniert – insbesondere, wenn es bereits im Sprint abgenommen wurde. Durch tägliches Testen des betreffenden Features erhält man schnell Rückmeldung, falls durch Änderungen an anderer Stelle Fehler für dieses Feature auftreten.
Früherkennung potenzieller Fehler im zu veröffentlichenden Feature gibt ausreichend Zeit für Korrekturen und erneutes Testen – ohne den Stress, dies unter Zeitdruck in der Release-Phase erledigen zu müssen. Je größer die Abdeckung der Anforderungen durch automatisierte Tests, desto weniger Fehler werden voraussichtlich in der Release-Phase auftreten.
Die Pre-Production-Phase ist wichtig und sollte einen Puffer enthalten.
Zeitfenster
Die Release-Phase besteht in der Regel aus einem Zeitraum, der dem Testen in einer Pre-Production-Integrationsumgebung gewidmet ist – zusätzlich zum eigentlichen Produktionstag oder ‑zeitraum. Als Tester, der am Release beteiligt ist, achte ich immer darauf, für angemessene Zeitfenster zu sorgen, sodass ich in der Pre-Production-Phase die zu veröffentlichenden Features ausreichend testen kann.
Ich kalkuliere ebenfalls immer einen Zeitpuffer ein, denn ich rechne damit, dass unvorhergesehene Probleme im Release-Management-Prozess auftreten – sei es durch Bugs im Release selbst oder durch externe Faktoren. Einer dieser Faktoren ist zum Beispiel, dass Pre-Production-Umgebungen Testumgebungen sind und häufig nicht die Zuverlässigkeit besitzen, die sie eigentlich haben sollten. Oft arbeiten sie sehr langsam oder sind gerade während der Release-Tests für eine gewisse Zeit nicht erreichbar.
Es ist immer eine gute Idee, eine zusätzliche Pufferzeit einzuplanen. Selbst wenn Sie diese Extrazeit nicht benötigen, ist das kein Problem. Sie können Ihr Okay zum Abschluss bereits vor dem Ablauf der vorgesehenen Testzeit geben und die restliche Zeit für andere Aufgaben nutzen. Schlimmer ist es, keinen Puffer zu haben und ihn dann zu brauchen, da Sie in diesem Fall sämtliche nötigen Tests in kürzerer Zeit unterbringen müssen. Das kann dazu führen, dass einige Tests nicht ausgeführt werden – und dies wiederum kann dazu führen, dass Fehler erst direkt in der Produktion entdeckt werden.
Umfang
Ein weiterer wichtiger Aspekt eines Pre-Production-Releases ist aus meiner Sicht ein dedizierter Koordinator für das Release-Management. Gemeint ist damit jemand, der bestimmte Aufgaben übernimmt, und die erste davon ist: Überprüfung des Release-Umfangs. Bevor überhaupt ein Release getestet wird, muss der Tester wissen, was geprüft werden soll. Das läuft letztlich auf den Umfang des Release hinaus.
Produktverantwortliche, also z. B. POs oder BAs, erwarten bestimmte Funktionen im Release, was zu Beginn der Entwicklung abgestimmt wird. Der Code, der ins Release gelangt, deckt jedoch nicht immer genau den vom Produktteam erwarteten Umfang ab. Manchmal vergessen Leute, ihren Code in den Branch zu pushen, aus dem das Release gebaut wird. Oder schlimmer: Sie pushen Code, der gar nicht in diesen Branch gehört. Das können Funktionen sein, die noch nicht fertiggestellt und von der Qualitätssicherung abgenommen wurden oder Funktionen, die nicht im aktuellen Umfang enthalten sind.
Um sicherzustellen, dass der Umfang auch wirklich eingehalten wird, sollte der Release-Koordinator den erwarteten Umfang mit dem tatsächlichen vergleichen. Dazu sollte der erwartete Umfang von den Produktverantwortlichen klar in bestimmten Dokumenten festgehalten werden (zum Beispiel in Ihrem Qualitätssicherungsplan). So gibt es vielleicht Planungsdokumente, in denen die Projektmeilensteine und deren Inhalte aufgeführt sind.
Für den tatsächlichen Umfang sollte ein Changelog aus dem verwendeten VCS (Version Control System, z. B. Git) gezogen werden. Das Changelog spiegelt alle Commits wider, die während der Entwicklungsphase in den Branch gemacht wurden, der das Release erstellt. Im Idealfall enthält jeder Commit eine Beschreibung, die auf ein Jira-Item verweist, auf das sich der Code bezieht. So sehen Sie, welche Jira-Items im Release enthaltenen Code haben und welche nicht hätten inkludiert werden dürfen. Wenn diese Commits notwendige Fehlerbehebungen betreffen, ist das natürlich kein Problem. Was Sie aber vermeiden möchten, sind Commits, die unfertige Funktionen oder Arbeit an Features repräsentieren, die in der aktuellen Version nichts verloren haben.
Wenn Sie fortgeschrittene Techniken im Release-Management anwenden, werden Sie feststellen, dass eine Integration Ihrer Abläufe mit Testmanagement-Lösungen für Jira einen weitaus effizienteren und konsistenteren Arbeitsfluss ermöglicht.
Stellt sich eine Diskrepanz zwischen erwartetem und tatsächlichem Umfang heraus, sollte der Release-Management-Koordinator mit dem Produkt-Team und den Entwicklungsleitern Rücksprache halten, um das beste weitere Vorgehen zu ermitteln. Wenn die betroffenen Commits unfertige Funktionen enthalten, sollten sie entfernt werden. Sie befinden sich bereits in der Pre-Production-Phase und möchten nicht riskieren, dass der übrigbleibende Code überhastet geschrieben und getestet wird, nur damit er es in die aktuelle Version schafft. Diese Eile könnte dazu führen, dass Tests vergessen werden und kritische Fehler in die Produktion geraten. Hier ist es besser, die weitere Arbeit an diesen Funktionen für ein späteres Release sorgfältig zu Ende zu bringen.
Das Testing
Ist der Umfang klar, beginnt die Testphase. Während der Tests vor dem Produktivgang gilt es, das gesamte Feature, das veröffentlicht werden soll, erneut zu überprüfen. Versetzen Sie sich in die Lage, als sähen Sie es zum ersten Mal, und testen Sie jedes Szenario wie während der Entwicklungsphase. Führen Sie die bereits geschriebenen automatisierten Tests in der Pre-Production-Umgebung aus und vergessen Sie nicht die nicht automatisierten Szenarien. Führen Sie ein vollständiges Regressionstest auf dieses Feature durch, denn sobald Sie sich in dieser Phase befinden, und in der Pre-Production-Umgebung testen, sind vermutlich auch andere Teams im gleichen Zeitraum mit ihren Releases beschäftigt. Das ist im Grunde das erste Mal, dass alle Abhängigkeiten mit produktionsreifem Code in einer Umgebung zusammentreffen – und dies ist (theoretisch) genau die Konfiguration, die später produktiv laufen wird.
Es sei denn, während der Tests treten Probleme auf und Korrekturen sind nötig. Sollte dieser Fall eintreten, überlegen Sie, was Sie erneut testen müssen. Egal, ob der Fix Ihren eigenen Code betrifft oder den einer externen Abhängigkeit: Wenn Änderungen Ihr Feature beeinflussen, ist eine weitere Testrunde unerlässlich. Testen Sie unbedingt die kritische Funktionalität erneut.
Das kann langweilig erscheinen, besonders wenn in dieser Phase viele Korrekturen anfallen. Doch Sie können die Auswirkungen der Fixes auf verschiedene Teile Ihres Features nicht zuverlässig vorhersagen.
Kleine Änderungen können große Nebenwirkungen haben, daher ist es besser, sich zu langweilen, aber sicher zu sein, dass die kritischen Funktionen weiterhin korrekt laufen, als später zu bereuen, nicht genug getestet zu haben.
Und selbstverständlich: Falls im Testing nur kleinere Fehler gefunden werden, sollten Sie deren Behebung in dieser Phase nicht erzwingen. Verzichten Sie auf übereilte Implementierungen oder Tests an einem ansonsten funktionierenden Feature, denn so verhindern Sie zusätzliche Risiken.
Während des Releases sind Kommunikation und Tests entscheidend.
Sobald das Feature in der Pre-Production-Umgebung abgenommen wurde, ist es bereit für die Überführung in die Produktionsumgebung.
Kommunikation
Beim Produktiv-Release hat der Release-Management-Koordinator einige Aufgaben zu erfüllen. Zunächst sollten das Release-Datum und die -Uhrzeit frühzeitig festgelegt und allen beteiligten Parteien mitgeteilt werden. Ich finde es sehr hilfreich für das Release-Management, das Release-Datum und die -Uhrzeit als Termin in den Kalendern der Teilnehmenden einzutragen, damit sie ihren Tag entsprechend organisieren können – eine Aufgabe, die vom Koordinator erledigt werden kann.
Am Tag des Releases sollte der Koordinator alle Beteiligten an den Zeitplan erinnern. Idealerweise sollte die Kommunikation über einen Kanal erfolgen, den alle verwenden, zum Beispiel Slack. Ein dedizierter Slack-Channel, in dem alle wichtigen Aspekte kommuniziert werden, stellt sicher, dass alle Beteiligten denselben Kenntnisstand haben – was wurde bereits erledigt, was ist der Scope, welche Probleme wurden entdeckt und wer kann bei deren Behebung helfen. Durch diese Kommunikation erhalten alle, die Informationen zum Release benötigen, diese auch – im Gegensatz zur mündlichen Weitergabe (bei der Anwesende fehlen könnten, ohne dass es bemerkt wird).
Der Release-Management-Koordinator sollte die wichtigsten Meilensteine des Releases in diesem Channel festhalten und bekanntgeben, etwa wann der Release beginnt oder abgenommen wurde. Auch jede am Release beteiligte Partei sollte über diesen Channel mitteilen, welche Schritte sie gerade durchführt, damit alle den Status und Fortschritt des Releases im Blick behalten. Sollte eine beteiligte Partei zu einem bestimmten Zeitpunkt nicht verfügbar sein, sollte der Release-Koordinator Kontakt zu den entsprechenden Personen aufnehmen, damit alles reibungslos abläuft.
Die Tests
Während des Produktiv-Releases sollten die neuen Funktionen erneut vollständig getestet werden – auch wenn das Feature bereits in anderen Testumgebungen abgenommen wurde, da diese nicht zu 100 % mit der Produktionsumgebung identisch sind (hinsichtlich Konfiguration und Ressourcen).
Um unerwartetes, fehlerhaftes Verhalten zu vermeiden, ist es wichtig, alle verfügbaren automatisierten Tests auszuführen und zusätzlich die manuellen Testfälle, die dafür definiert wurden. Niemals ohne vorherigen Test ein Feature in der Produktion abnehmen!
Nur anzunehmen, dass das Feature in Produktion funktioniert, bedeutet nicht, dass es das tatsächlich tut.
Stellen Sie sicher, dass es funktioniert – testen Sie es.
Nach dem Release
Das Release ist durchgeführt. Aber dafür zu sorgen, dass das Feature wirklich zuverlässig funktioniert, ist mehr als nur ein Test während der Release-Phase.
Sobald das erledigt ist, sollten Sie Ihre automatisierten Tests für die Produktion in der CI laufen lassen. Damit werden ungewünschte Verhaltensänderungen durch externe Einflüsse erkannt, von denen Sie vielleicht nichts wissen.
Überwachen Sie fortlaufend die Performance des Features, um sicherzustellen, dass die Produktionslast und die Nutzung durch Kunden nicht zu Leistungseinbußen führen. Und behalten Sie jegliche Problemberichte Ihrer Kunden im Blick. Diese weisen oft auf Bereiche hin, die nicht ordnungsgemäß funktionieren – so können Sie bei Bedarf rasch ein Update einplanen.
Und falls das Release nicht wie erwartet verlief, sollten Sie unbedingt ein Post-Release-Retrospektiv-Meeting abhalten. Dort können alle beim Release aufgetretenen Probleme im Managementprozess angesprochen und Aufgaben an die richtigen Personen verteilt werden, damit künftige Releases reibungslos und erfolgreich verlaufen.
