Behaviour Driven TestingBehaviour Driven Development (BDD) 2003 von Dan North als Antwort auf Test-Driven Development (Unit-Tests sind für Fachbereich schlecht lesbar) erstellt User-Stories

Software Quality Lab Handout

© Software Quality Lab Seite 1 www.software-quality-lab.com

SWQL Präsentationsvorlage V11.0

© Software Quality Lab www.software-quality-lab.com

Schließen der Lücke zwischen Fachtester und Testautomatisierer

Johannes BergsmannBerater, Trainer, Eigentümer

Behaviour Driven Testing

SWQL Präsentationsvorlage 16:9 V1.0

© Software Quality Lab www.software-quality-lab.com - 2 -

LEISTUNGSPORTFOLIOÜber Software Quality Lab

▪ Management Consulting

▪ Prozesse und Vorgehensmodelle

▪ Teststrategie und -konzeption

▪ Requirements und Ausschreibungen

▪ Architektur und Modellierung

▪ Code Analyse und Metriken

CONSULTING

▪ Requirements und Usability

▪ Architektur und Modellierung

▪ Testen und Automatisieren

▪ Agile Softwareentwicklung

▪ Projektabwicklung und

Vorgehensmodelle

▪ Lehrgänge und Zertifizierungen

ACADEMY

▪ TestCenter

▪ Requirements Engineering

▪ Testmanagement und -spezifikation

▪ Softwareverifikation und -validierung

▪ Testautomatisierung und -reporting

▪ Reviews und Code Analyse

OPERATIONAL SERVICES & TESTCENTER

▪ Tool Evaluation Center

▪ Tool-Einführung und Pilotprojekte

▪ Tool-Schnittstellen und –Einbindung

▪ Managed Services und Lizenzen

▪ Softwareprozessautomatisierung

▪ Test Automation Frameworks

▪ Tool-Studien und Tool-Expertisen

TOOL EXPERTISE





Auszug aus der KundenlisteÜber Software Quality Lab

Dienstleistungen & Handel

Medizin & Pharma

Österreiches

Rotes Kreuz

Finanz & Versicherung

Industrie & EngineeringEnergie & Versorgung

Software & IT

Elektronik & Automation

Mobilität & Kommunikation



InhaltPräsentationsvorlage

▪ Motivation

▪ TDD – Test Driven Development

▪ BDD – Behaviour Driven Development

▪ Beispielumsetzung in Polarion

http://www.frequentis.com/Internet/

http://www.wienkav.at/

http://www.svc.co.at/Default.aspx

http://www.kommunalkredit.at/DE/kommunalkredit/default.aspx

http://www.gi-de.com/portal/page?_pageid=45,48997&_dad=portal&_schema=PORTAL

http://www.omv.com/smgr/portal/jsp/start_page_g1.jsp?BV_SessionID=@@@@0435743148.1133015769@@@@&BV_EngineID=ccceaddgedifhmecefecefgdhfhdfgj.0&p_site=AT

http://www.hr-online.de/website/index.jsp

http://www.webasto.at/home/de/html/homepage.html

http://www.datev.de/





Test as an early indicator of specification & design

I don't care how good you think your design is. …

If I can't walk in and write a test for an arbitrary method of yours in five minutesit's not as good as you think it is, …

… and whether you know it or not, you're paying a price for it.

Michael Feathers



Test Driven Development (TDD)





▪ VOR Programmierung Tests erstellt

▪ Zu erstellende Software wird durch Testfälle beschrieben (= detaillierte Requirements)

▪ Ziele▪ von Anfang an testbaren und wartbaren Code erstellen

▪ Testabdeckung erhöhen

▪ Auf mehreren Ebenen einsetzbar▪ Testen im Kleinen (Unit Tests ) und

▪ Testen im Großen (Systemtests, Akzeptanztests)

TDD Eigenschaften



Testgetriebene Softwareentwicklung

Programm verbessern3

Funktionsblock

programmieren2

Unit-Test schreiben1





TDD Bewertung

Vorteile

Qualität der Entwicklung wird verbessert

Testabdeckung wird erhöht

Besser Basis für Sprint-Abnahme (Test = REQ)

Effizienz im Sprint wird erhöht

„lebende“ Testspezifikation

Herausforderungen

TDD alleine macht noch keine guten REQs und Code

Manches kann nicht vorab als Test automatisiert werden (Usablity, Systemkontext, Prozessmodellierung, Architektur, etc.)

Sehr hohe Disziplin erforderlich



(eine Variante von TDD)

Behavior Driven Development (BDD)





User-Stories – Funktionale Spezifikation

Als <Benutzerrolle/Systemrolle> will ich <Aufgabe/ Story> [, so dass <Grund für das Ziel / Nutzen>]

