Nicht ganz Rugby: Merkmale der Scrum-Methodik
Obwohl der IT-Begriff Scrum aus dem Rugby stammt, sollten Sie ihn nicht für bare Münze nehmen. Während sich Rugbymannschaften in drei Reihen organisieren, die größtenteils das Gleiche tun, spielt jede Person im Softwareteam normalerweise eine einzigartige Rolle mit unterschiedlichen Aufgaben und Verantwortlichkeiten.
Die meisten Merkmale der Agile Scrum-Methodik für Softwaretests stammen aus dem Produktlebenszyklusmanagement (PLM). Sie haben auch darüber hinaus Einfluss, weil Spezialisten aus anderen Teams (unter anderem Finanzprüfer oder unser Inhaltsteam) ebenfalls wichtige Grundsätze übernehmen.
✅ Bei Scrum geht es um inkrementelle und häufige Freigaben. Die Teams arbeiten in Sprints von fester Länge (in der Regel 2 Wochen), die zu neuen Funktionen führen. Einige setzen auf einwöchige Sprints oder noch kürzere
✅ Scrum bringt Flexibilität. Die Softwareentwicklung nach dem Wasserfallmodell beschreibt den Prozess von Anfang bis Ende, wobei sich die Planung über mehrere Monate erstreckt. Es ist schwer, auf potenzielle Verzögerungen oder veränderte Marktbedingungen zu reagieren, wenn man wochenlang mit der Erfüllung einer Anforderung beschäftigt ist, die möglicherweise irrelevant geworden ist.
Im Gegensatz dazu kann Scrum in einer relativ kurzen Zeitspanne angepasst werden. Alle Aufgaben werden in das Backlog aufgenommen, nach Prioritäten geordnet und später in den Umfang eines Sprints aufgenommen. Die Projektleiter erstellen in der Regel einen Plan für den aktuellen Sprint und ein bis zwei weitere Sprints. Das bedeutet, dass ein nicht prioritärer Funktionswunsch in etwa 2 Monaten umgesetzt werden kann, während etwas Dringenderes in ein paar Wochen gezaubert werden kann. Rein nach der agilen Methodik betrachtet, würde Scrum beim Testen keine Änderungen am Arbeitsaufwand des Sprints bedeuten, aber die meisten Teams achten ständig auf ein Gleichgewicht zwischen der Methodik und den geschäftlichen Anforderungen.
✅ Scrum fördert die Teamarbeit. Alle Teammitglieder tauschen sich über ihre Fortschritte aus und äußern sich zu möglichen Hindernissen, während sich die leitenden Mitarbeiter speziell Zeit nehmen, um weniger erfahrenen Kollegen zu helfen.
Das ultimative Ziel, eine schnelle und funktionsreiche Version zu erreichen, erfordert eine gut abgestimmte Zusammenarbeit. Obwohl dies unter dem Wasserfallmodell technisch möglich ist, beinhaltet der Agile Scrum-Testprozess, dass Entwickler Unit-Tests schreiben, damit die Qualitätssicherung einen ausgefeilteren und nicht konzeptionell fehlerhaften Code zum Testen erhält.
✅ Scrum-Zeremonien werden aus praktischen Gründen eingehalten. Bei den täglichen Besprechungen hat jeder die Möglichkeit, sich über Fortschritte und (mögliche) Hindernisse auszutauschen. Sprint-Demos ermöglichen es allen — nicht nur den Ingenieuren —, Fortschritte zu sehen und an einem visualisierten Ziel zu arbeiten. Rückblicke sind eine große Hilfe bei der Verbesserung des Arbeitsablaufs.
Auch die Rollen im Team sind ziemlich synergetisch. Dem Product Owner steht es frei, seine Vision in User Stories umzusetzen. Der Projektmanager liefert eine fundierte Version dieser Vision, indem er die User Story in Aufgaben aufteilt. Manche Teams stellen sogar einen Scrum Master ein, der sich bei agilen Tests oder darüber hinaus an die Scrum-Prinzipien hält.
Wie wir Scrum im aqua Dev Team einsetzen
Wir sind von Scrum auf Kanban umgestiegen, sodass wir jeden Tag und nicht erst am Ende des Sprints/der Iteration veröffentlichen. Eine Funktion wird freigegeben, nachdem sie ein oder zwei Überprüfungen durchlaufen und automatisierte Tests bestanden hat. Es gibt kein Warten auf andere Beteiligte oder einen willkürlichen Grenzwert.
Unser Team wechselte zu Kanban, nachdem es die Aufgaben auf einer Wertstromkartevisualisiert hatte. Sie zeigt an, wie lange es dauert, alle Status zu durchlaufen, bevor eine Aufgabe abgeschlossen ist. Die Ergebnisse waren ziemlich augenöffnend.
Normalerweise würden wir das tun:
-
1Anforderung erstellen (am selben Tag)
-
2Auf den nächsten Sprint warten (bis zu 13 Tage Wartezeit)
-
3Implementierung der User Story (~13 Tage Arbeit, ~7 Tage Wartezeit)
-
4Überprüfung des Codes (weniger als ein Tag Überprüfung, 1 Tag Leerlauf)
-
5QS durchführen (~2 Stunden, 2 Tage Leerlauf)
-
6Auf die vierteljährliche Veröffentlichung warten (bis zu 70 Tage Leerlauf)
Der offensichtliche Engpass bestand darin, von den vierteljährlichen Veröffentlichungen wegzukommen. Das hat je nach Aufgabe bis zu zwei Monate Zeitersparnis gebracht. Der nächste logische Schritt war die Abschaffung der Freigabe am Ende des Sprints. Jetzt liegen wir bei 43 Tagen von der Erstellung einer User Story bis zur Freigabe einer Funktion, was eine Steigerung von ~400 % gegenüber dem Vorjahr bedeutet.
Hauptunterschiede zwischen Agile und Scrum
Technisch gesehen, geht es nicht um Unterschiede. Scrum ist eine evolutionäre Untergruppe von Agile, auch wenn es eigentlich 10 Jahre früher entstanden ist. Was also ist Scrum in der agilen Test- und Entwicklungspraxis?
- Scrum ist praktisch, während Agile philosophisch ist. Obwohl beide darauf abzielen, qualitativ hochwertige Produkte auf flexible Weise zu liefern, sagt das agile Manifest nicht, wie man dies erreichen kann. Alle Scrum-Merkmale sind spirituell agil, werden aber nicht darin erwähnt.
- Scrum legt Teamrollen fest, während Agile rein selbstorganisierend ist. Auch hier geht Agile einen etwas idealistischen Weg, indem es jedem die Möglichkeit gibt, Verantwortung zu übernehmen, aber nicht vorschreibt, was er damit tun soll. Scrum gibt den regulären Teammitgliedern einen gewissen Handlungsspielraum, benennt aber auch Interessengruppen, die das Projekt zum Erfolg führen
- Scrum deckt die Produktentwicklung ab, während Agile das gesamte Unternehmen umfasst. Im Allgemeinen darf das Softwareteam, das nach Scrum arbeitet, die Arbeitsabläufe anderer Abteilungen überhaupt nicht beeinflussen. Andererseits ist die Übernahme der Agile-Philosophie eine Aufgabe für das gesamte Unternehmen
Holen Sie sich eine Vorlage für eine Teststrategie, die es uns ermöglicht, Software 2 Mal so schnell zu veröffentlichen
Gleichzeitig links und rechts gehen: Tipps für Scrum im agilen Testen
Da Sie nun wissen, was die Scrum-Methodik für Softwaretests ist, sollten wir uns einige der besten Praktiken ansehen.
Finden Sie heraus, ob traditionelle Tests besser funktionieren
Der beste Tipp für Ihr agiles Testen könnte der Rückgriff auf regelmäßige Tests sein. Es ist eine viel langsamere, aber auch vorhersehbarere Methode, die es vereinfacht, eine hohe Testabdeckung zu gewährleisten. Werfen Sie einen Blick auf unseren Vergleich von Agiles Testen vs. traditionelles Testen bevor Sie fortfahren.
Pilot und Test
Dan Wilson, ehemaliger Endbenutzer-Direktor bei Hertz, schlägt vor, dass Unternehmen Testregeln auf der Grundlage der Risiken potenzieller Änderungen festlegen.
- Änderungen mit geringem Risiko (unter anderem Aktualisierungen der Funktionen von Verbraucher-Apps und Sicherheits-Patches) werden mit vorherigen Beta-/Insider-Tests und automatisierten Tests eingeführt. Die ringbasierte Bereitstellung wird verwendet, um die Akzeptanz schrittweise zu erhöhen und gleichzeitig Feedback zu nutzen, um ein mögliches Problem zu beheben, bevor zu viele Menschen damit konfrontiert werden
- Änderungen mit mittlerem Risiko erfordern eine Reihe von automatisierten Testskripten, die mit geeigneten Testwerkzeugen ausgeführt werden (wie beispielsweise aqua). Dies kann durch einen QA-Experten oder sogar einen erfahrenen Endbenutzer ersetzt oder ergänzt werden, der dokumentierte Benutzerszenarien durchgeht
- Risikoreiche Änderungen, die zum Absturz von Legacy- oder kritischen Systemen führen können, sollten den gesamten QS-Prozess durchlaufen, einschließlich Regressionstests und Benutzerakzeptanztests (wo relevant)
Dieser Ansatz stellt ein Gleichgewicht zwischen Geschwindigkeit, Qualität und Aufwand her. Wenn etwas an den automatisierten Tests vorbeigegangen ist, sollte es nicht allzu viele Menschen betreffen.
Aufnahme der kontinuierlichen Qualität
Ein anderer prominenter Experte empfiehlt, den Ansatz der kontinuierlichen Qualität aufzugreifen.
„Kontinuierliche Qualität fördert einen ganzheitlichen und proaktiven Ansatz, bei dem funktionale und nichtfunktionale Anforderungen den Entwurf, die Entwicklung und die Lieferung von Produkten bestimmen. Qualität wird für das Unternehmen wahrscheinlich neu definiert, da sie mit seiner digitalen Geschäftsstrategie zusammenhängt. Was einst eine Methode der Kontrolle war, wird immer mehr zum Coaching eines Teams, um Geschäftsziele zu erreichen und einen Wettbewerbsvorteil auf dem Markt durch überlegene Qualität zu erlangen, die anhand von Geschäftszielen und -ergebnissen gemessen wird.“
Auch wir haben uns bereits mit kontinuierlichen Tests beschäftigt. Die 10 Vorteile der Einführung (mehr als „Qualität“ und „Geschwindigkeit“) finden Sie in unserem Blog.
Tests mit Linksverschiebung einführen
Beim Shift-Links-Testing liegt der Schwerpunkt auf der Durchführung von Tests zu einem früheren Zeitpunkt im Lebenszyklus, wobei der Schwerpunkt eher auf Unit-Tests als auf End-to-End- oder UI-Tests liegt. Dazu gehört oft, dass die Entwickler Tests schreiben und ausführen, bevor der Code überhaupt an das QS-Team weitergeleitet wird.
Seit letztem Jahr erstellen unsere Entwickler zwar Tests, aber die sind viel schwerer als die normalen Unit-Tests. In diesem Jahr haben wir ein Tool eingeführt, mit dem wir die Abdeckung der Einheitstests verfolgen und jede Woche um 10 % erhöhen können. Letztendlich erreichten wir den Industriestandard von 80 %, ohne die Zeit für das Schreiben von Code wesentlich zu verlängern.
Jede Nacht bauen wir automatisch die Umgebung auf, um alle Tests durchzuführen und zu sehen, ob die bevorstehende Version ausgeliefert werden kann. Ist dies nicht der Fall, arbeiten die Tester und Entwickler am Morgen daran, Fehler zu beheben und eine neue Version zu veröffentlichen.
Tests mit Rechtsverschiebung einführen
Das Shift-Right-Testing ist ein Test nach der Freigabe in der Produktionsumgebung. Es passt auch gut zu unserer täglichen Freigabestrategie, bei der es zu Änderungen mit unterschiedlichen Risiken und/oder bekannten Fehlern kommen kann. Manchmal können diese bekannten Probleme so schwerwiegend sein, dass die neue Funktion die bestehende Funktionalität beeinträchtigt.
Unsere Freigaben mit „unausgegorener“ Funktionalität verwenden sogenannte „Feature Flags“, die es uns ermöglichen, einen Build mit standardmäßig deaktivierten neuen Funktionen auszuliefern. Sobald das Build ausgeliefert ist, haben wir am nächsten Morgen Zeit, die Tests erneut durchzuführen und Fehler zu beheben. Da sie nun produktionsreif ist, kann diese Funktion für einzelne oder alle Benutzer aktiviert werden, ohne dass wir einen neuen Build veröffentlichen müssen.
Beseitigen von Voreingenommenheit
Gartners Senior Director Analyst Mike West betont den Wert von Blackbox-Tests, um zu vermeiden, dass die Tests dem Code zu ähnlich sind. Obwohl es eine gute Taktik ist, Personen, die mit dem Code nicht vertraut sind, Tests erstellen zu lassen, können Sie noch mehr tun.
„Viele agile Teams gehen in diesem Prozess noch weiter, indem sie den Test schreiben, bevor sie den Code schreiben. Dies verringert das Risiko, dass die eingebetteten QS-Ressourcen beim Testen der Lösung zu nahe an der Implementierung sind — und damit voreingenommen. Durch die Entwicklung des Tests vor der Erstellung des Codes wird der Test zu einer Bestätigung, dass die Implementierung die ursprünglichen Anforderungen erfüllt. Außerdem können so Fehler, die durch Fehlinterpretationen der Anforderungen verursacht werden, frühzeitig erkannt werden, sodass sie leichter behoben werden können.“
Schieben Sie die Abdeckung von Legacy-Code nicht auf
Das Testen von Legacy-Code ist ein großes Problem für Unit-Tests, weil hier die größte Diskrepanz in der Abdeckung zu finden ist. Leider gibt es keine einfache Antwort: Sie müssen alten Code mit qualitativ hochwertigen Unit-Tests abdecken. Sich allein auf End-to-End-Tests zu verlassen, ist nicht machbar: Dies ist sowohl zeitaufwändig als auch teuer.
Die gute Nachricht ist, dass die Abdeckung von Legacy-Code im Laufe der Zeit immer einfacher wird, da das Team mit den Tools zur Verfolgung der Testabdeckung immer vertrauter wird. Wenn Sie bereits seit einiger Zeit die richtigen Unit-Tests durchgeführt haben, werden neue Funktionen nicht mehr viel zum Rückstand beitragen. Das „Licht am Ende des Tunnels“ rückt wirklich Tag für Tag und Woche für Woche näher.
Richten Sie Ihre automatisierten Tests aus
Gute automatisierte Tests haben einen langen Weg vor sich. Wir bei aqua haben uns die Mühe gemacht, über 400 automatisierte Tests so zu stabilisieren, dass es höchstens ein paar Stunden dauert, um einen Fehler oder ein potenzielles Problem mit dem Test zu finden. Von da an wechselten wir zu TestProject für das Schreiben und Ausführen neuer automatisierter Tests, eine sehr nachhaltige und visuelle Lösung für das Testen unserer Anwendung.
Richtig durchgeführte Automatisierung macht im Testmanagement einen großen Unterschied. Dies gilt umso mehr für frühe Tests. Bei aqua dauert ein vollständiger Durchlauf von automatisierten End-to-End-Tests 12 Stunden (manuell wären es Tage gewesen). Alle Einheitstests können jedoch in weniger als 20 Minuten durchgeführt werden.
Verabschiedung von Infrastruktur als Code
Früher haben wir Testumgebungen auf herkömmliche Weise gehandhabt, was eine Menge manueller Arbeit bedeutete, nur um eine einzige konsistente Konfiguration zu erhalten. Dies war mühsam und entsprach nicht unbedingt der Produktionsumgebung. Dieser Ansatz beschränkte auch das QS-Team darauf, in derselben handgefertigten Testumgebung zu arbeiten.
Durch die Einführung von „Infrastructure as Code“ wurde der Arbeitsplan aller Beteiligten erheblich entlastet. Die Testumgebung wird jetzt automatisch bei der Lieferung von neuem Code erstellt. Dieselbe Umgebung kann von mehreren QS-Spezialisten parallel für die Durchführung manueller und automatisierter Tests genutzt werden. Solche automatisch generierten Umgebungen spiegeln praktisch die Produktionsumgebung wider, so dass keine spezielle Nachbildung (Bühnenumgebung) mehr erforderlich ist.
Wechsel zu einer auf Scrum ausgerichteten Testmanagement-Lösung
Leider können selbst die am besten auf Scrum vorbereiteten Teams Schwierigkeiten haben, die Prinzipien zu befolgen, wenn sie durch die falschen Tools behindert werden. Die Verwendung von Excel für Testfälle bringt sicherlich nicht die erforderliche Transparenz und Flexibilität. Sie benötigen ein Softwaretesttool, welches eine der praktischen, von Agile inspirierten Methoden unterstützt.
Noch besser ist es, wenn ein solches Werkzeug auch von Ihrem gesamten Team genutzt werden kann. aqua ALM ist ein solches Werkzeug: Sie können es für alle Schritte der Produktentwicklung nutzen, von der Anforderungserfassung über die Implementierung bis zur Qualitätssicherung.
Schlussfolgerung
Scrum ist die praktische Umsetzung der agilen Philosophie. Die Verwendung des richtigen manuellen oder automatisierten Testwerkzeugs für Agile Tests kann die Freigabezeit für neue Funktionen um bis zu 400 % beschleunigen. Allein durch die Produktentwicklung lassen sich beträchtliche Verbesserungen erzielen, aber der richtige Weg zu Agile ist eine unternehmensweite Anstrengung.
Holen Sie sich das ultimative Tool für Scrum-Tests mit branchenführender KI-Technologie
