Willkommen!<br />Christian Hassa<br />Jonas Bandi<br />
Software Testing Today<br />Ein Relikt aus dem goldenen Zeitalter des Wasserfalls?<br />
Es war einmal ...<br />
Und wenn sie nicht gestorben sind ...<br />
... die goldenen Zeiten sind vorbei!<br />
Hat sich etwas geändert?<br />2008<br />2000<br />Projekterfolglaut Chaos Report, Standish Group<br />
Wann ist ein Projekt erfolgreich?<br />Geschäftsnutzen<br />
Geschäftsnutzen?<br />Nutzung von Featureslaut Chaos Report 2000, Standish Group<br />
Wo entstehen Fehler?<br />Source: James Martin - An Information Systems Manifesto<br />
Bugs früh bekämpfen?<br />Testbare Spezifikationen?<br />
„Wasserfallanalysen“<br />Detailgrad<br />VerständnisgrenzeActor/Stakeholder<br />Vision<br />Lastenheft<br />Pflichtenhef...
Iterative Analyse<br />Detailgrad<br />VerständnisgrenzeActor/Stakeholder<br />Vision<br />Business goals<br />Actor/Stake...
Agilität löst alle Probleme?<br />
Aufwand<br />
Wann sind wir fertig?<br />
Regression<br />
Was nun ...?<br />
&quot;I believe that the hardest part of software projects, the most common source of project failure, is communication wi...
„Vertrauenswürdige Kommunikation“<br />
Vertrauenswürdige Kommunikation<br />Gemeinsames Artefakt<br />Lesbar für Business<br />Ausführbar gegen Endprodukt<br />N...
Aber Wo?<br />Detailgrad<br />VerständnisgrenzeActor/Stakeholder<br />Vision<br />Business goals<br />Actor/Stakeholder go...
FINALLY THE DEMO!<br />
Bowling<br />10 Durchgänge<br />10 Kegel pro Durchgang<br />2 Kugeln pro Durchgang<br />Strike: Alle 10 KegelmitdererstenK...
Das Konzept<br />
Step 1: Write a feature<br />
Step 2: Watch itfail<br />
Step 3: Implementstepdefinitions<br />
Step 4: Create a skeleton<br />
Step 5: Watch itfail<br />
Step 6: Implementthedomain<br />
Step 7: Watch it pass<br />
Repeat!Next Feature Please!<br />
The Real World<br />## TC:110 ##<br />@acceptance @TC110<br />Scenario: TC110 - Message with a rate for a currency that is...
Es geht hier nicht ums Testen ...<br />
Gemeinsame Abstraktion!<br />
Spezifikation an Hand von Beispielen<br />
Aber ...<br />Müssen Entwickler jetzt Testen?<br />Brauchen wir noch Tester?<br />JA!<br />
Entwickler ...<br />Bindet Beispiele an Implementierung<br />Worauf gebunden wird ist flexibel!<br />
Tester ...<br />1 Test pro „Beispiel“<br />Econonmy of Scale<br />Entwickeln „Testsprache“<br />Nutzung auch für manuelle ...
Manuelle Tests??<br />Zur Validierung von Main-Flows und Integration<br />Demo an Stakeholder<br />Geringere Anzahl<br />U...
Aufwand?<br />Ca. 15% Testspezifikation<br />+ manuelle Tests!<br />Ca. 10-25%Binding<br />Synergien!<br />
Wartbarkeit?<br />Richtiger Abstraktionsgrad<br />Wiederverwenbarkeit von Bindings<br />Ebene der Bindings<br />
The Topic is Hot!<br />www.cukes.info<br />www.concordion.net<br />www.fitnesse.org<br />www.specflow.org<br />JBehave / N...
Gemeinsame Artefakte:Spezifikation, Test, Dokumentation<br />Business lesbar (und schreibbar)<br />An Implementierung gebu...
Viel Erfolg bei der Kommunikation!<br />Christian Hassa<br />Jonas Bandi<br />
Upcoming SlideShare
Loading in...5
×

Testing Heute: ein Relikt aus dem Zeitalter des goldenen Wasserfalls?

793

Published on

