Akzeptanz-Test getriebene Produktentwicklung
•
0 gefällt mir•427 views
Wie man Product Owner und Fachspezialisten konsequent in den automatisierten Entwicklungsprozess integriert
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Akzeptanz-Test getriebene Produktentwicklung
Ähnlich wie Akzeptanz-Test getriebene Produktentwicklung (20)
Akzeptanz-Test getriebene Produktentwicklung
- 1. Akzeptanz-Test getriebene Produkt-Entwicklung Wie man Product Owner und Fachspezialisten konsequent in den automatisierten Entwicklungsprozess integriert
- 2. Anti-Pattern Nr. 8Die Schaukel 2
- 3. 3 As understood by the requirements engineers As specified in the project request. As designed by the senior architect. As produced by the engineers. As designed by the UX Team What the customer really wanted.
- 4. Anti-Pattern Nr. 8 Warum ist das so ein guter Comic? 4 ?
- 7. Anti-Pattern Nr. 8 Lösungen im agilen Umfeld 7
- 9. Crossfunktionale Teams - Skills statt Titel und Personen 9
- 10. Kommunikation 10
- 11. User Stories 11
- 12. User Stories 12 TitelEin Merker für das Versprechen die Diskussion zu führen
- 14. User Stories 14 AkzeptanzkriterienDiskussion Titel Diskussionsergebnisse werden durch Akzeptanzkriterien notiert
- 15. Lösungen im agilen Umfeld - Priorisiertes Product Backlog 15 Product Backlog Product Owner
- 16. Anti-Pattern Nr. 8 Dann beginnt der Sprint 16
- 17. Dann beginnt der Sprint - User Stories im Sprint 17 Product Backlog Sprint Backlog
- 18. Dann beginnt die Entwicklung 18 ● Schreiben des produktiven Codes ● Prüfen der Akzeptanzkriterien
- 23. Akzeptanzkriterien Ein Beispiel ● Terraform Google Cloud Provider ● Exzellente Testabdeckung (Unit-, Integrations- und Akzeptanztests) ● technisches Projekt ● Contribution 23 Source Code auf Github
- 24. 24 func TestAccDnsManagedZone_importWithProject(t *testing.T) { t.Parallel() zoneSuffix := acctest.RandString(10) project := getTestProjectFromEnv() resource.Test(t, resource.TestCase{ PreCheck: func() { testAccPreCheck(t) }, Providers: testAccProviders, CheckDestroy: testAccCheckDnsManagedZoneDestroy, Steps: []resource.TestStep{ resource.TestStep{ Config: testAccDnsManagedZone_basicWithProject(zoneSuffix, "description1", project), }, resource.TestStep{ ResourceName: "google_dns_managed_zone.foobar", ImportState: true, ImportStateVerify: true, }, }, }) }
- 28. 28 # language: de Funktionalität: Import einer DNS Managed Zone aus einem anderen Projekt Als Terraformer möchte ich die DNS Managed Zone aus einem anderen Projekt importieren, so dass ich alle DNS Einträge in einem Projekt konsolidiert habe. Szenario: DNS Managed Zone importieren Gegeben sei eine DNS Managed Zone "foobar" Und der zone-suffix 'zone-sf' Und die Zonenbeschreibung 'description1' Und das Testprojekt 'acctest' Wenn ich diese in mein Terraform-Projekt importiere Dann erhalte ich folgende Ressourcedefinition für 'resource "google_dns_managed_zone" "foobar"' | resource field | value | name | mzone-test-zone-sf | | dns_name | tf-acctest-description1.hashicorptest.com | | description | description1 | | project | acctest | Szenario: Infrastruktur abbauen Gegeben sei die importierte DNS Managed Zone "foobar" Wenn ich die importierte Zone abbaue Dann wird der importierte Eintrag nicht gelöscht
- 31. Anti-Pattern Nr. 8 ausführbare Akzeptanzkriterien 31
- 32. A-TDD Ablauf: Refinement 32 Refinement User Story VCS
- 33. Akzeptanzkriterien als Gherkin 33 # language: de Funktionalität: Import einer DNS Managed Zone aus einem anderen Projekt Als Terraformer möchte ich die DNS Managed Zone aus einem anderen Projekt importieren, so dass ich alle DNS Einträge in einem Projekt konsolidiert habe. Szenario: DNS Managed Zone importieren Gegeben sei eine DNS Managed Zone "foobar" Und der zone-suffix 'zone-sf' Und die Zonenbeschreibung 'description1' Und das Testprojekt 'acctest' Wenn ich diese in mein Terraform-Projekt importiere Dann erhalte ich folgende Ressourcedefinition für 'resource "google_dns_managed_zone" "foobar"' | resource field | value | name | mzone-test-zone-sf | | dns_name | tf-acctest-description1.hashicorptest.com | | description | description1 | | project | acctest | Szenario: Infrastruktur abbauen Gegeben sei die importierte DNS Managed Zone "foobar" Wenn ich die importierte Zone abbaue Dann wird der importierte Eintrag nicht gelöscht
- 34. Red - Green - Blue 34 A-TDD TDD
- 35. Red - Green - Blue 35 A-TDD Red Zu Beginn sind alle Akzeptanztests nicht ausführbar und rot. A-TDD TDD
- 36. Red - Green - Blue 36 Step Definition Code der textuellen Akzeptanzkriterien mit ausführbaren Aktionen verbindet. Implementierung ist nicht vorhanden. A-TDD weiterhin rot TDD
- 37. Red - Green - Blue 37 TDD Cycle beginnt Nur die für die Erfüllung der Akzeptanzkritieren erforderlichen Komponenten werden mit den Tests versehenTDD
- 38. Red - Green - Blue 38 TDD green Alle Unit- und Komponententests sind.
- 39. Red - Green - Blue 39 Akzeptanz-Tests Alle Akzeptanztests sind grün
- 40. Red - Green - Blue 40 Refactoring Alle Akzeptanztests sind grün A-TDD TDD
- 42. 42 Framworks Bekannteste Frameworks ● Cucumber https://cucumber.io/ ● Robot https://robotframework.org/ ● Fitnesse http://docs.fitnesse.org/FrontPage
- 43. Anti-Pattern Nr. 8 43 Y Warum A-TDD?
- 44. 44 Warum A-TDD? The High-Tech Illusion … Our successes stem from good human interactions by all participants in the effort, and our failures stem from poor human interactions. Tom DeMarco: Peopleware - Productive Projects and Teams. 1988.
- 45. 45 Warum A-TDD?
- 46. 46 Warum A-TDD?
- 50. Experimente Akzeptanzkriterien als Gherkin schreiben Versucht im Refinement eine oder mehrere User Stories mit Gherkin zu formulieren. Hilft euch die strikte Struktur eure Funktionalitäten konsistenter zu beschreiben? Ein große Hürde für automatisiertes A-TDD ist die Ablage in einem für die Entwicklung erreich- und nachvollziehbarem Werkzeug. Versucht mit dem gesamten Team die User Stories in eurem Version Controll System abzulegen. Akzeptanzkriterien in VCS ablegen 50
- 51. Experimente Versucht die Akzeptanzkriterien in euren bestehenden Testtools abzubilden. Eine User-Story mit A-TDD umsetzen 51
- 52. Experimente Cucumber, Robotframework und Fitnesse ausprobieren Macht Spikes und probiert, ob ihr mit einem der Frameworks arbeiten könnten. bei euch sinnvoll verwenden könnt. 52 Versucht einen sanften Migrationspfad zu A-TDD zu finden: Untersucht in einem Spike eure bisherigen (xUnit)-Tests in einen der Frameworks zu integrieren und den Glue-Code (Step-Definitions) so einfach wie möglich zu halten. Nehmt eine bestehende User-Story in einem ausführenbaren Format. Schreibt einen Wrapper für eure xUnit Tools unter einem der A-TDD Frameworks
- 53. Experimente 100% automatisierte A-TDD Wenn ihr schon A-TDD seid: Versucht alle Akzeptanztests zu automatisieren. Lasst automatisierte Akzeptanztests weg und testet von Hand. Manuelle Tests 53
- 54. Experimente Zeigt eure Akzeptanztests im Sprint-Review Lasst eure automatisierten Akzeptanztests als Teil des Sprintreviews laufen. Vollständige Integration der Akzeptanztests in die CI/CD 54
- 55. Anti-Pattern Nr. 8 Vielen Dank! 55
- 56. 56 Literatur
- 57. 57 Literatur Practices for Scaling Lean & Agile Development - Craig Larman, Bas Vodde User Stories applied - Mike Cohn Peopleware - Tom DeMarco The RSpec Book - David Chelimsky Cucumber - https://cucumber.io/ Robot - https://robotframework.org/ Fitnesse - http://docs.fitnesse.org/FrontPage
- 58. Ralf Waldvogel Lead Developer & Agile Architect Colenet GmbH | Jenaer Ring 12 | 76297 Stutensee Mobil: +49 (0)1511 8488 763 E-Mail: ralf.waldvogel@colenet.de | www.colenet.de https://twitter.com/waldvmuc https://www.xing.com/profile/Ralf_Waldvogel3 58
- 59. 59 Acknowledgements Icons on slides Vielen Dank Literatur Experimente Frameworks ausführbare Akzeptanzkriterien Akzeptanzkriterien Dann beginnt der Sprint Lösungen im agilen Umfeld made by https://www.flaticon.com/authors/sherzod-mirzaakhmedov from www.flaticon.com.