BDD – Behavior Driven Development

Es ist die Herausforderung im agilen Entwicklungsvorgehen möglichst schnell und effizient auf die Bedürfnisse der Nutzer und den daraus resultierenden Anforderungen zu reagieren. Daher sollte der gesamte Zyklus von Anforderungserhebung über Implementierung,  Dokumentation, Test und Betrieb nahtlos ineinander übergehen.

Häufig gibt es viele Reibungsverluste durch das Übersetzen fachlicher Anforderungen durch das anfänglich gesprochene Wort, den darauf folgenden schriftlichen Dokumenten bis hin zur eigentlichen User Story.
Um diese Reibungsversluste zu minimieren, sollte die Fachlichkeit möglichst früh in eine Form gebracht werden, mit der sich die spätere Implementierung messen lassen kann.

BDD verfolgt dabei den Ansatz das gewünschte Verhalten konkreter Use-Cases in Tests zu überführen und diese zu automatisieren. Das besondere dabei ist, dass diese Tests bereits selbst von den Business Analysten bzw. den Product Owner definiert und später auch im lauffähigen Zustand von ihnen gelesen werden können.

Das definieren dieser Akzeptanztests geschieht idealerweise spätestens zum Story Planning gemeinsam im Team. Als sehr hilfreich erweist sich das gemeinsame Diskutieren von Beispielen (Specification By Example). Dies sorgt vor allem für ein gemeinsames Verständnis der Anforderungen, und darüber hinaus dienen diese im automatisierten Zustand als Dokumentationsquelle.
Zum Zeitpunkt der Umsetzung der User Story werden eben auch die Tests vom Team implementiert. Dabei  spielt es eine wichtige Rolle die Tests auf der richtigen Ebene zu implementieren und die Ergebnisse aller Tests über die Buildchain zusammenzuführen und zu visualisieren.
Die Herausforderung der QA-Engineers ist hierbei vielerseits. Zum einen muss er die Fachlichkeit genau kennen und Umstimmigkeiten sofort hinterfragen. Zum anderen muss er die eingesetzten Framworks und die eigentliche Implementierung soweit kennen, dass er den Akzeptanztes auf der am besten  geeigneten Teststufe implementieren kann.

Die Tests entsprechen üblicherweise dem folgendem Format:

Given (setup)
Ein spezifischer Zustand des Systems.

When (trigger)
Eine entsprechende Akion wird ausgeführt.

Then (verification)
Der Zustand der Anwendung hat sich geändert oder eine Ausgabe wurde erzeugt.

Ein einfaches Beispiel:

Given
A registered user named John Doe.
When
The user logs in with his credentials.
Then
His personal dashboard is shown.

Die Implementierung mit Spock/Groovy könnte so aussehen:

class LoginSpec extends AbstractTest {

@Shared
def user

@Shared
DashboardPage dashboardPage

def setupSpec() {
user = TestBackbone.createUser("John Doe")
}

def cleanupSpec() {
user = TestBackbone.deleteUser("John Doe")
}

def "after login the dashboard is shown"() {

given: "A registered user named John Doe"
Testbackbone.userExists("John Doe")

when: "The user logs in with his credentials"
dashboardPage = browser().loginToPortal(user.name, user.password)

then: "His personal dashboard is shown"
dashboardPage.isOnPage()

}
}

Neben dem oben dargestellten Framwork Spock gibt es weitere populäre wie jBehave,  FIT, FitNesse, Concordion, Cucumber.

Die Methode BDD bietet eine gute Möglichkeit Fachlichkeit frühzeitig in Tests zu überführen. Damit existiert eine automatisiert prüfbare Beschreibung der Software, welche jederzeit die Korrektheit der umgesetzten Teile der Software überprüfen lässt.

Jedoch sollte stark darauf geachtet werden die Tests auf die entsprechenden Teststufen zu verteilen. Teure Tests im Sinne der Laufzeit wie beispielsweise Browser Ende zu Ende Tests sollten nur den Happy Path eines Anwendungsfalls wiedergeben. Detailierte tiefergehende Tests sollten dann auf den entsprechenden Ebenen umgesetzt werden.
Leider erschert wiederum die Verteilung der Tests den Überblick über die existierenden Tests und der damit verbunden Fachlichkeit.

Traditional vs. Agile QA

oder: find bugs vs. prevent bugs

Traditionelle QA

In den meisten traditionellen Softwareunternehmen wird QA  durch eine seperate Abteilung abgebildet. Die Abteilung besteht aus einem oder mehren Teams von QA-Engineers die dem QA Manager reporten. Die QA Teams können eng mit den Business Analysten oder Entwicklern zusammen arbeiten, meist jedoch beschränkt sich der Wirkungskreis der Engineers auf ihre Abteilung.
Von den Business Analysten erhält die QA Abteilung sowie die Entwicklungsabteilung die detailierten Anforderungen und Zeitpläne. Während die Programmierer Code schreiben, schreiben die Tester Testpläne und erstellen Testfälle um sicher zu stellen das die gelieferten  Anforderungen erfüllt werden.
Wenn die Programmierer das Produkt vermutlich fertiggestellt haben, wird die Software der QA-Abteilung zum Test übergeben. QA führt ihren vorab erstellten Testzyklus gegen das Produkt aus und reportet die Fehler zurück zur Entwicklungsabteilung. Testen besteht dabei angelehnt an ISO/IEC 9126 aus unterschiedlichen Aktivitäten wie funktionalen Tests, Lasttests und Regressionstests.
Nach beheben der Fehler durch die Entwicklung wird der Testabteilung eine neue Revision zum Test zur Verfügung gestellt. Dieser Zyklus wird sooft wiederholt bis die Software fertig für das Release ist, oder der Zeitplan ein Release vorgibt.