✓ Einfach lesbar

✓ Einfach verwaltbar

aber:

▪ Es fehlt das Verhalten!



Behaviour Driven Development (BDD)

▪ 2003 von Dan North als Antwort auf Test-Driven Development(Unit-Tests sind für Fachbereich schlecht lesbar)

▪ erstellt User-Stories und erfasst dazu auch das Verhalten (Behaviour) mit Vor-&Nachbedingungen

▪ Beschreibung erfolgt in „natürlicher Sprache“ (Gherkin):

Nicht-Programmierer schreiben „Code“ vor der eigentlichen Entwicklung

User-Story

Szenario / Verhalten

Vorbedingung

Nachbedingung / Ergebnis

Aktion

„Step“






Beispiel Cucumber (Tool für BDD)

1: Describe behaviour

in plain text (GHERKIN)

Quelle: http://www.cukes.info/

2: Write a step definition

in Ruby

3: Run and watch it fail

(Class Calculator missing)

4. Write code to make

the step pass

6. Repeat 2-5 until green

like a cuke5. Run again and see

the step pass

7. Repeat 1-6 until the money runs out ;-)

„Steps“ können

parametriert werden




▪ Automatisierte Regressionstests geben schnelles Feedback „lebende“ Spezifikation und Dokumentation

▪ BDD: interessanter Ansatz, der versucht einebessere Kopplung zwischen den Beteiligten (Fachexperten und Entwickler) zu erreichen.

▪ Probleme:▪ Fachtester arbeiten typischerweise mit anderen Tools (Testmanagement-Tools)

▪ Keine systemunterstützte direkte Kopplung zwischen Testspezifikation und Automatisierungscode

▪ Textbasierte Code-Aufrufe (Steps) – jeder Tippfehler (egal ob beim Tester oder beim Automatisierer) bricht den Zusammenhang und damit die Automatisierung

▪ Keine automatische Rückkopplung

▪ eignet sich ohne Ergänzung primär für entwicklungsnahe Tests (Unit-/Komponenten-Ebene)





„Closing the Gap in BDD“

Beispielumsetzung BDD-Plugin für Polarion



Neues Spezifikationselement





Create a BD Test Case



BD Test Case workitem – design BD Test Case





BD Test Case - Designer

Auswahl von

Given, When,

Then aus

vordefinierten

Listen

Definiertes

Szenario

Parameter für

das Szenario

Definition

neuer Steps

für Given,

When, Then



Execution of the testcases – create a new test run





Add the BD Test Cases to the test run



Start of the test run





Result of the test run



Zusammenfassung

▪ TDD ist ein guter Ansatz um die Qualität in der Entwicklung zu verbessern

▪ TDD erfordert jedoch sehr hohe Disziplin!

▪ BDD ist für die Zusammenarbeit zwischen Fachtester und TA sehr vielversprechend.

▪ Tester-Sicht wird nahtlos gekoppelt mit Testautomatisierung.

Effizienzsteigerung im Test, TA und SWE





Fragen / Diskussion zum ersten Teil?



Johannes Bergsmann

Berater, Trainer, Eigentümer

Automatische Legacy-Code Absicherung





Inhalt

▪ Motivation

▪ UnitTest-Erstellung Grobkonzept



Motivation





Unit-Test-Code Erstellung (halb)manuell

Entwickler oder Tester

Compiler, Build

Lauffähige SW /

Unit-Tests

CodeUnit-Test

CodeEntwickleroder Tester

Überprüfung

Verifizierung

Entwickler

tw. autom. Erstellung

von Unit-Test-Frames



▪ Unit-Tests decken oft nur einen Bruchteil des Code-Verhaltens ab

▪ Entwickler sind tw. nicht motiviert oder haben zu wenig Zeit, gute Unit-Tests zu schreiben

▪ Es gibt nur einen/wenige Unit-Tests je Funktion, damit im Continuous-Integration Tool „grün“ angezeigt wird und alle zufrieden sind

▪ Unit-Tests werden nicht gewartet und blockieren dann die Entwicklung

Legacy-Code und Unit-Test - Probleme





▪ Tests werden meist basierend auf Interfaces der Methoden oder „zufällig“ generiert und nicht aufgrund der inneren Struktur es fehlen Testfälle, die Semantik wird nicht ausreichend berücksichtigt

▪ Oft Zwischencode, der nicht mit den üblichen Tools weiter verarbeitbar ist

▪ Generierte Unit-Tests oft schwer lesbar

▪ Für spezielle Anwendungen sehr teuer (z.B. Embedded-Test-Tools)

▪ Generierte Abdeckung oft unzureichend (z.B. keine Mehrfachbedingungsüberdeckung)

▪ Keine offenen Schnittstellen übliche Versionsverwaltung und CI-Tools nicht oder nur schwer verwendbar

