Das Herzstück von Scrum ist ein Sprint, eine Zeitspanne von einem Monat oder weniger, in der ein "fertiges", brauchbares und potenziell releasefähiges Produktinkrement erstellt wird.
Warum also nicht jeden Sprint veröffentlichen?
Häufiger zu veröffentlichen ist leichter gesagt als getan. Die Häufigkeit der Veröffentlichung eines Produkts hängt davon ab, wie lange es dauert, es zu testen . Eine Codezeile zu ändern ist einfach. Das Testen dieser Änderung ist viel schwieriger. Und es ist normalerweise eine schlechte Idee, ungetestete Software zu veröffentlichen.
Die Implementierung der Testautomatisierung in einer bestehenden Codebasis kann sehr aufwändig sein. Es wird nicht nur der Code geändert, sondern auch die Arbeitsweise. Wo fangen wir also an?
Wissen, warum man automatisieren sollte!
In einem Wasserfallprojekt geht es beim Testen darum, neues Verhalten des Systems zu entdecken und zu validieren, es zu dokumentieren und die Korrektheit dieses Verhaltens zu beurteilen.
Das Entwerfen eines Systems in einem Wasserfallprojekt nimmt viel Zeit in Anspruch. Zunächst wird ein funktionaler Entwurf erstellt, dann benötigen Sie einen detaillierten technischen Entwurf. Ein solcher Prozess kann Wochen oder Monate dauern. Dann dauert es Monate, das System zu bauen. Das führt dazu, dass nach Abschluss der Build-Phase viele neue Verhaltensweisen in die Software eingeführt werden. Danach muss das beabsichtigte Verhalten validiert werden. Das bedeutet, dass eine Menge Überprüfungen und Sondierungstests durchgeführt werden müssen, und auch das ist ein zeitaufwändiger Prozess.
In einem agilen Projekt sieht der Entwicklungsprozess ziemlich gleich aus. Sie müssen immer noch entwerfen, was Sie bauen wollen. (Agiles Vorgehen ist keine Entschuldigung dafür, die Entwurfsphase auszulassen.) Der nächste Schritt? Bauen und testen Sie es. Der Unterschied zwischen Agile und Waterfall besteht darin, dass bei einem agilen Prozess der gesamte Prozess in wenigen Tagen statt in Monaten abgeschlossen ist und kontinuierlich wiederholt wird.
In neueren Versionen wird deutlich weniger neues Verhalten eingeführt, und das erfordert eine andere Art des Testens. Es müssen weniger Erkundungstests durchgeführt werden und es muss mehr validiert werden, um sicherzustellen, dass kein bestehendes Verhalten unbeabsichtigt geändert wurde. Dasselbe immer und immer wieder zu validieren, kostet zu viel Zeit und nimmt dem Spiel den Spaß.
Wissen, welche Tests Sie automatisieren müssen!
Identifizieren Sie triviale Prüfungen, die immer wieder durchgeführt werden, und beginnen Sie damit, diese zu automatisieren. Wenn Sie viele Dinge in kurzer Zeit manuell überprüfen, bleibt nur wenig Zeit für echte Sondierungstests. Die Automatisierung trivialer Prüfungen verschafft den Testern Zeit für das, was sie am besten können. Sie finden alle möglichen brillanten Szenarien, die Sie sich nie hätten vorstellen können.
Finden Sie die wichtigsten zu automatisierenden Testfälle, indem Sie die Häufigkeit der Freigabe (Bit für Bit) erhöhen.
Eine falsch durchgeführte Testautomatisierung kann zu einer längeren Markteinführungszeit führen. Behalten Sie das Ziel im Auge: Testautomatisierung ist kein Ziel. Genauso wenig wie die Abdeckung. Es geht darum, wertvolle neue Funktionen schneller an den Kunden zu liefern!
Das Definieren (und Ausführen) der richtigen Testfälle ist der Schlüssel zu hochwertiger Software. Ihre Automatisierung ist nur eine Möglichkeit, die Ausführungszeit zu verkürzen. Testautomatisierung ist nur ein Werkzeug. Das gilt auch für Unit-Tests. Welches Werkzeug und wie es eingesetzt wird, hängt von dem jeweiligen Problem ab. Wenn Sie die Anwendung häufiger ausliefern, können Sie die Dinge, die automatisch getestet werden müssen, zuerst bestimmen.
Finden Sie heraus, wie Sie Tests auf kosteneffiziente Weise automatisieren können.
Verschwenden Sie nicht viel Zeit mit der Entwicklung von Testautomatisierungen, die keine Fehler finden. Verwenden Sie stattdessen nur wenig Zeit auf einen (oder wenige), die es tun.
Einige Teile der Software werden häufig geändert. Andere werden nur selten angefasst. Folglich werden einige Dinge nie geprüft, andere dagegen ständig. Verwenden Sie diese Formel, um festzustellen, ob es sinnvoll ist, einen Test zu automatisieren:
(C * T$) > (B + M$)= Automatisieren Sie den Test!!!
C = Zeiten, in denen sich die zu testende Einheit ändert T$ = Kosten für das Testen der zu testenden Einheit, manuell B = Zeitaufwand für die Erstellung der Testautomatisierung. M$ = Wartungskosten für diesen Testansatz (wenn sich der Code ändert)
Versuchen Sie, so viele Tests wie möglich zu automatisieren. Wenn die Formel zeigt, dass die Testautomatisierung zu teuer ist, überlegen Sie sich eine billigere Möglichkeit, diesen Test zu automatisieren!
Wissen, wie Sie Tests automatisieren können!
Testautomatisierung ist kein Ziel. Die schnellere Lieferung von Werten schon! Das ist leichter gesagt als getan. Eine hohe Frequenz erfordert eine andere Arbeitsweise. Das bringt eine Reihe von unterschiedlichen Ansätzen, Praktiken und Tools mit sich.
Verschiedene Testfälle erfordern verschiedene Arten von Tests. Das Unit-Testing ist eine bekannte Methode zur Testautomatisierung. Aber Unit-Tests allein reichen nicht aus. Sie müssen viel mehr Testautomatisierungstechniken anwenden. Kombinieren Sie verschiedene Testarten, um eine effektive Testautomatisierungsstrategie zu erhalten .
Automatisierte Tests sind nutzlos, wenn sie nicht ausgeführt werden. Und je schneller ein Fehler entdeckt wird, desto einfacher ist es, ihn zu beheben. Führen Sie die automatisierten Tests so schnell wie möglich aus und installieren Sie die Software automatisch in einer Umgebung, wenn die Tests erfolgreich sind.
Durch die Anwendung eines Software-Engineering-Ansatzes namens "Continuous Delivery" können Sie innerhalb von Minuten stabile, kleine Inkremente Ihrer Software sicher in die Produktion einbringen.
Die Bereitstellung von Software, die oft eine automatisierte Installation erfordert. Dies geschieht in der Regel durch die Verwendung von
Kommunizieren Sie die Spezifikationen der neuen Funktionen an die Beteiligten. Verwenden Sie das Example Mapping, um die Spezifikationen im Verfeinerungsprozess zu finden, und schreiben Sie sie in der Gherkin-Syntax auf. So kann das Team eine 'lebende Dokumentation' erstellen : Eine Dokumentation, die ein automatischer Test ist.
Kommunizieren Sie über neue Spezifikationen , bevor sie erstellt werden, und validieren Sie sie so früh wie möglich. Nutzen Sie die verhaltensgesteuerte Entwicklung, um diese Spezifikationen zu implementieren.
Da Sie ständig neue Versionen herausbringen, muss die Software jederzeit lieferbar sein. Das bedeutet, dass Sie kleine, brauchbare Inkremente benötigen. Verwenden Sie Elephant Carpaccio, um die kleinstmöglichen, nicht-technischen User Stories zu definieren, die einen geschäftlichen Wert haben.
Vereinfachen Sie!
Je weniger Teams für die Erstellung oder Änderung von Funktionen benötigt werden und je weniger Systeme geändert werden müssen, um neue Funktionen zu erstellen, desto schneller schaffen Sie geschäftlichen Mehrwert und desto einfacher wird es, Funktionen automatisch zu testen und eigenständig zu liefern. Wollen Sie eine kürzere Markteinführungszeit? Entwerfen Sie dafür!
Je mehr Systeme modifiziert werden müssen, um Funktionen zu erstellen oder zu ändern, desto schwieriger wird es, Funktionen zu erstellen oder zu ändern. Alle Teams, die an diesen Systemen arbeiten, müssen die neuen Anforderungen vollständig verstehen und jemand muss die Funktion insgesamt testen, wenn alle Teams mit der Umsetzung ihres Teils fertig sind. Das erfordert Koordination.
Wenn Testbarkeit bisher kein architektonischer Faktor in Ihrer Codebasis war, ist es wahrscheinlich, dass große Teile des Codes schwer zu testen sind und - da diese Teile wahrscheinlich schon vor langer Zeit entwickelt wurden - ist es wahrscheinlich unklar, was die Anforderungen an diese Teile der Software überhaupt waren. Sie müssen einen Kettentest durchführen, um zu überprüfen, ob der Code noch funktioniert. Dies geschieht in der Regel durch einen End-to-End-Test, der bekanntermaßen teuer, unzuverlässig und langsam ist.
Gehen Sie zu unabhängigen Feature-Teams über und entwickeln Sie eine (Unternehmens-)Architektur, die leicht zu testen und freizugeben ist. Testbarkeit ist eine architektonische Triebkraft. Denken Sie sorgfältig darüber nach, wie Sie Ihre Funktionalität erstellen und testen können, bevor Sie sich überhaupt an die Tastatur setzen, um Code zu schreiben. Berücksichtigen Sie die Testbarkeit (auch auf Unternehmensebene). Die Umstellung von Software und Teams kann die Zeit bis zur Markteinführung verkürzen!