Testing in Agile Projects.
Introduction to ATDD and BDD.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
793
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Sie sind nicht alleineLaut Standish ist das seit Jahren so.
  • Es geht nicht um Zeit/Scope/Budget sondern um Geschäftsnutzen!
  • Liefern wir immer Geschäftsnutzen?Im Jahr 20089 noch immer nur bei 40%
  • Jeder stimmt über ein, Fehler früh zu stoppen.
  • Nicht iterativ erstelltEin wesentlicher Teil unter der Verständnisgrenze des AnwendersErst wieder bei den Tests
  • Freibrief für Anwender, seine Meinung zu ändern?
  • Kommunikation aber auch Übergabe und gegenseitiges Vertrauen, dass diese Übergabe funktioniert.
  • This was an evolutionarytechnicalapproach… still not convinced?Let´stryanotherapproach.
  • Sondern um das gemeinsame Verständnis
  • ... Ist das Erfolgsrezept!
  • Sicherung der „Ausführbarkeit“Flexibilität: Aufwand, Wartung
  • Testing Heute: ein Relikt aus dem Zeitalter des goldenen Wasserfalls?

    1. 1. Willkommen!<br />Christian Hassa<br />Jonas Bandi<br />
    2. 2. Software Testing Today<br />Ein Relikt aus dem goldenen Zeitalter des Wasserfalls?<br />
    3. 3. Es war einmal ...<br />
    4. 4. Und wenn sie nicht gestorben sind ...<br />
    5. 5. ... die goldenen Zeiten sind vorbei!<br />
    6. 6. Hat sich etwas geändert?<br />2008<br />2000<br />Projekterfolglaut Chaos Report, Standish Group<br />
    7. 7. Wann ist ein Projekt erfolgreich?<br />Geschäftsnutzen<br />
    8. 8. Geschäftsnutzen?<br />Nutzung von Featureslaut Chaos Report 2000, Standish Group<br />
    9. 9. Wo entstehen Fehler?<br />Source: James Martin - An Information Systems Manifesto<br />
    10. 10. Bugs früh bekämpfen?<br />Testbare Spezifikationen?<br />
    11. 11. „Wasserfallanalysen“<br />Detailgrad<br />VerständnisgrenzeActor/Stakeholder<br />Vision<br />Lastenheft<br />Pflichtenheft<br />Designdokument<br />Kein Feedback von<br />Stakeholdern möglich!<br />Code<br />Manual Test„Usage“<br />Automated Test<br />Zeit<br />
    12. 12. Iterative Analyse<br />Detailgrad<br />VerständnisgrenzeActor/Stakeholder<br />Vision<br />Business goals<br />Actor/Stakeholder goals<br />Projektstart<br />Stories<br />Epics<br />ProductBacklog<br />Sprint Planning Preparation<br />AcceptanceCriteria<br />Stories<br />SprintBacklog<br />Sprint Planning<br />Sprint 1-n<br />Sprint Implementation<br />AcceptanceTest Definition<br />Code<br />Kurze Feedbackzyklen<br />mit Stakeholdern<br />Manual Test/Demo<br />Automated Test<br />Zeit<br />
    13. 13. Agilität löst alle Probleme?<br />
    14. 14. Aufwand<br />
    15. 15. Wann sind wir fertig?<br />
    16. 16. Regression<br />
    17. 17. Was nun ...?<br />
    18. 18. &quot;I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.“<br /> - Martin Fowler<br />
    19. 19. „Vertrauenswürdige Kommunikation“<br />
    20. 20. Vertrauenswürdige Kommunikation<br />Gemeinsames Artefakt<br />Lesbar für Business<br />Ausführbar gegen Endprodukt<br />Nachverfolgbar<br />Konsistent<br />
    21. 21. Aber Wo?<br />Detailgrad<br />VerständnisgrenzeActor/Stakeholder<br />Vision<br />Business goals<br />Actor/Stakeholder goals<br />Projektstart<br />Stories<br />Epics<br />ProductBacklog<br />Sprint Planning Preparation<br />AcceptanceCriteria<br />Stories<br />SprintBacklog<br />Sprint Planning<br />Sprint 1-n<br />Sprint Implementation<br />AcceptanceTest Definition<br />Code<br />Kurze Feedbackzyklen<br />mit Stakeholdern<br />„VertrauenswürdigeKommunikation“<br />Manual Test/Demo<br />Automated Test<br />Zeit<br />
    22. 22. FINALLY THE DEMO!<br />
    23. 23. Bowling<br />10 Durchgänge<br />10 Kegel pro Durchgang<br />2 Kugeln pro Durchgang<br />Strike: Alle 10 KegelmitdererstenKugel-&gt; Die nächstenzweiWürfewerdenzumaktuellenDurchgangaddiert<br />Spare: Alle 10 KegelmitzweiKugeln-&gt; DernächsteWurfwirdzumaktuellenDurchgangaddiert<br />DerletzteDurchgangkann 3 Kugelnumfassen<br />
    24. 24. Das Konzept<br />
    25. 25. Step 1: Write a feature<br />
    26. 26. Step 2: Watch itfail<br />
    27. 27. Step 3: Implementstepdefinitions<br />
    28. 28. Step 4: Create a skeleton<br />
    29. 29. Step 5: Watch itfail<br />
    30. 30. Step 6: Implementthedomain<br />
    31. 31. Step 7: Watch it pass<br />
    32. 32. Repeat!Next Feature Please!<br />
    33. 33. The Real World<br />## TC:110 ##<br />@acceptance @TC110<br />Scenario: TC110 - Message with a rate for a currency that is not in the database (unknown currency) <br /> Given the current time is &apos;2009/09/15 13:52‘<br /> And there are currencies in the database with the following data:<br /> | code | <br /> | EUR | <br /> And there are exchange rates in the database with the following data:<br /> | code | rate | date | error code |<br /> | EUR | 1.2 | 2009/09/14 | OK |<br /> And the maximum exchange rate deviation is 2%<br /> When there are exchange rates received for &apos;2009/09/15&apos; on EMB with the following data:<br /> | code | rate |<br /> | EUR | 1.2 |<br /> | SKK | 1.3 |<br /> And wait until the exchange rate is porcessed<br /> Then there is an exchange rate in the database with:<br /> | code | rate | date | error code |<br /> | EUR | 1.2 | 2009/09/14 | OK |<br /> And there is no exchange rate in the database with:<br /> | code | date | <br /> | EUR | 2009/09/15 | <br /> And an e-mail is sent by the CurrencyConverter service to &apos;error@import.info&apos; (CC: &apos;error@import.info&apos;) with subject &apos;Unknown Currency‘<br /> And the e-mail should contain &apos;Error during import!’<br />
    34. 34. Es geht hier nicht ums Testen ...<br />
    35. 35. Gemeinsame Abstraktion!<br />
    36. 36. Spezifikation an Hand von Beispielen<br />
    37. 37. Aber ...<br />Müssen Entwickler jetzt Testen?<br />Brauchen wir noch Tester?<br />JA!<br />
    38. 38. Entwickler ...<br />Bindet Beispiele an Implementierung<br />Worauf gebunden wird ist flexibel!<br />
    39. 39. Tester ...<br />1 Test pro „Beispiel“<br />Econonmy of Scale<br />Entwickeln „Testsprache“<br />Nutzung auch für manuelle Tests<br />
    40. 40. Manuelle Tests??<br />Zur Validierung von Main-Flows und Integration<br />Demo an Stakeholder<br />Geringere Anzahl<br />Unterstützt durch „Testsprache“<br />Automatisierung aufwändiger!<br />
    41. 41. Aufwand?<br />Ca. 15% Testspezifikation<br />+ manuelle Tests!<br />Ca. 10-25%Binding<br />Synergien!<br />
    42. 42. Wartbarkeit?<br />Richtiger Abstraktionsgrad<br />Wiederverwenbarkeit von Bindings<br />Ebene der Bindings<br />
    43. 43. The Topic is Hot!<br />www.cukes.info<br />www.concordion.net<br />www.fitnesse.org<br />www.specflow.org<br />JBehave / NBehave<br />http://studios.thoughtworks.com/agile-test-automation<br />
    44. 44. Gemeinsame Artefakte:Spezifikation, Test, Dokumentation<br />Business lesbar (und schreibbar)<br />An Implementierung gebunden, ausführbar<br />Entwicklung auf Geschäftsnutzen fokussiert<br />Nachverfolgbarkeit von Anforderungen<br />Verfeinerung von gröberen Anforderungen (User Stories)<br />Nutzen<br />
    45. 45. Viel Erfolg bei der Kommunikation!<br />Christian Hassa<br />Jonas Bandi<br />

    ×