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.

1. sogehtsoftware.de
So geht Software.
DESIGN FOR TESTING
WIE? WIR MÜSSEN DAS NOCH TESTEN!

2. Seite sogehtsoftware.de
DESIGN FOR TESTING
2
Wir müssen mal testen!

3. Seite sogehtsoftware.de
System
Service
Unit
Kay Grebenstein
DESIGN FOR TESTING
Wir müssen mal testen!

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. 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. 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. 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. 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. 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. 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. 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. Seite sogehtsoftware.de
System
Service
Unit
DESIGN FOR TESTING
Blick der QA

13. Seite sogehtsoftware.de
System
Service
Unit
DESIGN FOR TESTING
Blick der QA

14. Seite sogehtsoftware.de
System
Service
Unit
DESIGN FOR TESTING
Blick der QA

15. Seite sogehtsoftware.de
System
Service
Unit

16. Seite sogehtsoftware.de
System
Service
Unit
System
Service

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. 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. 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. 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. 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. Seite sogehtsoftware.deKay Grebenstein 22
Was ist zu
testen?
Wie & Wo wollen
wir testen?
„Testkonzept“ für das Team
DESIGN FOR TESTING

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. 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. 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. Seite sogehtsoftware.de27
DESIGN FOR TESTING
QA-Oktant

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. Seite sogehtsoftware.de29
DESIGN FOR TESTING
QA-Oktant

29. Seite sogehtsoftware.de30
DESIGN FOR TESTING
QA-Oktant

30. Seite sogehtsoftware.deKay Grebenstein 31
Was ist zu
testen?
Wie & Wo wollen
wir testen?
„Testkonzept“ für das Team
DESIGN FOR TESTING

31. Seite sogehtsoftware.de
DESIGN FOR TESTING
Die Entwicklung
33

32. Seite sogehtsoftware.de
Die Entwicklung
DESIGN FOR TESTING
Sprint-
Backlog VCS BUILD
Produkt-
Inkrement
Coden
Code
34

33. Seite sogehtsoftware.de
Die Entwicklung und die QA
DESIGN FOR TESTING
Sprint-
Backlog VCS BUILD
Produkt-
Inkrement
Coden
Code
QA

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. 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. Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 41
QA-Schlachtplan

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. 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. 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. Seite sogehtsoftware.de
DESIGN FOR TESTING
Kay Grebenstein 45
QA-Schlachtplan
repository
• Wo werden die
Testartefakte
gespeichert?
• Gibt es
unterschiedliche
Artefakte?

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. 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. 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. 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. 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. Seite sogehtsoftware.de
IHR KONTAKT Telefon:
E-Mail:
sogehtsoftware.de
ZZ
Kay Grebenstein
Supertester
+49 351 49701 688
kay.grebenstein@saxsys.de