Enttäuschen sie sich, nicht Ihre Kunden!st.inf.tu-dresden.de/files/teaching/ws13/ring/2013... ·...

��

Acceptance Test-Driven Development - Enttäuschen sie sich, nicht Ihre Kunden! -

Christian Wende, DevBoost GmbH

18. November 2013, TU Dresden

��

2

Enttäuschen

Christian Wende | DevBoost GmbH

1All rights reserved. 2013 © ZeroTurnaround OÜ

HOW ENGINEERING TOOLS & PRACTICES IMPACT SOFTWARE QUALITY & DELIVERY

DEVELOPER PRODUCTIVITYREPORT 2013


+RZ�PXFK�IXQFWLRQDOLW\��QRW�FRGH�is covered by automated tests?

Automating functional tests are a good way to add another layer of stability to your software and make sure that what works in dev also works in production! Here is what the respondents told us about how much automated testing is used to verify functionality.

In more plain numbers, we can see an average of one-third (33%) of software functionality is covered by automated tests--but the standard deviation is huge, and most often respondents utilized only 10% of automated testing for their software.

The laggards literally did no automated testing (0%), and the rock stars covered 75% of functionality with automated tests. Way to go, rock stars!

How much of your functional testing is automated?

Average 33%

Median 25%

Mode 10%

Standard Deviation 30%

Laggards (Bottom 10%) 0%

Rock stars (Top 10%) 75%







Average 33%

Median 25%

Mode 10%





HOW ENGINEERING TOOLS & PRACTICES IMPACT SOFTWARE QUALITY & DELIVERY

DEVELOPER PRODUCTIVITYREPORT 2013







Average 33%

Median 25%

Mode 10%




18. November 2013

��

3

Enttäuschen == eine Täuschung nehmen


Meine Enttäuschung: Ich hatte erwartet, das mehr automatisiert getestet wird

Um mehr Entwickler zum Testen zu bringen, muss man Ihnen folgende Täuschungen nehmen

•  Testautomatisierung ist kompliziert

•  Testautomatisierung ist aufwendig

•  Testautomatisierung ist langweilig

•  Testautomatisierung zahlt sich nicht aus == unnötiger Aufwand

18. November 2013

��

•  Softwareentwickler bauen Software, um die Anforderungen ihrer Kunden zu erfüllen (Job to Be Done)

4

(Ent)Täuschungen in der Softwareentwicklung


•  Kommunikationsproblem in der Anforderungsanalyse

Kunde Entwickler

Kunde Entwickler

•  Anforderung als wichtiges Akzeptanzkriterium bei der Auslieferung

18. November 2013

��

5

Klassisches Vorgehen


Anforderungen

Software

Kundenwunsch

Manuelle Abnahmetests

Unit Tests

Unerfüllte Anforderungen, Unerwartes Verhalten

Funktionale Bugs

18. November 2013

��

•  Verständnisprobleme zw. Kunden und Entwicklern werden zu spät erkannt

•  Anforderungsspezifikation ist “totes” Artefakt

•  Communication Gap zwischen –  Anforderungsspezifikation und Softwareimplementierung –  Anforderungsspezifkation und Abnahmetest

•  Asynchronität zwischen Implementierung und Akzeptanztest

•  Unit Tests validieren aus Entwicklersicht nicht aus Kundensicht

6

Probleme

Christian Wende | DevBoost GmbH 18. November 2013

��

•  Viele, kurze Iterationen sichern eine kontinuierliche Annäherung von Kundenbedürfnis und Software

7

Lösungsansatz: Wir entwickeln agil


•  Agilität erhöht die Geschwindigkeit, verträgt sich das mit Testen?

•  Sind umfangreiche Anforderungsspezifikationen nicht unnötiger Aufwand?

•  Wie soll ich bei kurzen Iterationen die Anforderungen, die Software und die Tests warten?

Ja, klasse Idee! Fragen:

��

8

Acceptance Test-Driven Development (ATDD)


Anforderungen in natürlicher Sprache

Software

Kundenwunsch

Automatisierte Abnahmetests

Unerfüllte Anforderungen, Unerwartes Verhalten Funktionale Bugs

18. November 2013

��

9



Anforderungen in natürlicher Sprache

Software

Kundenwunsch


Unerfüllte Anforderungen, Unerwartes Verhalten Funktionale Bugs

