Einblick in die Qualitätssicherung bei der Softwareentwicklung und Vorstellung des Behavior Driven Development Ansatzes

Qualitätssicherung ist ein sehr wichtiges Thema in der komplexen Welt der Softwareentwicklung. Auch bei der PBM Personal Business Machine AG (PBM) spielen Softwareentwicklung und Qualitätssicherung eine wichtige Rolle. Tobias arbeitet bei der PBM im Bereich Software/Produkt Testing und Qualitätssicherung und hat dem gesamten PBM Team die Ansätze des Behavior Driven Development beim wöchentlichen Teamfrühstück in einem kurzen Vortrag nähergebracht. Im folgenden Blog Beitrag soll ein Überblick über die Arbeit der Qualitätssicherung mit besonderem Fokus auf die Methode Behavior Driven Development gegeben werden.

Aufgaben und Strukturen der Qualitätssicherung

Bei der Qualitätssicherung handelt es sich um die strategische und operative Überprüfung, Identifikation und Lösung von Softwarefehlern, um die Anforderungen an ein Programm sicherzustellen.

Die Mitarbeiter der Qualitätssicherung testen bei der PBM die gesamte Kunden Customer Journey mit ihren Eigenschaften vom personalisierten Brief, über die Funktionen der Landingpages bis hin zu Alexa Skills und Co. Auch unsere Produkte wie die TrustITBox und Kampagnen-Plattform laufen durch die Qualitätssicherung. Dies ist eine sehr wichtige Phase, damit der Kunde ein perfektes Kundenerlebnis ohne Probleme in der Software oder bei Anwendungen erleben kann.

V-Modell

Die klassische Softwareentwicklung folgt dabei dem Ansatz des V-Modells, wobei der Softwareentwicklungsprozess in Phasen organisiert wird. Dabei stellt die Qualitätssicherung die letzte Phase vor dem Live-Gang dar. Das V-Modell definiert das Vorgehen zur Qualitätssicherung, indem den einzelnen Entwicklungsphasen Testphasen gegenübergestellt werden. Die Software durchläuft die zeitlich aufeinander folgenden Phasen. Beginnend bei den Benutzeranforderungen, gefolgt von der Entwicklung bis hin zum Requirements Testing. Im letzten Schritt wird die Umsetzung der Anforderungen überprüft. Diese Gegenüberstellung soll zu einer möglichst hohen Testabdeckung führen, weil die Spezifikationen der jeweiligen Entwicklungsstufen die Grundlage für die Tests in den entsprechenden Teststufen sind.

Der Nachteil dieses Modelles sind die zeitlich aufeinanderfolgenden Phasen. Denn, je später ein Fehler festgestellt wird, desto teuer ist die Behebung. Wenn bei der Qualitätssicherung herauskommt, dass das zuvor entwickelte Programm nicht den Kundenanforderungen entspricht, müssen Benutzeranforderungen angepasst oder sogar neu erstellt werden. Daraufhin durchläuft das Projekt wieder alle Phasen, wodurch die Kosten steigen und sich der Projektstart verzögert. 

Agiles Projektmanagement

Ein neuerer Ansatz ist agiles Projektmanagement. Ziel dabei ist die Erhöhung der Transparenz und Flexibilität, was zu einem schnelleren Einsatz der entwickelten Systeme führen soll. Dadurch sollen Risiken im Entwicklungsprozess minimiert werden. Die selbstorganisierenden Projektteams verfügen über hohe Toleranzen bezüglich Qualität, Umfang und Zeit. Jedoch durchlaufen die agilen Projekte in kleineren Schritten die gleichen Phasen wie im V-Modell: Von den Anforderungen, über das Konzept und die Umsetzung bis hin zum Testing.

Bei Betrachtung der Abläufe wird deutlich, dass zur Vermeidung von Fehlern die Kommunikation zwischen den verschiedenen Einheiten von hoher Bedeutung ist. Häufig scheitern Projekte schon in der Kommunikation der Kundenanforderungen. In jedem Schritt werden andere Artefakte erstellt, die auf den Ergebnissen vorheriger Artefakte beruhen. Der Kunde stellt Anforderungen, die dokumentiert werden. Darauf aufbauend wird ein Lastenheft entwickelt, auf Basis dessen ein Pflichtenheft, dann ein technisches Konzept und so weiter. Das Ganze ist vergleichbar mit dem Spiel „Stille Post“.  Mit jedem Schritt kommt eine neue Interpretation dazu, was der Kunde eigentlich möchte. Wenn dann die Beschreibungen bei dem Entwickler angekommen ist, entsprechen diese nicht mehr dem, was der Kunde zum Projektstart kommuniziert hat.

