A Quick Guide to Implementing ATDD

Dieser Artikel bietet einen kurzen Leitfaden für alle, die ATDD in ihren Teams und Projekten implementieren möchten. Er umreißt die Vorteile dieses agilen Ansatzes auf der Grundlage meiner Erfahrungen aus erster Hand in einem Softwareentwicklungsteam eines Unternehmens.

Zusammenarbeit ist einer der Kernwerte der agilen Methodik. Als ich einmal an einem großen Projekt arbeitete, bemerkte ich einen Mangel an Zusammenarbeit zwischen Entwicklern, Testern und Geschäftsleuten, einen Mangel an Klarheit bei den Anforderungen, eine häufige Ausweitung des Anforderungsumfangs, einen Mangel an Transparenz in Bezug auf die durchgeführten Tests und Mängel, die erst spät im Projektlebenszyklus festgestellt wurden. Am wichtigsten war für mich jedoch, dass niemand eine Ahnung von unserem Automatisierungs-Framework hatte, so dass alle Automatisierungstests geschrieben wurden, nachdem die Funktionen entwickelt und testbereit waren. Aufgrund dieser Beobachtungen begann ich zu recherchieren, wie die Leute diese Art von Problemen angehen. Dabei stieß ich auf Acceptance Test Driven Development (ATDD) als einen der Ansätze, mit denen viele dieser Probleme entschärft werden können. Es wird oft synonym mit Behavior Driven Development (BDD), Story Test Driven Development (SDD) und Specification By Example (SBE) verwendet. Das Hauptunterscheidungsmerkmal von ATDD im Gegensatz zu anderen agilen Ansätzen ist der Fokus darauf, dass Entwickler, Tester, Geschäftsleute, Product Owner und andere Stakeholder als eine Einheit zusammenarbeiten und ein klares Verständnis davon entwickeln, was implementiert werden muss.

Auf der Grundlage meiner eigenen Erfahrungen werde ich meine Ideen dazu teilen, wie Teams ATDD in ihren eigenen Projekten umsetzen können.

Der Kontext

Ich arbeitete in einem großen Unternehmen, das eine Startup-Mentalität hatte, so dass alle innovativen Ideen und Rückmeldungen vom Team gefördert wurden. Wir bauten schnell Prototypen, um zu sehen, ob eine Idee unser Produkt verbessern oder zu den übergeordneten Unternehmenszielen beitragen würde. Ich war der leitende Tester in einem 25-köpfigen Team, das aus einem Scrum Master, einem technischen Leiter und mehreren Business-Analysten, Designern, Entwicklern und Testern bestand. Infolge der Innovationskultur herrschte im Team oft Chaos, u. a. durch häufige Änderungen der Funktionsanforderungen, durch die Arbeit der einzelnen Mitarbeiter in isolierten Umgebungen und durch eine sehr niedrige Arbeitsmoral. Dies war für mich besorgniserregend, also meldete ich mich freiwillig, um bei der Suche nach einer Lösung für diese Probleme zu helfen, was mich zu ATDD führte.

Alle meine Erkenntnisse und Erfahrungen mit ATDD lassen sich in die folgenden 3 Schritte einteilen.

Der ATDD-Implementierungszyklus

Geschaffen von Raj Subramanian

Schritt 1 – Training und Experimentieren

Es gibt viele Möglichkeiten, an Aufgaben heranzugehen, insbesondere wenn man die Erfahrungen der einzelnen Personen berücksichtigt, die in verschiedenen agilen Teams innerhalb und außerhalb ihrer derzeitigen Organisationen arbeiten. Um ein gemeinsames Verständnis für die Ziele des Teams und der Organisation zu schaffen, ist es wichtig, die richtige Schulung anzubieten. Speziell für ATDD sollte sie Ziele, Zielsetzungen, Erwartungen und Informationen über die Ergebnisse enthalten, die sich aus der Anwendung dieses Ansatzes ergeben. Nach der Schulung ist es wichtig, mit einer Implementierung in kleinem Maßstab zu beginnen, um verschiedene Dinge auszuprobieren und ein iteratives Feedback zu erhalten.