Anforderungen gemeinsam spezifizieren

18. November 2013

��

•  Anforderungsspezifikation erfordert Zusammenarbeit von Kunden, Analysten, Entwicklern und Testern

•  Kunden definieren Was sie benötigen und Warum

•  Entwicklungsteam gestaltet Wie Anforderungen umgesetzt werden

•  Natürliche Sprache ist das Mittel der Wahl für allseitiges Verständnis

•  z.B. Anwenderszenarien mit realistischen Bespielen begünstigen Verständigung

10



��

Beispiel Flugbuchungssystem (Airplanes, Flights, Passengers)

Story: Booking a Flight Given a Passenger John Doe Given an Airplane Boing-787 With 200 total seats Given a flight LH-1234 With 200 free seats Book seat for John Doe at LH-1234 Assume Success

11



Eingabe

Systemfunktion

Ergebniserwartung

18. November 2013

��

12



Abnahmetest in natürlicher Sprache

Software

Kundenwunsch



18. November 2013

��

13




Software

Kundenwunsch


Anforderungen schrittweise verfeinern und konsolidieren

18. November 2013

��

•  Verwendete Sprache konsolidieren (Redundanzen entfernen, Muster finden und konsistent verwenden, Terme vereinheitlichen)

•  Mit initialen Anforderungen und Daten experimentieren, Ausnahmefälle durchspielen und in Testdaten verwandeln

•  Die ursprünglichen Anforderungen weiterentwickeln und ggfs. mit Kunden abstimmen

•  Natürliche Sprache zur Abstimmung der Verfeinerungen immer noch notwendig

14



��

Beispiel Ausnahmefall In welchem Fall soll eine Buchung fehlschlagen?

Story: Booking a Flight with Passenger already booked Given a Passenger John Doe Given an Airplane Boing-787 Given a flight LH-1234 With 200 free seats Book seat for John Doe at LH-1234 Assume Success Book seat for John Doe at LH-1234 Assume Failure

15



��

16




Software

Kundenwunsch



18. November 2013

��

17




Software

Kundenwunsch


Ausführbare Tests automatisiert erzeugen und wiederholt ausführen

18. November 2013

��

•  Nur testbare (ausführbare) Anforderungen bleiben lebendig und sind wertvoll

•  Testerzeugung muss direkt aus Anforderung erfolgen und darf diese nicht verändern

•  Testerzeugung muss für Entwickler einfach und flexibel umsetzbar sein

•  Testerzeugung muss auf bestehende Test-Frameworks aufsetzen (Junit, TestNG, HtmlUnit, jMock, EasyMock, Arquillian, etc)

18

Ausführbare Tests automatisiert erzeugen…


��

Demo!

Christian Wende | DevBoost GmbH 19 18. November 2013

��

•  /// Verbesserte Kommunikation und Zusammenarbeit im Team und mit Kunden

•  /// Fokussierung auf die wesentlichen und kundenrelevanten Softwarefunktionen

•  /// Direkte Messung des aktuellen Projektfortschrittes

•  /// Höhere Entwicklungseffizienz durch klare, kontinuierliche Verständigung, weniger Misverständnisse, weniger Iterationen und weniger “tote” Spezifikationen

•  /// Höhere Produktqualität durch frühestmögliche, kontinuierliche Überprüfung des Implementierungszustandes bzgl. der Akzeptanzkriterien

20

Vorteile von ATDD


��

21

Vorteile von ATDD



When relating functional test automation with SUHGLFWDELOLW\�DQG�TXDOLW\��ZH�VHH�D�VLJQLȴFDQW�JDLQ�in both metrics as the % of (self-reported) test automation increases. It’s interesting that folks who GRQȇW�GR�DQ\�DXWRPDWHG�WHVWLQJ��DUH�EHWWHU�R�than folks who do a little (10%). We theorize that teams who do no automated testing are probably doing more manual testing and those who do just a little trust them more than they should. Once going further with it, we see a steady increase.

7KH�HHFWV�RI�DXWRPDWHG�IXQFWLRQDO�WHVWLQJ� on predictability and quality

��


