Testen und Scheitern auf dem Weg zur Softwarequalität in der Cloud

Die überraschende Wahrheit über den Erfolg (und warum manche Menschen nie aus ihren Fehlern lernen) ist, dass er alles mit dem Scheitern zu tun hat. Scheitern ist nicht das Gegenteil von Erfolg, es ist ein wesentlicher Bestandteil des Erfolgs. Durch Scheitern in einer kontrollierten und getesteten Umgebung können wir lernen und uns verbessern - ein Kernprinzip der kontinuierlichen Bereitstellung. Cloud-native Technologie beschleunigt den Entwicklungszyklus, so dass wir früher und schneller scheitern können. Aber Unternehmen müssen auch die Qualität aufrechterhalten, die Geschwindigkeit erhöhen und die Art und Weise ändern, wie sie ihre Software entwerfen und bereitstellen, um die volle Wirkung der Cloud zu erzielen. Dieser Artikel erklärt, wie Sie diese drei Punkte umsetzen können.

Abnahmeprüfung

Wenn das Scheitern ein wesentlicher Bestandteil des Erfolgs ist, dann ist das Testen der wichtigste Teil der Softwareentwicklung, insbesondere das Akzeptanztesten. Akzeptanztests schließen nicht nur die Feedbackschleife in der Kommunikation zwischen Unternehmen und IT, sondern stellen auch sicher, dass der Code "in einer produktionsähnlichen Testumgebung das tut, was das Unternehmen will", wie Dave Farley es ausdrückt. Sie können auch als "Definition von fertig" und "Definition von erledigt" verwendet werden, so dass Akzeptanztests unabhängig vom Anwendungsstapel anwendbar sind.

NN Investment Partners (NNIP) hat vor kurzem mit der Implementierung von Cloud-Native-Technologie begonnen und einige Erfolge bei der Erstellung von Cloud-Native-Serverless-Anwendungen erzielt. Sie haben vorher ihre Hausaufgaben gemacht, Blogs gelesen, Konferenzen besucht und an Cloud-spezifischen Treffen teilgenommen. Dies sind alles großartige Quellen, um sich mit den vielen Vorteilen der Cloud vertraut zu machen. Leider wird in diesen Quellen nur selten über Akzeptanztests gesprochen, so dass es unwahrscheinlich ist, dass diese angewendet werden, wenn die Technologien anschließend in die Praxis umgesetzt werden.

NNIP wusste, dass sie irgendwann Probleme haben würden, ihre Geschwindigkeit aufrechtzuerhalten. Dass sich das Team dieser Probleme im Voraus bewusst war, spielte eine entscheidende Rolle für den Erfolg.

Einführung von automatisierten Akzeptanztests in der Organisation

Softwareingenieure sind die einzigen, die Akzeptanztests brechen können. Es liegt also auf der Hand, dass sie auch für diese Tests verantwortlich sein sollten. In den meisten Unternehmen bedeutet dies einen Kulturwandel, aber es ist auch unerlässlich, damit Continuous Delivery und DevOps funktionieren. Unternehmen müssen Softwareingenieure in die Lage versetzen, Verantwortung zu übernehmen, indem sie ihnen die Möglichkeit geben, isolierte produktionsähnliche Umgebungen zu schaffen, in denen sie ihre Software testen können. Wenn ein Unternehmen bereits ein separates Team für die Stabilität der Infrastruktur verantwortlich gemacht hat, fällt es ihm oft schwer, Softwareingenieuren die Verantwortung für das Testen ihrer eigenen Software zu übertragen. Diese Schwierigkeit, zwischen den beiden Bereichen zu wechseln, führt oft dazu, dass sich die Ingenieure auf das Testen und Experimentieren konzentrieren, während das Infra-Team auf die Stabilität fokussiert bleibt, was zu einer Kollision der Ziele führt, was wiederum den Prozess verlangsamt.

Mit der nativen Cloud-Technologie können Teams isolierte, produktionsähnliche Umgebungen problemlos selbst konfigurieren und erstellen. Diese Konfiguration kann in verschiedenen Phasen des Entwicklungsprozesses wiederverwendet werden, von der lokalen Erstellung von Anwendungen über die Durchführung von Akzeptanztests in einer Continuous Delivery Pipeline bis hin zur Bereitstellung in der Produktion. Einmal eingerichtet, können Softwareingenieure jede Änderung an der Software schneller testen, ohne auf andere Teams angewiesen zu sein.