Nachdem ich mich beispielsweise über ATDD informiert hatte, erklärte ich den verschiedenen Beteiligten, warum wir diesen Ansatz erforschen sollten und welche Vorteile wir davon haben würden. Ich hob einige der möglichen Vorteile hervor, z. B. die verstärkte Zusammenarbeit im Team, die bessere Klärung der Anforderungen, die frühere Identifizierung von Fehlern im Softwareentwicklungszyklus (SDLC), die erhöhte Sichtbarkeit und der frühere Einsatz von Automatisierung im SDLC sowie die Beteiligung des gesamten Teams an der Ausarbeitung klarer Abnahmekriterien.

In meiner Diskussion mit den Beteiligten betonte ich, dass dies einige Versuche erfordern würde, aber ohne einen Versuch könnten wir die Vorteile nie erfahren. Nach einigen längeren Diskussionen beschlossen wir, das ursprüngliche Team von 25 Personen in zwei kleinere Teams aufzuteilen: Team A bestand aus 12 Personen und sollte ATDD implementieren. Team B bestand aus den verbleibenden 13 Personen und sollte mit dem fortfahren, was es bereits tat.

Ich plante einen zweitägigen Schulungsworkshop für Team A, in dem ich mich über ATDD informierte, feststellte, welche Konzepte im Kontext unseres Projekts sinnvoll waren und wie wir die Automatisierung in diesem Prozess nutzen konnten. Ich habe eine Mischung aus theoretischen und praktischen Übungen in die Schulung eingebaut. Einige der Übungen sind unten aufgeführt:

• Wie schreibt man Gherkin-Anweisungen – Given/When/Then (GWT)
• Was sind die wichtigsten Attribute einer guten User Story?
• Eine Demonstration unseres Automatisierungs-Frameworks, einschließlich seiner Funktionsweise und Struktur. Es gab auch Übungen, wie man als Team einfachen Testcode für die Automatisierung schreiben kann. Vor dem Workshop haben ein Teammitglied und ich unser Automatisierungsframework so angepasst, dass es mit dem ATDD-Ansatz übereinstimmt. Wir verwendeten das Cucumber-Plugin mit Java und Appium für unser Automatisierungs-Framework.

Quelle

Schritt 2 – Erhöhung der Sichtbarkeit

Wenn ein Projekt mehrere Sprints durchläuft, verliert man leicht den Überblick über die verschiedenen Prozesse, die befolgt werden müssen. Der Schlüssel liegt also darin, die Ziele, Vorgaben und Erwartungen für das gesamte Team sichtbar zu machen.

Als wir mit ATDD begannen, schrieb ich einfach jeden der täglichen Prozesse, die befolgt werden mussten, auf ein Whiteboard, das ich dort platzierte, wo unser Team seine täglichen Stand-up-Meetings abhielt. Zu jeder Benutzergeschichte fügte ich eine Checkliste mit den Punkten hinzu, die erledigt werden mussten, bevor die Geschichte als vollständig angesehen werden konnte. Auf diese Weise gab es keine Unklarheiten darüber, welche ATDD-Prozesse befolgt werden mussten. Einer dieser Punkte auf der Checkliste war ein Kick-off-Meeting, bei dem Entwickler, Tester und Geschäftsleute die Anforderungen im Team diskutierten, feststellten, welche Anforderungen automatisiert werden konnten, und die Akzeptanzkriterien der Story im GWT-Format skizzierten. Ein weiterer Punkt auf der Checkliste war das QA-Dev Handoff, bei dem der Entwickler dem Tester anhand einer kurzen Demo oder Diskussion zeigte, wie die Anforderungen erfüllt wurden und welche Unit-Tests als Teil der Story geschrieben wurden. Durch diese Übergabe erfuhr der Tester, welche Bereiche nicht durch Unit-Tests abgedeckt waren und entwickelte ein besseres Verständnis für die implementierte Funktion, was zu einer besseren Testabdeckung führte. Die Punkte der Checkliste waren manchmal offensichtlich, aber es war gut, sie klar zu formulieren. Ein weiterer Punkt war die endgültige Freigabe durch eine Geschäftsperson nach der Besichtigung einer Demo, um sicherzustellen, dass die Funktion gemäß den zuvor festgelegten Anforderungen und Erwartungen entwickelt wurde.