Behavior Driven Development

Behavior Driven Development (BDD) ist ein Entwicklungsansatz, welcher genau an dieser Stelle eingreift. Der Ansatz versucht Lösungen für fehlende Kommunikation innerhalb eines Entwicklungsprozesses aufzuzeigen, das Verständnis für die Kundenanforderungen bei allen Beteiligten zu stärken und sicher zu stellen, dass alle Anforderungen umgesetzt werden und funktionieren. Dabei wird eine gemeinsame Sprache von Business- und IT-Seite verwendet, die für eine direkte Kommunikation der Kundenanforderung sorgt.

GIVEN-WHEN-THEN-SCHEMA

Wie der Name schon vermuten lässt, sind die Kundenanforderungen bei diesem Ansatz die treibende Kraft. Zu Beginn des Entwicklungsprozesses werden gemeinsam mit dem Kunden die gewünschten Funktionalitäten (Features) der Software identifiziert. Diese werden im nächsten Schritt nicht in Use-Cases, sondern gemeinsam mit dem Kunden in Szenarien beschrieben. Die Szenarien folgen einem festen Aufbau: dem GIVEN-WHEN-THEN-Schema.

Zuerst werden im GIVEN-Teil die Voraussetzungen geschildert: In welcher Rolle und in welcher Situation befindet sich der Nutzer? Im darauffolgenden WHEN-Teil wird die Aktion geschildert, die ein Nutzer ausführt. Im THEN-Teil wird das erwartete Ergebnis vorgestellt.

Für eine Bank, die eine Situation beim Geld abheben beschreiben möchte, könnte es wie folgt aussehen:

GIVEN: Kunde mit Girokonto, welcher noch 10.000 € auf seinem Konto hat

WHEN: Der Kunde seine Karte in den Automaten steckt

THEN: Wird er nach seiner PIN gefragt.

Dieses Szenario lässt sich wie ein Fließtext lesen und ist damit auch von nicht-technischen Stakeholdern leicht zu verstehen. Auf der anderen Seite ist der Text strukturiert und die Anforderungen an die Funktion klar aufgelistet, sodass Entwickler und Tester damit arbeiten können.

Bei dem Behavior Driven Development Ansatz, wird direkt mit den oben genannten Szenarien gearbeitet. Verschiedene Tools am Markt ermöglichen es, aus den Beschreibungen der Szenarien automatische Abnahmetests zu generieren. Diese stellen sicher, dass alle Anforderungen von den Entwicklern auch umgesetzt wurden. Bei Änderungswünschen auf Kundenseite werden lediglich die Szenarien angepasst. Damit aktualisiert sich automatisch auch die Vorgabe für die Entwickler, die automatischen Testcases aktualisieren sich wegen der Verknüpfung zu den Szenarien ebenso. Alle Beteiligten sind immer auf demselben Stand.

Im Nachhinein hat der Kunde weniger Änderungswünsche oder Erweiterungen, da die Anforderungen jedem Projektteilnehmer durchgängig präsent sind und so schneller Fehler und Probleme auffallen.

Vorteile das BDD Ansatzes

• Das gewünschte Verhalten der Anwendung wird anhand von Beispielen beschreiben.
• Nicht-technische Projektteilnehmer, wie z.B. Kunden werden mit einbezogen.
• Die Beschreibungen sind lebendige Dokumente und können entgegen einer klassischen Spezifikation während des Projektes angepasst und erweitert werden.
• Die Kommunikation zwischen Business, Entwicklung und Testing wird verbessert und vereinfacht.

Fazit

Mit dem Behavior Driven Development Ansatz wird die Zusammenarbeit aller Beteiligten verstärkt und die Software vom Ergebnis her entwickelt. Die Benutzeranforderungen können schon früh mit dem Kunden und den Entwicklern beschrieben werden. Ein Vorteil dabei ist, dass so auch nicht-technische Projektteilnehmer von Anfang an involviert werden können. Durch die Unterstützung der Softwareexperten werden die Verhaltensbeschreibungen bzw. Benutzeranforderungen sehr lebendig und wirken als detaillierte Darlegung. Diese Dokumente bleiben während des gesamten Projektes lebendig und können so immer wieder um neue zu testende Szenarien sowie zusätzliche Funktionen erweitert werden. Die Anzahl von späten Changes wird dadurch verringert und die Dokumente müssen nicht überarbeitet werden, sobald sich ein Szenario ändert. Die Abnahmetests verändern sich gleichzeitig mit. Der Fokus ist ab Beginn auf das Endprojekt gerichtet, wodurch die Benutzeranforderungen von Anfang an für alle Teilnehmer und Abteilungen klar definiert sind.