Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
sogehtsoftware.de
So geht Software.
DESIGN FOR TESTING
WIE? WIR MÜSSEN DAS NOCH TESTEN!
Seite sogehtsoftware.de
DESIGN FOR TESTING
2
Wir müssen mal testen!
Seite sogehtsoftware.de
System
Service
Unit
Kay Grebenstein
DESIGN FOR TESTING
Wir müssen mal testen!
Seite sogehtsoftware.de
System
Service
Unit
Kay Grebenstein
Mutation
Testing
Test
Implementierung
Refaktorisierung
TDD
BDD...
Seite sogehtsoftware.de
System
Service
Unit
Kay Grebenstein
Mutation
Testing
Test
Implementierung
Refaktorisierung
TDD
BDD...
Seite sogehtsoftware.de
Anforderungs
-abdeckung
Last -
Test
Perfomance
- test
Usability
Security
System
Service
Unit
Kay G...
Seite sogehtsoftware.de
Anforderungs
-abdeckung
Last -
Test
Perfomance
- test
Usability
Security
System
Service
Unit
Kay G...
Seite sogehtsoftware.de
Anforderungs
-abdeckung
Last -
Test
Perfomance
- test
Usability
Security
System
Service
Unit
Kay G...
Seite sogehtsoftware.de
Anforderungs
-abdeckung
Last -
Test
Perfomance
- test
Usability
Security
System
Service
Unit
Kay G...
Seite sogehtsoftware.de
Anforderungs
-abdeckung
Last -
Test
Perfomance
- test
Usability
Security
System
Service
Unit
Kay G...
Seite sogehtsoftware.de
System
Service
Unit
Testdaten
Kay Grebenstein
CDC CDC-Tests
Mutation
Testing
Produktions-
nahe Tes...
Seite sogehtsoftware.de
System
Service
Unit
DESIGN FOR TESTING
Blick der QA
Seite sogehtsoftware.de
System
Service
Unit
DESIGN FOR TESTING
Blick der QA
Seite sogehtsoftware.de
System
Service
Unit
DESIGN FOR TESTING
Blick der QA
Seite sogehtsoftware.de
System
Service
Unit
Seite sogehtsoftware.de
System
Service
Unit
System
Service
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 17
Das Testkonzept – Klassische Projekte
Ziele der Tests Strate...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 18
„Testkonzept“ für das agile Entwicklungsteam
„Ziele der Test...
Seite sogehtsoftware.de
DESIGN FOR TESTING
19
„Testkonzept“ für das Team
TeamTestKonzept
Test-
Umgebungen
Test-
Aktivitäte...
Seite sogehtsoftware.de
DESIGN FOR TESTING
20
„Testkonzept“ für das Team
TeamTestKonzept
Test-
Umgebungen
Test-
Aktivitäte...
Seite sogehtsoftware.de
DESIGN FOR TESTING
21
„Testkonzept“ für das Team
TeamTestKonzept
Test-
Umgebungen
Test-
Aktivitäte...
Seite sogehtsoftware.deKay Grebenstein 22
Was ist zu
testen?
Wie & Wo wollen
wir testen?
„Testkonzept“ für das Team
DESIGN...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 24
ISO 25010
Funktionalität
Vollständigkeit
Korrektheit
Angemes...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 25
ISO 25010
Funktionalität
Vollständigkeit
Korrektheit
Angemes...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 26
ISO 25010
Funktionalität
Vollständigkeit
Korrektheit
Angemes...
Seite sogehtsoftware.de27
DESIGN FOR TESTING
QA-Oktant
Seite sogehtsoftware.de28
DESIGN FOR TESTING
QA-Oktant
Übertragbarkeit
Wie leicht lässt sich die Software
in eine andere U...
Seite sogehtsoftware.de29
DESIGN FOR TESTING
QA-Oktant
Seite sogehtsoftware.de30
DESIGN FOR TESTING
QA-Oktant
Seite sogehtsoftware.deKay Grebenstein 31
Was ist zu
testen?
Wie & Wo wollen
wir testen?
„Testkonzept“ für das Team
DESIGN...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Die Entwicklung
33
Seite sogehtsoftware.de
Die Entwicklung
DESIGN FOR TESTING
Sprint-
Backlog VCS BUILD
Produkt-
Inkrement
Coden
Code
34
Seite sogehtsoftware.de
Die Entwicklung und die QA
DESIGN FOR TESTING
Sprint-
Backlog VCS BUILD
Produkt-
Inkrement
Coden
C...
Seite sogehtsoftware.de
Die Entwicklung und die QA
DESIGN FOR TESTING
BigPic:
Entwicklung
und QA
Sprint-
Backlog VCS BUILD...
Seite sogehtsoftware.de
BigPic: Die Entwicklung und die QA
DESIGN FOR TESTING
Sprint-
Backlog
Repository Build
System
Serv...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 41
QA-Schlachtplan
Seite sogehtsoftware.de42
requirements
• Wo liegen die Anforderungen?
• Unterstützen die Anforderungen die
Testfall-erstel...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 43
QA-Schlachtplan
requirements
• Wo liegen die
Anforderungen?
...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 44
QA-Schlachtplan
test / code
•Wo werden die
Tests platziert?
...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 45
QA-Schlachtplan
repository
• Wo werden die
Testartefakte
ges...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 46
QA-Schlachtplan
test management
• Wie planen wir unsere
Test...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 47
QA-Schlachtplan
automation
• Wieviel Test-
automatisierung?
...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 48
QA-Schlachtplan
build
• Wieoft wollen wir bauen
und testen?
...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 49
QA-Schlachtplan
test environments
•Haben wir für jeden
Test ...
Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 51
QA-Schlachtplan
JIRA
XRAY
System-
Test-
Umgebung
Selenium
Ma...
Seite sogehtsoftware.de
IHR KONTAKT Telefon:
E-Mail:
sogehtsoftware.de
ZZ
Kay Grebenstein
Supertester
+49 351 49701 688
ka...
Upcoming SlideShare
Loading in …5
×