Wir begannen auch mit einem „Prozess-Hawk“. Dabei handelte es sich um ein einzelnes Teammitglied, z. B. einen Scrum Master, einen Projektmanager oder eine andere Person, die dafür sorgte, dass das Team den Prozess einhielt. In meinem Fall war es ein anderer Senior-Tester im Team; er und ich erinnerten alle regelmäßig daran, den ATDD-Prozess in allen Besprechungen zu befolgen, einschließlich Standup, Planung, Retrospektive und anderen Teambesprechungen.

Schritt 3 – Iteratives Lernen und Feedback

Eine ständige Feedbackschleife ist bei der Umsetzung jedes agilen Ansatzes, einschließlich ATDD, von entscheidender Bedeutung. Wöchentliche oder zweiwöchentliche Retrospektiv-Meetings mit dem gesamten Team sind ein wichtiger Weg, um zu erfahren, welche Teile des Prozesses dem Team tatsächlich nützen und welche eventuell geändert werden müssen. Wie wir bereits wissen, führt etwas, das dem Team nicht hilft, zur Verschwendung von Zeit und Mühe. Brian Tracy, Autor von Eat That Frog: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time, sagt: „Eine der schlimmsten Arten, Zeit zu verschwenden, besteht darin, etwas sehr gut zu machen, das überhaupt nicht getan werden muss.“

Im heutigen Zeitalter der Informationstechnologie können es sich Organisationen nicht leisten, Zeit und Energie für ineffektive Ansätze zu verschwenden; vielmehr brauchen wir schlanke und effektive Prozesse. Dies entspricht dem Lean-Startup-Prinzip des validierten Lernens: dem Zyklus Build, Measure, Learn

In diesem Sinne begann ich, jeden Donnerstag 30-minütige Besprechungen mit Team A abzuhalten, um zu sehen, wie das Team mit dem neuen Prozess zurechtkommt. Auf diese Weise konnte ich anhand der Reaktionen des Teams feststellen, welche Änderungen vorgenommen werden mussten. Diese Besprechung fand getrennt von der Retrospektive statt, die am Ende der zweiwöchigen Sprints abgehalten wurde. Dieser Ansatz ermöglichte ein kontinuierliches Feedback des Teams, so dass wir sofortige und effektive Änderungen vornehmen konnten. Das Feedback stammte nicht nur aus den wöchentlichen Prozess-Check-ins; auch die täglichen Stand-up-Meetings erwiesen sich als wertvolle Informationsquelle. Die Aktualisierungen und Diskussionen der einzelnen Teammitglieder deckten rote Fahnen in Bezug auf den Prozess auf, und wir waren in der Lage, sie sofort anzugehen, bevor sie sich auf den Rest des Teams auswirkten.

Zusammenfassung

Als Ergebnis der Befolgung des ATDD-Implementierungszyklus begann Team A, beträchtliche Unterschiede in der Team-Moral, der Zusammenarbeit und den Anforderungen zu erkennen.

Team-Moral

Alle begannen als Team zu arbeiten und fühlten sich ermächtigt. Jede Person war von Anfang bis Ende für eine Geschichte verantwortlich. Er/sie stellte sicher, dass die Geschichte alle notwendigen Informationen enthielt, um mit der Entwicklung und den Tests zu beginnen. Das Teammitglied sorgte auch dafür, dass alle Folgemaßnahmen im Zusammenhang mit der Story durchgeführt wurden. Schließlich war die Person dafür verantwortlich, die Story am Ende des Sprints allen Beteiligten vorzustellen. Dieses Gefühl der Eigenverantwortung steigerte die Moral des Teams erheblich.

Zusammenarbeit