Diese neue Arbeitsweise erforderte eine neue Art der Kommunikation. Die Ingenieure waren es nicht gewohnt, die geschäftsspezifische (Domänen-)Sprache zu verwenden, um Anforderungen zu erstellen und zu testen, denn das war traditionell die Aufgabe der Geschäftsanalysten und des QA-Teams.

Während sich das Unternehmen also in erster Linie darum kümmerte, ob der Kunde die richtigen Informationen sehen konnte, fragten sich die Techniker, ob die API die richtigen Daten in der dynamoDB oder einem anderen Technologietool, von dem das Unternehmen noch nie etwas gehört hatte, abrufen konnte. Dies führte zu Missverständnissen und Unverständnis zwischen den verschiedenen Abteilungen.

Neue Arbeitsweisen einführen

Was wir brauchen, ist eine gemeinsame Denkweise oder eine allgegenwärtige Sprache, mit der wir sicher kommunizieren können. Die verhaltensgesteuerte Entwicklung (Behaviour Driven Development, BDD), auch bekannt als ATDD, Spezifikation nach Beispielen und ausführbare Spezifikationen, wurde geschaffen, um diese Lücke zu schließen. Lernen (und damit Scheitern) ist hier der Schlüssel. Softwareentwicklung ist ein Lernprozess; funktionierender Code ist ein Nebeneffekt.

Aus diesem Grund war das erste, was wir als Xebia bei NNIP getan haben, die Art und Weise zu ändern, wie Verfeinerungen durchgeführt wurden. Die meisten Verfeinerungen unterliegen dem "Straßenlaternen-Effekt", einer Form der Verzerrung durch Beobachtung, bei der wir nur die positiven Ergebnisse oder die einfachsten Ergebnisse sehen. Wir wollen so viel wie möglich herausfinden, bevor wir mit einer bestimmten User Story in einen Sprint gehen. Wenn wir während eines Sprints neue Anforderungen entdecken, können wir ihn nicht abschließen, was die Geschwindigkeit verringert. Schlimmer noch, wir bauen Software, die voller Fehler ist, also von geringerer Qualität.

In seinem Buch Specifications by Example beschreibt Gojko Adzic mehrere Methoden, mit denen Sie den Laterneneffekt bekämpfen können. Eine Methode besteht darin, Input und Output in konkreten Beispielen (oder Szenarien) zu beschreiben, da das menschliche Gehirn abstrakte Anforderungen auf diese Weise viel besser erfassen kann.

Der nächste Schritt besteht darin, diese Beispiele in Form von Gherkin-Skripten (Funktionsdateien) zu formalisieren. Diese Skripte bilden die Grundlage für unsere automatisierten (Abnahme-)Tests und vermitteln den Ingenieuren das praktische Wissen, wie man das Richtige baut. Die Skripte liefern die Definition von "fertig". Ohne die Skripte können wir nicht mit der Erstellung von Funktionen beginnen.

Schlussbemerkung

Zusammenfassend lässt sich sagen, dass die Cloud-native Technologie Unternehmen die Möglichkeit gibt, sich schneller in Richtung DevOps und Continuous Delivery zu bewegen. Es entstehen agile Teams, die alle Funktionen umfassen, die für die schnelle Erstellung und Ausführung von Software, die das Unternehmen benötigt, erforderlich sind.

Cloud Native bringt auch neue Herausforderungen mit sich, z. B. die Notwendigkeit, dass die Ingenieure das Geschäft verstehen und eine allgegenwärtige szenariobasierte Sprache verwenden, um Fehler zu reduzieren und die Codequalität zu verbessern. Andernfalls wird die Leistung der Cloud-Native-Technologie vergeudet.

Dieser Artikel ist Teil des Berichts Urgent Future Cloud - Ein goldenes Zeitalter.

{{cta('7e1bb41c-1580-458d-b3c3-226db4630ad7')}}