Technische Schulden. Sie bringen Funktionen schneller zum Laufen, indem Sie im Quellcode Abkürzungen nehmen. Das hat zur Folge, dass künftige Funktionen schwieriger zu erstellen sind, weil der Quellcode komplexer geworden ist.
Das Gleiche gilt für das Testen. Ein Mangel an automatisierten Tests verlangsamt ein Team und macht die Veröffentlichung von Software komplizierter. Vor allem, wenn Sie gerade erst mit Continuous Delivery beginnen, gibt es nur wenige Testautomatisierungen, wenn überhaupt. Alles auf einmal zu beheben, ist zu viel Arbeit. Wie können Sie also damit umgehen?
Test-Schuld
Technische Schulden verlangsamen schließlich ein Team. Das Gleiche gilt für das Fehlen von automatisierten Akzeptanztests. Das Fehlen eines automatisierten Akzeptanztests für eine neue Funktion bedeutet manuelle Arbeit und ein höheres Risiko, dass in der Produktion etwas schief geht.
Wenn Sie zu häufigen, automatisierten Implementierungen übergehen, ist die Testautomatisierung genau das Richtige für Sie. Sie beschleunigt die Bereitstellung der Software ohne das Risiko von Qualitätsverlusten.
Die Installation von Software auf einer Website wird nicht häufig in einem Wasserfallprojekt durchgeführt. Die Automatisierung des Installations- und Testprozesses zahlt sich wahrscheinlich nicht aus.
Eine höhere Veröffentlichungshäufigkeit ändert nichts an der Anzahl der Dinge, die Sie vor dem Livegang validieren müssen. Ohne jegliche Testautomatisierung wird der Testprozess genauso lange dauern wie bisher. Das Testen wird der Engpass im Prozess bleiben. Sie haben also die Wahl, entweder mehr Tester einzustellen oder die von ihnen durchgeführten Validierungen zu automatisieren. Sie haben einige Test-Schulden zu begleichen.
Planen Sie es?
Es scheint naheliegend, eine Benutzergeschichte zu erstellen, sie zu planen und mit der Entwicklung einer Testautomatisierung zu beginnen. Nehmen Sie sich ein oder zwei Sprints und fertig. Aber das ändert nur die Code-Basis. Und eine Code-Basis ist ein Spiegelbild der Denkweise. Ändern Sie die Denkweise und Sie werden die Codebasis ändern. Wenn Sie das nicht tun, wird sich Ihr Code wieder ändern.
Das Automatisieren von Tests ist eine Lernerfahrung. Genau wie das Programmieren. Und jede Code-Basis ist anders. Jeder Bereich ist anders. Es braucht Zeit, um herauszufinden, was getestet werden soll und wie es getestet werden soll. Es braucht ein paar Versuche, um es richtig zu machen.
Mit anderen Worten: Ändern Sie den Prozess und die Menschen, nicht den Code. Der Code ist ein Nebeneffekt. Ändern Sie Ihre Einstellung dahingehend, dass Sie von nun an automatisierte Akzeptanztests für jede User Story durchführen. Die Abdeckung wird folgen.
"Softwareentwicklung ist ein Lernprozess, funktionierender Code ist ein Nebeneffekt." - Alberto Brandolini
Liefern Sie weiterhin Wertsteigerungen
Ich habe selten einen Produktverantwortlichen getroffen, der bereit war, die Art von Benutzergeschichten, die rein technisch sind, mit nur einem einzigen Stakeholder zu planen: Das Entwicklungsteam.
Stellen Sie sich das vor. Stellen Sie sich vor, Sie beauftragen einen Klempner mit der Reparatur der Küchensynchronisation und bitten ihn, den Arbeitsaufwand zu schätzen. Der Abfluss ist überschwemmt und Sie müssen jede Stunde wischen. Stellen Sie sich vor, der Klempner will sich erst einmal eine Woche Zeit nehmen, um alles Mögliche an Werkzeugen vorzubereiten. Denn er ist sich sicher, dass er sie in Zukunft brauchen wird. Ich würde einen anderen Klempner beauftragen.
Einige Produktverantwortliche sind bereit, etwas Zeit auf technische Verbesserungen zu verwenden. Aber die Stakeholder haben oft das Gefühl, dass es dringendere Dinge gibt, für die sie Entwicklungszeit aufwenden müssen. Aber dem Produktverantwortlichen sollte es egal sein, wie getestet wird, er sollte sich darum kümmern, was getestet wird. Die Wahl der geeigneten Testmethode ist Sache des Teams. Wenn Sie also für jede Story ein paar Tests automatisieren, wird das Team weiterhin Geschäftswert liefern und die Testsuite wird organisch wachsen.
Beginnen Sie von außen nach innen
Die Testautomatisierung sollte den Prozess beschleunigen, nicht verlangsamen. Ja, Sie brauchen Unit-Tests. Sie sind wichtig. Aber sind sie das Wichtigste, was Sie brauchen? Ihr Umfang ist gering. Oft lässt sich anhand der Unit-Tests nur schwer feststellen, ob die Software mit allen Geschäftsregeln der automatisierten Prozesse übereinstimmt oder nicht.
1.) Automatisieren Sie zuerst die Akzeptanztests
Testen wird durchgeführt, um das Verhalten der Software zu entdecken und zu beschreiben. Sie werden durchgeführt, um das Hinzufügen von Funktionen oder das Refactoring zu ermöglichen. Beim Testen werden Informationen gesammelt, um die Entscheidung zu unterstützen, ob die Software in Betrieb genommen werden soll oder nicht.
Das Schreiben einer Reihe von Tests, die sicherstellen, dass eine Klasse ArgumentNullExceptions auslöst, wird diese Entscheidung nicht unterstützen. Tests sind nützlich, wenn sie Informationen liefern, nicht Daten.
Automatisieren Sie Prozesse, um Abläufe zu beschleunigen und menschliche Fehler zu vermeiden. Manuelle Akzeptanztests könnten einer dieser Prozesse sein. Ein Akzeptanztest, der auf API-Ebene implementiert wird, ermöglicht dem Team eine Umstrukturierung. Er liefert Informationen über das Verhalten der Anwendung und es ist ein manueller Prozess weniger, der durchgeführt werden muss.
2.) Verwenden Sie die Testautomatisierung, um Produktionsprobleme zu reproduzieren und zu beheben.
Produktionsprobleme treten auf, wenn Dinge passieren, die während des Entwicklungsprozesses nicht vorhergesehen wurden. Irgendeine seltsame Kombination von Mutationen oder Eingaben könnte das System zum Absturz gebracht haben.
Das Reproduzieren von Produktionsproblemen erfolgt häufig durch das Einfügen von Daten in ein System und die Durchführung einer Prüfung des Ergebnisses. Normalerweise gibt der Tester Benutzereingaben ein und fügt Daten in eine Datenbank oder ein externes System ein, um das Problem zu reproduzieren.
Bugs sind (vergessene) Akzeptanzkriterien, die nicht erfüllt werden. Jeder Fehler ist ein Testfall. Er ist der fehlende Teil Ihres Regressionssets. Wenn Sie ihn automatisieren, vervollständigen Sie die Testsuite, können ihn leichter reproduzieren und beheben und verhindern, dass er jemals wieder auftritt.
Vertrauen gewinnen
Unterschätzen Sie nicht, wie schwer es ist, eine Testsuite zu erstellen, die vertrauenswürdig ist. Gehen Sie nicht davon aus, dass Ihre ersten automatisierten Tests gut sind. Es ist eine Lernerfahrung, es richtig zu machen. Führen Sie eine Zeit lang manuelle Tests durch und korrigieren Sie Tests, die falsch-positive Ergebnisse liefern, bis Sie ihnen genug vertrauen.
Refactor
Manche sagen, die testgetriebene Entwicklung sei eine Software-Design-Methode, keine Test-Methode. Es ist ein guter Prozess, um eine sauberere Code-Basis zu erhalten. Es ist ein guter Weg, um eine solide Basisschicht von Fowlers Testpyramide zu erhalten.
Codebasen von Anwendungen, die nicht für die Unterstützung automatisierter Tests konzipiert wurden, können schwer zu testen sein. Testbarkeit ist ein architektonischer Aspekt einer Anwendung. Die ersten holistischen Akzeptanztests, die repräsentativ genug sind, sind in vielen Fällen zu langsam. Verwenden Sie Akzeptanztests und Unit-Tests, um die Code-Basis sicher zu refaktorieren, damit sie besser testbar ist.
Zusammenfassung
Code-Basen von Produkten, die jährlich veröffentlicht werden, haben wahrscheinlich keine automatisierten Tests. Aber Sie brauchen sie, wenn Sie kontinuierlich und häufig liefern wollen.
Wenn Sie Menschen und Prozesse ändern, ändert sich auch die Code-Basis. Ändern Sie die Codebasis, ohne die Menschen zu ändern, dann wird sie sich auch wieder ändern.
Automatisieren Sie zuerst die Akzeptanztests. Sie liefern dem Team und den Interessengruppen genügend Informationen, um zu entscheiden, ob Sie das Projekt in Betrieb nehmen wollen oder nicht. Vertrauen Sie nicht blind auf die Testautomatisierung. Testen Sie auch weiterhin manuell. Reparieren Sie Tests, die falsch-positive Ergebnisse liefern.
Beginnen Sie mit der testgesteuerten Entwicklung, um eine angemessene Anzahl von Unit-Tests zu erhalten. Zu Beginn könnten die Tests langsam sein. Das liegt auf der Hand, wenn die Softwarearchitektur die Testautomatisierung nicht unterstützt. Machen Sie sich darüber keine Sorgen. Sobald die Tests vertrauenswürdig genug sind, können Sie sie getrost überarbeiten.
Contact