Qualitätsmuster 2: Automatisieren Sie Ihre Akzeptanztests

Willkommen zu meinem zweiten Blog in der Serie über fünf Qualitätsmuster in der agilen Entwicklung, die Ihnen helfen können, die richtige Software mit hoher Qualität zu liefern. In meinem letzten Blog habe ich das Example Mapping als Methode vorgestellt, mit der Sie zu konkreten Beispielen für Szenarien oder Regeln gelangen, aus denen Ihre User Story besteht. Das Ergebnis der Verfeinerungssitzungen sind Ihre Anforderungen und damit Ihre Tests. In diesem Blog werden wir einen weiteren Blick auf diese Testfälle werfen und darauf, warum es wichtig ist, diese Akzeptanztests zu automatisieren. Nicht nur aus der Sicht des Entwicklungsteams, sondern auch, was sie Ihrem Unternehmen bringen können.

Der perfekte Entwicklungsprozess

Falls Sie es noch nicht getan haben, empfehle ich Ihnen dringend das Buch "How Google Tests Software" von James A. Whittaker, Jason Arbon und Jeff Carollo.

"Stellen Sie sich einen Moment lang den perfekten Entwicklungsprozess vor. Er würde mit dem Testen beginnen. Bevor auch nur eine einzige Zeile Code geschrieben wird, würde ein Entwickler darüber nachdenken, wie er ihn testen kann. Er wird Tests für Grenzfälle schreiben, für zu große und zu kleine Datenwerte, für Werte, die Schleifen über ihre Grenzen bringen würden, und für eine Unzahl anderer Probleme. Einige dieser Tests werden Teil der Funktionen sein, die sie schreibt, selbsttestender Code oder Unit-Tests. Für diese Art von Tests ist die Person, die den Code schreibt und ihn am besten versteht, auch am besten geeignet, ihn zu testen.

-- James A. Whittaker, Jason Arbon & Jeff Carollo. "Wie Google Software testet".

Es ist ziemlich klar. In einem perfekten Entwicklungsprozess beginnen die Tests bereits am Anfang des Prozesses. Dieser perfekte Entwicklungsprozess ist schwer zu erreichen, aber es ist durchaus möglich, bei allem, was Sie tun, von Anfang an an Tests zu denken.

Wir brauchen also einen Tester?

In dem Buch wird argumentiert, dass Sie an diesem Punkt einen Tester brauchen.

"Dies ist der erste Punkt, an dem ein perfekter Entwicklungsprozess einen Tester erfordert. Beim Schreiben von Funktionscode und beim Schreiben von Testcode gibt es unterschiedliche Denkweisen. Es ist notwendig, zwischen einem Feature-Entwickler und einem Test-Entwickler zu unterscheiden. Bei Funktionscode geht es um die Erstellung und Berücksichtigung von Benutzern, Anwendungsfällen und Arbeitsabläufen. Beim Testcode geht es darum, den Code zu brechen und zu schreiben, um Fälle zu finden, die den Benutzer und seinen Arbeitsablauf stören."

-- James A. Whittaker, Jason Arbon & Jeff Carollo. "Wie Google Software testet".

Es stimmt zwar, dass wir Menschen mit unterschiedlichen Fähigkeiten, Denkweisen und Schwerpunkten an Bord brauchen, aber das bedeutet nicht, dass dies getrennt geschehen sollte. Wie in meinem letzten Blog erläutert, müssen bei der Abbildung von Beispielen alle Disziplinen durch das Konzept der "drei Amigos" einbezogen werden. Wenn Sie Ihre Verfeinerungen gut durchführen, erhalten Sie detaillierte Testszenarien einschließlich der Boundary Cases.

Strukturierung Ihrer Ausgabe

Das Ergebnis Ihrer Example Mapping-Sitzungen ist eine Wand voller mehrfarbiger Klebezettel. Dieses Medium eignet sich sehr gut für die Erstellung von Regeln und Beispielen. Es ist eine sehr visuelle Art, User Stories zu schreiben. Aber um diesen Output als Input für die Entwicklung, das Testen und die spätere Dokumentation zu verwenden, müssen wir ihn digitalisieren.

Der erste Schritt kann einfach darin bestehen, ein Foto zu machen, damit jemand es später digitalisieren kann. Wechseln Sie die Person, die diese Aufgabe übernimmt. Wenn Sie die Ausgabe in ein System eingeben, müssen Sie die Lesbarkeit im Auge behalten. Die Struktur ist extrem wichtig. Ein Format zur Dokumentation Ihrer Szenarien ist Gherkin.

Die Gherkin-Syntax ist eine Reihe von Schlüsselwörtern, die ausführbare Spezifikationen strukturieren können. Wir nennen die Spezifikationen ausführbar, da es Tools wie Cucumber gibt, die diese Spezifikationen automatisieren können. Jede Spezifikation mit Beispielen führt daher direkt zu funktionalen Testfällen.

Gegeben Wenn Dann