Betrachten wir den Zeitverzug zwischen Fertigstellung der Software und dem Reporting der Fehler zurück an die Entwicklung. Diese Verzögerung erfordert das Code, welcher Wochen oder Monate vorher geschrieben wurde, geändert werden muss. Grundlegende Änderungen haben weitreichende Auswirkungen die sich wiederum in den nachgelagerten Tests wiederspiegeln.
Zusätzlich ändern sich im Laufe der Zyklen fachliche Anforderungen die daran münden, Testfällen neu zu erstellen und Testplan zu ändern.
Im Falle fehlerhafter Kommunikation, droht das Risiko das QA, Entwicklung und die Business Analysten unterschiedliche Erwartungen an das Produkt haben.

Solange QA die letzte Aktivität vor einem festen Release Datum ist, stehen die QA Aktivitäten unter starkem Zeitdruck wodurch die Produktqualität beeinträchtigt wird.

vereinfachtes Schema traditioneller Softwareentwicklung
vereinfachtes Schema traditioneller Softwareentwicklung
Agile QA

Agiles Testen folgt einem flexibleren und kontinuierlicherem Vorgehen, welches Hand in Hand mit der Entwicklung und dem Produktmanagement geht. Ein Agiles Team erstellt nicht erst alle Anforderungen, dann die Entwicklungsarbeit und dann den Test. Stattdessen nimmt sich das Team einen kleinen Teil, und arbeitet übergreifend zusammen um dieses Teilstück fertig zu stellen. Diese Teilstück kann sich auf Infrastruktur, Feature Entwicklung, eines Spikes oder anderes beziehen. Das Projekt geht so kontinuierlich Schritt für Schritt voran.

Um ein Teilstück des System mit Hilfe von User-Stories fertig zu stellen, ist es notwendig das Produkt Management, Entwicklung und Test zusammen ein gemeinsames Ziel anstreben: die Story fertig stellen.
Die Stories werden vom Product Owner erstellt und priorisiert im Backlog verwaltet. Stories werden je nach Priorität und Aufwand ausgewählt. Die Aufwandsschätzung ist eine Teamarbeit an der ebenfalls die Tester beteiligt sind. Das Team identifiziert gemeinsam Abhängigkeiten, technische sowie testbezogene Herausforderungen. Das Gesamte Team definiert Akzeptanzkriterien welche beschreiben wann eine Story fertig ist.

Während einer Iteration können sich verschiedene Stories in unterschiedlichen Stufen von Entwicklung oder Test befinden. Agiles Testen ist kontinuierlich da jeder in einem agilen Team testet. Dabei ist jedoch der Fokus und das Timing unterschiedlich abhängig davon was getestet werden soll. Die Entwickler haben einen starken Fokus auf Code-Level Test. Währenddessen geben die Tester im Team in allen Entwicklungsstufen frühes Feedback, kennen die Unit-Testabdeckung, übernehmen die Automatisierung der Akzeptanz- und Regressionstests und finden zusätzliche Testszenarien durch explorative Tests. Zusätzlich hat der Tester das Gesamtsystem im Blick und stellt die Integrität der Story in das Gesamtsystem sicher. Zusätzliche Aktivitäten wie Performance Tests können über technische Stories abgedeckt werden welche wie User Stories behandelt werden.

vereinfachtes Schema agiler Softwareentwicklung
vereinfachtes Schema agiler Softwareentwicklung
Skills für agile Tester

Anstatt einer Qualitätspolizei muss der agile Tester vielmehr ein Team Player sein dessen gemeinsames Teamziel es ist die Story umzusetzen.
Der Tester ist dabei ein vollständiges Teammitglied der an allen Aktivitäten wie beispielsweise Planning, Estimating, Development, Review, Retrospektive, Release teilnimmt.

Ein wesentlicher Bestandteil der agilen Entwicklung sind automatisierte Tests. Die Automatisierung der Tests ist kein separates Projekt, sondern Teil einer jeden Umsetzung von User-Stories und kann von jedem Teammitglied realisiert werden. Continuous Integration (CI) ist heute ein weit verbreitetes Vorgehen wobei die Tester dabei führend in der  Automatisierung von Akzeptanztest (inkl. end-to-end Szenarien) sind. Eine vollständige automatisierte Testpipline resultiert in schnellen Testergebnissen und beschleunigt die Umsetzung der User-Story sowie das darauf folgende Release.

Der agile Tester benötigt kein großes Anforderungsdokument und bekommt keine drei Monate um Testfälle zu spezifizieren bevor je ein Stück Code produziert wurde.
Vielmehr lernt der agile Tester zur richtigen Zeit die richtigen Fragen zu stellen und gibt ein angemessenes Niveau an Feedback zur richtigen Zeit.

find bugs vs. prevent bugs

find bugs vs. prevent bugs