Schwächen bestehender Frameworks



Unit-Tests Erstellung





Unit Test Erstellung

▪ Welche Unit-Tests werden typischerweise erstellt?▪ Unit-Test, der einmal links geht und

▪ Unit-Test, der einmal rechts geht

100% Code-Abdeckung ist mit 2 Tests erreicht und im CI-System ist alles „grün“

▪ Welche Tests sollten erstellt werden,um dies funktional voll zu testen?▪ Jede (Einzel-)Bedingung muss für sich

getestet werden (4 Normal-Testfälle)

▪ Grenzwerte (oben/unten) der beiden Bedingungen (weitere 4 Testfälle)

▪ Fehlertests außerhalb der Grenzen oben und unten sowie innerhalb der Grenzen mit Fehlerwerten (weitere 6 Testfälle)

mind. 14 Unit-Tests erforderlich für gute funktionale Testabdeckung!

A > 10

& B < 5

T1 T2 T3 T4

A > 10 1 1 0 0

B < 5 1 0 1 0



Unit-Test CodeUnit-Test Code

Test-Code-Generator

▪ 20-30% Entwicklungsaufwand fließt in Unit-Test Erstellung

▪ Ziel: ¾ davon einsparen und Entwicklerproduktivität erhöhen

(Legacy)

CodeEntwickler

Parser

Generator

Zwischen-

Modell

Jeder Code, der

getestet und für gut

befunden wurde

Syntax und

Semantik des

Codes.

lesbar z.B. als

XML-Datei.

fertiger Unit-Test-

Code sichert den

Legacy-Code ab

Code

Änderung

Code

Änderung

Einbindung in

CI-System

ist möglich





Komponenten-SchemaSoftware Quality Lab Code Absicherung

Code-Parser

Code(freigegeben)

(C, C++, C#, Java)

TestCode-Generator

UnitTest-Code

(im Format CUnit, CPPUnit / CppTest, Nunit,

JUnit)

Modell

Syntaxbaum, Semantik, Ein-Ausgabe-

Parameter, Schleifen/Verzweigungen, etc.

CI

(z.B. Jenkins, Gitlab CI, Bamboo, etc.)

Code-VerwaltungTestcode-

Verwaltung

(z.B. GIT, SVN, etc.)

Statische Code-Analyse

(z.B. Lint, Checkstyle, Findbugs, Cppcheck, Splint, etc.)

Quality- & Test-Reports

Entwicklungs-framework,

Compile / Build, Unit-Test Ausführung

Dynamische Analyse

Finden der Soll-Werte



Unit-Test Generierung aus ModellSoftware Quality Lab Code Absicherung

Überprüfung

Verifizierung /

Validierung

Entwickler oder Tester

Unit-Test

CodeGenerator

Compiler, Build

Lauffähige SW /

Unit-Tests

lesbarer fertiger

Unit-Test-Code

Kunde / TesterModellierer

Modell-

Parser

Zwischen-

Modell

(Test-)

Modell

Code

Entwickler

Code-

Parser

B

A

Reine Legacy-Code

Absicherung

TDD/MBT

Ansatz

Syntax und Semantik des

Modells bzw. Codes.

Lesbar z.B. als XML-Datei.

Soll-Werte für die Tests

aus dem Test-Modell





Projektstatus und -planung



Software Quality Lab Code Absicherung

▪ Einfache automatische Absicherung von Legacy-Code

▪ Generieren von Standard-Unittest-Code

▪ Einsparung eines großen Teils der Unit-Test-Codierungs-Aufwände

▪ Offen und gute Schnittstellen für eigene Erweiterungen

▪ Einfache Integration in bestehende Unit-Test Frameworks

▪ Verwendung bestehender Code-Verwaltung und CI-Systeme ist möglich

Vorteile





Zusammenfassung

▪ (Legacy-)Code ist meist zu wenig durch Unit-Tests abgesichert!

▪ Bestehende Tools und Ansätze noch nicht „rund“

▪ Innovations-Projekt zur autom. Test-Code Generierung wird mit TU Wien durchgeführt

▪ Pilotkunden / Partner sind noch willkommen



Fragen / Diskussion





Software Quality Lab GmbH

Gewerbepark Urfahr 6A - 4040 Linz

Johannes Bergsmann

[email protected]

+43 676 840072-420

Kontakt für Interessenten



Academy | Consulting | Operational Services | Tool Expertise

INNOVATION MEETS QUALITY

Software Quality Lab

mailto:[email protected]

Documents

Behaviour Driven TestingBehaviour Driven Development (BDD) 2003 von Dan North als Antwort auf Test-Driven Development (Unit-Tests sind für Fachbereich schlecht lesbar) erstellt User-Stories