Die wichtigsten in der Gherkin-Syntax verwendeten Schlüsselwörter sind Given, When, Then (GWT). Der Vorteil dieser Syntax ist, dass sie ein für den Menschen lesbares Format erzeugt, das jedes Mal gleich verwendet wird. Wie bei unserer Beispiel-Mapping-Ausgabe hilft dies, ein gemeinsames Verständnis zu schaffen.

Lassen Sie uns noch einmal auf unsere Geschichte "Wechselgeld aus einem Süßigkeitenautomaten erhalten" zurückkommen, die wir im ersten Blog verwendet haben.

Das Aufschreiben einer Regel als ausführbare Spezifikation könnte so aussehen:

Benutzergeschichte: Entgegennahme von Wechselgeld
Spezifikation: Das Wechselgeld soll in der geringsten Anzahl von Münzen zurückgegeben werden

Gegeben	von
Wenn	wird in den Süßigkeitenautomaten eingesetzt
Dann	das Wechselgeld ist Münze(n)

Beispiele:

Betrag	Süßigkeiten	Preis	Betrag_eingesetzt	Anzahl_Münzen	typ_münze
1	Mars	€1,50	€2,-	1	€0,50
1	Snickers	€1,60	€2,-	2	€0,20

Anmerkung:

• Regeln können eins-zu-eins in Spezifikationen übersetzt werden.
  Specification by Example arbeitet auf der Grundlage von Spezifikationen, wobei Example Mapping Geschichten in kleine und eindeutige Regeln aufspaltet. Diese Regeln sind das gleiche Konzept wie die Spezifikationen.
• Beginnen Sie nicht mit dem Schreiben im GWT-Format. Formatieren Sie Ihre Geschichten erst nach der Verfeinerung. Wenn Sie mit dem GWT-Format beginnen, besteht die Gefahr, dass Sie in die Falle tappen und die GWT-Szenarien zum Ziel machen. Die Konversation bei der Erstellung der Szenarien ist viel wichtiger als das Format. Die Formatierung direkt in GWT-Szenarien schränkt diese Konversation ein.

Automatisieren Sie, oder automatisieren Sie nicht

Im letzten Blog habe ich gesagt: "Sorgen Sie dafür, dass Sie diese Szenarien und Beispiele automatisieren. Alle, ohne Ausnahme." Das ist zwar ein gutes Ziel, aber machen Sie es nicht zu Ihrer ersten Handlung! Bei guten Tests geht es darum, sicherzustellen, dass Sie gute Spezifikationen schreiben. Die Einbettung von Specification by Example mit Example Mapping in Ihren Verfeinerungsprozess ist wichtiger als die Automatisierung der Spezifikationen.

Wenn Sie diese jedoch nicht automatisieren, bringen Sie sich in eine schwierige Lage. Wenn Sie Ihre Anwendung häufiger veröffentlichen und die Tests kontinuierlich durchführen, wird das sehr schwierig und zeitaufwändig. Vor allem, wenn Ihre Anwendung wächst. Beim Testen geht es darum, schnelles Feedback zu erhalten. Je früher Sie Ihre Spezifikationen besprechen und je früher Sie Ihre Tests durchführen, desto schneller wissen Sie, ob Sie auf dem richtigen Weg sind.

Das Schöne an ausführbaren Spezifikationen ist, dass es mehrere Tools gibt, die Ihnen helfen, Ihren Testcode mit Ihrem Anwendungscode zu verbinden. Dies geschieht in Form von Schrittdefinitionen. Schrittdefinitionen bilden den "Klebecode" zwischen Ihren Tests und Ihrer Anwendung.

Bitte beachten Sie, dass Sie diese Art von Tooling nicht verwenden müssen. Ich habe schon viele Spezifikationen automatisiert, ohne die ausführbaren Spezifikationen zu verwenden, um die Tests wirklich zu steuern. Angenommen, Sie haben eine moderne Webanwendung und möchten Cypress.io für die Testautomatisierung verwenden, dann haben Sie zwei Möglichkeiten. Entweder Sie verwenden das BDD-Plugin, oder Sie erstellen eine .spec-Datei pro Spezifikation, in die Sie das GWT-Szenario und die Beispiele als Kommentar am Anfang der Datei einfügen. Auf diese Weise ist sofort klar, was der Test zu erreichen versucht, und Sie halten den Test klein und beschränken ihn auf eine Spezifikation.

Nächste Schritte

Nachdem Sie nun Ihre Tests automatisiert haben, ist es Zeit für den nächsten Schritt.
Automatisieren Sie Ihren Build- und Release-Prozess. Im nächsten Blog werde ich Ihnen erklären, warum das so ist, wie Sie das erreichen können und worauf Sie achten müssen. Bis zum nächsten Mal!

Ich bin ein Spezialist bei Qxperts. Wir unterstützen Unternehmen dabei, zuverlässige und hochwertige Software zu entwickeln. Haben Sie Fragen? Wir sind für Sie da! www.qxperts.io