When relating functional test automation with SUHGLFWDELOLW\�DQG�TXDOLW\��ZH�VHH�D�VLJQLȴFDQW�JDLQ�in both metrics as the % of (self-reported) test automation increases. It’s interesting that folks who GRQȇW�GR�DQ\�DXWRPDWHG�WHVWLQJ��DUH�EHWWHU�R�than folks who do a little (10%). We theorize that teams who do no automated testing are probably doing more manual testing and those who do just a little trust them more than they should. Once going further with it, we see a steady increase.

7KH�HHFWV�RI�DXWRPDWHG�IXQFWLRQDO�WHVWLQJ� on predictability and quality

22

Vorteile von ATDD


Warum mit Kunden-vorgaben nur

testen?!!

18. November 2013

��Lean Modeling

•  Konzeptuell analog zu ATDD, aber: –  keine Beschränkung auf Test-Code –  keine syntaktischen Beschränkungen bzgl. der verwendeten

Sätze

23 Christian Wende | DevBoost GmbH 18. November 2013

��Vergleich zu „klassischer Modellierung“

24 Christian Wende | DevBoost GmbH

http://xkcd.com/859/

18. November 2013

��

25 Christian Wende | DevBoost GmbH

Requirements Interchange Format (RIF)

•  Kontrollierte, Formale Sprachen Vergleich zu „klassischer Modellierung“

18. November 2013

��

Turmbau zu Babel

26

Probleme


��

27

Probleme


Turmbau zu Babel

Blame Them ?

18. November 2013

��

Turmbau zu Babel

Communication Gap

Tracing

Komplexität

Klammern J

28

Probleme


��

29

Was läuft schief?


Formale Spezifikation

Software

Kundenwunsch

Generierter Code

Metamodel Syntax (Text, Graphik,…)

Meta-Metamodel Grammatik

Codegenerator/ Interpreter

Modellierungsframework

Sprache für Modelltransformation

Sprache für Codegenerierung

18. November 2013

��

30

Was läuft schief?


Formale Spezifikation

Software

Kundenwunsch

Generierter Code

Metamodel Syntax (Text, Graphik,…)

Meta-Metamodel Grammatik

Codegenerator/ Interpreter

Initialer Overhead.

Ressourcengrab?

Investitionsrisiko!

Blame MDSD?

18. November 2013

��

31

Lean Modelling (mit NatSpec)


Natürlichsprachl. Spezifikation

Software

Kundenwunsch

Generierter Code

Spezifikationen in natürlicher Sprache

18. November 2013

��

32

Lean Modelling (mit NatSpec)


Natürlichsprachl. Spezifikation

Software

Kundenwunsch

Generierter Code

Anforderungen gemeinsam mit Kunden spezifizieren (Specification-by-Example)

Anforderungen, Domänenglossar, Businessregeln, etc. in natürlicher Sprache erfassen

Muster in Spezifkation erkennen und auf ausführbaren Code abbilden

Anwendungsteile und Dokumentation generieren

Kund

enfe

edba

ck a

ufne

hmen

und

Pr

ozeß

iter

iere

n

18. November 2013

��

Demo!


��

34

Vorteile von Lean Modelling


Klassische Modellierung Lean Modelling

Turmbau zu Babel Eine Unmenge verschiedener, spezielle Sprache

Eine Universelle Sprache mit Möglichkeit zur Spezialisierung

Communication Gap Formale Sprachen für Kunden schwer zugänglich

Natürliche Sprache ist für Menschen gemacht

Tracing Kann durch Zusatzaufwand realisiert werden

Im Entwicklungsvorgehen “eingebaut”

Komplexität 10.000+ Seiten Formalismus, Millionen LOC im Framework

So minimal wie möglich, So formal wie nötig

18. November 2013

��

/// NatSpec selbst testen

•  www.nat-spec.com - Kostenlose 30-Tage Trial Version

/// ATDD und Lean Modelling einführen

•  Was: Aufmerksamkeit wecken, Wissen etablieren

•  Wie: In eigene Toollandschaft und Prozesse integrieren

•  Warum: Überwachen und Benefit messen

/// Feedback geben, Fragen klären, Unterstützung anfordern

•  [email protected]

35

Die nächsten Schritte


��

Danke!

Fragen?

http://www.devboost.de

[email protected]


Date post:	05-Jul-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Enttäuschen sie sich, nicht Ihre Kunden!st.inf.tu-dresden.de/files/teaching/ws13/ring/2013... ·...

Documents