BDD Teil 1

1. Der Product-Owner (PO) hat eine Idee. Hier ein schickes Portal für die Kunden
2. Der PO setzt die Idee in ein Konzept um und übergibt dies an das Entwicklerteam
3. Dev-Team entwickelt ein Produkt auf Basis des Konzeptes
4. Die Entwickler übergeben das Product an QA
5. Der Test-Manager (QA) meldet Fehler zurück an das Dev-Team. Es geht weiter mit3)So oft, bis das Produkt abnahmebereit ist
6. Nach einigen Zyklen in der Qualitätssicherung muss das Produkt letztlich zur Abnahme dem PO Übergeben werden
7. Der PO findet seine Anforderungen nicht umgesetzt und ist entsprechend unzufrieden.

Dieser Prozess ist so schmerzhaft, weil erst nach der Entwicklung der Software festgestellt werden kann, dass nicht alle Projektteilnehmer das gleiche Bild von der Software haben. Die bereits entwickelte Software muss aufwendig geändert werden. Die Testphase steht immer unter dem Risiko eine Aufwandsexplosion zu verursachen.

Das Erlebnis kann für alle Beteiligten frustierend sein

• Der Test-Manager fungiert als Überbringer der schlechten Nachricht.  Er erhält ein negatives Feedback des Teams obwohl er  gute Arbeit geleistet hat und für das entstandene Missverständnis nicht verantwortlich ist.
• Die Entwickler haben gute Arbeit geleistet.  Sie verweisen darauf wie technisch gut die entwickelte Lösung ist.  Die Stabilität der Software ist im Bild durch die verwendeten Ziegelsteine symbolisiert. Die Entwickler müssen nun unter Zeitdruck die Software umbauen und dabei Kompromisse eingehen, zu denen sie eigentlich nicht bereit sind.
• Der Product-Owner hatte eigentlich damit gerechnet, eine neue Funktionalität abnehmen und in Betrieb nehmen zu können. Er muss nun akzeptieren, dass die Entwicklung länger dauert bzw teurer wird. Eventuell muss er auch fachliche Kompromisse eingehen, um die geleistete Arbeit und den Projekterfolg zu retten.

Frühes Feedback als Schmerzmittel.

Das beschriebene Problem ist in der Geschichte der Softwareentwicklung immer wieder und in unzähligen Formen aufgetreten. Viele halten es wahrscheinlich für ein Naturgesetz. Entsprechend gibt es eine Vielzahl von Strategien um diesen Schmerz zu vermeiden oder wenigstens zu lindern. Bei vielen dieser Strategien geht es darum, möglichst früh Feedback einzuholen.

Eine klassische Technik um während der Softwareentwicklung frühes Feedback einzuholen ist die Testgetriebene Entwicklung (test-driven-development aka TDD). Der Entwickler schreibt zuerst den Test, dann erst die eigentliche Software. Die so entstandenen Unit-Tests dienen so zunächst der Entwicklung und ab dann als Regressionstests. TDD ist ein Kernbestandteil von BDD wie wir später sehen werden.