Die Kick-off-Meetings brachten Geschäftsleute, Entwickler und Tester zusammen, um ein gemeinsames Verständnis der User Story zu entwickeln. Das QA-Dev Handoff, das vor der Übergabe des Builds an die QA-Server stattfand, half sowohl den Entwicklern als auch den Testern zu wissen, welche Tests als Teil der Story durchgeführt werden würden, und führte zu einem besseren Verständnis der implementierten Funktion. Die Sichtbarkeit der Automatisierung wurde erhöht, da das gesamte Team die Verantwortung übernahm und nicht nur die Tester. Und schließlich diskutierte das gesamte Team in den Planungsbesprechungen die Story gemeinsam, was zu mehr Ideen, Fragen und Diskussionen führte. Das Team beschloss, Peer-to-Peer-Coaching-Sitzungen abzuhalten, um voneinander zu lernen. Die Tester begannen, paarweise Sondierungstests durchzuführen, und verschiedene Teammitglieder veranstalteten Lunch-n-Learn-Sitzungen, um verschiedene technologische Themen zu diskutieren. All dies führte zu einer verbesserten Zusammenarbeit im Team.

Anforderungen

Eines der Hauptprobleme bei unseren früheren Prozessen waren die häufigen Änderungen der Anforderungen und die schleichende Ausweitung des Umfangs. Mit dem ATDD-Ansatz war es zwingend erforderlich, dass die Anforderungen festgeschrieben wurden, sobald der Entwickler mit der Arbeit an einer Story begann. Alle Änderungen müssen zusammen mit den anderen anstehenden Stories priorisiert und in die nächsten Sprints eingefügt werden. Dies reduzierte die Arbeitsbelastung von Entwicklern und Testern und verhinderte, dass die Stakeholder unrealistische Erwartungen an fertige Features hatten.

Nachdem alle oben genannten Verbesserungen sichtbar wurden, begann auch Team B mit der Implementierung von ATDD. Nach regelmäßigem Experimentieren und Feedback wandte das gesamte ursprüngliche Team diesen Ansatz an.

Schlussfolgerung

Ich empfehle den ATDD-Ansatz, da er mit dem „Shift Left Paradigm“ übereinstimmt, das besagt, dass Entwicklung und Test so früh wie möglich im SDLC beginnen sollten. Es brachte mehr Transparenz in die Automatisierung, da wir zu Beginn des SDLC mit dem Schreiben von automatisierten Tests begannen, was wiederum die Zusammenarbeit im Team verbesserte.

Quelle

Erinnern Sie sich, ATDD ist keine „Einheitslösung“ für alle. Es war der agile Ansatz, der im Kontext meines Projekts am meisten Sinn machte, aber es gibt verschiedene andere Möglichkeiten, Prozesse in Teams zu verbessern. Ich habe mich für diesen Ansatz entschieden, weil er den Schwerpunkt auf bessere Akzeptanztests legt, aber noch wichtiger ist, dass er die Zusammenarbeit in den Vordergrund stellt. Die Zusammenarbeit ist ein wesentlicher Bestandteil dieses Ansatzes und meiner Meinung nach der wertvollste.

Über den Autor

Raj Subrameyer ist ein technischer Karrierestratege, der sich darauf konzentriert, Menschen zu helfen, ihren Traumjob zu finden und erfolgreiche Führungskräfte zu werden. Seine Leidenschaft ist es, Fachleuten dabei zu helfen, ihre Chancen zu maximieren und ihren genialen Bereich zu entdecken. Er nutzt seine Erfahrung in der Tech-Branche, um darüber zu forschen, zu sprechen und zu schreiben, wie wir uns die Technologie zu eigen machen und zu vollwertigen digitalen Bürgern werden können. Er ist ein gefragter Redner auf verschiedenen Konferenzen und wurde in zahlreichen Podcasts und Publikationen vorgestellt, darunter CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success und The Good Men Project. Er ist auch der Autor des neuen Buches „Skyrocket Your Career“. Zu seinen Fachgebieten gehören Karriereförderung, Führung, Motivation, Produktivität und Unternehmertum. In seiner Freizeit reist er gerne und genießt Craft Beer. Weitere Informationen darüber, wie er den Menschen dient, finden Sie auf seiner Website.