Scrum minus Testplan entspricht POC auf Steroiden.
Heutzutage beginnen die meisten erfolgreichen Projekte mit einem Proof of Concept (POC), einer relativ kleinen Bewertung einer Idee, bei der die gewählte Technologie und das ausgewählte Feature-Pack zuerst verifiziert, auf potenzielle Auswirkungen auf Geschäftsanwender bewertet und dann, sobald sie sich bewährt haben eine Investition wert ist, wird ein vollwertiges Projektteam beauftragt, das Produkt mit vollem Funktionsumfang zu entwerfen und zu liefern und es in der Produktion einzusetzen.
Dies ist der perfekte Fall für ein Scrum-Team. Das Team kann den Prototyp schnell entwickeln und in jedem Sprint wesentliche neue Funktionen hinzufügen, während Geschäftsanwender in Echtzeit den schnellen Fortschritt verfolgen und sehen können, wie die Idee innerhalb von nur etwa 10 Sprints von Grund auf neu entwickelt wird. Es hinterlässt einen starken Eindruck (was sowieso das Hauptziel des POC ist), aber es hat auch eine bedeutende Eigenschaft – minimale oder keine Testaktivitäten, und selbst an den Testprozess zu denken, wäre ein Witz.
Es ist keine lustige Aktivität innerhalb eines Scrum-Teams, und die Leute werden die Idee am meisten mögen, ohne Prozesse zu entwickeln, die sie verlangsamen. Dies ist im Grunde das, was jede Testaktivität implizit tun wird. Und wer will schon unnötige Langsamkeit in der Zeit, die wir brauchen, um den Endverbraucher am meisten zu beeindrucken?
Der Zustand, der eintritt, wenn das Projektteam nach Ablauf der POC-Phase auf die gleiche Weise fortfährt, nenne ich POC auf Steroiden – ein Produktionssystem, das an Größe und Funktionen zunimmt, sich aber immer noch wie ein POC verhält – ein Möchtegern-Komplettprodukt mit versteckte Defekte und unerforschte Eckfälle, die nur auf einen schweren Crash warten.
Aber bevor es dort konvertiert wird, wird es dem Team von Sprint zu Sprint schwerer fallen, mit stabilen Releases Schritt zu halten, da die Behebung der laufenden Probleme nur noch komplexer wird.
Hier sind einige Techniken, die sich bewährt haben, als ich mit ähnlichen Problemen zu tun hatte, und die meiner Meinung nach als Best Practices für die Implementierung solider Testprozesse bezeichnet werden können, ohne den Entwicklungsfortschritt zu sehr zu stören – denn das wollen wir alle ein Scrum-Team.
Inhaltsverzeichnis
Verteile den Schmerz
Wo sollen wir sonst anfangen, wenn es um unnötige Belästigung geht, als damit, den Schmerz zu teilen :).
Und was ich damit meine, ist das Erstellen eines Plans, der hier und da kleine zusätzliche Aktivitäten von Entwicklern erfordert, der aber im Laufe der Zeit einen großen Beitrag zum gemeinsamen Ziel leisten wird, inkrementell, aber konsistent.
#1. Entwickeln Sie Unit-Testcode für jedes erstellte Stück neuen Codes
Wenn es Ihnen gelingt, Ihre Scrum-Teams davon zu überzeugen, die Entwicklung von Unit-Tests für jeden neuen Code, der innerhalb des Sprints erstellt wird, in die Definition-of-Done-Klausel aufzunehmen, dann wird dies aus langfristiger Sicht eine großartige Leistung sein.
Die Gründe sind ziemlich offensichtlich:
Es zwingt Entwickler, über verschiedene nicht standardmäßige Pfade des Codes nachzudenken. –
- Solche Unit-Tests können in automatisierte DevOps-Pipelines eingebunden und bei jeder einzelnen Bereitstellung in der Entwicklungs- oder Testumgebung ausgeführt werden. Außerdem können Metriken aus der Pipeline einfach exportiert und dann zur Demonstration der prozentualen Abdeckung von direkt an den Quellcode gebundenen Testfällen für Geschäftsanwender verwendet werden.
Das Wichtigste ist, sehr bald zu beginnen. Je später mit der Entwicklung der Unit-Tests begonnen wird, desto ablenkender wird es für Entwickler, sie innerhalb eines Sprints hinzuzufügen.
- Es wird erhebliche Anstrengungen erfordern, Komponententests für bereits vorhandenen Code rückwärts zu entwickeln. Einige Teile des Codes könnten von einem anderen Entwickler erstellt worden sein, und das genaue Wissen darüber, wie es in jedem einzelnen Codeteil funktionieren sollte, ist dem aktuellen Entwickler nicht genau klar. In einigen Fällen kann es so weit kommen, dass das Hinzufügen eines Unit-Tests zum geänderten Code mehr Zeit in Anspruch nimmt, als die Feature-Änderung für den Sprint zu entwickeln (ein Zustand, den niemand während der Sprint-Planung mit Sicherheit berechnet hat).
#2. Machen Sie es sich zur Routine, alle Teile von Komponententests in der Entwicklungsumgebung auszuführen
Noch bevor ein Pull-Request zum Mergen des neuen Codes in den Master-Branch erstellt wird, sollte es eine Standardaktivität sein, sowohl den Feature-Code als auch den Unit-Test-Code in der Entwicklungsumgebung zu testen. Dadurch wird sichergestellt, dass:
- Unit-Test-Code funktioniert tatsächlich für jeden Teil (am Ende ist es nur ein weiterer Code, der verifiziert werden muss). Dieser Schritt wird sehr oft ganz übersprungen. Es wird irgendwie davon ausgegangen, dass, wenn der Unit-Test sowieso in die DevOps-Pipeline gesteckt wird, er schließlich standardmäßig irgendwo ausgeführt und getestet wird. Dies ist jedoch nichts anderes, als die Probleme in die oberen Ebenen der Sprint-Aktivitäten zu schieben, wo das Team normalerweise weniger Zeit und mehr Stress hat, um jede engagierte Geschichte zu beenden.
- Der neue Funktionscode wird vom Entwickler auf grundlegende Funktionalität getestet. Natürlich kann von diesem Test nicht erwartet werden, dass die Geschäftsfunktionalität vollständig verifiziert wird, aber zumindest wird dieser Test bestätigen, dass sich der Code so verhält, wie der Entwickler es beabsichtigt hat (wobei vorerst die Tatsache ignoriert wird, dass die Geschäftslogik dies könnte beim Entwickeln falsch verstanden werden).
#3. Erwarten Sie die Ausführung des Komponententests nach dem Zusammenführen des Codes mit dem Master-Zweig
Es ist eine Sache, funktionierenden Code auf dem lokalen Branch zu haben (wo niemand außer dem Branch-Eigentümer ein neues Feature entwickelt), aber es ist eine völlig andere Sache, denselben Code nach der Pull-Anforderung zu haben und in den Master-Branch zu führen.
Der Master-Branch enthält Änderungen von anderen Scrum-Teammitgliedern, und selbst wenn die Konflikte gelöst sind und alles gut aussieht, ist der Code nach der Zusammenführung und Konfliktlösung im Grunde immer noch ein ungetestetes Stück Code, und es ist riskant, ihn ohne vorherige Überprüfung weiterzusenden es funktioniert immer noch gut.
Was sich hier also als effektiv erwiesen hat, ist einfach zu fragen, ob die gleichen Komponententests – die bereits zuvor in der Entwicklungsumgebung durchgeführt wurden – auch in der Umgebung ausgeführt werden, die aus der Master-Branch-Code-Version erstellt wurde.
Für die Entwickler ist es vielleicht ein zusätzlicher Schritt, den sie in ihr Leben einbauen müssen, aber es ist kein großer Aufwand, da in diesem Fall nichts Neues erfunden werden muss, sondern nur das wiederholt wird, was bereits einmal getan wurde.
Nun könnte dieser Schritt in einem bestimmten Fall übersprungen werden:
- Die automatisierten Unit-Tests in DevOps-Pipelines sind so umfassend, dass sie bereits das gesamte darüber hinausgehende manuelle Testen abdecken.
Während das Erreichen dieses Zustands definitiv machbar ist, habe ich einen solchen Zustand im wirklichen Leben noch nie erlebt. Es wäre wahrscheinlich sogar für Entwickler zu zeitaufwändig, solche tief detaillierten automatisierten Unit-Tests zu erstellen. Es könnte für den Product Owner leicht inakzeptabel werden, das Team dieser Aktivität so viel Zeit widmen zu lassen, da dies einen deutlichen Einfluss auf die Anzahl der gelieferten Storys innerhalb eines Sprints hätte.
Die Bevorzugung von Sprint-Content darf jedoch niemals als Entschuldigung dafür dienen, die Unit-Tests nicht durchzuführen oder gar zu minimieren. Dadurch wird das Team wieder in einen solchen Zustand übergehen, dass dem Code zu wenig Unit-Test-Abdeckung fehlt und es dann für eine Nachholaktion schon zu spät sein könnte (auch hier ist der Aufwand für die Unit-Test-Vervollständigung höher als der eigentliche Codeänderung für einen Sprint).
Aus all diesen Gründen würde ich bedenkenlos eine erneute Ausführung der Unit-Tests auf der Mastercode-Version empfehlen. Es ist so ein geringer Aufwand im Vergleich zu dem Wert, den es bringen wird.
Es wird die endgültige Überprüfung der Bereitschaft des Master-Zweigs für die Release-Testphase durchführen. Außerdem wird es helfen, die meisten technischen Fehler zu finden (z. B. Fehler, die verhindern, dass der Quellcode bis zum erfolgreichen Ende erfolgreich ausgeführt wird), sodass sich die nächste Phase ausschließlich auf die Überprüfung der Geschäftsfunktionalität konzentrieren kann.
Bereiten Sie sich auf Funktionstests vor
Alle bisherigen Testaktivitäten sollen zu einem konkreten Ergebnis führen – der Master Branch Code ist frei von technischen Fehlern und für durchgängige Funktionsabläufe problemlos lauffähig.
Dies ist eine Phase, die leicht von einer einzelnen Person abgedeckt werden kann, und diese Person muss nicht einmal einen technischen Hintergrund haben.
Tatsächlich ist es viel besser, wenn dies von jemandem ausgeführt wird, der nichts mit den Entwicklern zu tun hat, aber ein funktionales Bewusstsein dafür hat, wie sich Geschäftsbenutzer vom Verhalten des Codes erwarten. Es sind zwei Haupttätigkeiten zu erledigen:
#1. Neue Sprint Stories gezielter Funktionstest
Jeder Sprint soll idealerweise eine neue Funktionalität (Sprint Goal Increment) bringen, die vorher nicht vorhanden war, und somit verifiziert werden. Es ist wichtig sicherzustellen, dass die neue Software so funktioniert, dass die Geschäftsanwender jetzt froh sind, sie zu haben, da sie sich offensichtlich mindestens den ganzen letzten Sprint darauf gefreut haben :).
Es ist so eine traurige Erfahrung, wenn die (lange) versprochene Funktionalität endlich als Veröffentlichung angekündigt wird, nur um neulich herauszufinden, dass sie tatsächlich nicht gut funktioniert.
Daher ist es von entscheidender Bedeutung, neue Sprint-Funktionen richtig zu testen. Um dies zum Erfolg zu führen, empfiehlt es sich, wichtige Testfälle im Voraus und von relevanten Interessengruppen (entweder vom Produkteigentümer oder sogar von den Endbenutzern) zu sammeln und eine Liste aller solcher Testfälle zu erstellen, die für den darin enthaltenen Inhalt benötigt werden der Sprint.
Das mag auf den ersten Blick überwältigend erscheinen, ist aber meiner Erfahrung nach auch von einer einzelnen Person völlig überschaubar. Da die Sprints meistens recht kurz sind (z.B. zwei Wochen kurz), ist es sowieso fast nie zu viel neuer Inhalt, da der Sprint auch zusätzliche Aktivitäten wie technische Debt Stories, Dokumentation, Design/Spike Stories usw. beinhaltet.
Anschließend werden Testfälle mit dem Ziel ausgeführt, in erster Linie die gewünschte Funktionalität zu verifizieren. Wenn ein Problem mit den Ergebnissen auftritt, wird nur der zuständige Entwickler kontaktiert (derjenige, der die Änderungen im Zusammenhang mit diesem bestimmten Fehler besitzt), um das Problem hoffentlich schnell zu lösen.
Auf diese Weise verbringen die Entwickler nur minimale Zeit mit Funktionstests und können sich dennoch auf die Aktivitäten konzentrieren, die ihnen am besten gefallen.
#2. Ausführung von Regressionstestfällen
Der andere Teil des funktionalen Testens besteht darin, sicherzustellen, dass alles, was bisher funktioniert hat, auch nach dem nächsten Release funktioniert. Dafür sind Regressionstests da.
Testfälle für Regressionstests sind am besten, wenn sie regelmäßig gepflegt und vor jedem Release überarbeitet werden. Basierend auf den konkreten Projektspezifikationen ist es am besten, sie einfach zu halten, aber die Mehrheit der Kernfunktionalitäten und wichtigen End-to-End-Flows abzudecken, die durch das gesamte System laufen.
Normalerweise hat jedes System solche Prozesse, die viele verschiedene Bereiche berühren, das sind die besten Kandidaten für Regressionstestfälle.
In einigen Fällen decken Regressionstests sogar implizit auch neue Features im Sprint ab, zum Beispiel wenn die neue Story im Sprint einen bestimmten Teil des bestehenden Flusses verändert.
Daher ist es in den meisten Fällen überhaupt nicht sehr aufwendig, Regressionstests neben neuen Funktionstests für Sprint-Storys durchzuführen, insbesondere wenn dies regelmäßig vor jedem Produktionsrelease durchgeführt wird und die Periodizität von Produktionsreleases nicht zu gering ist.
Bestehen Sie darauf, vor jeder Produktionsfreigabe Qualitätssicherungstests durchzuführen
Der Qualitätssicherungstest (QA) ist der letzte Schritt vor der Freigabe für die Produktion, und oft wird dieser Test als unwichtig übersprungen. Vor allem, wenn das Scrum-Team aggressiv für neue Inhalte geführt wird.
Auch Geschäftsanwender werden sagen, dass sie an neuen Features interessiert sind und nicht so sehr daran, die Funktionalität zu erhalten oder die Anzahl der Fehler gering zu halten. Aber andererseits – im Laufe der Zeit ist dies der Hauptgrund, warum das Entwicklerteam irgendwann langsamer werden muss, und dann erhalten Geschäftsanwender sowieso nicht das, wonach sie fragen.
Der QA-Test sollte ausschließlich von Personen außerhalb des Scrum-Teams durchgeführt werden, idealerweise von Geschäftsanwendern selbst in einer dedizierten Umgebung, die so nah wie möglich an der zukünftigen Produktion ist. Alternativ kann der Product Owner hier die Endanwender ersetzen.
In jedem Fall sollte dies aus Sicht des Endbenutzers ein sauberer, funktionaler Test sein, ohne Verbindung zum Entwickler-Scrum-Team. Es wird eine endgültige Ansicht des Produkts darstellen und auf eine Weise verwendet werden, die möglicherweise niemand aus dem Scrum-Team erwartet hat (überhaupt kein Idealfall, aber es kann definitiv passieren). Es ist noch Zeit für Last-Minute-Korrekturen.
Alternativ könnte klar werden, dass die Erwartungen vom Scrum-Team nicht gut verstanden wurden, und in einem solchen Fall können wir uns zumindest noch lange vor der eigentlichen Produktionsfreigabe auf einen Folgeplan einigen. Dies ist wiederum kein Idealfall, aber immer noch viel besser, als würde man den Fehler direkt nach der Meldung einer erfolgreichen Produktionsfreigabe zugeben.
Wo soll es von hier aus weitergehen?
Die Anwendung dieser Praktiken auf die tägliche Scrum-Arbeit kann Sie ernsthaft zu stabileren und vorhersehbareren Sprint-Release-Gewohnheiten führen, ohne die Produktions-Releases zu verzögern oder den gesamten Sprint damit zu verbringen, sich nur auf das nächste Release vorzubereiten, oder sogar ohne jeden im Scrum-Team zu zwingen, etwas zu tun, was er tut Ich mag oder weiß sowieso nicht, wie ich den größten Teil des Sprints effektiv machen soll.
Aber Sie müssen hier sicherlich nicht aufhören.
Die Einbeziehung von Leistungstests ist ein Thema, das hier zu nennen ist. Diese werden oft ignoriert oder als unnötig erachtet und schaben in der ersten Runde der „Optimierung von Scrum-Aktivitäten“. Ich hatte jedoch immer Zweifel, wie sich das Produktivsystem im Laufe der Zeit entwickeln wird, wenn es nicht regelmäßig auf Leistung überprüft wird.
Eine Stufe höher zu gehen bedeutet auch die Einführung automatisierter Tests.
Ich habe bereits eine Gruppe von automatisierten Tests (Einheitentests in der Pipeline) behandelt. Sie können jedoch vollständige End-to-End-Regressionstests entwickeln, die vollständig automatisiert und nach jeder Bereitstellung in der Testumgebung von selbst ausgeführt werden. Dies würde das Entwicklungs-Scrum-Team noch mehr entlasten, aber es erfordert ein dediziertes Team, um solche automatisierten Tests zu entwickeln und zu pflegen. Es würde zu einer ständigen Arbeit werden, da bei jeder Änderung des Produktionscodes einige vorhandene automatisierte Tests ungültig werden können und daher aktualisiert werden müssen, um in den Pipelines weiterzuarbeiten. Es ist ein Aufwand, den nur wenige zu zahlen bereit sind, der Nutzen für das Dev-Scrum-Team wäre jedoch groß.
Das sind Themen, die weit über den Rahmen dieses Artikels hinausgehen und den richtigen Zeitplan und das richtige Timing für jeden hier erwähnten Testtyp herausfinden – damit Sie es innerhalb eines Sprint-Fensters schaffen. Beim nächsten Mal tauche ich gerne ein!