Das direkteste Feedback bietet wohl das Pair Programming hier bekommt der Entwickler Feedback von seinem Kollegen noch während er den Code schreibt. Siehe dazu die Artikel von Guido (link) und Robert (link

Scrum & Co: Iterative Methoden

Eine weitere Strategie möglichst früh und möglichst oft das Ergebnis der Entwicklung zu veröffentlichen um am Feedback der Tester und Verwender eine Fehlentwicklung möglichst früh erkennen zu können. (http://en.wikipedia.org/wiki/Release_early,_release_often). Eine Möglichkeit dies umzusetzen ist die Entwicklung in Iterationen: Anstatt ein Softwareprojekt über Monate zu entwicklen, dann zu veröffentlichen und das Feedback des Kunden abzuwarten, wir die Arbeit in Iterationen aufgeteilt.

Beispiel für iterative Methoden sind die Sprints im Scrum oder die Releases im Feature Based Programming Nach einer Iteration von vielleicht 2 oder 3 Wochen wird ein Teil der Software veröffentlicht und zum Test und zur Verwendung freigegeben.

In einem iterativen Vorgehen verspricht man sich, dass nur die Arbeit von einer Iterationslänge (z.B. 2 Wochen) in die falsche Richtung laufen kann. Die oben beschriebenen Fehlentwicklungen gibt es demnach immer noch. Insbesondere, wenn man nicht nach jeder Iteration entsprechend genau den Projektfortschritt prüft und auf Regressionen testet.

Nach derselben Überlegung kann in klassischen Projekten die Arbeit von Monaten oder Jahren gefährdet sein. Im schlimmsten Fall stellt sich heraus, dass die Anforderungen gar nicht mehr erfüllt werden können und ein Projekt scheitert

Continuous Delivery als nächste Stufe der Evolution

Einen großen Schritt weiter geht das Konzept von Continuous Delivery, wie wir es bei Otto betreiben. Jeder Commit eines Entwicklers, kann prinzipiell in den Produktivbetrieb gehen. Im Idealfall passiert das mehrmals am Tag. In der Realität vielleicht alle 2 Tage. Anstatt also die Änderungen an der Software über Wochen zu sammeln und auf einmal live zu stellen, versucht man, möglichst viele und möglichst kleinteilige Deployments durchzuführen. Ein schöner Seiteneffekt ist es, dass mit jedem Release nur noch eine sehr kleine Änderung in den Produktivbetrieb geht. Wenn in einem Release also ein Fehler entdeckt wird, kann man ihn entsprechend genau eingrenzen und zielgerichtet beheben. Auch ein vielleicht notwendiger Rollback verliert an Schrecken und wird leichter überschaubar.

Continuous Delivery ist ein ganzheitlicher Ansatz und eine höchst komplexe Aufgabe. Eine der technischen Hürden die wir dazu überwinden mussten beschreibt Guido in seinem Beitrag über Blue-Green-Deployment eines der Probleme in der Entwicklung in seinem Artikel über Feature Toggles (link).

Eigentlich will man jedoch Fehler im Produktiv-Betrieb schon vor dem Deployment ausschliessen. Continuous Delivery ist deshalb nur möglich, wenn ein hohes Vertrauen in die Qualität der ausgelieferten Software besteht. Dieses Vertrauen kann nur durch einen geeigneten Entwicklungsprozess hergestellt werden, und muss in diesem durch automatisierte Tests abgesichert werden.

Es gibt zwei wichtige Anforderungen an den Build-Prozess, die erfüllt sein müssen, bevor man daran denken kann jederzeit und oft zu deployen

1. Durch Tests muss möglichst das vollständige Verhalten der Software abgeprüft werden. Dies muss für jeden Softwarestand gelten, der in den Produktivbetrieb gehen soll.
2. Die Tests müssen eine möglichst kurze Ausführungszeit benötigen damit der Deployment-Prozess nicht unnötig verlängert wird. Idealerweise ist die Ausführungszeit so kurz, dass für jeden Commit eines Entwicklers die komplette Testsuite durchlaufen wird

Behaviour Driven Development als Schmiermittel

Hier kommt Behaviour Driven Development ins Spiel. Es leistet dabei zwei ganz wesentliche Beiträge

1. Es schafft Vertrauen der Nicht-Techniker in die Arbeit der Entwickler. Dies gelingt, indem die zu automatisierenden Funktionstests in von Menschen lesbarer Sprache verfasst sind. Jede funktionale Anforderung wird zunächst in einem automatisierten Test umgesetzt. So ist das durch diese Tests abgeprüfte Verhalten der Software für alle Projektteilnehmer nachvollziehbar. Darum geht es im zweiten Teil der Serie.
2. Es ermöglicht die automatisierten Tests möglichst effizient und umfassend zu entwickeln. Es bietet dem Entwickler mit der Testpyramide eine Methode an, eine minimale Testsuite zu entwicklen, die sämtliche Funktionalitäten der Software abdeckt. Darum wird es im dritten Teil gehen.