of

Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 1 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 2 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 3 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 4 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 5 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 6 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 7 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 8 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 9 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 10 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 11 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 12 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 13 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 14 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 15 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 16 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 17 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 18 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 19 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 20 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 21 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 22 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 23 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 24 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 25 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 26 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 27 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 28 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 29 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 30 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 31 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 32 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 33 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 34 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 35 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 36 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 37 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 38 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 39 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 40 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 41 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 42 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 43 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 44 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 45 Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability Slide 46
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

0 Likes

Share

Download to read offline

Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability

Download to read offline

Bereits vor der Einführung von agile Methoden und DevOps war das Ziel von Entwicklungsprojekten die schnelle Bereitstellung von hochwertigen Produkten. Im Vordergrund stehen die Überlegungen zur optimalen Architektur und zum passenden Design. Die Aspekte der Qualitätssicherung kommen meist später, was sich während der Tests bemerkbar macht. In diesem Vortrag werden die Überlegungen und Erfahrungen zum design for testability angesprochen, die sinnvoll sind, um in Softwareprojekten von Beginn an eine optimale Testbarkeit gewährleisten zu können.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

Dev Day 2019: Kay Grebenstein – Wie wir müssen das noch testen? - design for testability

  1. 1. sogehtsoftware.de So geht Software. DESIGN FOR TESTING WIE? WIR MÜSSEN DAS NOCH TESTEN!
  2. 2. Seite sogehtsoftware.de DESIGN FOR TESTING 2 Wir müssen mal testen!
  3. 3. Seite sogehtsoftware.de System Service Unit Kay Grebenstein DESIGN FOR TESTING Wir müssen mal testen!
  4. 4. Seite sogehtsoftware.de System Service Unit Kay Grebenstein Mutation Testing Test Implementierung Refaktorisierung TDD BDD DDD DESIGN FOR TESTING Wir müssen mal testen!
  5. 5. Seite sogehtsoftware.de System Service Unit Kay Grebenstein Mutation Testing Test Implementierung Refaktorisierung TDD BDD DDD funktional Testarten nicht-funktional Test Management Tool DESIGN FOR TESTING Wir müssen mal testen!
  6. 6. Seite sogehtsoftware.de Anforderungs -abdeckung Last - Test Perfomance - test Usability Security System Service Unit Kay Grebenstein Mutation Testing Test Implementierung Refaktorisierung TDD BDD DDD funktional Testarten nicht-funktional Test Management Tool Test- umgebungen DESIGN FOR TESTING Wir müssen mal testen!
  7. 7. Seite sogehtsoftware.de Anforderungs -abdeckung Last - Test Perfomance - test Usability Security System Service Unit Kay Grebenstein Mutation Testing Test Implementierung Refaktorisierung TDD BDD DDD funktional Testarten nicht-funktional Test Management Tool Test- umgebungen DESIGN FOR TESTING Wir müssen mal testen!
  8. 8. Seite sogehtsoftware.de Anforderungs -abdeckung Last - Test Perfomance - test Usability Security System Service Unit Kay Grebenstein Mutation Testing Test Implementierung Refaktorisierung TDD BDD DDD funktional Testarten nicht-funktional Test Management Tool Test- umgebungen DESIGN FOR TESTING Wir müssen mal testen!
  9. 9. Seite sogehtsoftware.de Anforderungs -abdeckung Last - Test Perfomance - test Usability Security System Service Unit Kay Grebenstein Mutation Testing Test Implementierung Refaktorisierung TDD BDD DDD funktional Testarten nicht-funktional Test Management Tool Test- umgebungen Testdaten complex test fixture complex test fixture complex test fixture DESIGN FOR TESTING Wir müssen mal testen!
  10. 10. Seite sogehtsoftware.de Anforderungs -abdeckung Last - Test Perfomance - test Usability Security System Service Unit Kay Grebenstein Mutation Testing Test Implementierung Refaktorisierung TDD BDD DDD funktional Testarten nicht-funktional Test Management Tool Test- umgebungen Testdaten complex test fixture complex test fixture complex test fixture CDC CDC-Tests DESIGN FOR TESTING Wir müssen mal testen!
  11. 11. Seite sogehtsoftware.de System Service Unit Testdaten Kay Grebenstein CDC CDC-Tests Mutation Testing Produktions- nahe Tests Test- umgebungen funktional Testarten nicht-funktional complex test fixture Test Implementierung Refaktorisierung TDD complex test fixture complex test fixture BDD DDD Test Management Tool Anforderungs -abdeckung Last - Test Perfomance - test Usability Security DESIGN FOR TESTING Wir müssen mal testen!
  12. 12. Seite sogehtsoftware.de System Service Unit DESIGN FOR TESTING Blick der QA
  13. 13. Seite sogehtsoftware.de System Service Unit DESIGN FOR TESTING Blick der QA
  14. 14. Seite sogehtsoftware.de System Service Unit DESIGN FOR TESTING Blick der QA
  15. 15. Seite sogehtsoftware.de System Service Unit
  16. 16. Seite sogehtsoftware.de System Service Unit System Service
  17. 17. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 17 Das Testkonzept – Klassische Projekte Ziele der Tests Strategie Integration und Koordination innerhalb ALM Anforderungen Rollen Alle durchzuführenden Test-Aktivitäten Berichte Testablaufplan Ressourcen Testdokumentation Testumgebungen
  18. 18. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 18 „Testkonzept“ für das agile Entwicklungsteam „Ziele der Tests“ „Strategie“ Integration und Koordination innerhalb ALM Anforderungen Rollen Alle durchzuführenden Test-Aktivitäten Berichte Testablaufplan Ressourcen Testdokumentation Testumgebungen
  19. 19. Seite sogehtsoftware.de DESIGN FOR TESTING 19 „Testkonzept“ für das Team TeamTestKonzept Test- Umgebungen Test- Aktivitäten Ziele der Tests Strategie Test- ablauf- plan Berichte Test -doku Ressourcen
  20. 20. Seite sogehtsoftware.de DESIGN FOR TESTING 20 „Testkonzept“ für das Team TeamTestKonzept Test- Umgebungen Test- Aktivitäten Ziele der Tests Strategie Test- ablauf- plan Berichte Test -doku Ressourcen
  21. 21. Seite sogehtsoftware.de DESIGN FOR TESTING 21 „Testkonzept“ für das Team TeamTestKonzept Test- Umgebungen Test- Aktivitäten Ziele der Tests Strategie Test- ablauf- plan Berichte Test -doku Ressourcen
  22. 22. Seite sogehtsoftware.deKay Grebenstein 22 Was ist zu testen? Wie & Wo wollen wir testen? „Testkonzept“ für das Team DESIGN FOR TESTING
  23. 23. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 24 ISO 25010 Funktionalität Vollständigkeit Korrektheit Angemessenheit Effizienz Antwortzeiten Ressourcen- verbrauch Kapazität Kompatibilität Koexistenz Interoperabilität Benutzbarkeit Angemessenheit Erlernbarkeit Bedienbarkeit Fehlertoleranz ggü. Anwender- fehlern Ästhetik der Benutzer- oberfläche Barrierefreiheit Zuverlässigkeit Ausgereiftheit Verfügbarkeit Fehlertoleranz Wieder- herstellbarkeit Sicherheit Vertraulichkeit Integrität Nachweis- barkeit Verantwort- lichkeit Authentizität Wartbarkeit Modularität Wieder- verwendbarkeit Analysierbarkeit Modifizierbarkeit Prüfbarkeit Übertragbarkeit Anpassbarkeit Installierbarkeit Austauchbarkeit
  24. 24. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 25 ISO 25010 Funktionalität Vollständigkeit Korrektheit Angemessenheit Effizienz Antwortzeiten Ressourcen- verbrauch Kapazität Kompatibilität Koexistenz Interoperabilität Benutzbarkeit Angemessenheit Erlernbarkeit Bedienbarkeit Fehlertoleranz ggü. Anwender- fehlern Ästhetik der Benutzer- oberfläche Barrierefreiheit Zuverlässigkeit Ausgereiftheit Verfügbarkeit Fehlertoleranz Wieder- herstellbarkeit Sicherheit Vertraulichkeit Integrität Nachweis- barkeit Verantwort- lichkeit Authentizität Wartbarkeit Modularität Wieder- verwendbarkeit Analysierbarkeit Modifizierbarkeit Prüfbarkeit Übertragbarkeit Anpassbarkeit Installierbarkeit Austauchbarkeit
  25. 25. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 26 ISO 25010 Funktionalität Vollständigkeit Korrektheit Angemessenheit Effizienz Antwortzeiten Ressourcen- verbrauch Kapazität Kompatibilität Koexistenz Interoperabilität Benutzbarkeit Angemessenheit Erlernbarkeit Bedienbarkeit Fehlertoleranz ggü. Anwender- fehlern Ästhetik der Benutzer- oberfläche Barrierefreiheit Zuverlässigkeit Ausgereiftheit Verfügbarkeit Fehlertoleranz Wieder- herstellbarkeit Sicherheit Vertraulichkeit Integrität Nachweis- barkeit Verantwort- lichkeit Authentizität Wartbarkeit Modularität Wieder- verwendbarkeit Analysierbarkeit Modifizierbarkeit Prüfbarkeit Übertragbarkeit Anpassbarkeit Installierbarkeit Austauchbarkeit
  26. 26. Seite sogehtsoftware.de27 DESIGN FOR TESTING QA-Oktant
  27. 27. Seite sogehtsoftware.de28 DESIGN FOR TESTING QA-Oktant Übertragbarkeit Wie leicht lässt sich die Software in eine andere Umgebung übertragen bzw. nutzen? Wartbarkeit Wie aufwändig ist die Änderung an der Software?
  28. 28. Seite sogehtsoftware.de29 DESIGN FOR TESTING QA-Oktant
  29. 29. Seite sogehtsoftware.de30 DESIGN FOR TESTING QA-Oktant
  30. 30. Seite sogehtsoftware.deKay Grebenstein 31 Was ist zu testen? Wie & Wo wollen wir testen? „Testkonzept“ für das Team DESIGN FOR TESTING
  31. 31. Seite sogehtsoftware.de DESIGN FOR TESTING Die Entwicklung 33
  32. 32. Seite sogehtsoftware.de Die Entwicklung DESIGN FOR TESTING Sprint- Backlog VCS BUILD Produkt- Inkrement Coden Code 34
  33. 33. Seite sogehtsoftware.de Die Entwicklung und die QA DESIGN FOR TESTING Sprint- Backlog VCS BUILD Produkt- Inkrement Coden Code QA
  34. 34. Seite sogehtsoftware.de Die Entwicklung und die QA DESIGN FOR TESTING BigPic: Entwicklung und QA Sprint- Backlog VCS BUILD Produkt- Inkrement Coden Code QA System Service Unit
  35. 35. Seite sogehtsoftware.de BigPic: Die Entwicklung und die QA DESIGN FOR TESTING Sprint- Backlog Repository Build System Service Unit manuellautomatisiert Test Umgebung(en) Repository Repository Test- Management Test- Automatiom 38
  36. 36. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 41 QA-Schlachtplan
  37. 37. Seite sogehtsoftware.de42 requirements • Wo liegen die Anforderungen? • Unterstützen die Anforderungen die Testfall-erstellung? • Lassen sich Anforderungen und Tests verknüpfen? test / code • Wo werden die Tests platziert? • Haben wir die nötigen Skills? repository • Wo werden die Testartefakte gespeichert? • Gibt es unterschiedliche Artefakte? test management • Wie planen wir unsere Tests? • Wir dokumentieren wir unsere Tests? • Wie informieren wir? • Und Wen? automation • Wieviel Test-automatisierung? • Benötigen wir weitere Werkzeuge? • Benötigen wir Testdaten? build • Wieoft wollen wir bauen und testen? • Wie wollen wir die QA integrieren? • Wollen wir Wartbarkeit prüfen? test environments • Haben wir für jeden Test die passende Umgebung? • Kommen wir uns in die Quere? Die richtigen Fragen zur Übersicht DESIGN FOR TESTING
  38. 38. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 43 QA-Schlachtplan requirements • Wo liegen die Anforderungen? • Unterstützen die Anforderungen die Testfall- erstellung? • Lassen sich Anforderungen und Tests verknüpfen?
  39. 39. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 44 QA-Schlachtplan test / code •Wo werden die Tests platziert? •Haben wir die nötigen Skills?
  40. 40. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 45 QA-Schlachtplan repository • Wo werden die Testartefakte gespeichert? • Gibt es unterschiedliche Artefakte?
  41. 41. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 46 QA-Schlachtplan test management • Wie planen wir unsere Tests? • Wir dokumentieren wir unsere Tests? • Wie informieren wir? • Und Wen?
  42. 42. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 47 QA-Schlachtplan automation • Wieviel Test- automatisierung? • Benötigen wir weitere Werkzeuge? • Benötigen wir Testdaten?
  43. 43. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 48 QA-Schlachtplan build • Wieoft wollen wir bauen und testen? • Wie wollen wir die QA integrieren? • Wollen wir Wartbarkeit prüfen?
  44. 44. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 49 QA-Schlachtplan test environments •Haben wir für jeden Test die passende Umgebung? •Kommen wir uns in die Quere?
  45. 45. Seite sogehtsoftware.de DESIGN FOR TESTING Kay Grebenstein 51 QA-Schlachtplan JIRA XRAY System- Test- Umgebung Selenium Manuelle Tests automatisierte Tests Test Implementierung Refaktorisierung TDD GIT JENKINS Plugins QF-Test Autom. Test- Umgebung
  46. 46. Seite sogehtsoftware.de IHR KONTAKT Telefon: E-Mail: sogehtsoftware.de ZZ Kay Grebenstein Supertester +49 351 49701 688 kay.grebenstein@saxsys.de

Bereits vor der Einführung von agile Methoden und DevOps war das Ziel von Entwicklungsprojekten die schnelle Bereitstellung von hochwertigen Produkten. Im Vordergrund stehen die Überlegungen zur optimalen Architektur und zum passenden Design. Die Aspekte der Qualitätssicherung kommen meist später, was sich während der Tests bemerkbar macht. In diesem Vortrag werden die Überlegungen und Erfahrungen zum design for testability angesprochen, die sinnvoll sind, um in Softwareprojekten von Beginn an eine optimale Testbarkeit gewährleisten zu können.

Views

Total views

418

On Slideshare

0

From embeds

0

Number of embeds

89

Actions

Downloads

7

Shares

0

Comments

0

Likes

0

×