Technischer Report zur Umfrage 2011:

Transkript

1 Technischer Report zur Umfrage 2011: Softwaretest in der Praxis Nummer des Dokuments: SW-TU TR 13-1 Institutionen: Hochschule Bremerhaven Hochschule Bremen Fachhochschule Köln Sachtitel: Softwaretest-Umfrage 2011 Untertitel: Autoren: Detaillierte Ergebnisse Karin Vosseberg Andreas Spillner Mario Winter Karin Valbert-Polenske Veröffentlichungsdatum: Herbst 2013

2 Wissenschaftliche Leitung Förderer Unterstützer

3 I Abstract Der vorliegende technische Report befasst sich thematisch insbesondere mit der Datenerhebung und der Auswertung der Umfrage 2011: Softwaretest in der Praxis, welche auf der Grundlage einer Online-Befragung in softwareentwickelnden Unternehmen unterschiedlicher Größen und Branchen innerhalb von Deutschland, Österreich und der Schweiz im Frühjahr 2011 durchgeführt wurde. Der Report erörtert den aktuellen Stand der Qualitäts- und Testaktivitäten in der Praxis und analysiert den Handlungsbedarf im Testen für Forschung, Ausbildung und Beratung. [URL_SOFT] Der Bericht liefert einen umfassenden Einblick in den Aufbau und die Durchführung der Umfrage. Er erläutert die verwendeten Analyseverfahren, mit denen die erhobenen Datensätze ausgewertet worden sind. Eine Zusammenfassung aller wesentlichen Ergebnisse zu speziellen Fragestellungen findet sich ebenso im Report wie eine ausführliche Auflistung sämtlicher Analyseergebnisse zu allen Fragen des Fragebogens. Dieser ist dem Anhang (siehe Anhang A )des Reports beigefügt. Wir möchten uns an dieser Stelle bei allen 1623 Teilnehmern der Umfrage recht herzlich bedanken. Wir hoffen, dass Ihnen dieser Report die Möglichkeit eröffnet, Ihr Vorgehen beim Testen in Relation zum aktuellen Vorgehen in der Praxis zu setzen und daraus Ihre Schlüsse für Verbesserungen zu ziehen. [URL_PRAXIS]

4 II

5 III Inhaltsverzeichnis Seite 1 Einleitung Motivation Veröffentlichungen Aufbau der Umfrage Rollenspezifische Aufteilung Der Fragebogen Teilnahmezahlen Durchführung der Datenanalysen Variablenauswahl, Skalierung und Auswahl der Analyseverfahren Univariate Ergebnisse des gesamten Fragebogens Tabellarische Auswertung von univariaten Analysen Fragenkomplex 1 Allgemeines zum Unternehmen Frage 1.1 Rollenzuordnung Frage 1.2 Anzahl Mitarbeiter im Unternehmen Frage 1.3 Anzahl Mitarbeiter in der SE Frage 1.4 Softwareentwicklung für Frage 1.5 Hauptaufgaben / -projekte Frage 1.6 Migration Frage 1.7 Vorgehen für Migration Frage 1.8 Projekte im Unternehmen Frage 1.9 Branche Frage 1.10 Größenklassen durchgeführter Projekte Frage 1.11 Projektdauer Fragenkomplex 2 Fragen zum Vorgehensmodell Frage 2.1 Vorgehensmodell Frage Phasenmodell zur Softwareentwicklung Frage Phasen der Softwareentwicklung Frage Agile Vorgehensmodelle Frage Qualitätssicherung in Sprints Frage Praktiken agiler VM mit Blick auf QS Frage 2.2 Bedarf bei Vorgehensmodellen Fragenkomplex 3 Risiko- und Qualitätssicherungsmanagement Frage 3.1 Risikomanagement Frage Überprüfung von Risiken Frage Die drei größten Risiken Frage Gründe gegen Risikoanalyse Frage 3.2 Selbständige Qualitätssicherungsgruppe Frage Zuordnung QS-Gruppen / -Abteilungen Frage Anzahl Personen in der QS Frage Prozentualer Anteil verglichen mit SE-Beschäftigte Frage 3.3 Verantwortlicher für die QS in Projekten Frage 3.4 Entscheidung über Maßnahmen zur QS Frage 3.5 Ziele der QS Frage Weitere Ziele der QS Fragenkomplex 4 Maßnahmen zur Qualitätssicherung Frage 4.1 Reviews in Projekten Frage Dokumente für Reviews Frage Andere Dokumente Frage Personengruppen, die Reviews durchführen... 83

6 IV Frage 4.2 Tests auf unterschiedlichen Teststufen Frage Teststufen Frage Andere Teststufen Frage Personengruppen für Test unterschiedlicher Teststufen Frage 4.3 Unterscheidung unterschiedlicher Testarten Frage Spezielle Testarten Frage Andere Testarten Frage Personengruppen, die Tests der Testarten durchführen Fragenkomplex 5 Aufwandsschätzung Frage 5.1 Aufwandsplanung der QS Frage Aufwandsplanung QS: Verhältnis zum Gesamtaufwand Frage Geplantes Budget für die QS Frage Gewichtung der Maßnahmen zur QS Frage Andere Maßnahmen der QS Fragenkomplex 6 Fehlermanagement Frage 6.1 Dokumentation gefundener Fehler Frage 6.2 gefundene Fehler Frage 6.3 Fehlernachtests Frage 6.4 Bedarf für Risiko- und Qualitätsmanagement Fragenkomplex 7 Testprozess Frage 7.1 Durchführung von Testaktivitäten Frage 7.2 Audits Frage 7.3 Systemumgebung Frage Andere Systeme Frage 7.4 Administrator der Testumgebung Frage 7.5 Testvorbereitung Frage Weitere Aktivitäten der Testvorbereitung Frage 7.6 Beschreibung der Testfälle Frage 7.7 Personen, die Testfälle erstellen Frage 7.8 Unterscheidung zw. Testfall- und Testdatenerstellung Frage 7.9 Testdaten Frage 7.10 Erwartete Testergebnisse Frage 7.11 Effektivität der Testfälle Frage 7.12 Fehler nach der Auslieferung Frage 7.13 Kennzahlen zur Bewertung des Test-Endes Frage 7.14 Testendkriterien Frage 7.15 Einhaltung der Testendkriterien Frage 7.16 Bedarf für den Testprozess Fragenkomplex 8 Testverfahren Frage 8.1 Verfahren für den statischen Test Frage 8.2 Verfahren für werkzeuggestützte Analysen Frage 8.3 Verfahren für den dynamischen Test Frage 8.4 Black-Box Verfahren Frage 8.5 White-Box Verfahren Frage 8.6 Erfahrungsbasierte Verfahren Frage 8.7 Bedarf bei statischen und dynamischen Verfahren Fragenkomplex 9 Testwerkzeuge Frage 9.1 Einsatz von Testwerkzeugen Frage Testwerkzeuge in Planung Frage Jährlicher Aufwand für Testwerkzeuge Frage Grad der Automatisierung

7 V Frage Testaktivitäten für den Einsatz von Testwerkzeug Frage Eingesetzte Kategorien von Testwerkzeugen Frage Weitere Arten / Kategorien von Werkzeugen Frage Konkreter Einsatz welcher Testwerkzeuge Frage 9.2 Auswahl / Pilotierung durch Testwerkzeug-Labor Frage 9.3 Bedarf von Testwerkzeugen Fragenkomplex 10 Qualifizierung und Weiterbildung Frage 10.1 Unterstützung von QS Weiterbildung Frage 10.2 Weiterbildung / Informationsbeschaffung Frage 10.3b Treffen Regionalgruppe Deutschland Frage 10.3b Treffen Regionalgruppe Österreich Frage 10.3d Treffen Regionalgruppe Schweiz Frage 10.4 Bekanntheit ISTQB Ausbildungsschema Frage ISTQB Foundation Level-Zertifikat Frage ISTQB Foundation Level fehlende Themen Frage ISTQB Advanced Level-Zertifikat Frage ISTQB Advanced Level fehlende Themen Frage ISTQB Expert Level wichtige Themen Frage ISTQB Expert Level weitere Themen Frage 10.5 Bedarf von Aus- / Weiterbildungsmaßnahmen Fragenkomplex 11 Zur Person Frage 11.1 Geschlecht Frage 11.2 Berufserfahrung in der Industrie Frage 11.3 Land der Beschäftigung Frage 11.4 Ausbildung Frage Studienrichtung Frage 11.5 Anmerkung zur Umfrage Multivariate Ergebnisse Ausgesuchte Thesen Tabellarische Auswertungen von multivariaten Analysen Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Multivariate Ergebnisse These Zusammenfassung Literaturverzeichnis Anhang A Der Fragebogen B Zuordnung der Variablenkennung zu den Fragen C Thesen und Ergebnisse der Umfrage von Müller C.1 These C.2 These C. 3 These C. 4 These

8 VI C. 5 These C. 6 These C. 7 These C. 8 These C. 9 These C. 10 These C. 11 These C. 12 These C. 13 These

9 VII Abbildungsverzeichnis Abbildung 2-1: Rollenzuordnung... 3 Abbildung 4-1: Rollenzuordnung anhand der Hauptaufgaben... 7 Abbildung 4-2: Anzahl Mitarbeiter im Unternehmen... 8 Abbildung 4-3: Anzahl Mitarbeiter Softwareentwicklung... 9 Abbildung 4-4: Softwareentwicklung für Abbildung 4-5: Hauptaufgaben / Projekte Abbildung 4-6: Ablösung von Softwaresystemen Abbildung 4-7: Vorgehen für Migration Abbildung 4-8: Projekte im Unternehmen Abbildung 4-9: Einordnung des Vorgehensmodells Abbildung 4-10: Phasenmodell zur Softwareentwicklung Abbildung 4-11: Phasen der Softwareentwicklung Vorstudie Abbildung 4-12: Phasen der Softwareentwicklung - Fachkonzept Abbildung 4-13: Phasen der Softwareentwicklung Systementwurf Abbildung 4-14: Phasen der Softwareentwicklung Realisierung Abbildung 4-15: Phasen der Softwareentwicklung Integration Abbildung 4-16: Phasen der Softwareentwicklung Abnahme Abbildung 4-17: agile Vorgehensmodelle zur Softwareentwicklung Abbildung 4-18: Wortwolke der Antworten zu Frage Abbildung 4-19: Häufigkeit der Risikenüberprüfung Abbildung 4-20: Wortwolke der Antworten zu Frage Abbildung 4-21: Gründe gegen eine Risikoanalyse Abbildung 4-22: Selbständige Qualitätssicherungsgruppe Abbildung 4-23: Zuordnung der Qualitätssicherungsgruppe/ -abteilung Abbildung 4-24: Anzahl der Personen in der QS Abbildung 4-25: Prozentualer Anteil Abbildung 4-26: Entscheidung über Maßnahmen zur Qualitätssicherung Abbildung 4-27: Ziele Qualitätssicherung Kostensenkung Abbildung 4-28: Ziele Qualitätssicherung - Erhöhung der Leistungsfähigkeit Abbildung 4-29: Ziele Qualitätssicherung Erhöhung der Standardisierung Abbildung 4-30: Ziele Qualitätssicherung Erhöhung der Automatisierung Abbildung 4-31: Wortwolke der Antworten zu Frage Abbildung 4-32: Reviews in Projekten Abbildung 4-33: Dokumente für Reviews Anforderungen Abbildung 4-34: Dokumente für Reviews Architektur Abbildung 4-35: Dokumente für Reviews Design Abbildung 4-36: Dokumente für Reviews Code Abbildung 4-37: Dokumente für Reviews Testfälle Abbildung 4-38: Wortwolke der Antworten zu Frage Abbildung 4-39: Tests auf unterschiedlichen Teststufen Abbildung 4-40: Teststufen Unit-/Modul-/Klassen-/Komponententest Abbildung 4-41: Teststufen Integrationstest Abbildung 4-42: Teststufen Systemtest Abbildung 4-43: Teststufen Abnahmetest Abbildung 4-44: Wortwolke der Antworten zu Frage Abbildung 4-45: Wer testet auf unterschiedlichen Teststufen? Abbildung 4-46: Unterscheidung unterschiedlicher Testarten Abbildung 4-47: Testarten Last-/Performancetest Abbildung 4-48: Testarten Migrationstest... 95

10 VIII Abbildung 4-49: Testarten Regressionstest Abbildung 4-50: Testarten Smoketest Abbildung 4-51: Testarten Sicherheitstest/Penetrationstest Abbildung 4-52: Wortwolke der Antworten zu Frage Abbildung 4-53: Wer testet in den verschiedenen Testarten? Abbildung 4-54: Planung des Aufwands (Budget und Zeit) der Qualitätssicherung Abbildung 4-55: Gesamt-Budget prozentualer Anteil Abbildung 4-56: Gesamt-Zeit Prozentualer Anteil Abbildung 4-57: Geplantes Budget / Zeit für die Qualitätssicherung Abbildung 4-58: Maßnahmen QS Reviews Abbildung 4-59: Maßnahmen QS Unit-/Modul-/Klassen-/Komponententest Abbildung 4-60: Maßnahmen QS Integrationstest Abbildung 4-61: Maßnahmen QS Systemtest Abbildung 4-62: Maßnahmen QS Abnahmetest Abbildung 4-63: Dokumentation gefundener Fehler Abbildung 4-64: gefundene Fehler einer Fehlerklasse zugeordnet Abbildung 4-65: gefundene Fehler einer Priorität zugeordnet Abbildung 4-66: gefundene Fehler entsprechend seiner Priorität korrigiert Abbildung 4-67: Fehlernachtests fehleraufdeckende Testfälle wiederholt Abbildung 4-68: Fehlernachtests weitere Testfälle aus Fehlerumfeld ausgeführt Abbildung 4-69: Fehlernachtests alle Testfälle als vollständiger Regressionstest Abbildung 4-70: Fehlernachtests keine Testfälle ausgeführt Abbildung 4-71: Wortwolke der Antworten zu Frage Abbildung 4-72: Durchführung von Testaktivitäten nach festgelegtem Prozess Abbildung 4-73: Testprozess in Abhängigkeit der Anzahl Mitarbeiter in der SE Abbildung 4-74: Systemumgebung Produktivsystem Abbildung 4-75: Systemumgebung gesondertes Testsystem Abbildung 4-76: Systemumgebung Entwicklungssystem Abbildung 4-77: Systemumgebung Integrationssystem Abbildung 4-78: Systemumgebung Pre-Life-System Abbildung 4-79: Wortwolke der Antworten zu Frage Abbildung 4-80: Zuständigkeit für die Administration Testumgebung Abbildung 4-81: Testvorbereitung Review/Analyse der Testbasis auf Testbarkeit Abbildung 4-82: Testvorbereitung Testfallerstellung Abbildung 4-83: Testvorbereitung Testdatendefinition Abbildung 4-84: Testvorbereitung Testdatenerstellung Abbildung 4-85: Wortwolke der Antworten zu Frage Abbildung 4-86: Beschreibung Testfälle frei verbal / textuell Abbildung 4-87: Beschreibung Testfälle mit standardisierten Formularen Abbildung 4-88: Beschreibung Testfälle mit formal textueller Sprache Abbildung 4-89: Beschreibung Testfälle mit graphischer Modellierungssprache Abbildung 4-90: Beschreibung Testfälle aus Modellen generiert Abbildung 4-91: Beschreibung Testfälle während Testdurchführung Abbildung 4-92: Beschreibung Testfälle werkzeuggestützt erfasst und verwaltet Abbildung 4-93: Personen, die Testfälle erstellen Abbildung 4-94: Explizite Unterscheidung zw. Testfall- und Testdatenerstellung Abbildung 4-95: Testdaten Ausführliche Dokumentation Abbildung 4-96: Testdaten Erfassung mit standardisierten Formularen Abbildung 4-97: Testdaten (Anonymisierte) Kopie der Produktionsdaten Abbildung 4-98: Testdaten Originalproduktionsdaten Abbildung 4-99: Testdaten Zusammenfassung in einer Testdatenbibliothek

11 IX Abbildung 4-100: erwartete Ergebnisse Festlegung vor Testdurchführung Abbildung 4-101: erwartete Ergebnisse Manueller Vergleich Abbildung 4-102: erwartete Ergebnisse Automatischer Vergleich Abbildung 4-103: erwartete Ergebnisse Verfügbar für spätere Tests Abbildung 4-104: Effektivität der Testfälle Abbildung 4-105: Effektivität der Testfälle bei Prozesstrennung Abbildung 4-106: Fehler nach Auslieferung Abbildung 4-107: Fehler nach Auslieferung bei Prozesstrennung Abbildung 4-108: Kennzahlen zur Bewertung des Testendes Abbildung 4-109: Testendkriterien Alle Testfälle sind auszuführen Abbildung 4-110: Testendkriterien Anforderung mindestens einmal getestet Abbildung 4-111: Testendkriterien Vorgesehenes Testbudget ausgeschöpft Abbildung 4-112: Testendkriterien Auslieferungszeitpunkt erreicht Abbildung 4-113: Testendkriterien Für Vertrauen genug Fehler gefunden Abbildung 4-114: Testendkriterien Geforderte Werte der Kennzahlen erreicht Abbildung 4-115: Einhaltung der Testendkriterien Abbildung 4-116: Wortwolke der Antworten zu Frage Abbildung 4-117: Verfahren für den statischen Test Abbildung 4-118: Verfahren für werkzeuggestützte Analysen Abbildung 4-119: Black-Box Testverfahren Abbildung 4-120: White-Box Testverfahren Abbildung 4-121: Erfahrungsbasierte Testverfahren Abbildung 4-122: Wortwolke der Antworten zu Frage Abbildung 4-123: Einsatz von Testwerkzeugen Abbildung 4-124: Einsatz von Testwerkzeugen in Planung Abbildung 4-125: Grad der Automatisierung Unittest Abbildung 4-126: Grad der Automatisierung Integrationstest Abbildung 4-127: Grad der Automatisierung Systemtest Abbildung 4-128: Grad der Automatisierung Abnahmetest Abbildung 4-129: Testaktivitäten für den Einsatz von Werkzeug Abbildung 4-130: Einsatz von Testwerkzeugen Abbildung 4-131: Wortwolke der Antworten zu Frage Abbildung 4-132: Wortwolke der Antworten zu Frage Abbildung 4-133: Auswahl durch herstellerneutrales Testwerkzeug-Labor Abbildung 4-134: Wortwolke der Antworten zu Frage Abbildung 4-135: Weiterbildung in Bezug zur Unternehmensgröße Abbildung 4-136: ASQF Arbeitskreis Software-Qualität und -Fortbildung e.v Abbildung 4-137: Abbildung 3 290: GI Gesellschaft für Informatik Abbildung 4-138: GI TAV FG Testen, Verifizieren, Analysieren Abbildung 4-139: Softwareforen Leipzig Abbildung 4-140: ASQF Arbeitskreis Software-Qualität und -Fortbildung e.v Abbildung 4-141: ATB SW Test Network Meeting Abbildung 4-142: ÖGI Österreichische Gesellschaft für Informatik Abbildung 4-143: STEV Öster. Vereinigung für Software-Qualitätsmanagement Abbildung 4-144: ADV Arbeitsgemeinschaft für Datenverarbeitung Abbildung 4-145: Future Network Abbildung 4-146: SI Schweizer Informatik Gesellschaft Abbildung 4-147: STB Swiss Software Tester Forum Abbildung 4-148: SwissQ SwissTesting Day Abbildung 4-149: SwissQ Swiss Testing Nights Abbildung 4-150: bbv QEvent

12 X Abbildung 4-151: Bekanntheit des ISTQB Ausbildungsschemas Abbildung 4-152: Bekanntheit von ISTQB im Management Abbildung 4-153: Bekanntheit von ISTQB bei Testern Abbildung 4-154: Bekanntheit von ISTQB bei Entwicklern Abbildung 4-155: Besitz des ISTQB Foundation Level Zertifikats Abbildung 4-156: Wortwolke der Antworten zu Frage Abbildung 4-157: Besitz des ISTQB Advanced Level Zertifikats Abbildung 4-158: Wortwolke der Antworten zu Frage Abbildung 4-159: Wortwolke der Antworten zu Frage Abbildung 4-160: Wortwolke der Antworten zu Frage Abbildung 4-161: Geschlecht Abbildung 4-162: Berufserfahrung Abbildung 4-163: Land der Beschäftigung / Tätigkeit Abbildung 4-164: Art der Ausbildung Abbildung 4-165: Studienrichtung Abbildung 4-166: Wortwolke der Antworten zu Frage Abbildung 5-1: Symmetrische Maße zur Analyse von These Abbildung 5-2: Kreuztabelle zur Analyse von These Abbildung 5-3: Symmetrische Maße Standardsoftware Aufwandsplanung Abbildung 5-4: Kreuztabelle Standardsoftware Aufwandsplanung Abbildung 5-5: Symmetrische Maße Individualsoftware Aufwandsplanung Abbildung 5-6: Kreuztabelle Individualsoftware Aufwandsplanung

13 XI Tabellenverzeichnis Tabelle 2-1: Fragebogen-Kategorien der Umfrage 2011 mit zugehöriger Fragenanzahl. 4 Tabelle 4-1: Rollenzuordnung anhand der Hauptaufgaben... 7 Tabelle 4-2: Anzahl Mitarbeiter im Unternehmen... 8 Tabelle 4-3: Anzahl Mitarbeiter Softwareentwicklung... 9 Tabelle 4-4: Softwareentwicklung für Tabelle 4-5: Hauptaufgaben / Projekte im Unternehmen Tabelle 4-6: Ablösung von Softwaresystemen Tabelle 4-7: Vorgehen für Migration Tabelle 4-8: Projekte im Unternehmen Tabelle 4-9: Branche Öffentliche Hand (Verwaltung) Tabelle 4-10: Branche Finanzdienstleister Tabelle 4-11: Branche Dienstleistung Tabelle 4-12: Branche - Leichtindustrie Tabelle 4-13: Branche Schwer- bzw. Grundstoffindustrie Tabelle 4-14: Größenklassen durchgeführter Projekte Tabelle 4-15: Projektdauer kürzer als 0,5 Jahre Tabelle 4-16: Projektdauer zwischen 0,5 und 1 Jahr Tabelle 4-17: Projektdauer zwischen 1 und 2 Jahren Tabelle 4-18: Projektdauer länger als 2 Jahre Tabelle 4-19: Einordnung des Vorgehensmodells Tabelle 4-20: Phasenmodell zur Softwareentwicklung Tabelle 4-21: Phasen der Softwareentwicklung Vorstudie Tabelle 4-22: Phasen der Softwareentwicklung Fachkonzept Tabelle 4-23: Phasen der Softwareentwicklung Systementwurf Tabelle 4-24: Phasen der Softwareentwicklung Realisierung Tabelle 4-25: Phasen der Softwareentwicklung Integration Tabelle 4-26: Phasen der Softwareentwicklung Abnahme Tabelle 4-27: agile Vorgehensmodelle zur Softwareentwicklung Tabelle 4-28: Qualitätssicherung in Sprints Tabelle 4-29: Praktiken agiler Vorgehensmodelle in Hinblick auf QS Tabelle 4-30: Antworten zu Frage Tabelle 4-31: Risikomanagement in Softwareprojekten Tabelle 4-32: Häufigkeit der Überprüfung der Risiken Tabelle 4-33: Antworten zu Frage Tabelle 4-34: Gründe gegen eine Risikoanalyse Tabelle 4-35: Selbständige Qualitätssicherungsgruppe Tabelle 4-36: Zuordnung der Qualitätssicherungsgruppe/ -abteilung Tabelle 4-37: Verantwortlicher für Qualitätssicherung in Projekten Tabelle 4-38: Entscheidung über Maßnahmen zur Qualitätssicherung Tabelle 4-39: Ziele Qualitätssicherung Kostensenkung Tabelle 4-40: Ziele Qualitätssicherung Erhöhung der Leistungsfähigkeit Tabelle 4-41: Ziele Qualitätssicherung Erhöhung der Standardisierung Tabelle 4-42: Ziele Qualitätssicherung Erhöhung der Automatisierung Tabelle 4-43: Antworten zu Frage Tabelle 4-44: Reviews in Projekten Tabelle 4-45: Dokumente für Reviews Anforderungen Tabelle 4-46: Dokumente für Reviews Architektur Tabelle 4-47: Dokumente für Reviews Design Tabelle 4-48: Dokumente für Reviews Code... 79

14 XII Tabelle 4-49: Dokumente für Reviews Testfälle Tabelle 4-50: Antworten zu Frage Tabelle 4-51: Personengruppen die Reviews durchführen Tabelle 4-52: Tests auf unterschiedlichen Teststufen Tabelle 4-53: Teststufen - Unit-/Modul-/Klassen-/Komponententest Tabelle 4-54: Teststufen Integrationstest Tabelle 4-55: Teststufen Systemtest Tabelle 4-56: Teststufen Abnahmetest Tabelle 4-57: Antworten zu Frage Tabelle 4-58: Personengruppen für Tests auf unterschiedlichen Teststufen Tabelle 4-59: Unterscheidung unterschiedlicher Testarten Tabelle 4-60: Testarten Last-/Performancetest Tabelle 4-61: Testarten Migrationstest Tabelle 4-62: Testarten Regressionstest Tabelle 4-63: Testarten Smoketest Tabelle 4-64: Testarten Sicherheitstest/Penetrationstest Tabelle 4-65: Antworten zu Frage Tabelle 4-66: Personengruppen die Tests der Testarten durchführen Tabelle 4-67: Planung des Aufwands (Budget und Zeit) der Qualitätssicherung Tabelle 4-68: Geplantes Budget / Zeit für die Qualitätssicherung Tabelle 4-69: Maßnahmen QS Reviews Tabelle 4-70: Maßnahmen QS Unit-/Modul-/Klassen-/Komponententest Tabelle 4-71: Maßnahmen QS Integrationstest Tabelle 4-72: Maßnahmen QS Systemtest Tabelle 4-73: Maßnahmen QS Abnahmetest Tabelle 4-74: Dokumentation gefundener Fehler Tabelle 4-75: gefundene Fehler einer Fehlerklasse zugeordnet Tabelle 4-76: gefundene Fehler einer Priorität zugeordnet Tabelle 4-77: gefundene Fehler entsprechend seiner Priorität korrigiert Tabelle 4-78: Fehlernachtests fehleraufdeckende Testfälle wiederholt Tabelle 4-79: Fehlernachtests weitere Testfälle aus dem Fehlerumfeld ausgeführt. 117 Tabelle 4-80: Fehlernachtests alle Testfälle als vollständiger Regressionstest Tabelle 4-81: Fehlernachtests keine Testfälle ausgeführt Tabelle 4-82: Antworten zu Frage Tabelle 4-83: Durchführung von Testaktivitäten nach festgelegtem Prozess Tabelle 4-84: Audit, dem der Testprozess unterzogen wird Tabelle 4-85: Systemumgebung Produktivsystem Tabelle 4-86: Systemumgebung gesondertes Testsystem Tabelle 4-87: Systemumgebung Entwicklungssystem Tabelle 4-88: Systemumgebung Integrationssystem Tabelle 4-89: Systemumgebung Pre-Life-System Tabelle 4-90: Antworten zu Frage Tabelle 4-91: Zuständigkeit für die Administration der Testumgebung Tabelle 4-92: Testvorbereitung Review/Analyse der Testbasis auf Testbarkeit Tabelle 4-93: Testvorbereitung Testfallerstellung Tabelle 4-94: Testvorbereitung Testdatendefinition Tabelle 4-95: Testvorbereitung Testdatenerstellung Tabelle 4-96: Antworten zu Frage Tabelle 4-97: Beschreibung Testfälle frei verbal / textuell Tabelle 4-98: Beschreibung Testfälle mit standardisierten Formularen Tabelle 4-99: Beschreibung Testfälle mit formal textueller Sprache

15 XIII Tabelle 4-100: Beschreibung Testfälle mit graphischer Modellierungssprache Tabelle 4-101: Beschreibung Testfälle aus Modellen generiert Tabelle 4-102: Beschreibung Testfälle während Testdurchführung Tabelle 4-103: Beschreibung Testfälle werkzeuggestützt erfasst und verwaltet Tabelle 4-104: Personen, die Testfälle erstellen Tabelle 4-105: Explizite Unterscheidung zw. Testfall- und Testdatenerstellung Tabelle 4-106: Testdaten Ausführliche Dokumentation Tabelle 4-107: Testdaten Erfassung mit standardisierten Formularen Tabelle 4-108: Testdaten (Anonymisierte) Kopie der Produktionsdaten Tabelle 4-109: Testdaten Originalproduktionsdaten Tabelle 4-110: Testdaten Zusammenfassung in einer Testdatenbibliothek Tabelle 4-111: erwartete Ergebnisse Festlegung vor Testdurchführung Tabelle 4-112: erwartete Ergebnisse Manueller Vergleich Tabelle 4-113: erwartete Ergebnisse Automatischer Vergleich Tabelle 4-114: erwartete Ergebnisse Verfügbar für spätere Tests Tabelle 4-115: Effektivität der Testfälle Tabelle 4-116: Fehler nach Auslieferung Tabelle 4-117: Kennzahlen zur Bewertung des Testendes Tabelle 4-118: Testendkriterien Alle Testfälle sind auszuführen Tabelle 4-119: Testendkriterien Anforderung mindestens einmal getestet Tabelle 4-120: Testendkriterien Vorgesehenes Testbudget ausgeschöpft Tabelle 4-121: Testendkriterien Auslieferungszeitpunkt erreicht Tabelle 4-122: Testendkriterien Für Vertrauen genug Fehler gefunden Tabelle 4-123: Testendkriterien Geforderte Werte der Kennzahlen erreicht Tabelle 4-124: Einhaltung der Testendkriterien Tabelle 4-125: Antworten zu Frage Tabelle 4-126: Verfahren für den statischen Test Tabelle 4-127: Verfahren für werkzeuggestützte Analysen Tabelle 4-128: Verfahren für den dynamischen Test Tabelle 4-129: Black-Box Testverfahren Tabelle 4-130: White-Box Testverfahren Tabelle 4-131: Erfahrungsbasierte Testverfahren Tabelle 4-132: Antworten zu Frage Tabelle 4-133: Einsatz von Testwerkzeugen Tabelle 4-134: Einsatz von Testwerkzeugen in Planung Tabelle 4-135: Grad der Automatisierung Unittest Tabelle 4-136: Grad der Automatisierung Integrationstest Tabelle 4-137: Grad der Automatisierung Systemtest Tabelle 4-138: Grad der Automatisierung Abnahmetest Tabelle 4-139: Testaktivitäten für den Einsatz von Werkzeug Tabelle 4-140: Einsatz von Testwerkzeugen Tabelle 4-141: Antworten zu Frage Tabelle 4-142: Antworten zu Frage Tabelle 4-143: Auswahl/Pilotierung durch herstellerneutrales Testwerkzeug-Labor Tabelle 4-144: Antworten zu Frage Tabelle 4-145: Unterstützung der Weiterbildung im Bereich QS Tabelle 4-146: Weiterbildung/Informationsbeschaffung durch Tabelle 4-147: Informationsquellen der Tester Tabelle 4-148: Informationsquellen der Manager Tabelle 4-149: ASQF Arbeitskreis Software-Qualität und -Fortbildung e.v Tabelle 4-150: GI Gesellschaft für Informatik

16 XIV Tabelle 4-151: GI TAV FG Testen, Verifizieren, Analysieren Tabelle 4-152: Softwareforen Leipzig Tabelle 4-153: ASQF Arbeitskreis Software-Qualität und -Fortbildung e.v Tabelle 4-154: ATB SW Test Network Meeting Tabelle 4-155: ÖGI Österreichische Gesellschaft für Informatik Tabelle 4-156: STEV Österreich Vereinigung für Software-Qualitätsmanagement. 225 Tabelle 4-157: ADV Arbeitsgemeinschaft für Datenverarbeitung Tabelle 4-158: Future Network Tabelle 4-159: SI Schweizer Informatik Gesellschaft Tabelle 4-160: STB Swiss Software Tester Forum Tabelle 4-161: SwissQ SwissTesting Day Tabelle 4-162: SwissQ Swiss Testing Nights Tabelle 4-163: bbv QEvent Tabelle 4-164: Bekanntheit des ISTQB Ausbildungsschemas Tabelle 4-165: Besitz des ISTQB Foundation Level Zertifikats Tabelle 4-166: Verbreitung des ISTQB Foundation Level Zertifikats Tabelle 4-167: Antworten zu Frage Tabelle 4-168: Besitz des ISTQB Advanced Level Zertifikats Tabelle 4-169: Antworten zu Frage Tabelle 4-170: Wichtige Themen für ISTQB Expert Level Tabelle 4-171: Tabelle zu Frage Tabelle 4-172: Antworten zu Frage Tabelle 4-173: Geschlecht Tabelle 4-174: Berufserfahrung Tabelle 4-175: Land der Beschäftigung / Tätigkeit Tabelle 4-176: Art der Ausbildung Tabelle 4-177: Studienrichtung Tabelle 4-178: Antworten zu Frage

17 1 1 Einleitung 1.1 Motivation In den letzten Jahren gab es im Bereich Qualitätssicherung und Testen viele neue Trends wie z.b. Test-Driven Development, exploratives Testen, modellbasiertes Testen oder auch die agilen Vorgehensmodelle. Diese Trends bieten Chancen als auch Herausforderungen in Test und Qualitätssicherung. Was davon hat bereits Einzug in den Test-Alltag gehalten? Hat sich in den letzten Jahren etwas verändert? Wie sieht der Test- Alltag heute in den Unternehmen überhaupt aus? Diese und weitere Fragen waren Grundlage für die Umfrage 2011»Softwaretest in der Praxis«[URL_SOFT]. Im Mai 2011 wurde in Kooperation der Hochschulen Bremen und Bremerhaven, der Fachhochschule Köln, der ANECON Software Design und Beratung GmbH, dem German Testing Board e.v. (GTB) und dem Swiss Testing Board (STB) eine anonyme Online-Umfrage zum Thema»Softwaretest in der Praxis«im deutschsprachigen Raum durchgeführt. Ein Teil der Fragen wurde aus einer Umfrage aus dem Jahr 1997 (»Prüfund Testprozesse in der Softwareentwicklung«, [MWA98]) übernommen, um Veränderungen und neue Trends im Bereich der Qualitätssicherung bei der Softwareentwicklung aufzuzeigen. 1.2 Veröffentlichungen ILIAS-Umfragekomponente: Erfahrungen mit großen Umfragen ILIAS Anwendertreffen Nord 21. Juni 2011 an der HS Bremen Testwerkzeuge in der Praxis Ergebnisse der Umfrage 2011: Softwaretest in der Praxis 6. Arbeitstreffen User Group >>Softwaretest und Qualitätssicherung<< 12./13. September 2011 in Leipzig Testen von Software systematisch oder agil? 3. Baden-Württemberg Testing-Day >>Baden-Württemberg testet<< 20. Oktober 2010 in Stuttgart Wie agil sind wir? Software-QS-Tag 2011 >>Test und QS agil<< 2./3. November 2011 in Nürnberg You are here Erste Ergebnisse der >>Umfrage 2011: Softwaretest in der Praxis<< German Testing Day November 011 in Frankfurt am Main Überraschende, unerwartete und erfreuliche Ergebnisse der anonymen Online-Umfrage 2011: Softwaretest in der Praxis 32. Treffen der GI Fachgruppe TAV 17./18. November 2011

18 2 Quo vadis Softwaretest? Ergebnisse einer aktuellen Online-Umfrage 4. Symposium Testen im System- und Software-Life-Cycle Embedded Systems meet IT 23. November 2011 in Ostfildern/Stuttgart (Veranstaltung wurde kurzfristig abgesagt) Sichtbarkeit von Testaktivitäten Ergebnisse aus der Umfrage 2011 Softwaretest in der Praxis Treffen der ASQF-FG Softwaretest Nord und der GI Regionalgruppe Bremen/Oldenburg 29. November 2011, Bremen Trends und Ergebnisse der >>Umfrage 2011: Softwaretest in der Praxis<< Software Quality Days Januar 2012, Wien Softwaretest-Umfrage 2011 Erkenntnisziele, Durchführung und Ergebnisse SE2012: Software Engineering Februar 2. März 2012, Berlin Ergebnisse der Umfrage 2011: Softwaretest in der Praxis Swiss Testing Day März 2012 Zürich, Schweiz Ergebnisse der Umfrage Treffen der GI Fachgruppe Vorgehensmodelle für die betriebliche Anwendungsentwicklung (WI-VM) 27./28. März 2012, Düsseldorf Testskills in der Praxis Thesenbasierte Teilauswertung der Umfrage Softwaretest in der Praxis - Bachelorarbeit 2012, Hochschule Bremerhaven Statistische Auswertung der Umfrage 2011: Softwaretest in der Praxis Praxisprojektarbeit 2013, Fachhochschule Köln Multivariate Analysen, Validierung und Weiterentwicklung der Umfrage 2011: Softwaretest in der Praxis Bachelorarbeit 2013, Fachhochschule Köln

19 3 2 Aufbau der Umfrage 2.1 Rollenspezifische Aufteilung Die Umfrage ist rollenspezifisch aufgebaut. Folgende drei Gruppen von Rollen im Unternehmen wurden für die unterschiedlichen Fragebogen zusammengefasst: Projektleiter, Qualitätssicherungsbeauftragte, Testmanager und Tester (Gruppe Tester) Business Analysts, Entwickler, Mitarbeiter aus Betrieb & Support und andere Mitarbeiter (Gruppe Entwickler) Executive und mittleres Management (Gruppe Management) Abbildung 2-1: Rollenzuordnung Einige Fragen wurden an alle drei Gruppen gestellt, andere wiederum waren auf die jeweiligen Rollen bezogen, um spezifische Aspekte zu erfragen. Die Beantwortung der Fragen war optional, es konnte also zur nächsten Frage weiter gegangen werden, ohne diese zu beantworten. Über alle Gruppen gleich verteilt haben 50% den sehr umfangreichen Fragebogen vollständig ausgefüllt. Mit der vorliegenden Verteilung auf die einzelnen Rollen in dem Unternehmen (Abbildung 2-1) konnte im Wesentlichen die Zielgruppe Praktiker mit unterschiedlichen Blickwinkeln auf die Qualitätssicherung (QS) sowie eine gute Datenbasis für die Auswertung erreicht werden. Um eine Verfälschung der Ergebnisse durch unterschiedliche Interpretation der Fachbegriffe zu verhindern, wurden bei fast jeder Frage die verwendeten Begriffe mit einer Definition nach dem ISTQB (International Software Testing Qualifications Board)-Glossar [ISTQB] hinterlegt.

20 4 2.2 Der Fragebogen Der Fragbogen enthielt insgesamt 110 Fragen. Davon wurden der Gruppe Tester alle 110 Fragen, der Gruppe Entwickler 63 und der Gruppe Management 51 zugeordnet. Die genaue rollenspezifische Zuordnung der Fragen ist aus Anhang B ersichtlich. Einen Überblick über die jeweiligen Themenbereiche der Kategorien des Fragebogens und die Anzahl maximal gestellter Fragen gibt die folgende Tabelle 2-1. Kategorie 1 Allgemeines zum Unternehmen 15 Fragen Kategorie 2 Fragen zum Vorgehensmodell 7 Fragen Kategorie 3 Risiko- und Qualitätsmanagement 12 Fragen Kategorie 4 Maßnahmen zur Qualitätssicherung 12 Fragen Kategorie 5 Aufwandsschätzung 6 Fragen Kategorie 6 Fehlermanagement 4 Fragen Kategorie 7 Testprozess 18 Fragen Kategorie 8 Testverfahren 7 Fragen Kategorie 9 Testwerkzeuge 10 Fragen Kategorie 10 Qualifikation und Weiterbildung 13 Fragen Kategorie 11 Zur Person 6 Fragen Tabelle 2-1: Fragebogen-Kategorien Umfrage 2011 mit zugehöriger Fragenanzahl [Quelle: ValbertBA 2013] Der Original-Fragebogen ist dem Anhang A beigefügt. Der Fragebogen setzte sich aus 73 Single-/Multiple-Choice Fragen, 19 Matrix-Fragen, die anhand einer mehrteiligen Likert-Skala beantwortet wurden, vier metrischen Fragen und 14 Fragen, die den Eintrag eines Freitextes erforderten. 2.3 Teilnahmezahlen Insgesamt 1092 Tester haben die Umfrage aufgerufen, 1008 davon die Studie gestartet, 476 haben sie bis zum Ende bearbeitet. Bei den Entwickler haben 421 die Seite aufgerufen, 394 mit der Befragung angefangen und 197 sie zu Ende gebracht. Von den Managern haben 266 die Online-Umfrage aufgerufen, 221 diese begonnen und 137 alle Fragen bis zum Ende beantwortet. Die höchste Abbruchquote lag bei den Testern, die niedrigste bei den Managern. Allen gemeinsam war der Zeitpunkt, an dem sie die Umfrage beendeten. Im Schnitt wurden im Online-Fragebogen zwischen 20 und 34 Fragen beantwortet. Somit erfolgte der Abbruch in den meisten Fällen nach Abschluss des dritten Themenfeldes Risiko- und Qualitätsmanagement. Sämtliche Fragen, die die Motivation, Prüf- und Testprozesse [Müller99] in der Praxis zu untersuchen, betreffen, finden sich erst in den späteren Frageblöcken bezüglich Fehlermanagement, Testprozess und Testverfahren (siehe Tabelle 2-1: Fragebogen-Kategorien Umfrage 2011 mit zugehöriger Fragenanzahl).

21 5 3 Durchführung der Datenanalysen 3.1 Variablenauswahl, Skalierung und Auswahl der Analyseverfahren Für den praktischen Teil, die statistische Auswertung der Rohdaten, wurde das von der Firma IBM vertriebene lizensierte Softwareprodukt SPSS Statistics in der Version 20 angewendet. SPSS ist speziell ausgelegt auf den Prozess der Datenverarbeitung. Der Daten-Editor bietet einerseits die Möglichkeit, Datensätze einzulesen, zu öffnen oder neu zu erstellen, andererseits können hier Variablen benannt, skaliert und validiert werden. Alle Antworten der Umfrage 2011 standen als Rohdatensatz einer Excel Datei zur Verfügung. Da SPSS auch Fremdformate verarbeiten kann, wurde der komplette Datensatz aus ILIAS über die entsprechende SPSS Funktion eingelesen und gespeichert. SPSS übernimmt alle Werte einer Excel-Datei und weist sie den entsprechenden Spalten der Tabelle zu. Die Variablennamen lassen jedoch in dieser Form keinen Rückschluss auf die Fragestellung zu. Um bei den tabellarischen und grafischen Auswertungen nachvollziehen zu können, welcher Frage eine Variable zuzuordnen ist, wurden alle 110 Variablen mit entsprechenden Kennungen versehen (siehe Anhang B). Ebenso wurde mit den restlichen Spalten verfahren. Um die Daten mit den entsprechenden statistischen Analyseverfahren auswerten zu können, war eine Skalierung zwingend erforderlich. Die Möglichkeiten, die SPSS anbietet, um Datensätze zu untersuchen, sind ausgesprochen vielfältig. Welche Form der Datenanalyse zum Einsatz kommt hängt von verschiedenen Faktoren ab. Im Vergleich zu univariaten Analyseverfahren, die sich auf eine Merkmalsausprägung fokussieren, beschäftigen sich die multivariaten Analysen mit zwei oder mehr Merkmalsausprägungen. Univariate Analyseverfahren verfolgen das Ziel, die Häufigkeit einer Merkmalsausprägung innerhalb eines Datensatzes zu bestimmen. Multivariate Analyseverfahren werden mit dem Ziel eingesetzt, zu überprüfen, ob und wenn ja, welche Zusammenhänge zwischen ausgesuchten Variablen existieren. Hierfür gibt es spezielle Verfahren, die, abhängig von der Skalierung der Variablen, sogenannte Zusammenhangsmaße berechnen. Aufgrund der Höhe und des jeweiligen Vorzeichens des Ergebnisses können dann Angaben über die Stärke einer möglichen Korrelation getroffen werden.

22 6 4 Univariate Ergebnisse des gesamten Fragebogens Wie bereits in Kapitel 3.1 erläutert, liegt bei univariaten Analysen der Fokus auf dem Grad der Verteilung aller im Vorfeld bestimmten Merkmalsausprägungen bezogen auf genau ein ausgesuchtes Merkmal. Dieses Kapitel umfasst sämtliche Analyseergebnisse zu allen 110 Fragen der Umfrage. Sowohl die tabellarische Darstellung der Häufigkeitsverteilungen als auch die Grafiken wurden über das Softwaretool SPSS Statistics erstellt. Fragen, die sich aus mehreren Multiple-Choice Antworten zusammensetzen, mussten mit einer besonderen statistischen Auswertung behandelt werden. SPSS bot hierfür eine spezielle Funktion an, mit deren Hilfe sogenannte Mehrfachantworten-Sets erstellt wurden. Ein stellvertretendes Beispiel für eine Datenanalyse von Mehrfachantworten- Sets zeigt die Häufigkeitstabelle der Tabelle Tabellarische Auswertung von univariaten Analysen N: Anzahl der Antworten Prozent: auf der Basis der Anzahl erhaltener Antworten Prozent der Fälle: auf der Basis der Anzahl aller Befragten, die geantwortet haben Dichotomie-Gruppe tabellarisch dargestellt bei Wert 1: alle Variablen haben in der Definition des Mehrfachantworten-Sets den Wert 1 erhalten und sind somit im Set vorhanden (0 hieße, Variable ist nicht vorhanden)

23 7 4.2 Fragenkomplex 1 Allgemeines zum Unternehmen Frage 1.1 Rollenzuordnung Welcher Rolle ordnen Sie sich mit Ihren Hauptaufgaben zu? Tabelle 4-1: Rollenzuordnung anhand der Hauptaufgaben Abbildung 4-1: Rollenzuordnung anhand der Hauptaufgaben

24 Frage 1.2 Anzahl Mitarbeiter im Unternehmen Wie viele Mitarbeiter beschäftigt ihr Unternehmen insgesamt? Tabelle 4-2: Anzahl Mitarbeiter im Unternehmen Abbildung 4-2: Anzahl Mitarbeiter im Unternehmen

25 Frage 1.3 Anzahl Mitarbeiter in der SE Wie viele Mitarbeiter beschäftigt ihr Unternehmen in der Softwareentwicklung? Tabelle 4-3: Anzahl Mitarbeiter Softwareentwicklung Abbildung 4-3: Anzahl Mitarbeiter Softwareentwicklung

26 Frage 1.4 Softwareentwicklung für Für wen wird die Software hauptsächlich entwickelt? Tabelle 4-4: Softwareentwicklung für Abbildung 4-4: Softwareentwicklung für [Quelle: Henning12]

27 Frage 1.5 Hauptaufgaben / -projekte Was sind die Haupt-Aufgaben bzw. -Projekte in Ihrem Unternehmen? Tabelle 4-5: Hauptaufgaben / Projekte im Unternehmen Abbildung 4-5: Hauptaufgaben / Projekte

28 Frage 1.6 Migration Plant Ihr Unternehmen in naher Zukunft Softwaresysteme abzulösen und durch neue zu ersetzen bzw. alte zu modernisieren (Migration)? Tabelle 4-6: Ablösung von Softwaresystemen Abbildung 4-6: Ablösung von Softwaresystemen

29 Frage 1.7 Vorgehen für Migration Gibt es ein definiertes Vorgehen für die Migration? Tabelle 4-7: Vorgehen für Migration Abbildung 4-7: Vorgehen für Migration

30 Frage 1.8 Projekte im Unternehmen In Ihrem Unternehmen werden Tabelle 4-8: Projekte im Unternehmen Abbildung 4-8: Projekte im Unternehmen

31 Frage 1.9 Branche In welcher Branche sind die Projekte/Produkte überwiegend einzuordnen? Öffentliche Hand (Verwaltung) Tabelle 4-9: Branche Öffentliche Hand (Verwaltung) Finanzdienstleister Tabelle 4-10: Branche Finanzdienstleister Dienstleistung (Service) Tabelle 4-11: Branche Dienstleistung

32 16 Leichtindustrie Tabelle 4-12: Branche - Leichtindustrie Schwer- bzw. Grundstoffindustrie Tabelle 4-13: Branche Schwer- bzw. Grundstoffindustrie

33 Frage 1.10 Größenklassen durchgeführter Projekte Welchen Größenklassen sind die durchgeführten Projekte zuzuordnen? Tabelle 4-14: Größenklassen durchgeführter Projekte

34 Frage 1.11 Projektdauer Frage 1.11 Wie lange dauern die durchgeführten Projekte? Tabelle 4-15: Projektdauer kürzer als 0,5 Jahre Tabelle 4-16: Projektdauer zwischen 0,5 und 1 Jahr Tabelle 4-17: Projektdauer zwischen 1 und 2 Jahren Tabelle 4-18: Projektdauer länger als 2 Jahre

35 Fragenkomplex 2 Fragen zum Vorgehensmodell Frage 2.1 Vorgehensmodell Wie ordnen Sie Ihr Vorgehensmodell ein? Tabelle 4-19: Einordnung des Vorgehensmodells Abbildung 4-9: Einordnung des Vorgehensmodells

36 Frage Phasenmodell zur Softwareentwicklung Frage An welchem Phasenmodell zur Softwareentwicklung orientieren Sie sich in Ihren Projekten? Tabelle 4-20: Phasenmodell zur Softwareentwicklung Abbildung 4-10: Phasenmodell zur Softwareentwicklung

37 Frage Phasen der Softwareentwicklung (abhängige Frage 2.1.1) In welchen Phasen der Softwareentwicklung werden Maßnahmen zur Qualitätssicherung in Ihren Projekten durchgeführt? Tabelle 4-21: Phasen der Softwareentwicklung Vorstudie Abbildung 4-11: Phasen der Softwareentwicklung Vorstudie

38 22 Tabelle 4-22: Phasen der Softwareentwicklung Fachkonzept Abbildung 4-12: Phasen der Softwareentwicklung - Fachkonzept

39 23 Tabelle 4-23: Phasen der Softwareentwicklung Systementwurf Abbildung 4-13: Phasen der Softwareentwicklung Systementwurf

40 24 Tabelle 4-24: Phasen der Softwareentwicklung Realisierung Abbildung 4-14: Phasen der Softwareentwicklung Realisierung

41 25 Tabelle 4-25: Phasen der Softwareentwicklung Integration Abbildung 4-15: Phasen der Softwareentwicklung Integration

42 26 Tabelle 4-26: Phasen der Softwareentwicklung Abnahme Abbildung 4-16: Phasen der Softwareentwicklung Abnahme

43 Frage Agile Vorgehensmodelle (abhängige Frage 2.1.1) An welchem agilen Vorgehensmodell zur Softwareentwicklung orientieren Sie sich in Ihren Projekten? agiles Vorgehensmodell Häufigkeit Prozent Gültige Prozent Kumulative Prozente Gültig Scrum 141 7,9 56,9 56,9 extreme Programming XP 10,6 4,0 60,9 Feature Driven Development FDD 13,7 5,2 66,1 Crystal 1,1,4 66,5 Kanban 6,3 2,4 69,0 eigenes/angepasstes Modell 67 3,8 27,0 96,0 anderes agiles Modell 10,6 4,0 100,0 Gesamtsumme ,9 100,0 Fehlend System ,1 Gesamtsumme ,0 Tabelle 4-27: agile Vorgehensmodelle zur Softwareentwicklung Abbildung 4-17: agile Vorgehensmodelle zur Softwareentwicklung

44 Frage Qualitätssicherung in Sprints Frage Wie handhaben Sie die Qualitätssicherung in den einzelnen Iterationen (Sprints) Ihres Vorgehensmodells? Tabelle 4-28: Qualitätssicherung in Sprints

45 Frage Praktiken agiler VM mit Blick auf QS (abhängige Frage 2.1.1) Welche Praktiken agiler Vorgehensmodelle haben eine hohe Bedeutung für Sie in Hinblick auf Qualitätssicherung? Tabelle 4-29: Praktiken agiler Vorgehensmodelle in Hinblick auf QS

46 Frage 2.2 Bedarf bei Vorgehensmodellen Abbildung 4-18: Wortwolke der Antworten zu Frage 2.2 Wo sehen Sie Bedarf in Forschung, Entwicklung oder Beratung von Vorgehensmodellen? (Stichworte reichen aus) An den Modellen selber sehe ich kaum forschungsbedarf. Aber der Softwaretest an sich wir noch nicht von allen Firmen als notwendig betrachtet. "Agile" Ansätze auch für richtig große Projekte 1. SW-Entwicklung ist Kunsthandwerk mit wissenschaftlich, fundierten Werkzeugen 2. somit ist kein "Künstler" austauschbar 3. leider hat das noch niemand so betrachtet 1. V (oder W-) -Modell in Verbindung mit Sicherheitsanforderungen (ISO 26262): wie wirkt sich die ISO auf das Vorgehensmodell aus? 2. Wie passt das V-Modell mit agiler Entwicklung zusammen, wenn Standards wie die ISO und AUTOSAR berücksichtigt werden müssen?

47 31 abgestimmte, angepasste Toolunterstützung - möglichst durchgängige Verknüpfungen über die Bereichspalette: Iterationsplanung, Requirements, Bugs, Tasks (im Sinne von Tagesagenda/TODOs), Versionskontrolle (id/changeset), Buildnummer (kontinuierl. Integration) - idealerweise integriert in Entwicklungsumgebung (via Schnittstelle od. komplett) Abgleich der Rollenmodelle in Unternehmen mit den Rollen aus Vorgehensmodellen (z.b. Scrum) Adaption V-Modell auf agile Vorgangsweisen Agile agile Anforderungs-QS beim Auftraggeber, agile Spezifikations-QS Agile Entwicklung von sehr großen Projekten mit langen Laufzeiten (>200 Entwickler, >10Jahre Entwicklungszeit mit Zwischenreleases). Agile Methoden sollten die QS und das Testen nicht nur kurz Erwähnen sondern konkret mit einplanen. Dabei sollte man konkrete Handlungsanweisungen. IN der Theorie wird zwar viel über Agile Methoden und andere Neumodische Vorgehensmodell beschrieben aber NIE, wie die QS bzw. das Testen durchzuführen ist und wie die Tester in die Lage versetzt werden können, den Anforderungen aus der agilen SW- Entwicklung zu genügen. agile mit verteilten Teams agile Programmierung und/vs. finanzielles Controlling agile Programmierung und/vs. Outsourcing Agile Projekte mit Outsourcing-Anteilen (verteilte Teams) agile Prozesse agile SW-Entwicklungsvorgehen mit Test & Qualitätssicherung verbinden. Agile Techniken Integration Testprozess agilen Vorgehensmodelle sollten mehr gefördert werden Agiles Testen agiles Testen und Versöhnung mit V-Modell Agiles Vorgehen erfordert agile Personen und man muss damit rechnen dass es Pufferzeiten hat (einberechnen). Aktuell ist es so, dass diese Pufferzeiten mit einer 100% Volllast versucht werden zu planen und somit die Agilität automatisch verschwindet. Die Projektleiter verstehen aber nicht warum, dabei scheint es ja offensichtlich. Agilität und Testen Scrum und Testen Integration von Test und Entwicklung Performance Test aktuell keine Aktuell keinen Akzeptanz des Testens Alle allgemein bei der Softwareentwicklung und beim Testen Anforderungsmanagement, agile Konzeption, Kosten-Nutzen-Analysen von Legacy (Host)- Systemen vs. C-S-Architekturen (JAVA) Angemessenheit Angemessenheit für unterschiedlich umfangreiche Teilaufgaben Anpassung bei Neuanforderungen

48 32 Anpassung der Modelle auf schnelllebige Projekte im Embedded Bereich, Interfaceing mit Hardware Entwicklung, Test, Zertifizierungen, Produktion etc. Anpassung der Teststufen des Vorgehensmodells auf das Unternehmen Anpassungen von Vorgehensmodellen an die Arbeitsorganisation Anpassungsfähigkeit der Modelle an spezielle Anforderungen des Kunden. Anwendbarkeit Anwendbarkeit auf automotives Umfeld, Vergleich/Anbindung zu anderen Modellen Anwendung auf existierende, nirgendwo niedergeschriebene, aber in einer Firma gelebte Vorgehensweisen Aufklärung Aufwandsschätzung Risikoanalyse und -management Ausbildungsmäßige Rückstände; Vereinheitlichung des Sprachgebrauches dringend erforderlich; Theorie und Praxis liegen weit auseinander Auswahl des für Unternehmen/Team passenden Vorgehensmodell Einführung von neuen Vorgehensmodellen automatisiertes Testen: in welches Phasen sinnvoll und machbar Bedarf sehe ich in der Kommunikation zwischen Entwicklung und Test Bedarfsgerechte Modellanpassung während des laufenden Zyklus bei Entscheidern zur Vermittlung der Wichtigkeit zur Anwendung von Vorgehensmodellen in Projektteams, die aus den Best Practices Ihre Erfahrungen weiter geben können Beratung Beratung Beratung Beratung Beratung Beratung andere Unternehmen bzgl. Scrum Beratung bei agilen Vorgehensweisen Beratung bei den Kunden Vorgehensmodelle umzusetzen. Schwerpunkt wie komme ich vom jetzigen Modell ins neue. Wer macht alles mit und von wem wurde es getrieben (Wunsch des Managements oder der Entwicklung). Beratung und Information des Managements über notwendige Prozess- und Strukturänderungen beim Umstieg auf agile Softwareentwicklung... Beratung von Vorgehensmodellen Beratung von Vorgehensmodellen, Stufeneinordnung Beratung zur Einführung agiler Methoden, Akzeptanz der Planungsunsicherheit im höheren Management Beratung, die meisten wissen nicht wie Agil funktioniert Beratung: geeignetes Modell adaptieren; Forschung: Kriterien für Auswahl von Modellen Beratung: Welches Vorgehensmodell ist vorzugsweise anzuwenden? bereichsübergreifend, Rollenverteilung bei Multiprojektmanagement mit SIL-Stufen, Parallelität Bessere Anlehnung an das V-Modell Bessere nachträgliche Anpassungsmöglichkeiten nach Freigabe von z.b. Anforderungen; Architektur; Testfällen Betreffend mit Kunden abgestimmte Spezifikation Bisher waren die Reviews häufig, jetzt durch SW-Verlagerung ins Ausland, hauptsach billig, leidet die Qualität, kein Reviews mehr. Entwicklung, bei Kundenanforderungen ist es auch wichtig.

49 33 Budget & Time Da wir ein eigenes Vorgehensframework angelehnt an PMI und System Developement Livecycle erarbeitet haben ist hier Bedarf an Weiterentwicklung, Training und Beratung der Anwender als dringende Ziele zu sehen. Das Problem an Modellen ist, dass sie in der Praxis meist nicht wie vorgesehen umgesetzt werden oder werden können. Es sollte hier besser eine Unterscheidung in "ideal" und "real" stattfinden. Der Richtige Vorgehensmodel für die Richtige Projekt anzuwenden der Tiger ist die Schnittstelle die Begriffe der Vorgehensmodelle waren mir gänzlich unbekannt. Ich konnte nur über die Beschreibung überhaupt etwas zuordnen Die Beratung zum praktikablen Einsatz von Vorgehensmodellen im Bereich der Fach- und Systemkonzepte unter frühstmöglicher Einbeziehung des Begriffs Qualität. Die Finance-Branche hat noch vielfältig Schwierigkeiten mit agilen Vorgehensmodellen und grenzt diese sogar bewusst durch Vertragsgestaltungen/hausinterne Vorgaben aus. Hier wären verstärkte Beratungsleistungen zur Sinnvermittlung sinnvoll. Die klassischen Vorgehensmodelle werden abgewandelt hin zu Agilenc Vorgehen, da sich doch einige Dinge als Vorteilhaft abzeichenen, z.b. enge Zusammenarbeit mit dem Auftraggeber schon bei der Implementierung, häufigere Rückmeldungen zu bereits implementierten Funktionen, dadurch sind werden die Erwartungen und Anforderungen des Auftraggebers effektiver und konkreter erfüllt. Die Modelle sind ausgereizt. Letztendlich liegt es am Kunden, wie stark er sich an Modelle hält oder nicht. Damit der Kunde entscheiden kann, bedarf es geschulter Berater oder Mitarbeiter des Kunden. Allgemein stellen wir fest, dass wir zwar längst in 2011 angekommen sind und über Dekaden sehr weit auch in der IT gekommen sind, der Kunde allgemein aber noch zu wenig verstanden hat, wofür der Einsatz von QS geeignet, ja erforderlich ist. Die sozialen Aspekte in den Modellen müssen noch gestärkt werden - wichtig ist es den Menschen und seine Erfahrungen in den Mittelpunkt zu stellen. Effizienz ist heute sowie so ein Muß, leider wird allzu oft vergessen da Menschen zusammen arbeiten und Ihnen eine entsprechende Wertschätzung entgegen gebracht werden muß. die Überprüfung von Vorgehensmodelle sollten mehr an der gängigen Praxis orientiert sein: wirkliche Größe der Projekte; Zeitdauer (inkl. Verspätungen) (die Theorievorgaben sind oft praxisfern) Die Verwendung von Vorgehensmodellen rückt stellenweise neben der eigentlichen Softwareentwicklung zu sehr in den Vordergrund. Effektive Methodenanwendung (Test) Vorgehensweise bei der Methodenauswahl (Test), Effizienz von Managed Testing Messung des wirklichen Nutzens einer IT-Lösung als Teil des Testens eigentlich keinen Bedarf Ein Werkzeug, das alle Phasen des Softwareentwicklungsprozess unterstützt und miteinander verbindet. Einbettung QS und Testaktivitäten in agile Vorgehensmodelle Agile Entwicklung und QS in verteilten und/oder hiearchischen Strukturen Einbindung mehrerer externer Entwicklungsunternehmen, globale Projekte bei großen Konzernen mit vielen Standorten. Ideale Tool Chains für größere agile Projekte. Einbindung von agilen Ansätzen in die standardisierte Softwareproduktion;

50 34 Eine Analyse inwieweit verschiedene Vorgehensmodelle sich auf Qualitaet und Kosten auswirken. Sind Vorgehensmodelle wirklich zentrale Erfolgsfaktoren? eine Analysemethode, welches Vorgehensmodell für ein spezifisches Unternehmen optimal ist einfachere Adaptierbarkeit für unterschiedliche Projektarten (Einführung Standardsoftware - Entwicklung Individualsoftware - Client-Server-Basistechnologie - Austausch Großrechnerkomponenten) Risikoanalysen für Abweichungen von Standardmodellen Einführung von agilem Vorgehensmodell in einer Firma, die bisher hauptsächlich nach Phasenmodell entwickelt Ko-Existenz beider Modelle in einer Firma Projekte, bei denen ein Teilprojekt agil entwickelt wird und folgende Integration einige Seniorentwickler haben wären ihres Informatikstudium nicht viel über Vorgehensmodelle gehört und sich danach nicht damit befasst, hier sind Schulungen o.ä. notwendig Embedded Systems mit komplexen proprietären Schnittstellen (Stichworte: Kartenzahlungssysteme, ZKA-Spezifikationen, PED = PIN Entry Devices) Empirische Analyse, in welchem Ausmaß sich Vorgehensmodelle tatsächlich auf die Qualität auswirken Empirischer Nutzen bestimmter Praktiken End-2-End Kettentests. Prozessorientieres Testen der Geschäftsvorfälle SOA und Cloud-Testing End2End Test bei vielen kleinen Scrumprojekten, die alle zu einem Zeitpunkt bei einer Version landen sollen (Integrationstests sind nahezu unmöglich, wenn es keinen definierten Overall Plan gibt) Entwicklung und Beratung von Vorgehensmodellen Entwicklung von auf Normen (z.b. DO-178, ISO 26262) abgestimmter Vorgehensmodelle, die sich in der Praxis kostengünstig umsetzen lassen Entwicklung von Konzepten für die Schulung der Mitarbeiter auf Auftraggeberseite. Agile Vorgehensmodelle sind für den Auftraggeber meist Neuland. Bei fehlendem Know-How oder Widerständen bzgl. neuer Methoden geht im Projekt sehr viel Zeit verloren. Entwicklungstechniken sind hinreichend vorhanden, aber die Schnittstelle Softwareentwicklung/Projektmanagement ist hauptsächlich Domäne von Modeerscheinungen und unseriöser Forschung. Erfordernisse zu automatisierung von Test und der Wiederholbarkeit von Testergebnissen! Erhögung der Geschwindigkeit+Flexibilität Es fehlen eindeutige und wiederverwendbare Entscheidungshilfen, was und in welchem Umfang einem Modell-Tailoring unterzogen werden sollte. Es fehlt an praktischen Vorgehensmodellen, die ganz konkret beschreiben, wie man vorgehen kann. Die meisten sind zu abstrakt und gehen an der Realität vorbei. es gibt genug Modelle; die individuelle Anpassung ist die Herausforderung! Es gibt nicht das one and only Modell Es ist noch erheblicher Handlungsbedarf in der Entwicklung und Beratung Etablierung von Reviews in der Analysephase Etablierung von Vorgehensmodellen in Zusammenhang - Zertifizierungsberatung (z.b SIL) - Produkthaftung

51 35 Exploratives Testing Akzeptanztest-getriebene Entwicklung Finden eines abgewandelten und für das Unternehmen passenden Ansatzes auf Basis eines bestehenden Modells. fixere Planungsmöglichkeiten Forschung in Bezug auf statistischen Mothoden / Modelle der Testplanung. Z.B. Modell zur Auswirkung der Fehlerhäufungstheorie auf die Plaung vontestiterationen Frage verstehe ich nicht grosskonzernen sollt SCRUM verboten werden, schadet der agilen Community Grundannahmen (Voraussetzungen für Gelingen des Vorgehensmodells) explizit machen, da oft nicht erfüllt. Brücke zwischen Theorie und Praxis!!! Grundsätzliche Integration von MDSD in alle Phasen. Hierzu sollten regelmäßig, interne Schulungen angeboten werden und es sollte ein Ansprechpartner existieren, um bestimmte Problemfälle im Vorgehensmodell zu besprechen und zu lösen. Höhere Akzeptanz/aktives Vorantreiben von agilen Entwicklungsmethoden, Continuous Integration und Qualitätsdenken im Management ich weiß nicht Im Abgleich Praxis-Theorie, Effizienz der Prozesse Im Moment gibt es zu viel Theorie und zu wenig best practice. in allen Bereichen in allen bisherigen Projekten wurden kundenseitig diesese Themen zu gering eingeschätzt und bedurften größtenteils massive Aufklärung Integration Integration der agilen Softwareentwicklung (Scrum) für unsere Portalanwendungen Integration verschiedener Vorgehensmodelle, Auswahl des für ein Projekt geeignetsten Vorgehensmodell Integration von agilen Ansätzen; Standardisierung von Vorgehensmodellen; Integration von agilen Vorgehensmodellen in der Entwicklung in die übergreifenden Aufgaben eines System-, Abnahme- und End-to-End Tests. Wie stellt man sicher, dass kurzfristige Entwicklungsschritte sich mit langfristigen QS-Strategien integrieren (Aufwand für Verbesserung und Automatisierung im Testprozess und Testumfeld) Integration von Produkten zu Systemen/Solutions; ganzheitliche Teststrategien; Integration von Software-Testern in agile Vorgehensweisen Testautomatisierung über APIs innerhalb der Software (also ohne GUI-basierte Automatisierung) Entwickler-Unterstützung beim Erstellen von unit tests Integration von Testprozessen in agile Softwareentwicklungsmodelle Integrationstests Integrationtests Integrierte Tests IST: Scrum versus Testing (inkl. Qualitätssicherung SOLL: Integration Testing (QS) - Scrum Jedes Team entscheidet selbst, welches Vorgehensmodell am besten zu seiner Arbeitsweise passt. Aktuelle Forschung wird berücksichtigt, aber nicht selbst

52 36 vorangetrieben. Beratung von außerhalb hat am Anfang geholfen - inzwischen können wir fast nur noch durch die Lektüre neuer Publikationen dazulernen. ka kein Bedarf Kein Bedarf Kein Bedarf kein Bedarf Kein Bedarf. keine Angabe keine explizite Anforderung Keine, da Umstieg auf agiles Vorgehen geplant. keinen habe mich damit zu wenige beschäftigt Keinen! Die beratenden Branchen haben in den letzten Jahren ihre spezifischen Vorgehensmodelle entwickelt. Die Beratung muss sich individuell darauf einstellen. Klärung und Bereitstellung einheitlicher Begrifflichkeiten bei den Überdeckungsmaßen. Es gibt so viele Meinungen dass man als Firma sich nur dadurch helfen kann, selbst dies (jeweils) zu definierten... ist unschön und verursacht Mehraufwand weil keine einheitlichen Abkürzungen verwendet werden können. Auch die ausgeschriebenen Begriffe (z.b. Entscheidungs- und Zweigüberdeckung) weichen voneinander ab. Kombination der Vorteile phasenorientierter Modelle (Sicherheit) mit denen agiler Modelle (Flexibilität) Motivation der Kunden, ihren Beitrag zum agilen Vorgehen zu leisten Kombination der Vorteile von Phasenmodellen (Sicherheit) mit den Vorteilen von agilen Modellen (Flexibilität) Motivation des Kunden, seinen Beitrag zum agilen Vorgehen zu leisten Balance zwischen Dokumentation und Flexibilität Kommunikation der Resultate in die Wirtschaft Kommunikation zwischen Entwicklung und QS konsequente Umstzung Koordination mit integrierten Entwicklungsumgebungen leichtgewichtige QS-Prozesse, Doing-Prozesse Softwareentwicklung, Doing-Prozesse ALM/Betrieb Leichtgewichtige Vorgehensmodelle, die einer ständigen Anpassung unterliegen. m.e. genug 'stoff' vorhanden Maketing/Vertrieb im Kontext der agilen Methoden Man könnte dem obersten Management mal ein paar Grundlagen zum Thema "Projektmanagement", "Testmanagement" oder "Teambildung und Teamführung" vermitteln. Medizintechnik -Mehr Gewichtung auf Teamzusammenstellung und Team Coaching. -Beratung für die Migration von linearem Vorgehen zu agilem Vorgehen mehr Praxis, weniger Theorie. Modelle sind eben theoretisch. Mehr Tests, Tester andere als Entwickler Meines Erachtens ist überall Bedarf angesagt. Messen der Effizienz

53 37 Methoden für verbesserte Reviews Strukturiertes Lesen Migration V-Modell zu agil Missverstaendnisse bei agiler Entwicklung: Zeit fuer Konsolidierung / Refactoring fehlt immer. modellbasierte Vorgehensmodelle, Schnittstellen Modelle mit stärkerer Einbindung der enduser Modelle sind auf den ersten Blick gut - bei der Umsetzung in die Praxis kommen die Probleme Nachhaltiges Management Commitment notwendig Offene Tools Optimierte, verschlankte Prozesse und Schulung der Prozesse Paralleler Umgang im Test von Software Modulen aus Scrum und aus V-Modell. Phasenorientiertes im Übergang zur aglien Sw-Entwichlung unter Erfüllung der regulartorischen Anforderungen bzgl. Produktentwicklung Pokern von Aufwandsschätzungen in Projekten -Praktiken der Anforderungsanalyse -Kommunikationsstrategien zwischen Auftraggeber und Auftragnehmer -Arbeitsorganisation der Projektteams -Personalführung bei stark autonom arbeitenden Projektteams praktische Anwendbarkeit, insbesondere in größeren Projekten Praktische Beispiele, Skalierbarkeit auf kleine und große Projekte Praktische Umsetzbarkeit der Vorgehensmodelle praktische Umsetzung der QS innerhalb der Vorgehensmodelle praktische Umsetzung; mehr Spaß bei der Arbeit; Verdeutlichung des Sinns in den einzelnen Schritten; Vermeidung von Overhead praxisnähe Praxisnähe, Modelle entsprechen nicht unbedingt dem Prozessen in vielen Unternehmen. Stellenwert von QS liegt weit unter SE und somit ist der Einfluss in Prozessen entsprechend gering. Projektbegleitende Langzeitstudien, die Erfolg, Risiken, Kosten von unterschiedlichen Vorgehensmodellen vergleichen. Projektspezifische Anpassung von Vorgehensmodellen projektspezifische Auslegung individuelle Ansätze einbringen Hilfe beim Start oder in schwierigen Projektphasen Prozesseinhaltung Qualitätsmanagement (definierte und dokumentierte Prozesse), regulatorische Anforderungen (IEC 62304, FDA), Verifizierung Reduzierung der Anzahl an Änderungsanforderungen (Change Requests) Schnellere Produktivsetzung Optimierung Kommunikation Auftraggeber/Auftragnehmer reelle praktische Umsetzung Requirements Engineering. Traceability, Testmanagement Risikoabschätzung wie gehe ich mit Veränderung um? wer liest die Dokumente (Requirements, Architektur) und _versteht_ diese auch

54 38 risk based orientierter Bereich Aktuell wird immer mehr AGIl in die Diskussion gerückt Rolle der Tester in agilen Vorgehensmodellen Rücksicht auf Fluktuation bei Projekten bzw. Life Cycle Management bei mittel- bzw. langfristigen Projekten bzw. Risikomanagement des Prozesses Schulung / Fortbildung Schulung der Mitarbeiter Motivation, Testen sehr ernst zu nehmen Schulung zur/vor der Einführung neuer Methodiken; Warum benötigen wir eine Änderung? Scrum tötet Unternehmenskultur: - Scrum führt zu weniger Dokumentation - Scrum führt zu Mangelhaften Rollenverständnis innerhalb des Teams - Scrum führt zur Unterlassung von Führungsaufgaben in Teams wegen angeblicher Selbstorganisation - Scrum funktioniert nur in kleinen Unternehmen, mit hochmotivierten Teammitgliedern, bei einem genauen Kenntnisstand der Anforderungen, top-geskillten, sozial sehr kompetenten Mitarebitern. Kurz: Scrum funktioniert in einer Umgebung, wo alle Prozes ScrumMaster, Retrospektive Sehr starr, führt zu Fehlplanungen und vielen teuren, komplizierten Änderungen während des Probebetriebs. Sie müssten flexibler werden. U.a. wenn agile Vorgehensmodell bspw. mit dem Wasserfallmodell in einem Projekt kombiniert werden soll. Speziell in der Beratung: Es existieren keine best practices für agile SW-Development. SCRUM, XP oder Kanban müssen nicht zwangsweise die Lösung sein, sondern eine an das Unternehmen angepasste Methodik ist weit aus effizienter. Standardisiertes Vorgehen bei Zertifizierungen/Terminologien Stärken von agilen und phasenorientierten Vorgehensmodellen kombinieren Stringente Einhaltung bei allen Teilprojekten. strukturierte Vorgehensweisen beim Test Risikoabschätzung und ~überwachung Tailoring der Vorgehensmodelle. Verknüpfung & Kombination verschiedener Modelle. Tailoring sowie Customizing an unterschiedliche Projekttypen Tailoring von Standardvorgehensmodellen Tailoring von Standardvorgehensmodellen Tailoring von Vorgehensmodellen Tayloring von Vorgehensmodellen Test Driven Development, Modelbased Testing, Agiles Testen: Wann wird welche Methode bei welchen Projekten eingesetzt? Test Methoden haben sich in den letzten 20 Jahren kaum veraendert. Testen nicht als notwendiges Übel betrachten. Testen darf nicht Dokumentation und Schulung ersetzen Testmethodik bei Integration agiler Entwicklung in ein phasengesteuertes Entwicklungsmodell Testmethodik im agilen Umfeld Testprozess an sich Testspezifika für agile Vorgehensmodelle, Rolle des Testers im agilen Vorgehensmodell, Standards/Empfehlungen für Dokumentation im agilen Vorgehensmodell

55 39 Testverfahren von Anfang an bis zum Ende, Einarbeitung von MA in das verwendete Vorgehensmodell Thema Test / QS in Agilen Modellen Transparenz Um besser entscheiden zu können, welches Modell/-variante für ein bestimmtes Projekt/Team/... gut oder wenig geeignet ist, würden aufbereitete, reale "Lessons learned" oder Beispiele helfen (natürlich anonymisiert). Umgang mit Change Requests Anforderungsmanagement Zeitmanagement Umgang mit Issues aus der Produktion, die in die Sprints integriert werden müssen Umsetzung in Organisationen Tailoring Unit test, model based test, risk based test, test driven design Unser Vorgehensmodel ist abgeleitet von einem Gatemodel welches in anderen Ingenieurdisziplinen angewandt wird. Für Softwareprojekte ist es aber nicht flexibel genug. Leichtere Vorgehensmodelle müssen besser in die Unternehmensumgebung integriert werden können. unsicheres Umfeld Zeitrestriktionen unternehmensspezifische Anpassung; Beratungs - und Überzeugungsbedarf warum, welche Schritte getan werden müssen Unterstützung im methodischen Vorgehen Testautomation durch fachliche Mitarbeiter (keine Programmierkenntnisse) Usability-Engineering gepaart mit agilem Vorgehen Vorgehensmodelle in Forschungsprojekten - wo sind Unterschiede, wo Gemeinsamkeiten User Story - der Begriff wird oft unterschiedlich benutzt. Es ist dem Kunden - unseren Fachbereichen - nicht zuzumuten, die Anforderungen sofort in User Stories zu beschreiben. Sie müssten z. B. wissen, dass die Story in einem Sprint zu erledigen ist. Außerdem gehören die Akzeptanztest zur Story. Es wird eine größere strukturierte Einheit benötigt (vielleicht doch wieder Use Case?), aus denen unabhängige User Stories abgeleitet werden können. Verbesserung der Kommunikation bei Requirementsanalyse zwischen Kunden und Software-Ingenieuren Verbindung von agilen und phasenbasierten Modellen; ISO 9001 u.a. in agiler Software- Entwickung!? Bessere Software-Tools für kombinierte Vorgehensmodelle! Vereinbarkeit agiler Methoden mit Reifegradmodellen wie SPICE, CMMI Vereinbarkeit der QA-Aufgaben innerhalb eines SCRUM- oder KANBAN-Teams bei einer Besetzung von 1 Tester auf 3-5 Entwicklern und gleichzeitiger Unterstützung de POs bei der Definition der Akzeptanzkriterien und dem Anspruch, alle für die Automatisierung vorgesehenen Testfälle innerhalb des Sprints oder im Anschluss auch zu automatisieren, Reviews der Unittests durchzuführen und die Kommunikation zwischen PO und Entwicklung zu unterstützen. Vereinbarkeit von Fixpreis-Projekten mit agilen Entwicklungsmodellen Vereinbarkeit zwischen Neuentwicklungsprojekten und Maintenance Vereinheitlichen von Kommunikationswegen Verfahrensmodelle sollten so gestalten, dass deutlicher wird, dass Validieren Teil der Entwicklung ist. Verknüpfung agiler Methoden mit phasenorientierten Modellen Requirementsengineering mit test(fall)bezogener Anforderungsspezifikation

56 40 Verknüpfung von Tools (Jira, BugZilla,...) mit den Anforderungen von agilen Modellen Vermittlung und Anwendungssicherheit von Vorgehensmodellen verschiedene theoretische Modelle/Methoden - Abgrenzung, Unterschiede, Übereinstimmungen (z.b. CMMI-Projektmgmt-Phasenmodelle) Überblick / Einordnungen organisatorische Implementierungsmöglichkeiten Reduzierung Rollenvielfalt V-Modell agiler gestalten, Testplanung/entwicklung von Beginn an, V-Modell im Softwarelebenszyklus bei phasenorientierter Entwicklung und Probleme mit Linienorganisationen V-Modell XT ist im Bereich des SW-QS viel zu oberflächlich. Es gibt viele "Unterrollen" im Bereich der Entwicklung und der Projektplanung. Dagegen werden analytische und konstruktive QS, Entwicklertests, Integrationstests, Reviews u.a.m. unter "Prüfung" zusammengefasst. Schade, wenn man bedenkt, was das V-Modell ursprünglich bot. V-Modell-XT wäre schön zu kennen. Vorgehen bei langen, immer wiederholten Wartungszyklen Vorgehensmodelle auf Projekte mit unterschiedlichem Umfang zuschneiden; Vorgehensmodelle an den Unternehmensbesonderheiten anpassen. Vorgehensmodelle zu starr für Realität, Berater schlecht ausgebildet und nicht in der Lage Modell für Bedarf anzupassen Vorgehensmodellen taugen meistens nur um eien struktur an projekte zu geben und dukomentevorlagen zu liefern. sie sind sonst nicht genügend praxisnäh. Vorlagen, best practices aus Industrie/Dienstleister Vorteile agiler Vorgehensweisen gegenüber klassischem V-Modell Wann agil, wann klassisch? Vorteile von guten Teams/ Vermitteln, dass Pläne alleine nicht reichen gute Software zu entwickeln Wann ist die Qualität gut genug? Zuordnung von Anforderungen zu Code. wenig Bedarf werden formal erfüllt aber nur halb gelebt Werkzeuge für das ALM, Organisation von Regressionstests (über die Lebensdauer des Erstprojektes und der folgenden Wartungsreleases hinweg) Wichtig bei der Anwendung von Vorgehensmodellen in den jeweiligen Projekten ist die Adaption. Hier braucht es mehr Sensibilisierung Wie findet man in einem Unternehmen den Weg vom V-Modell zu einer agilen Softwareentwicklung ohne die gesamte gewachsene Struktur des Unternehmens komplett umzukrempeln. Wie meinen Sie das? Bei uns? Ist prinzipiell dringend notwendig, bedarf aber ein Aufbrechen meist langjähriger Firmenstrukturen Wie passen sich die anderen Abteilungen (z.b. Marketing, Vertrieb,..) wenn z.b. Scrum in der Softwareentwicklung eingeführt wird? Was muss sich in den Abteilungen ändern? Wieso hält sich die Mär vom erfoglreichen Wasserfallmodell bei Manager wider besseren Wissens/Erfahrung? Wir nutzen TMap von Sogeti. Hier sehen wir positive Effekte in der Beratung. W-Modell in Verbindung mit SCRUM und Spiralmodell. zeit, preis kalkulation Zu einem einzelnen Modell ist eine Zuordnung schwer möglich, da sich durch die unterschiedlichen Anforderungen und die IMMER heterogene Zusammensetzung des Projektteams Mischformen ergeben. Zusammenarbeit Entwicklungsabteilung und Management

57 41 Zusammenarbeit zwischen Programmier- und Testbereich, besonders wenn diese aus verschiedenen Unternehmen kommen. Zusammenführung der besten Eigenschaften von V-Modell & Agilen Methoden (Zusammenführung von Phasen & Iterativem Vorgehen). Insbesondere organisatorisch hinsichtlich getrennten Organisationen von Entwicklung & Validation. Zusammenführung von agilen konstruktiven Phasen mit den zusammenfassenden Integrationsphasen (Integrations-, System-, Abnahme- und End-to-End-Test), d.h. wie kann ich sicherstellen, dass agile Flexibilität in kleinen Schritten zusammenpasst mit grundsätzlichen Strategien und Release-Zyklen. Zusammenhänge zwischen Teams Releaseprozess Zusammenspiel von Vorgehensmodell und Maturity Models (SPICE, CMMi) Tabelle 4-30: Antworten zu Frage 2.2

58 Fragenkomplex 3 Risiko- und Qualitätssicherungsmanagement Frage 3.1 Risikomanagement Wird in Ihren Softwareprojekten Risikomanagement durchgeführt? Tabelle 4-31: Risikomanagement in Softwareprojekten

59 Frage Überprüfung von Risiken Wie oft werden die Risiken überprüft? Tabelle 4-32: Häufigkeit der Überprüfung der Risiken Abbildung 4-19: Häufigkeit der Risikenüberprüfung

60 Frage Die drei größten Risiken Was sind regelmäßig die drei größten Risiken in Ihren Projekten? Abbildung 4-20: Wortwolke der Antworten zu Frage Change Requests des Kunden in Bezug auf neue oder abgeänderte Features 2. Geänderte Zielplattformen ("Der Chef hat aber noch IE 5 auf seinem Rechner zu Hause, da muss es auch laufen!") 3. Eingeschränkte Funktionen der Server Zielplattform ("Unser Admin sagt, Java sei unsicher auf dem Server" o.ä.) 1. Produktrisiken, Sicherheitsaspekte, Datensicherheit 2. Projektrisiken 1. Vernachlässigung der Risikoanalyse 2. verspätete Zulieferungen des Kunden bei gleichzeitiger Erwartungshaltung der Termin und Budgettreue 3. Ressourcenengpässe, Staffing 4. Vernachlässigung Test bei Terminschwierigkeiten 3. Firmen Abhängigen zu anderen Projekten, Schlüsselressourcen, rechtliches Umfeld

61 45 Abhängigkeit zu anderen Projekten; Ressourcen von MA werden in anderen Projekten auch noch benötigt Abhängigkeiten Abhängigkeiten von Dritten Abhängigkeiten zu anderen Projekten oder Lieferanten Abhängigkeiten zu anderen Projekten Komplexität der Systemlandschaft Abhängigkeiten zu anderen, sich verändernden, Systemen. Produktrisiken. Abhängigkeiten zu externe, instabilen Projekten Personalressourcen abweichende Kundenanforderungen während der Umsetzung Überschneidungen bei Aufgabenverteilungen / Ressourcenengpässe Akzeptanz durch enduser, mangelnder Support nach Inbetriebnahme Alter undokumentierter Code, hohe Komplexität der Funktionalität, Starke Überziehung der Budgets Änderungen Zulieferungen (vom Kunden) zu spät oder in mangelnder Qualität Anforderungen nicht verstanden ("Was will der Kunde eigentlich erreichen?") Änderungen der organisatorischen Rahmenbedingungen Änderungen der Anforderungen Änderungen der technischen Randbedingungen Änderungen in den Anforderungen Änderungen in den Feindefinitionen der Ziele und Meilensteine sowie Erweiterung des ProjektScopes während der Projektlaufzeit. Die Kunden verwechseln dies mit agilen Methodiken. Änderungen/Interpretation von Requirements, Zulieferungen Änderungsanforderungen, Personalkapazitäten, Extern zustimmungspflichtige Vorgänge Anforderungen Anforderungen priorisierung projektdauer Anforderungen, Zeit, instabile Umgebungen Anforderungsänderungen Human Ressources Annahmen aus der Aufwandsschätzung Verfügbarkeit Testumgebung Verfügbarkeit Mitarbeiter Stabilität der Anforderungen Auftreten von hidden bugs nach SoftwareErweiterung. Aufwand für Implementierung unterschätzt unklare Vorgaben vom Kunden Aufwand für Tests und Fehlerbehebung unterschätzt Ausfall von spezialisierten Entwicklern und Testern Aufwand, Scopeänderungen, Stakeholderbedürfnisse, Kundeneinbindung Ausfall und/oder Verfügbarkeit von Schlüsselpersonen

62 46 Ausfall von Entwicklern / Testern Offshore Managent Änderungen von Vorgaben während der Projektlaufzeit Ausfall von Ressourcen (manuelles Testen) Ausfall von Schlüsselpersonal, Missverständnis Fachbereich/IT, neue Technologien, mehrere unterschiedliche Umsetzungspartner in einem Projekt ausreichend Ressourcen fehlende Ansprechpartner fehlende KnowHowTräger Komplexität der Technologie außerplanmäßige Ressourcenbindung von Entwicklungsteilnehmern, Änderungsmanagement in der Entwicklung wie auch der Anforderungen von außen (Auftraggeber, Product Owner) Bauteilausfälle, komplexe software Beteiligung Stakeholder Fehlende oder ungenaue Anforderungen bezogen auf das Produkt, Ressourcenproblem Zeit, geld, personal Budget Schnittstellen andere Systeme Budget Time Budgetausfall, Resourcenmangel Budgetplanung, Zeitplanung Budgetprobleme Ressourcenprobleme Budgetüberschreitung und verspätete Auslieferung Budgetüberschreitung, Kundenzufriedenheit Change Requests Datenbank Migration Nachrichtenkommunikation und Verarbeitung Datenindiskretion Datenverlust Dateninkonsistenzen im alten System Datenmigrationen, Ressourcenengpässe, 'Termin vor Qualität'Logik DAUs Design / Build dauert länger als geplant und dadruch muss die Testphase verkürzt werden bzw. es kommt zu Parallelisierung von Testphasen, was das Riskio erhöht. Designfehler, die erst spät, womöglich erst bei der Integration entdeckt werden. Sich ändernde Anforderungen. Die Abhängigkeiten zu anderen Projekten; Zeit die sind geheim und die hat die Projektleitung alleine. Vor Testmanagern wird das versteckt

63 47 Die üblichen: unklare oder wechselnde Anforderungen instabile Ressourcensituation Dokumentation Ressourcenbedarf vs. Verfügbarkeit Planungsschwierigkeiten Dringende andere Aufgaben (Maintenance) mit höherer Priorität Ausfall von Mitarbeitern Durch Budgetvorgaben der Kunden knapp bemessene Projektmittel. Durch Planungsvorgaben der Kunden zu knapp bemessene Projektlaufzeiten, die keine Störfälle vorsehen. Ein Softwarezulieferer liefert verspätet. Geänderte gesetzliche Anforderungen. Software kommt ohne Entwicklertest. Testerfahrung der zur Verfügung gestellten Tester eher gering. Einhaltung Meilensteintermine und Budget, Einhaltung geplanter Testumfang Einhaltung Termin Einhaltung von Termin und Kostenvorgaben Einsatz neuer Technologien Engpässe bei Personal, Kosten, zu hoher Aufwand, verspätete Zulieferungen Entwicklung unter Zeitdruck. Feature Entwicklung vor Bugfix. Entwicklungszeit, Abhängigkeit von Basissoftware Erkannt werden meist organisatorische Risiken. Technische Risiken werden eher schlecht erkannt. Erreichen der Meilensteine bei Erreichen des vereinbarten Scopes Exotische Datenkonstellationen Abhängigkeit zu Drittsystemen / externen Dienstleistern Fachbereich weiß nicht was er will Noch sehr späte Anforderungen / Change Requests Verzögerungen bei externen Partner Ressourcen werden nicht bereit gestellt fachliche und personelle Differenzen Entscheidungsschwäche falsches Verständnis der Anforderungen falsche Einschätzung des Entwicklungsumfangs fehlende Mitarbeit der Kunden Verfügbarkeit der internen Fachleute Fehldiagnosen durch Missinterpretation durch den Benutzer fehlende Abstimmungen zwischen Partnersysteme Testbüdget neue Lieferant fehlende Skills Fehlende Kommunikation, Anforderungsänderungen, weitere Projektpartner fehlende Personalkapazitäten mangelnde Beteiligung des Auftraggebers

64 48 Fehlende Ressourcen aufgrund "Konkurrenz" zu anderen Projekten Fachliche und technische Komplexität fehlende Ressourcen nicht ausreichend qualifizierte Ressourcen Schnittstellen zu Applikationen, die kaum bis wenig beeinflussbar sind unpräzise Anforderungen fachl. Qualitätssicherung wird nicht bzw. nicht ausreichend durchgeführt fehlende Ressourcen ungenügende SW Qualität bei der Integration Termin wird höher bewertet als Qualität und Kosten Fehlende Vereinbarungen und Aktivitäten hinsichtlich Qualitäts(Abnahme)kriterien und Test; Unklare Anforderungen; Unrealistische Planung unter Zeit und Kostendruck Fehlendes Knowhow Zu wenig Ressourcen Unrealistische Projektplanung Ungeplante "Störungen" durch das Management Fehler in Standardsoftware, Kein funktionierendes Team fehlerhafte/fehlende requirements (kaum vorhandenes bis fehlerhaftes requirements engineering), testumgebung nicht den bedürftnissen der software anpassbar (v.a. bei externen abhängigkeiten) finazielle Risiken Image Verlust Fremdleistung Funktionale Risiken Ressourcen geänderte Anforderungen geänderte Anforderungen. geänderte Anforderungen; Ressourcenveränderungen Genehmigung fehlt Geldfreigabe fehlt Geschäftskontext, Projektleitung, Finanzen, Qualität der Software Gesundheitsgefährdung des Patienten Fehldiagnose Hardware Häufige Änderung der Anforderungen durch den Kunden Wenig Erfahrene Mitarbeiter Falscher Schnitt der Applikation in einzelne Releases Heterogene Umfeld, Abhängigkeiten von Lieferanten, Im Projekt ist die Verfügbarkeit von 'wichtigen' Mitarbeitern (KeyPeople) und der permanenten Unterstützung durch den Auftraggeber oft ein eintretendes Risiko. Im Produktbereich ist es die Unterschätzung des Abstimmungsaufwandes von PlattformIntegrationen / Konfiguration von ServiceInfrastrukturen. Imageverlust Geldverlust In der Regel sind es politische Themen im Ökosystem des Projektes, die zu ProjektKrisen führen. Daher legen wir auf diese Themen größeres Augenmerk als auf technische Risiken, die in der Regel lösbar sind. Instabile Anforderungen; Probleme bei der Integration von verschiedenen Systemen

65 49 Insufficient requirements Change requests Lack of planning reliability Integration in Fremdsysteme (SAP) Unklare Anforderungen des Kunden (denn er weiss nicht, was er will) Konfuse Datenlage jein ka Kalkulation für Festpreisprojekte Kapazität/KnowHowAusfall, Erfahrung, AuftraggeberStrategiewechsel Kapazitäten Zielkonflikte Konzeptlücken Akzeptanzprobleme Kapazitäten, Programmentwicklungszeiten, Fehlerbehebung, Testen, Migration keine Ahnung keine explizite Aussage Keyplayer fallen aus geeignetes Personal Zeit Budget Knappe Ressourcen, unrealistische Zeitpläne, wechselnde Anforderungen Knowlegeverlust Komplexität, Ressourcen Kosten Zeit undefinierte / nicht vollständig definierte Anforderung Change Requests Kosten Zielerreichungsgrad Krankmeldung/Abwesenheit eines Mitarbeiters länger als eine Woche Hardware Ausfall Kundenänderungen Terminengpässe Kundenanforderungen unklar Aufwandsschätzungen zu optimistisch Beteiligung des Kunden oft unzureichend Kundenanforderungen zu verfehlen, Änderung von Plattformen und Technologien während der Laufzeit kurze Projektlaufzeiten Key User Motivation Kurzfristige Änderungswünsche des Auftraggebers; unzureichend qualifiziertes Projektpersonal laufende Anpassungen an Ziele und Requirements zu wenig Einbindung der Kunden während der frühen Realisierungsphasen, d.h. Kunde sieht die ersten FunktionalitätsImplementationen frühestens in SystemtestPhase wenn nicht später. Falls es Fehler in der Requirementsanalyse gegeben hat oder Requirements falsch umgesetzt worden sind, kommen Korrekturen erst relativ spät. PerformanceProbleme sind erst in Systemtests ersichtlich

66 50 Leistungsüberschreitung, Zeitüberschreitung Lieferanten, Qualität Lieferengpässe, Knowledge, Fester GoLive Termin und die Zeit die dem Test nach diversen Terminverschiebungen noch bleibt, etc. Lieferverzögerungen, Qualitätsmängel MA Ausfall Zeit Machbarkeit, Akzeptanz, Umfang, Kosten mangelnde Verfügbarkeit von Mitarbeitern Performance der Systeme mangelndes Prozesswissen, Fehleinschätzungen Marktverluste durch Projektscheitern Meilensteine, Übergabepunkte, z.t definiert durch das Entwicklungsmodell Milestones werden oft nicht eingehalten Missverständnisse, menschliche Beziehungen Mitarbeiterdisposition; Entwicklungsstatus; Mitarbeiterfluktuation, schlechte Qualität bei Anforderungen, Zeit/Geldmangel Mitarbeiterüberlastung, Zeitmanagement Mitarbeiterwechsel Mortalität des Patienten neue Features neue Software Neue Funktionalitäten strukturelle Änderungen externe Software Libraries zunehmende Komplexität neue Priorisierungen, notwendige Reaktionen auf gesetzliche Änderungen Neue Technologien, FremdHardware nicht rechtzeitig oder qualitätsmäßig nicht wie erwartet neue Technologien, Verfügbarkeit Mitarbeiter, Verhalten der Stakeholder nicht ausreichende Konzeption, Datenmigrationen nicht ausreichende Konzeptionen, Datenmigrationen, nicht ausreichende Kundenmitarbeit, Integration von Umsystemen nicht gesetzkonform Datenverlust Nichteinhalten der Vorgehensmodelle (z.b. Entwicklung bevor Konzept geschrieben wurde nachträglicher Änderungsaufwand) Vendoren haben Business Anforderungen nicht verstanden Nicht Einhalten des Projektplans, da regelmäßig absurd naive Annahmen oder schlichtweg lächerlich kurze Zeitspannen angenommen und gesetzt werden. Nichteinhaltung von Terminen durch Partner organisatorische und technische R. Parallele Projekte, externe Systeme, Ressourcen Parallelisierung von Host und GUI Entwicklung Providermanagement Unterschiedliche Vorgehensmodelle Patientengefährdung

67 51 Performanz, Lastverhalten, Sicherheit und mögliche Seiteneffekte auf andere Projekte Personal ressourcen Personal Anforderungen (Changes) Veränderungen der Rahmenbedingungen Personal, Kosten, Anforderungen Personal, Kunden, Personal; wechselnde Anforderungen und Rahmenbedingungen während der Projektlaufzeit Personalbedarf, Komplexität Personalengpass im Test Testdatenbereitstellung nicht konsistent Terminverzug aufgrund paralleler Projekte auf gleicher Testumgebung Unterschätzung der Auswirkung einer Änderung in der Implementierung ungenaue schwammige Anforderung Personalunion von Anforderungsgeber = Testdesigner = Tester (implzites Wissen) Personalmangel Personalressourcen, Hardwarebeschaffung Personalueberschneidungen, Aenderungen der geschaeftlichen Prioritaeten, Aenderungen im Markt Personelle Ressourcen personelle Ressourcen Personelle Ressourcen und die Zeit personelle Ressourcen, unklare Anforderung durch mangelhafte Auftraggeberbeteiligung, unklare Gesetzesänderungen und deren Interpretation, Kosteneinsparungen bei Testinfrastrukturen personelle Wechsel Kapazitätsengpässe Systemverfügbarkeit Personenschäden Planabweichung durch verzögerte SWLieferungen und schlechte Qualität der gelieferten SW. Portalausfälle und damit verbundener wirtschaftlicher verlust durch wegfall von geschalteten werbekampagnen und geringere Besucherzahlen Probleme mit Ressourcen Wechselnde/neue Anforderungen Produktrisiken: Produkte der aktuellen Aktion können nicht ausgewählt werden Verträge können nicht korrekt erfasst werden Ressourcen werden falsch zugeordnet Aktivierung/Deaktivierung von Anschlüssen funktioniert nicht Mobilfunkaktivierung dauert zu lange Produkt wird inkorrekt ins Billing übertragen Projektrisiken: Ressourcenengpässe Prozesse werden nicht eingehalten Konzepte werden nicht rechtzeitig fertiggestellt Konzepte haben eine schlechte Qualität Implementierungen ste

68 52 Produktrisiko > keinen Schaden für Personen indirekt durch die Software. Allgemein: Aufwandschätzungen schwierig und Verzug von Projekten häufig der Fall >Time Bei grossen Projekten zuviel in Details zu verlieren > Quality Dokumentation nicht genügend beachtet unter Zeitdruck > Quality Programmierfehler, WebSecurity, Fehlerhafte Algorythmen Projekt ist nicht fertig in der Zeit und im Budget Projekt: Dauer/kosten zu groß Regulatorisch: FDA/EMEA Anforderungen erfüllen Datensicherheit Projektabhängigkeiten, Ressourcen Projektlaufzeiten, nicht eingehaltene Termine Projektrisiken z.b. RessourcenEngpässe Umstellung auf neue Architekturen z.b. SOAP Projektrisiken: Ausfall bzw. Nichtverfügbarkeit von Experten /KeyPlayern Produktrisiken: realisierte Fachlichkeit und Workflow entspricht nicht den Vorstellungen der Fachseite Projektumfang ändert sich Projektumfang, Iterationen, fester Liefertermin Qualität der Lieferanten Verfügbarkeit der im Projekt involvierten Mitarbeiter Qualität und Vollständigkeit der Anforderungen Ausbildung der Implementationspartner Change Management im Projekt Querschläger (Fehlerbehebung führt zu neuen Fehlern auch im nicht direkten Programmumfeld) Spezifikation war unzureichend / falsch / unverständlich Entwicklungszeit dauert länger als geplant (unerwartete Probleme bei der Umsetzung) Refactoring (Austausch alter Komponenten gegen neue) funktioniert nur eingeschränkt (z.b. hardwareabhängig) Realitätsferne Auftragslagen Rechenfehler bei Zahlungen Rechenfehler, Falsche Vorschreibungen, Buchungsfehler, Aussendungen, Performance Requirements nicht richtig, klar dargestellt Entwicklung wird duch IT durchgeführt ohne Business/Kunden Einbindung Ressourcen Ressourcen Ressourcen Zeitplanung Späte Änderungswünsche Ressourcen, Lieferverzögerungen der SW Ressourcen, Speicher, Performance, laufende und späte Kundenänderungen Ressourcenplanung RessourceVerfügarkeit Späte Änderungen (auch undokumentiert) schlechte Aufwandsabschätzungen Ressourcen, Termintreue, Kosten(überschreitung) Ressourcen (allgemein) Kundenknowhow und Prozesse sind nicht wie zugesagt verfügbar

69 53 Ressourcen (Krankheit, Überlappung, etc.) Lieferengpässe bei Vorlieferanten Ressourcen (Personell und Finanziell) Ressourcen / Personal Zulieferungen Ressourcen und Performance und damit verbunden die Zeit, da dieser dadurch nicht eingehalten werden kann und somit auch die Kosten :) Ressourcen Neue Technologien Ressourcen Neue Technologien Ressourcen Termine Ressourcen Zeit Ressourcen Zeitplan Budget Systemverfügbarkeit keine klar definierten Prozesse nicht qualifizierte Tester, Testkoordination und Testmanagement kundenseitig (Verständnismangel dieser Thematik oft werden hier Kollegen eingesetzt die "irgendwo" untergebracht werden müssen) Ressourcen, abweichende fachliche Definitionen, Scopeänderungen, gesetzliche Rahmenbedingungen Ressourcen, Budget, Zeit, Qualität, Requirement Engineering, Ressourcen, Technik, Managementsupport, Abhängigkeiten Ressourcen, Testdaten Ressourcen, unbeherrschte Technologie, Ext. Zulieferung Ressourcen; Abhängigkeiten von anderen Projekten Ressourcenausfall Qualität des Requirenments / Fachkonzepte Qualität des Lifecycle Releasemanagement Zeit Ressourcenengpässe Ressourcenengpässe Architekturmängel Ressourcenengpässe konkurrierende Projekte variable Anforderungen

70 54 RessourcenEngpässe sich verändernde Anforderungen konkurrierende Änderungen an anderen Komponenten Ressourcenengpässe technologische Unwägbarkeiten Ressourcenengpässe, unrealistische Zeitvorgaben Ressourcenkonflikte, Requirements creepping, zeitliche Verzögerungen durch nicht bekannte Effekte/ unterschätzten Aufwand bei neuen Entwicklungsumgebungen Ressourcenmangel Ressourcenmangel, Meilensteine werden nicht erreicht Ressourcenplanung: Zeit und Personal Ressourcenverfügbarkeit Ressourcenverfügbarkeit Ressourcenverfügbarkeit Ressourcenverfügbarkeit HWVerfügbarkeit in ausreichender Menge für Entwicklung und Test Termintreue Ressourcenverfügbarkeit Projektverzögerungen neue/sich ändernde Anforderungen Abhängigkeiten zu andere Projekten/Releases Ressourcenverfügbarkeit wechselnde Anforderungen Ressourcenverfügbarkeit/Budget restrictions Dependencies/Dependency management (techn. Abhängigkeiten, Abhängigkeiten zwischen Projekten, TechStack, Integration) User acceptance (technische und Infrastrukturprojekte ausgelöst durch LifeCycle Mgmt und EndofLife of Components kein direkter Business Nutzen) Scope creep, unclear requirements ressources and priority Ressourenproblematiken aufgrund Multiprojektansätze, zu kurz anberaumter "Pilotzeitraum" Schadensersatz, Datenschutz, Umsatzdatenverlust Schätzung stimmt nicht mit dem tatsächlichen Aufwand überein Schlecht formulierte Anforderungen. NichtFunktionale QMerkmale schlechte Anforderungsqualität unrealistische Termine zuwenig Testkapazität schlechte Testplanung Schnittstellen ausserhalb unseres Kontrollbereichs; Mangelndes Commitment des Kunden Scopeänderungen, Unklarheiten bei der technischen Konzeption, Änderungen im Zeitplan, unrealistische Zeitpläne Security, Umsysteme sich ändernde Anforderungen Enger Zeitrahmen Budget unbekannte Technologien

71 55 Sicherheitsrisiken für Patienten und Anwender (Medizintechnik Branche) Sicherheitsrisiken, die von der entwickelten Software ausgehen können Sicherheitsrisiken, Stabilitäten, Performance, Termineinhaltung, Zulieferqualität sind leider nicht näher zu definieren... meißtens jedoch Stat von PreTest Phasen Software externer Zulieferer sehr fehlerhaft Fehler werden erst im hauseigenen Abnahmetest gefunden Späte Softwarelieferungen Spezifikation, Verfügbarkeit von Mitarbeitern, Tests und Testdaten ständiger Wechsel von Prioritäten und Anforderungen an Software hat Auswirkungen auf Testqualität zu viele Tools Systemkomplexität / Abhängigkeiten sowohl technisch wie organisatorisch Technical Debt Mißverständnis zwischen PO und Team BusNumber (wie viele Leute können krank werden, bevor das Projekt leidet) technische Details, Kapazität, Hardwareentwicklung technische Probleme Ressourcen Teilung technische Realisierbarkeit, externe SW Entwicklung technische Risiken, Scope Creep, Verfügbarkeit von Schlüsselpersonen Technologie Unklare Anforderungen Zeitplan Technologische Machbarkeit, Umsetzbarkeit mit eigenem Personal, Partikularinteressen Termin (Erstlieferung, Abnahme) termine personal technik Termine, die nicht eingehalten werden Termine, Ressourcen, belastbare Requirements Termineinhaltung Termineinhaltung aufgrund unzureichender Testbasis verminderte Prüftiefe aufgrund unzureichender Testbasis Termineinhaltung der externen Lieferanten Termintreue aufgrund unzureichender Testbasis Testtiefe aufgrund unzureichender Testbasis Termintreue durch externe Lieferanten Unklare Qualität der gelieferten SW Terminüberschreitung Terminüberschreitung durch veränderte Anforderungen Terminverschiebungen; Budgetüberschreitung; Erweiterung des Projektumfanges Terminverzug bei externen und internen Zulieferer ChangeRequest durch Kunden Terminverzug oder unzureichende Prüftiefe (beides aufgrund unzureichender Testbasis)

72 56 Terminverzug von Beistellungen Sich vom Kunden ändernde Anforderungen Verschiebung von Kundenmeilensteinen Testbarkeit der Basis Zeit Budget zu spätes Testen Testkapazität Teststrecken nicht vorhanden Serienhardware nicht für Freigabetests verfügbar Testumgebung Testdaten nicht klare, eindeutige Requirements Time Spez Errors Time & Budget time and budget Time and Budget Testumgebungen stehen nicht zur Verfügung Tod Einzelner oder vieler Umsetzungsphase Umsysteme Lieferverzögerungen der früheren Phasen unangemessene Aufwandsplanung fehlerhafte Ressourcenplanung Unbekannte Anforderungen, sich ändernde Anforderungen, nicht ausreichend bekannte und dokumentierte Softwaresysteme, Kommunikationsprobleme ungenügend exakt recherchierte Randbedingungen und Anforderungen. fehlerhaft validierter Test. (Ein Test, welcher die korrekte Funktion zu bestätigen scheint und fälschlicherweise als gültig validiert wurde.) ungenügende Anforderungen; mangelhafte Beistellungen ungeplante Anforderungsänderung Ressourcenmangel aufgrund Projektverlängerung ungeplanter Terminverzug aus anderen Projekten und externen Projekten ungünstige Teamkonstellation (viele JuniorEntwickler, kaum bis keine Senioren) unklare Anforderungen unklare Anforderungen bei Beginn, Abgrenzung, KnowHow nicht mehr verfügbar Unklare Anforderungen Budget Overflow Unklare Anforderungen, Ressourcenausfall, Systeminkompatibilitäten, zu späte bzw. mangelhafte Zulieferungen Unklare Anforderungen: Z. B. nicht detailliert genug Anforderungen nicht mit fachlichen Testfällen gehärtet Mehr als drei Autor/LeserZyklen Mangelnde fachliche Beistellungen des Auftraggebers ITVerständnis des Auftraggebers (fehlender Coach für den AG) unklare Kundenanforderungen, Änderungen gesetzlicher Rahmenbedingungen Unklare Schnittstellen zum Projektpartner, unklare requirements

73 57 unklare und sich ändernde Anforderungen, Mitarbeiterwechsel Unscharfe Anforderungen, sich stetig verändernde Anforderungen, nicht entscheidungswillige Entscheidungsträger, mangelnde Auftraggebermitwirkung, Entwicklungskosten, mangelndes Personal/mangelnde Qualifizierung Unsicherheiten in der Spezifikation. Unsteuerbare externe Einflüsse (Gesamtlage Wirtschaft, etc.) Keine direkte Einflussnahme auf strategische Entscheidungen des Zielmarktes unterschaetzung der komplexitaet bzw. der abhaengigkleit zwischen komponenten Unterschiedliches Verständnis von agilen Requirements Unvollständige oder falsche Vorgaben unvollständige Requirements der Kunden, Terminverschiebungen durch den Kunden unzureichende Beistellungen Verzögerungen im Zeitplan Unzureichende oder ungenaue Spezifikationen, Fehlerhaft validierte Tests Veränderungen des Feature Sets durch Kunden Technische Komplikationen bei Einsatz innovativer Techniken Verfügbarkeit / Ausfall / Fluktuation von Personal, technische Probleme (inkl. Performance) späte Änderungen der Requirements Verfügbarkeit der Anforderer Verfügbarkeit der embedded HW, technologische Risiken, Änderung der kundenanforderung, Verfügbarkeit der Mitarbeiter im Projekt, ausreichendes KnowHow fachlich und technisch, Change Management, Einbindung & Mitarbeit Fachbereich (RequirementsEngineering, Modellierung, User Acceptance Test) Verfügbarkeit der Ressourcen (Menschen, Geld, HW/SWSysteme) Verfügbarkeit Personal (geteilt unter mehreren Projekten) Verfügbarkeit Ressourcen (Entwicklung) Zusammenarbeit mit externen Lieferanten Verfügbarkeit Testumgebung Verfügbarkeit von (kritischen) Ressourcen Verfügbarkeit von KeyPlayern, KeyRessourcen, meist Mitarbeiter mit fachlichem KnowHow. Verletzung/med. Falschbehandlung von Beteiligten in der Anwendung Vernachlässigung Risikomanagement Verspätete / qualitativ schlechte Zulieferungen des Kunden bei gleichzeitiger Erwartungshaltung der Termin und Budgettreue Ressourcenengpässe Vernachlässigung Test beim Zeitdruck am Projektende verschiedene Projektrisiken: Personen nicht verfügbar, nicht genügend Commitment der obersten Leitung

74 58 Verständnis der Kundenanforderungen Verzögerte Fertigstellung der Softwareartefakte; Qualitätsmängel der Anforderungen; Unzureichende Qualität der Software bei Auslieferung zum Systemtest. Verzögerungen, ausbleibende Lieferung, Stau Verzug bei der Entwicklung (nicht geplante volle Funktionalität erreicht) Fehlende Stabilität und Performance Themen unterschätzt oder bei Quote ganz übersehen Späte Änderungswünsche vom den Kunden Verzug durch Dritte Vertragsschwierigkeiten vom Kunden vorgegebene Zeitrahmen schlechte/verspätete/unzureichende Beistellungen Z.T. werden kritische (kostspielige) Fehler viel zu spät entdeckt. Zeit Zeit und Budget, manchmal "MEnschen mit magischer Bedeutung" Zeit und Ressourcenmangel Nichteinhaltung der erforderlichen Kommunikation Gesetzliche Änderungen Zeit zu kurz Zeit Ressourcenknappheit Zeit, Budget, Resourcen Zeit, Geld, Mitarbeiter Zeit, Geld, Überschneidung mit parallel Projekten Zeit, Kompetenz der externen Ressourcen (Entwickler, Tester) Zeit, Kosten, Qualität Zeit, Resorcen Zeit/Budgetüberschreitung durch unvorhergesehene technische Herausforderungen und Probleme Zeitbedarf, Konzeptionelle Änderungen Zeitdruck; mangelndes Testverständnis der Fachabteilung Zeitdruck, wechselnde Kundenanforderungen Zeitlich unrealistische Schätzungen; Falsche Erwartungen an die SW Zu wenig Unterstützung der Kunden / Fachseite Zeitmangel, Komplexität der Systeme, Produktivnahme mit akzeptierten Fehlern Zeitplan Budgetüberschreitung Zeitüberschreitung, mangelnder Funktionsumfang, fehlerhafte Software Zeitüberschreitungen, Wechsel der Auftraggeber/Sponsoren, Veränderung des Projektscope Zeitverzoegerungen Zeitverzögerung Zeitverzug durch Verzögerung bei der eigentlichen Softwareentwicklung (teilweise wegen schlechter Abstimmung mit Fachbereich; teilweise schlechte Vorgaben); Außer Acht lassen von RolloutVorbereitungen Zeitverzug Budgeterweiterung Scope Management

75 59 Zieländerungen, Kundenumfeld zu grobe Planung, falsche Einsschätzung, Verzögerung nicht akzptiert da politisch motiviert dies nicht sein darf. zu hoher Entwicklungsaufwand, technische Probleme (Hardware) zu knappe Zeit, Ressourcen fehlen, Performance zu späte Erstellung von Fachkonzepten, zu späte Lieferung der Software fürs Testing zu späte Fertigstellung Offshore (mangelnde Qualität) zu viel Fachlichkeit unklare Spezifikation keine Instanz bei Kunden die projektübergreifend entscheidend und priorisieren kann Zu viel Funktionalität geplant (PM), Vergolden, Kontinuierliche Anforderungsänderungen zu wenig erprobte Produkte Zu wenig Ressourcen Termin kann nicht gehalten werden Kosten laufen davon, Qualität leidet unter Termindruck zu wenig Ressourcen; Schlüsselpersonen fallen aus zu wenig Tests, sich ändernde Anforderungen, unerfahrene Projektleiter, fehlerhafte Software vom Zulieferer. Zugriffe Unberechtigter auf vertrauliche Daten zulieferer nicht fertig, daten sind nicht konsitent, ressourcen sind nicht in der Zeit verfügbar. Zulieferer, neue Techniken, Ressourcen Zulieferleistungen, Änderung der Vorgaben bzw. Qualität der Dokumentation, Zulieferungen zu spät (z.b. Hardware), Ressourcenengpässe (SW und Test) Zu späte Lieferung der Software aufgrund von schlechter Release Planung Zuverlässigkeit Tabelle 4-33: Antworten zu Frage 3.1.2

76 Frage Gründe gegen Risikoanalyse Warum wird keine Risikoanalyse erstellt? Tabelle 4-34: Gründe gegen eine Risikoanalyse Abbildung 4-21: Gründe gegen eine Risikoanalyse

77 Frage 3.2 Selbständige Qualitätssicherungsgruppe Existiert in Ihrem Unternehmen eine selbständige Qualitätssicherungsgruppe/-abteilung? Tabelle 4-35: Selbständige Qualitätssicherungsgruppe Abbildung 4-22: Selbständige Qualitätssicherungsgruppe

78 Frage Zuordnung QS-Gruppen / -Abteilungen (abhängige Frage 3.2) Welchem Bereich ist die Qualitätssicherungsgruppe/-abteilung zugeordnet? Tabelle 4-36: Zuordnung der Qualitätssicherungsgruppe/ -abteilung Abbildung 4-23: Zuordnung der Qualitätssicherungsgruppe/ -abteilung

79 Frage Anzahl Personen in der QS Wie viele Personen sind der Qualitätssicherungsgruppe/-abteilung zugeordnet? Anzahl: 4500 Anzahl Personen Abbildung 4-24: Anzahl der Personen in der QS

80 Frage Prozentualer Anteil verglichen mit SE-Beschäftigte Dies entspricht einem prozentualem Anteil im Vergleich zu allen in der Softwareentwicklung beschäftigten Personen von: Anteil: 120 Prozentualer Anteil Abbildung 4-25: Prozentualer Anteil

81 Frage 3.3 Verantwortlicher für die QS in Projekten Wer ist verantwortlich für die Qualitätssicherung in den Projekten? Tabelle 4-37: Verantwortlicher für Qualitätssicherung in Projekten

82 Frage 3.4 Entscheidung über Maßnahmen zur QS Wie wird in der Regel über die Maßnahmen zur Qualitätssicherung entschieden? Tabelle 4-38: Entscheidung über Maßnahmen zur Qualitätssicherung Abbildung 4-26: Entscheidung über Maßnahmen zur Qualitätssicherung

83 Frage 3.5 Ziele der QS Welche Ziele werden in Ihrem Unternehmen bezüglich der Qualitätssicherung verfolgt? Tabelle 4-39: Ziele Qualitätssicherung Kostensenkung Abbildung 4-27: Ziele Qualitätssicherung Kostensenkung

84 68 Tabelle 4-40: Ziele Qualitätssicherung Erhöhung der Leistungsfähigkeit Abbildung 4-28: Ziele Qualitätssicherung - Erhöhung der Leistungsfähigkeit

85 69 Tabelle 4-41: Ziele Qualitätssicherung Erhöhung der Standardisierung Abbildung 4-29: Ziele Qualitätssicherung Erhöhung der Standardisierung

86 70 Tabelle 4-42: Ziele Qualitätssicherung Erhöhung der Automatisierung Abbildung 4-30: Ziele Qualitätssicherung Erhöhung der Automatisierung

87 Frage Weitere Ziele der QS Weitere Ziele? Abbildung 4-31: Wortwolke der Antworten zu Frage Einhaltung der Revisionsanforderungen Bessere Software abliefern Absicherung von SW Q-Standards Abwicklung von Entwicklungsprojekten nach Firmenstandards, Reduktion des kaufmännischen Risikos Akzeptanz der Anwendung Anwender-Zufriedenheit Auch die Standardisierung des Entwicklungsprozesses, Dokumentation und Compliance, Förderung Einbeziehung der Fachbereiche/Auftraggeber Automotive-SPICE Konformität Befolgung von nationalen Vorschriften FDA, MPG,... Betrieb Das ist schwer zu sagen wie viele Leute da arbeiten - pro Entwicklung ist einer zugeordnet, der kann aber mehrere Entwicklungen betreuen... Die Kosten sind kein explizit genanntes Ziel, sondern ein implizites. Fehlervermeidung (Prävention) ist vorrangig.

88 72 Effiziente Verwaltung von Softwaresystemfamilien über den kompletten Lebenszyklus, um insb. in der laufenden Wartung Aufwände einzusparen. Effizienzsteigerung (mehr Testprojekte im selben Zeitraum) Einarbeitung neuer KollegInnen Qualitätsbewußtsein Wartungsfähigkeit Einführung der Entwicklungsmethodik SCRUM Einführung Risikobasiertes Testing, Testmetriken Einhaltung der Planung (Termine / Kosten / Funktionalität) Einhaltung der Richtlinien für Zertifizierung Einhaltung Vorschriften, Normen Erhöhung der Agilität für die Geschäftsprozesse bzw. deren IT-Entwicklung Erhöhung der Kundenzufriedenheit Erhöhung der Kundenzufriedenheit Einhaltung von Terminen Erhöhung der Testabdeckung Erhöhung der Leistung, die zum Kunden getragen werden kann. Erhöhung der Performance: Verminderung der Gesamt-Testdauer bei gleichbleibender Qualität und Berücksichtigung aller regulatorischen Erfordernisse Erhöhung der Produktqualität Erhöhung der Testabdeckung Erhöhung der Testgeschwindigkeit Erhöhung der Wiederverwendbarkeit Erhöhung des Bewusstseins der Entwickler für Qualitätsfragen Erkenntnisgewinn Erleichterung für die Kunden Erreichung der Zieltermine - Hauptziel Abarbeitung der Testfallsollmengen - Hauptziel Es geht nicht nur um SW-Fehler, sondern um die QS fuer alle Artefakte waehrend der SW- Entwicklung: Modelle, Dokumente, etc. Feedbackmeeting, Lesson learned zur Analyse der Schwachstellen und darauf Ableitung von Verbesserungsmassnahmen. Fehler bei SOP Funktionierender Betrieb Gutes Bild nach außen liefern Hauptziel ist Senkung Testaufwand beim Kunden Hauptziel: Kundenzufriedenheit Hauptziele: Erreichung der Zieltermine und der Sollzahlen, insbesondere: Zahl der durchgeführten Testfälle = Zahl der geplanten Testfälle und das unabhängig von der Eingangsqualität und irgendeiner Priorisierung der Testfälle - zur Not halt abhaken. Hohe Qualität der erstellten Software bezüglich Antwortzeiten, Korrektheit und Robustheit Image-Pflege In den meisten Projekten nur durchgeführt, weil das Projektvorgehen es so vorschreibt. in Time and Budget Industrialisierung des Software-Entwicklungs-Prozess

89 Kundenwahrnehmung und Marken(=Firma)Bewusstsein durch Produktqualität positiv beeinflussen, steigern und langfristig sichern und somit insegsamt zur gesamtbetriebswirtschaftlichen Zielerreichung (monetärer, etc.) beutragen. Kundenzufriedenheit kundenzufriedenheit Kundenzufriedenheit Kundenzufriedenheit Kundenzufriedenheit Kundenzufriedenheit durch reduzierte Fehleranzahl nach Inbetriebnahme Kundenzufriedenheit Mitarbeiterzufriedenheit Integration von Partner und Zulieferern Soziale Verantwortung Zufriedenheit der Anteilseigner Kundenzufriedenheit, Erreichung der Projektziele der kunden Kundenzufriedenheit, Qualität als Aushängeschild mehr Kapazitäten für Neuentwicklung freisetzen Kundenzufriedenheit / Akzeptanz der Software bei den Endnutzern korrekte Umsetzung der Kundenvorgaben Prozeßanlyse und Prozeßverbesserung QS bezieht sich v.a. auf das Projektmanagement, V-Modell QS ist Voraussetzung für die Zulassung der Produkte auf dem Markt (FDA-Prüfung) Qualitätssteigerung Qualitätssteigerung, Kundenzufriedenheit, schnellere Prozesse in der Testabwicklung Reduzierung der Fehleranzahl im ausgelieferten Produkten Reduzierung der Projektkosten und Durchlaufzeit Regulatorien Restriktivere Prozesse Seigerung der Verbraucherzufriedenheit Senkung der Projektlaufzeiten und späterer Reklamationen Sicherstellung der Benutzbarkeit Sicherung der Projektrendite Stabilisierung der prod. Umgebung Stabilität des Gesamtsystems ist das hauptsächliche Ziel Stabilität, Performance Stärkung der Geschäftstreiber Stärkung des Qualitätsbewusstseins innerhalb der Projekte Steigerung Kundenzufriedenheit, Synergiennutzung in verschiedenen Projekten, Implementierung von Firmenstandards Teamverantwortlichkeit für Qualität Technologiepräsenz am Markt Teilweise detailliert geregelt: Prinzip: so viel wie nötig - Terminhaltung Testabdeckung muss für Continuous Deployment ausreichen Tests wurde erst durch mich eingeführt, die Unternehmensleitung sieht darin teilweise noch keinen Sinn time2market Verbesserung der Gebrauchsqualität, Erhöhung der Kundenzufriedenheit 73

90 74 Verbesserung der Produktqualität, Verbesserung der Kundenzufriedenheit, Verbesserung der Ausbildung der Projektmanager, verstärkter Einsatz qualifizierter Testmanager, Vermarktung von Qualitätsmanagement-/Qualitätssicherungs-Dienstleistungen Verbesserung der Qualität Verbesserung der Softwarequalität. Verbesserung des Code Designs gestärktes Vertrauen in Software Vergleichbarkeit der Projekte Verkürzung der Testzeit Vermeidung von Budget Overrun Weniger Administration Weniger Fehler Tabelle 4-43: Antworten zu Frage 3.5.1

91 Fragenkomplex 4 Maßnahmen zur Qualitätssicherung Frage 4.1 Reviews in Projekten Werden in Ihren Projekten Reviews durchgeführt? Tabelle 4-44: Reviews in Projekten Abbildung 4-32: Reviews in Projekten

92 Frage Dokumente für Reviews Welche Dokumente werden in Ihren Projekten in aller Regel einem Review unterzogen? Tabelle 4-45: Dokumente für Reviews Anforderungen Abbildung 4-33: Dokumente für Reviews Anforderungen

93 77 Tabelle 4-46: Dokumente für Reviews Architektur Abbildung 4-34: Dokumente für Reviews Architektur

94 78 Tabelle 4-47: Dokumente für Reviews Design Abbildung 4-35: Dokumente für Reviews Design

95 79 Tabelle 4-48: Dokumente für Reviews Code Abbildung 4-36: Dokumente für Reviews Code

96 80 Tabelle 4-49: Dokumente für Reviews Testfälle Abbildung 4-37: Dokumente für Reviews Testfälle

97 Frage Andere Dokumente Abbildung 4-38: Wortwolke der Antworten zu Frage Andere Dokumente: Alle Artefakte des Softwareerstellungsprozesses werden per Review Qualität gesichert Alle work products werden gereviewed Analysen, Testprotokolle, Release Notes Angebote, Projekt- und Testpläne das fertige Programm / Modul / Funktionalität Dokumente im Bereich Projektmanagement (Projektplan, Ressourcen, etc.) fast jedes Dokument - unterstützt durch unser eigens Web-basiertes Review Tool Handbücher und Hilfen. Jedes Dokument, das das Haus verlässt. inkl. Betriebskonzepte Kundendokumentation mdl. Auswertung des Projektverlaufs zw. QS und Projektleiter

98 82 Pflichtenhefte Pläne Pläne (KM. QS, Projekt, Testkonzept) Planungsdokumente Projektabhängig alle bis kein Dokument Projektmanagementplan Projektpläne, Projekthandbücher Projektpläne, Qualitätssicherungspläne (nur formal - wurde das richtige Template verwendet?) Qualitätssicherungspläne, Projektpläne, Change-Requests Requirement Spezifikationen, User Stories, Review = Demonstration der Sprint Ergebnisse (= Fertige User Stories) für das Produkt Management am Ende des Sprints Riskiobetrachtung sonstige Entwicklungsdokumente aus unterstützenden Prozessen Systemdokumentation, Infrastrukturbeschreibungen, Projektpläne, Richtlinien Test begleitende, nicht technische, Dokumentation, die die Entwicklung bzw. deren Ablauf beschreiben (z.b. Design & Development Plan, Integration & Test Plan) Test Quality Gates Testergebnisse Testkonzept Testkonzept Testkonzept immer Planungen (Einführung, Test usw.) selten Testkonzept, sonstige Spezifikationen Testkonzepte Testpläne, Testberichte Teststrategie User Stories Variiert je nach Führungskraft. Wird in letzter Zeit immer mehr vernachlässigt. ITIL macht nun alles :-) wenn vorhanden, dann kein Review Tabelle 4-50: Antworten zu Frage 4.1.2

99 Frage Personengruppen, die Reviews durchführen Folgende Personengruppen führen Reviews in den Projekten durch: Tabelle 4-51: Personengruppen die Reviews durchführen

100 Frage 4.2 Tests auf unterschiedlichen Teststufen Werden Tests auf unterschiedlichen Teststufen durchgeführt? Tabelle 4-52: Tests auf unterschiedlichen Teststufen Abbildung 4-39: Tests auf unterschiedlichen Teststufen

101 Frage Teststufen Auf welchen Teststufen wird in Ihren Projekten getestet? Tabelle 4-53: Teststufen - Unit-/Modul-/Klassen-/Komponententest Abbildung 4-40: Teststufen Unit-/Modul-/Klassen-/Komponententest

102 86 Tabelle 4-54: Teststufen Integrationstest Abbildung 4-41: Teststufen Integrationstest

103 87 Tabelle 4-55: Teststufen Systemtest Abbildung 4-42: Teststufen Systemtest

104 88 Tabelle 4-56: Teststufen Abnahmetest Abbildung 4-43: Teststufen Abnahmetest

105 Frage Andere Teststufen Abbildung 4-44: Wortwolke der Antworten zu Frage Andere Teststufen: (Regressions-)Test ausführbarer Spezifikationen (xuml) 1. Annahmetest - 2. Funktionstest - falls Kundenauftrag: 3. Abnahmetest durch Kunde Akzeptanztest Backward/Forward Kompatibilitaet, Performance Tests, Coexistence Tests Betatest Beta-Test durch Anwender

106 90 da wir kein Systemhaus sind, sondern auf der Kundenseite, geht es bei uns nur um Abnahmetests und Systemintegrationstests. Letztere fehlen leider bei den Auswahlmöglichzeiten. Diese werden von ausgebildeten Testern ausgeführt. E2E-Tests Performancetests Eingangstests für zugelieferte Komponenten fachlicher Test Einzelfunktion (FTE) Fachlicher Test Einzelfunktionen Fahrzeugtest Freigabetest Funktionstests von Einzelfunktionen Für ausgewählte Systeme findet noch ein Gesamtintegrationstest statt (End-to-End Test) Handovertest (Entwicklung -> Fachtest) - meist Integrative Tests mit Kunden - meist Flight Check (nach Installation auf Produktion) - teils/teils Handovertest (Übergabe Entwicklung an Test) - meist Anbindungstests mit Großkunden - immer HOST und Serverwelt unterscheiden sich. UNIT-Tests gibt es für den HOST nicht Inhouse, Werkabnahme Integrationstest aufgeteilt in Modulintegrations- und Systemintegrationstest Je nach Projekt und Kunde unterschiedlich keine Lasttest Performancetest Lokalisierung -meist MIL/SIL/HIL Nichtfunktionale Tests (Performance, Usability) Nightly Builds (CI) Nonfunctional tests (usability, security, performance) Öffentlicher Betatest Performance Test, Element-Test Performancetest, Deploymenttest permanenter Regressionstest Produkt- und Funktionstests Qualifikationstest Regressionstests Releasetest mehrerer abgenommener Projekte auf einer gemeinsamen Preproduktionsumgebung Sicherheitstest nach Richtlinien SST = System Stability Test vor Eintritt in Abnahmetest SW-HW-Integrationstest Softwaretest (nicht auf dem Target!) SW-Systemtest SW-Systemtest Systemintegrationstest Systemintegrationstest

107 91 Systemintegrationstest Systemintegrationstest Systemintegrationstest entlang Geschäftsprozessen, da bei uns in der Regel mehrere Anwendungen in einem Geschäftsprozess zum Einsatz kommen müssen Systemintegrationstests Test - Integration - Produktion Test-Planung folgt den Agile Testing Quadrants von Brian Marick. Im Laufe der Iteration wird mehrfach dieselbe User Story getestet, ohne dabei zwischen Integration- und Systemtest zu unterscheiden (dies findet zwar statt, aber nicht als Begrifflichkeit). Zudem findet Pair Testing (Tester mit Entwickler statt) um den Feedback Loop der Entwickler zu verkürzen. Unit/Integrationstests werden in Testsuites nach Laufzeit und Funktionalität unterschieden und nicht immer alle durchlaufen. Unterscheidung Komponenten-/Systemintegrationstests, Wartungs-/Regressionstests User acceptance test User Acceptance Test, Performance Test, Operational Readiness Test Validationstests mit Fahrzeug Verbundtest, System-Integrationstest verfahrensübergreifender/releaseweiter Systemintegrationstest Wartungstest Wir testen nicht, um die Qualität zu sichern, sondern um Code-Design zu erhalten. Ein Irrtum dieser Umfrage? Nein, ich habe sie anders verstanden! Tabelle 4-57: Antworten zu Frage 4.2.2

108 Frage Personengruppen für Test unterschiedlicher Teststufen (abhängige Frage 4.2.1) Folgende Personengruppen führen Tests auf den unterschiedlichen Teststufen durch: Tabelle 4-58: Personengruppen für Tests auf unterschiedlichen Teststufen Abbildung 4-45: Wer testet auf unterschiedlichen Teststufen? [Quelle: Henning12]

109 Frage 4.3 Unterscheidung unterschiedlicher Testarten Werden in Ihrem Projekt unterschiedliche Testarten unterschieden? Tabelle 4-59: Unterscheidung unterschiedlicher Testarten Abbildung 4-46: Unterscheidung unterschiedlicher Testarten

110 Frage Spezielle Testarten Welche speziellen Testarten werden in Ihren Projekten eingesetzt? Tabelle 4-60: Testarten Last-/Performancetest Abbildung 4-47: Testarten Last-/Performancetest

111 95 Tabelle 4-61: Testarten Migrationstest Abbildung 4-48: Testarten Migrationstest

112 96 Tabelle 4-62: Testarten Regressionstest Abbildung 4-49: Testarten Regressionstest

113 97 Tabelle 4-63: Testarten Smoketest Abbildung 4-50: Testarten Smoketest

114 98 Tabelle 4-64: Testarten Sicherheitstest/Penetrationstest Abbildung 4-51: Testarten Sicherheitstest/Penetrationstest

115 Frage Andere Testarten Abbildung 4-52: Wortwolke der Antworten zu Frage Andere Testarten: Überprüfung der Umsetzung lt. definiertem Testplan Abnahmetest Abnahmetests durch Kunden/Anwender Akzeptanztests Ausfalls-Tests, Usability-Tests Benutzbarkeitstest Beta-Test durch Anwender Betreibbarkeit Black-Box-Test ca. 40% Test neuer Funktionen, 55% Regressionstest, 5% Lasttests

116 100 Conformance tests gegen offizielle Standards Dauerlauftest Drunken Monkey Test End-to-End - Tests Explorativer Test Fachliche Abnahmetests Fachliche Tests (tlw. automatisch, tlw. manuell) Funktionale Tests (anforderungs- oder geschäftsprozess-basiert) Funktionale Tests, Layouttests, Contenttests, Browser-Kompatibilitäts-Tests Funktionaler Test, Funktionaler Test unter Last Funktionstest Funktionstest Funktionstest, Benutzbarkeitstest, Stresstest, Installationstest Funktionstest, End-to-End-Tests Funktionstest, e2e Test Funktionstest, Resourcentest (RAM/ROM/CPU) Funktionstests, Layouttests, Content-Tests, Browser-Kompatibilitäts-Tests Installationstest, Datenbanktest Je nach Projekt und Kunde keine Kompatibilitätstests, Usability-Tests, Explorative Tests Komponententests, Usability-Tests, Fachliche Systemtests Konformitätstests Mission Simulation Test, Operabilitätstests, Failovertest, Fallbacktest Paralleltest - gleiche Eingaben in Produktionsumgebung und Test Portabilitätstests Produktionstest (Gütekontrolle) Robustheitstests Sizing (Resource Consumption) test, Usability Test, Type (Device in the field / Safety) Test Stabilitäts-, Trackingtest Temperaturtest (SW in abh. von HW) Tests im Produktionsanlauf Unit-Tests, Explorative Tests, Akzeptanztests Usability Testing User Acceptance Testing (findet i.d.r. im "End Game" statt, eventuell aber auch nach einer Release-Iteration) Usability Tests, Test auf Einhaltung von Design und Styleguide Usability tests, operation tests Usability-Test, Stresstest, Fehlernachtest, weitere NFA-Tests nach Anforderung Usability-Test; betriebliche Validierung Zuverlässigkeitstest Tabelle 4-65: Antworten zu Frage 4.3.2

117 Frage Personengruppen, die Tests der Testarten durchführen Folgende Personengruppen führen Tests der Testarten in den Projekten durch: Tabelle 4-66: Personengruppen die Tests der Testarten durchführen Abbildung 4-53: Wer testet in den verschiedenen Testarten? [Quelle: Henning12]

118 Fragenkomplex 5 Aufwandsschätzung Frage 5.1 Aufwandsplanung der QS Der Aufwand (Budget und Zeit) der Qualitätssicherung wird in aller Regel in Ihren Projekten Tabelle 4-67: Planung des Aufwands (Budget und Zeit) der Qualitätssicherung Abbildung 4-54: Planung des Aufwands (Budget und Zeit) der Qualitätssicherung

119 Frage Aufwandsplanung QS: Verhältnis zum Gesamtaufwand Wie hoch planen Sie den Aufwand für die Qualitätssicherung im Verhältnis zum Gesamtaufwand? Prozentualer Anteil zum Gesamt-Budget: 120 Gesamt-Budget - prozentualer Anteil Abbildung 4-55: Gesamt-Budget prozentualer Anteil Prozentualer Anteil zur Gesamt-Zeit: 120 Gesamt-Zeit - prozentualer Anteil Abbildung 4-56: Gesamt-Zeit Prozentualer Anteil

120 Frage Geplantes Budget für die QS Das geplante Budget/Zeit für die Qualitätssicherung wird im Mittel Tabelle 4-68: Geplantes Budget / Zeit für die Qualitätssicherung Abbildung 4-57: Geplantes Budget / Zeit für die Qualitätssicherung

121 Frage Gewichtung der Maßnahmen zur QS Gewichten Sie die Maßnahmen zur Qualitätssicherung bezüglich Ihrer Aufwandsschätzung. Tabelle 4-69: Maßnahmen QS Reviews Abbildung 4-58: Maßnahmen QS Reviews

122 106 Tabelle 4-70: Maßnahmen QS Unit-/Modul-/Klassen-/Komponententest Abbildung 4-59: Maßnahmen QS Unit-/Modul-/Klassen-/Komponententest

123 107 Tabelle 4-71: Maßnahmen QS Integrationstest Abbildung 4-60: Maßnahmen QS Integrationstest

124 108 Tabelle 4-72: Maßnahmen QS Systemtest Abbildung 4-61: Maßnahmen QS Systemtest

125 109 Tabelle 4-73: Maßnahmen QS Abnahmetest Abbildung 4-62: Maßnahmen QS Abnahmetest

126 Frage Andere Maßnahmen der QS Andere Maßnahmen: 1) Frage zum prozentualen zeitlichen Aufwand nicht beantwortet, da Frage unklar: prozentualer Anteil der Ressourcen (dann Dopplung) oder zeitliche Begleitung (dann andere Formulierung notwendig). 2) Bei der vorliegenden Frage passen Frage und Antwortauswahl nicht zusammen (Was ist angemessene Gewichtung als Mittelwert einer Maßnahme bzgl. Aufwandsschätzung?) Gewichtung sollte immer angemessen sein (auch sehr wichtig kann angemessen sein). 3) Markierung lässt sich nicht mehr entfernen. Die Frage ist unklar. Was ich für wichtig halte, ist nicht identisch mit dem, was tatsächlich gemacht wird. die Fragestellung ist mir nicht ganz klar - ich interpretiere es so: angemessen = Budget entspricht dem Bedarf weniger Wichtig = Budget zu klein wichtig = Budget größer, als nötig Drunken Monkey Test, Stabilitätstest Einfache "Mitarbeit" im Projekt macht einen großen Teil des Aufwands aus (Teilnahme an Besprechungen etc.). Nur wenn man dabei ist, weiß man was los ist. Fahrzeugtest ist sehr wichtig

127 111 fehlende Maßnahmen müssen erst noch eingeführt werden keine keine Lokalisierung - wichtig nicht meine Verantwortung Paralleltest - wichtig Piloteinführung (als UAT) - sehr wichtig Qualitätsplanung, Testspezifikation, Testerstellung, Testdatenbeschaffung/-erstellung, Testsystembeschaffung/-verwaltung Trainings, Handbuecher, Guidelines

128 Fragenkomplex 6 Fehlermanagement Frage 6.1 Dokumentation gefundener Fehler In der Regel wird jeder gefundene Fehler Tabelle 4-74: Dokumentation gefundener Fehler Abbildung 4-63: Dokumentation gefundener Fehler

129 Frage 6.2 gefundene Fehler In der Regel wird jeder gefundene Fehler Tabelle 4-75: gefundene Fehler einer Fehlerklasse zugeordnet Abbildung 4-64: gefundene Fehler einer Fehlerklasse zugeordnet

130 114 Tabelle 4-76: gefundene Fehler einer Priorität zugeordnet Abbildung 4-65: gefundene Fehler einer Priorität zugeordnet

131 115 Tabelle 4-77: gefundene Fehler entsprechend seiner Priorität korrigiert Abbildung 4-66: gefundene Fehler entsprechend seiner Priorität korrigiert

132 Frage 6.3 Fehlernachtests Für Fehlernachtests werden Tabelle 4-78: Fehlernachtests fehleraufdeckende Testfälle wiederholt Abbildung 4-67: Fehlernachtests fehleraufdeckende Testfälle wiederholt

133 117 Tabelle 4-79: Fehlernachtests weitere Testfälle aus dem Fehlerumfeld ausgeführt Abbildung 4-68: Fehlernachtests weitere Testfälle aus Fehlerumfeld ausgeführt

134 118 Tabelle 4-80: Fehlernachtests alle Testfälle als vollständiger Regressionstest Abbildung 4-69: Fehlernachtests alle Testfälle als vollständiger Regressionstest

135 119 Tabelle 4-81: Fehlernachtests keine Testfälle ausgeführt Abbildung 4-70: Fehlernachtests keine Testfälle ausgeführt

136 Frage 6.4 Bedarf für Risiko- und Qualitätsmanagement Abbildung 4-71: Wortwolke der Antworten zu Frage 6.4 Wo sehen Sie Bedarf in Forschung, Entwicklung oder Beratung zum Risiko- und Qualitätsmanagement? (Stichworte reichen aus) 1) Risikomanagement: Bei der Abschätzung von Risiken gibt es meist 2 Gruppen: a) sofort für Experten / Kenner des Umfeldes bewertbar b) schwer bis gar nicht bewertbare Risiken (z.b. Notfallszenarien) ad b) bewirkt bei einer Kostenbewertung meist, dass jedes Projekt nicht finanzierbar ist -> wodurch die gesamt Risikoabschätzung meist ad absurdum geführt wird -> Praxis: Entscheidung Bauchgefühl "wir machen es doch" Hier wäre ein Professionelles Auseinandersetzten wünschenswert - ist auch Abnahmetests als kontinuierliches Mittel der QS Agile Software Entwicklung in Verbindung mit Risikoabschätzungen, Governance, Vorgehensweisen Spezifikationen (Testplan, Strategie)

137 121 agiles Risikomanagement agile Qualitätssicherung Aktives Risikomanagement einführen Analyse von Modulübergreifenden Softwareänderungen Anforderungsanalyse Metriken zur Testaufwandsschätzung Anwendbarkeit Auf welchen Bereich bezieht sich die Frage? Allgemein oder im Unternehmen? Aufklärung des Managements Aufwandschätzung für Tests müssen meist sehr kurzfristig (aus dem Bauch) abgegeben werden. Das widerspricht dem Ansatz, sehr detaillierte Schätzungen nach verschiedenen Methoden anzuwenden. Letztendlich gibt die Erfahrung mit ähnlichen Projekten den Ausschlag. Welche Schätzmethoden sind wirklich in der Praxis anwendbar? Aufzeigen des ROI von QS-/Risikomaßnahmen Ausbildung, Zertifizierungen, Generierung modellhafter Testfälle, Methodik, Modultesting, außer man tut es Automation, Integration in Prozesse Automatisierte Tools, die Case-Tool + Testfall-Generierung kombiniert; stärkere Integration von QM in Rational Unified Process, sinnvolles Normen-Bewusstsein im QM; Forschung in statistischer Risikobewertung Automatisiertes Testen auf Basis von Abnahmekriterien Entwickeln von künstlichen Testdaten (mit dedizierten Defekten einer Echtumgebung) Automatisierung integrativer Systeme Security Testing Usability Testing Automatisierung mit einfachsten Mitteln, sprich ohne Software-Entwicklungs-KnowHow. automatisierung, wiederverwendbarkeit, testdatenerzeugung, standardisierung von testabläufen Bedarf für Risikomanagement generell groß Begleitendes Risikomanagement, leicht in der Anwendung für den operativen Gebrauch Beratung Beratung: Oberer-Management Beratung: Mittel-Management Beratung: Finanz-Management Beratung: Vermittlung von Fähigkeiten für exploratives Testen und erläutern, dass exploratives Testen sehr wohl strukturell ist (siehe Session Based Testmanagement, oder Thread Based Testmanagement). bessere Tools für SW-Integrationstests (Stub- Treibererzeugung und Handling, automatische Dokumentation...) Bessere und umfangreichere Reviews in den Anfangsphasen der Projekte Best practice Lösungen für Risikoanalysen und Aufwandsschätzungen Bewusstsein bei Auftraggebern für die lange Perspektive und die notwendigen Kosten/Aufwände Positiver Umgang mit Fehlern: Jeder Fehler ist ein Schatz - das sieht nicht jeder AG so Bewusstsein für Aufwand im Verhältnis zum Gesamtthema Bewusstseinsbildung bei Kunden und Führungskräften. Darstellung der Qualität in Kennzahlen, die für ein Unternehmen schlüssig sind

138 122 Das Bewusstsein der Entwicklung zu entwickeln, dass QA nicht nur Aufgabe der Tester im Team ist, sondern auch auf Codeebene durchgeführt werden muss. Besonders vor dem Hintergrund, dass der Tester keine Tests durchführen sollte, die sinnvollerweise bereits von den Entwicklern durchgeführt werden können und mehr Zeit für die notwendige Automatisierung aufbringen kann. Das dieses in den Chefetagen ankommt, z.b. Studien über ROI vom R&QM, klare Kostenkalkulation im controlling Das Management muss die entsprechenden Nachweise von Tests und Risikobetrachtungen einfordern, sonst werden diese im Projekt nicht erarbeitet. Definition brauchbarer KPI's Den Kunden muss klar gemacht werden, dass Änderungen im Projekt Risiken nach sich ziehen und nicht mit agilen Methodiken begründet oder abgehandelt werden können, ohne Budget und / oder Zeit zu verursachen. Detaillierte Messung der funktionalen Testabdeckung im System- und Systemintegrationstest Messung von Wartungs-relevanten Code-Kennzahlen Standardisiertes Messen und Verfolgen der Fehlerkosten Erfahrungskennzahlen zur Schätzung des Testaufwands Die Aufwandsschätzungen werden häufig durch die Projekte mit dem Argument "Das ist zu teuer" gedrückt - was zur Folge hat, dass der Test teurer als "geplant" ist. Grundkenntnisse zum Thema Test fehlen vielen Projektleitern. Die Finanzgier des Managements unterdrückt Risiko- und QM bei uns fast vollständig. E s gibt hierfür kein Budget. Erst wenn Fehler beim Kunden vor die Wand fahren - kann/darf man sich drum kümmern. Dazu gibt es dann permanent verbale Prügel, das man nicht schnell genug arbeitet. Am besten mal erforschen, wie man solche gierigen Chefs schnell loswird, da sie mehr kaputt machen als aufbauen! Die Kritikalität von Fehlern wird oftmals technisch als auch wirtschaftlich unterschätzt; es liegen keine Kenntnisse über Fehlerfolgekosten vor, die auch pragmatisch zur Beurteilung von Fehlern zurate gezogen werden können die Person des Projektleiters und seine Einstellung zu QS ist das höchste Risiko im Projekt. Dies geht bisher nirgendwo mit ein. Die Qualitätssicherung muss früher im Projekt beginnen. Das ist aber schwer zu vermitteln. Diese Themen sind insbesondere in der Lehre auf den Universitäten deutlich unterrepräsentiert. Diese sollten - auch über den Werkzeugeinsatz - integraler Bestandteil von Methoden und Techniken werden, die über Modelle/Workflows/Automatismen "dringlich unterstützt" sind. Domänen Automotive und Medizintechnik Durchgängiges Tracking vom Requirement zu Testcase zu Code; Automatisierte Test-Tools in allen Bereich, statische Code-Analysen bis zu dynamischen Tests Durchgängigkeit, Standardtool kann nicht immer excel sein Durchschnittliche Kontingentierung? Abdeckungsgrad? eine bessere "Aufklärung" des Managements ist nötig, weil dort meist entschieden wird, an den Tests zu sparen. Einfach anwendbare, anpassbare (Projektgröße, Risikokategorien,...), mit dem SW Entwicklungsprozess integrierte Vorgehensmodelle Messbarkeit, Quantifizierbarkeit Einfachere Aufwandschätzung

139 123 Einführung in das Qualitätsmanagement bei den Endanwendern, stärkere Prozessorientierung, insgesamt stärkere Integration Entwicklung Entwicklung und Umsetzung von Qualitätsmaßnahmen Erstellung von Standards in Produktrisiko: Identifikation, Analyse und Steuerung hier mangelt es an IEEE und operational nutzbaren Verfahren Es würde ausreichen, die bekannten Dinge konsequent anzuwenden. Kein Bedarf an Forschung, Entwicklung oder Beratung zum Risiko- und Qualitätsmanagement Etabliertes gesamtheitliches Risikomanagement (heißt wie kommen FMEA, SW, Bauteilbetrachtungen usw. zusammen) Fehlendes Prozesswissen zum Risikomanagement Fehlerkosten je nach Phase in der sie gefunden werden Reviews Feste Verankerung in Vorgehensmodelle Überzeugung des Managements über die Notwendigkeit von QM Festlegungen Strukturtest durch Entwicklung Testverfahren, automatisierte vermehrt einbinden Feldtest, Testkunden Fokussierter Test nach Risikoschwerpunkten Formalisierung der Testautomatisierung Forschung, Entwicklung und Beratung Frage ist mehrdeutig Frage nicht verstanden... frühe Fehlerfindung, Modellierung Frühe Verfügbarkeit abgestimmter, eindeutiger, festgeschriebener Anforderungen Fundierte Argumente zu finden, die auch Manager überzeugen können. für mich ist kein Bedarf erkennbar Geschäftsführung sollte zum Thema Qualitätsmanagement besser ausgebildet werden Gibt es einfache Indikatoren, die einen Hinweis geben, wo verstärkt zu testen ist? Es kann 100% Testüberdeckung geben und trotzdem noch Fehler, wenn die Anzahl der Testfälle zu gering! Grobe Vorgaben zur Aufwandsabschätzung (z.b. im Verhältnis zur Implementierung) gute Erfahrung mit TOP Mitarbeitern (gut ausgebildet) guter Mix zwischen manueller/automated execution und ad hoc tests hoher Bedarf bei öffentlichen Einrichtungen, da es unterschätzt wird Ich denke hier fehlt eher das Bewusstsein, als wissenschaftliche Grundlagen. ich weiß nicht Im Bereich Entwicklung Im Topmanagement von Großkonzernen muss ein Bewusstsein dafür entstehen, dass das Ausrufen von Qualitätsoffensiven alleine nicht reicht. Wenn diese Ziele denn ernst gemeint sind, muss auch eine Institution (QM?) mit hinreichender Hausmacht etabliert werden, die in der Lage ist die definierten und notwendigen Prozesse mit Augenmaß durchzusetzen. Oft beobachte ich: - machtlose Qualitätmanagement-Abteilungen, - sehr schlechte Reviews ohne Beteiligung des Tests, auch wenn der Test laut Pro In der Testsystematisierung

140 124 Inspektionen Integration in Testmanagement Tools bzw. Testautomations Tools ja - automatischer Regressionstest und Performancetest mit HP Quality Center Ja neue normen muss berücksichtigt werden keinen, ich arbeite gut mit V-Modell oder Prince Klare Positionierung als eigenständige Disziplin. Ausbildungs-, Weiterbildungs- und Karrierepfade definieren. Nutzen und Wertschöpfung für alle verständlich nachweisen. Etablieren als eine der Steuerungsfunktionen der IT. Know-how-Aufbau bzgl. automatisierten Testens in den Fachabteilungen (d.h. nicht IT) Kommunikation zwischen Risikomanager und Fachbereich, damit das Risiko auch an den Fachbereich vermittelt wird. Komplexität bei verteilten Systemen, HMI Komplexität der Projekte, Strukturverbesserung Kostenfaktor nicht behobener Fehler, Kostenfaktor nicht erreichter Usability. Kosten-Nutzen-Betrachtungen Kundenzufriedenheit sicherstellen, Einhaltung der Prozesse, Produktqualität / Produktsicherheit, geringe Restfehler leichtgewichtige QS-Prozesse, Qualitätssicherung in agilen Projekten, freie Werkzeuge für Effizienztests, freie integrierte Werkzeuge für Testentwurf und -durchführung (wann ist Bromine endlich fertig?), Beschreibungssprachen für automatisierte Oberflächentests Machbarkeitsanalyse, Planung, Zeit, Budget, Zahl der Mitarbeiter maßgeschneiderte Testtools im SAP Umfeld für Kundenanpassungen Maßnahmenauswahl Entscheidungsfreude Medizintechnik Mehr Ausbildung für Tester und Testmanager; mehr Automatisierung von GUI-Tests mehr Budget und Zeit notwendig, bessere koordinierte Prozesse Mehr Budget + Zeit! Mehr Möglichkeiten, kritische Bereiche analytisch zu identifizieren Mehr Ressourcen beim Qualitätsmanagement Messbarkeit des Projektrisikos Gegenüberstellung Aufwand und Ertrag des Qualitätsmanagement Methoden (Risiko-/Q-Management) & Tools Methoden für die Risikoverteilung im Test (z.b. bezogen auf Testfälle) Methoden zur frühzeitigen Fehlererkennung Rollen und Verantwortlichkeiten in Projekten Methoden, Standards Methodik zur Reduktion der Komplexität Tools Methodik zur Implementierung von Prozessen und Methoden Training, Coaching Methodik, Softwareunterstützung, Bedeutung methodische Empfehlungen zum Test von Standard-GUI-Komponenten Methodische Erfassung der Produktiv/Einsatzumgebung Metriken, Benchmarks, best practices konsolidieren

141 125 Modellbasiertes Testen; Effiziente Automatisierung; Verbesserung der Testmanagementwerkzeuge; Statische Codeanalyse; Werkzeuge für Performance-Test und für Security-Test. Nutzen und Anwendbarkeit von Methoden und Vorgehensweisen unter bestimmten Bedingungen. Die Ergebnisse der Forschung differenzieren hier zu wenig. Z.B. für welche Art Software eignet sich Scrum? Was muss gegeben sein, dass Unittests oder GUI- Testautomatisierung mehr bringt als sie kostet. One common understanding for evaluation and prioritization of risks. Risk based testing. Traceability of defect detection and correction in development phase. Cost benefits of fixing defects in development phase. Cost of defect slippage from a given phase to subsequent phase(s). Optimierung im Testvorgehen und Mix von Teststufen und -arten Perfektionismus angemessene Qualität Termindruck Personalressourcen, Kommunikation an Fachabteilungen Planung und Controlling Planungsübersicht fehlt, wichtige Kernkomponenten werden nicht berücksichtigt, Zuständigkeit werden an Externe vergeben, aber aus Kostengründen von diesen nicht übernommen, Risiko- und Qualitätsmanagement ist nur auf dem Papier gültig, es zählt nur Time und Budget, Inhalte werden vernachlässigt Position des Managements zur Qualität in frühen Projektstadien potenzial aufzeigen mehr Budget einplanen Automatisierung Security Test pragmatische Ansätze/Guidelines zur Clusterung von Fehlern Praktische Beispiele, Unterscheidung nach Branchen Praktische Leitfäden, wie Risiken ermittelt werden und wie man sie pflegt und wie sie sich in das Testmanagement integrieren. Beispiele, wie Risikomanagement sich verbessernd in den Aufwand und die Anzahl von Restfehler im Projekt auswirkt. Praxisnahe Modelle, Metriken Praxistaugliche Schätzmodelle für Planungsaktivitäten Softwaretest im agilem Umfeld prinzipiell überall, aber am wichtigsten bei existenzbedrohenden Risiken Priorisierung des Testaufwandes Priorisierung von Testfällen Testmanagement in der agilen Entwicklung Standard-Risiken in der Entwicklung und im Systemtest Produktrisikoanalysen Teststrategie Kosten/Nutzen-Analysen Projektleiter Testmanager Projektübergreifendes QM QM in Dienstleistung, insbesondere bei Customizing von Standard-SW

142 126 QM: Ableitung konkreter Qualitätsziele (etwa nach SMART); Definition und Erhebung geeigneter Kennzahlen zur Zielerreichung; RM: Beratung: bessere Unterscheidung Produkt- vs. Projektrisiken; Abhängigkeiten zwischen Risiken erkennen und entsprechend agieren; Risikobewertung von Anforderungen: "Wer macht s?" (Fachkonzept), wie reagieren nachgelagerte Disziplinen (verstärkt Design- und Codereview, höhere Testintensität)... Qualität wichtiger als Termin Qualitäts- und Risikomanagement bei knappen Terminen und Ressourcen in dynamischen Umfeldern Qualitätssicherung in agilen Projekten Reaktionsmöglichkeiten bei Eintritt verschiedener Risikofälle Realitätsnaher Regulatorische Anforderung für medizinische Software (ISO 13485, ISO 14971) Requirement - Management interne Kommunikation Implementierung von Prozesse Einhaltung von Prozesse Requirements Engineering Restfehlerabschaetzung Richtwerte der Branche (Fehler/SLOC) und brauchbare Erfahrungswerte Risiko- und Qualitätsmanagement im agilen Umfeld (Scrum, BDD, MMFs) Risiko und Qualitätsmanagement der Praxis nahe und pragmatischer geschult werden. Zu sehr Theorie bezogen Risikoabschätzung, -management Erreichbare Qualität Risikobasiertes Testen Risikomanagement ist in meinem Projektumfeld so gut wie gar nicht oder nur schwach entwickelt. Obwohl sich das Bewusstsein für eine notwendige Qualitätssicherung gesteigert hat, gehört das Review der Anforderungsdokumentation bei AG in der Wahrnehmung noch immer nicht zur Qualitätssicherung einer Applikation. Hierbei passieren aber immer noch die meisten Fehler. Risikomanagement und Projekt - bzw. Unternehmenspolitik: "Was nicht sein darf, wird ignoriert." => Sensibilisierung notwendig, Veränderungen von Incentivierungen im Management beinhalten oftmals nicht vorsorgendes Risikomanagement => Ermittlung von Vergleichszahlen, öffentlich verfügbare DB und Studien zu Auswirkungen nicht beachteter Risiken. Risikomanagement praktisch nicht existent. In der QS fehlen grundsätzlich fachlich qualifiziertes Personal und Weiterbildungsmaßnahmen, Zertifizierungen etc. Es wird an allen Industriestandards vorbei gearbeitet. Risiko-orientierte Testgenerierung Risikomodellierung Restrisikobewertung in Abhaengigkeit von Testergebnissen Risikoorientiertes Testen - Tool Unterstützung - Durchsetzung im gesamten Entwicklungsprozess Risk based testing Risiko & QS muss integraler Bestandteil des PM sein.

143 127 RM: Abschätzung von Fehlerkosten und Auswirkung auf die Projektlaufzeit QM: vorbeugende Maßnahmen verstärken: Verbreitung von Design-Reviews und Modultests. ROI von Maßnahmen aufzeigen Schätzmetriken für Test in agilen Methoden Referenzarchitekturen für Testwerkzeuge über alle Bereich der QM (Anfo.Mgmt, Defects, Testfälle, Testdaten,...) Schulung, Wahrnehmung, Prüfung, Beratung Schulungen Security Testing: Testen der Umsetzung und Effizienz von Sicherheitsmaßnahmen sehr wichtig, Risikominimierung ist trotz Kostenreduzierung anzustreben, QS kostet Geld aber meist zu gering in der Projektdauer und den Projektkosten berücksichtigt und wird grob vernachlässigt ==> Zeitersparnis, Kostenreduktion Sensibilität für dieses Thema muss noch deutlich angehoben werden. Es fehlen praxisbezogene Standards zur Ermittlung und Darstellung der KPIs Software-FMEA ist zurzeit ein Begriff der gerne verwendet wird, aber keiner so recht weiß wie's am besten gemacht werden soll. Software-Komplexität drastisch reduzieren (back to the roots) QA-Zertifizierung der Fachspezialisten Objektmodellierung nicht als Ersatz der Realität betrachten! Speziell ist das Risikomanagement zu wenig ausgeprägt. "Kaffeesatz lesen" RM muss integrierter Bestandteil jeden Projektes werden (entweder als eigenständige Unit oder in QS integriert). Standardisierte Tools für das Risikomanagement, Bessere QS-Ausbildungen, bessere Verzahnung SWE und QS Standardisierter und optimierter Testprozess, Sourcing von Test-Services standardisiertes Vorgehen Standardisierung des Risikomanagements durch Definition von Regeln Standardisierung des Testprozesses, Erhöhung der Planbarkeit im Bereich Testing. Standardisierung, Vorgehensmodelle, Bewusstseinsschaffung Standards um die Vergleichbarkeit zu erhöhen stärkere Einbindung des Managements Stärkere Integration in laufende Entwicklungsprozesse Strukturierung der Testfälle Pro Fachverfahren haben wir bis zu ca Testfälle --> Überblick?? Testautomatisation im GUI-Bereich Testautomatisierung muss noch ausgebaut werden Testautomatisierung Testdatenmanagement Testdatenqualität, Automatisierung, Integration in Entwicklungsumgebungen Testing für agile Projekte und Testautomatisierung. Testmanagement ist noch immer nicht als vollwertiger Bestandteil der Softwareentwicklung anerkannt. Hier wäre Beratungsleistung zur Nutzenvermittlung sinnvoll.

144 128 Testmanagement: Zusammenhang zwischen durchgeführten Testfällen und tatsächlicher Qualität der Software Toolberatung/ Anforderungsmanagement Toolunterstützung Toolunterstützung; Best practise Kataloge, überall, es ist wenig Qualitätsbewusstsein vorhanden Übergreifendes Risikomanagement Aufwandsplanung und Monitoring Risikobasiertes Testen Um die Projektvorgaben von Budget und Zeit erfüllen zu können, wird bei Risiko- und Qualitätsmanagement zuerst eingespart. Automatisiertes Testen im Hintergrund würde Hilfe schaffen. umsetzbare Ideen in der Praxis Umsetzbarkeit von neuen Vorgehensmodellen im Test (MBT, TDD) Welche Testvorgehen passt zu welchem Projektvorgehen Umsetzung von Maßnahmen findet meist nicht statt, obwohl diverse Konzepte vorliegen Unterscheidung in technisches Qualitätssicherung(Management) als Teil des Testteams zur Wahrung der QA-Aufgaben/Rollen während der Entwicklung/Test Phasen und Qualitäts- Prozessmanagement als Management Aufgabe zur übergreifenden Kontroll- /Koordinierungsfunktionen unterstützende Tools Unwissenheit beim Top-Management und darunter liegenden Managementebenen. Verantwortliche konzentrieren sich zu stark auf Hardware-Qualitätsaspekte. Softwarequalität scheint selbstverständlich und nebensächlich zu sein. Einschätzung des Qualitätsbegriffs wird hauptsächlich aufgrund Kundenmeldungen definiert, weil eigene Maßstäbe fehlen. Es herrscht die Einstellung: wenn der Kunde nicht reklamiert, dann stimmt die Qualität. Verbesserte Beschreibung zur leichteren praktischen Umsetzung der theoretischen Prinzipien im konkreten Projekt. Verbesserung der Berechnungen und Metriken von Risiken zu monitären Auswirkungen vermehrt auf den Nutzen von Reviews hinweisen Inhalte des Qualitätssicherung stärker in den Fokus der Ausbildung stellen Vermittlung bekannter und praxiserprobter Methoden und Werkzeuge an alle Projektbeteiligten Vermittlung des Sinns von Qualitaetsmanagement verschärfte Milestone Kontrolle im Projektmanagement Transparentes Planungs- und Ressourcenmanagement Professionalisierung Testpersonen Verschlankung und Beschleunigung der Prozesse; Kosten-Nutzen-Analyse Verständnis der Entwickler für Tests fehlt Management sieht nur momentane Kosten, keine Kostensenkung durch Optimierung Verstehe die Frage nicht Verteilung der Aufwände auf verschiede Teststages Verzahnung Verifizierung und agile SW- Entwicklung ohne Zeitverluste, weil Anforderungen und Spezifikationen zur Testvorbereitung kurzfristiger zur Verfügung gestellt werden Vorgehensmodelle; best practices

145 129 Während Quereinsteiger mit anderen Erfahrungen in der Industrie meistens auch "quer denken", wird in der Informatik zu oft der "gute Fall" als Basis des Risikos und der QS- Maßnahmen verwendet. Das negative, destruktive Herangehen ist eine Vorgehensweise, die zum QM dazugehört damit Entwickler testen können. Anderenfalls wird "happy path- Testing" schon bei den Unit- und Integrationstests zum QM-Risiko. Was ist Qualität? Was ist Qualität für wen? Wer kann etwas an der Qualität ändern? Was ist Risikomanagement und brauche ich das überhaupt? Weiterentwicklung des Risikoorientierten Testens. Welches Vorgehensmodell ist für ein Unternehmen geeignet, das mit rund 40 Mitarbeitern auf klassische Weise aufgestellt ist (Trennung von Vertrieb, Produktmanagement, Marketing, 12 Entwickler, 2-3 Systemtester, 4 Support-Mitarbeiter, Client Management, Einkauf, HR etc.)? Es gelingt nicht, alle Rollen im W-Modell adäquat zu besetzen. Es gibt keine Ressourcen für gute Dokumentation, umfassende Reviews, Testplanung etc. Outsourcing von Regressionstests?? Wichtigkeit von Tests in frühen Phasen der SE Wie bringt man Projektleiter dazu, die geplanten Aufwände für das Testen nicht für andere Projektarbeiten umzuplanen bzw. zu verbrauchen. Wie findet man den richtigen Mittelweg zwischen sorgfältiger und guter Testplanung und flexiblem Reagieren auf geänderte Randbedingungen? Wie kann ich die Geschäftsleitung überzeugen über notwendige QS Maßnahmen? Wie sieht das Risikomanagement praktisch aus? Heute werden oft zu Projektbeginn Risiken erfasst, aber oft nicht weiter gemanagt und für die Steuerung im Projekt genutzt. Hier wären Beispiele und Schulungen und Metriken hilfreich. Wie nutze ich Risiken im Qualitätsmanagement wirklich? wird zu wenig berücksichtigt Wirtschaftlichkeit von werkzeugbasierten Tests in kleinen Unternehmen Zusammenführung mit TMAP Zusammenhang Scope- / Risk- /Qualitymgmt. Zusammenhang zwischen Qualität und langfristigen Kosten. z.b. die Frage ob ein kurzfristige Kostensenkung (bei niedriger Qualität) langfristig höhere Kosten verursacht Tabelle 4-82: Antworten zu Frage 6.4

146 Fragenkomplex 7 Testprozess Frage 7.1 Durchführung von Testaktivitäten Gibt es für die Durchführung der Testaktivitäten einen festgelegten Prozess? Tabelle 4-83: Durchführung von Testaktivitäten nach festgelegtem Prozess Abbildung 4-72: Durchführung von Testaktivitäten nach festgelegtem Prozess [Quelle: Henning12]

147 131 Abbildung 4-73: Testprozess in Abhängigkeit der Anzahl Mitarbeiter in der SE [Quelle: Henning12]

148 Frage 7.2 Audits (abhängige Frage 7.1) Wird der Testprozess einem Audit unterzogen? Tabelle 4-84: Audit, dem der Testprozess unterzogen wird

149 Frage 7.3 Systemumgebung Welche Systemumgebungen setzen Sie in Ihren Projekten für das Testen ein? Tabelle 4-85: Systemumgebung Produktivsystem Abbildung 4-74: Systemumgebung Produktivsystem

150 134 Tabelle 4-86: Systemumgebung gesondertes Testsystem Abbildung 4-75: Systemumgebung gesondertes Testsystem

151 135 Tabelle 4-87: Systemumgebung Entwicklungssystem Abbildung 4-76: Systemumgebung Entwicklungssystem

152 136 Tabelle 4-88: Systemumgebung Integrationssystem Abbildung 4-77: Systemumgebung Integrationssystem

153 137 Tabelle 4-89: Systemumgebung Pre-Life-System Abbildung 4-78: Systemumgebung Pre-Life-System

154 Frage Andere Systeme Abbildung 4-79: Wortwolke der Antworten zu Frage Andere Systeme: Continues Integration System Embedded System im Gerät es gibt leider noch keine vollständig unabhängiges Testsystem, die Datenbank ist gleichzeitig auch Live (ja, ist zum Gruseln) keine keines Lasttest-Umgebung lokale Test-/Entwicklersystem Mehrere Testsysteme für verschiedene Teststufen und -arten Mein Arbeitgeber meint, eine Testumgebung für Systemintegration, UAT und als Referenz reiche aus. Mitarbeiter aus KM betreuen primär die Testumgebung.

155 139 Nur bei ganz neuer Software kann das Produktivsystem vor golive zum Testen verwendet werden. Produktions Notfall Umgebung (gespiegeltes ProduktivSystem) Produktivsystem nur, soweit keine Datenmanipulationen betroffen sind Protoypensystem (Automotive Embedded) Simulation auf PC SUT temporäre Testsysteme, Cloud-Testsysteme Test System orientieren sich an der Systementwicklung (technisches System), d.h. reine SW Umgebungen, mixed Test Umgebung (SW mit teilweiser Hardware) und flugidentische Systemumgebung (SW wie für orginal Flugmodell, HW als sogenanntes "Engineering Model") Testsystem ist immer das System, das zur Auslieferung kommen wird. Training (Schulung) Verschieden Systemkonfigurationen die der reellen Umgebung am nächsten kommt. Was ist ein Pre-Live-System? Wichtige Schnittstellen können sehr gut simuliert werden, so dass nicht unbedingt immer in der Produktivumgebung getestet werden muss. Zielhardware mit der die Software ausgeliefert wird Tabelle 4-90: Antworten zu Frage 7.3.1

156 Frage 7.4 Administrator der Testumgebung Wer ist für Administration der Testumgebung zuständig? Tabelle 4-91: Zuständigkeit für die Administration der Testumgebung Abbildung 4-80: Zuständigkeit für die Administration Testumgebung [Quelle: Henning12]

157 Frage 7.5 Testvorbereitung Zur Testvorbereitung werden in Ihrem Unternehmen folgende Aktivitäten durchgeführt: Tabelle 4-92: Testvorbereitung Review/Analyse der Testbasis auf Testbarkeit Abbildung 4-81: Testvorbereitung Review/Analyse der Testbasis auf Testbarkeit

158 142 Tabelle 4-93: Testvorbereitung Testfallerstellung Abbildung 4-82: Testvorbereitung Testfallerstellung

159 143 Tabelle 4-94: Testvorbereitung Testdatendefinition Abbildung 4-83: Testvorbereitung Testdatendefinition

160 144 Tabelle 4-95: Testvorbereitung Testdatenerstellung Abbildung 4-84: Testvorbereitung Testdatenerstellung

161 Frage Weitere Aktivitäten der Testvorbereitung Abbildung 4-85: Wortwolke der Antworten zu Frage Weitere Aktivitäten in der Testvorbereitung: Abstimmung Teststrategie mit Kunde Aufbau spezieller Testdatenbanken mit eigenen Codepages Aufplanen der Testfälle Aufwands-/Ressourcenplanung der Testkapazitäten; Abstimmung mit externen Partnern, welche mit uns zusammen Testumgebungen zur Verfügung stellen. Beschaffen geeigneter zugelassener Prüfmittel Erstellung ggf. notwendiger Testtools Design der Testmethodik Dokumentation der Testdurchführung sowie Testauswertung durch Engineering (Rolle) Erstellen Testkonzept und Testplan

162 146 Erstellung unterschiedlicher, testfallspezifischer Konfigurationsdateien - wie Testdaten selten im Zuge der Testvorbereitung - meist im Zuge der Testdurchführung keine keine Konzeption von wiederverwendbaren Startzuständen; Einführung/Verwendung einer keyword-basierten Testfallnotation Planung Produktivdaten werden als Testdaten ins Testsystem kopiert Requirementextraktion und Zuordnung von Testfällen (Testcoverage) Review der Testspezifikation Risikobasiertes Vorgehen: Je nach Kritikalität Systematische Testfallermittlung, Testdatenerstellung, Automatisierung... Sehr viel exploratives Testen, daher erfolgt die Testvorbereitung entweder wirklich vorher oder aber während des testens statt (ergo teils/teils). Testfallerstellung meist als MindMaps (nachfolgende Frage, aber dort kein Feld verfügbar) Spezifikation mit Beispielen, kollaborative Erstellung von Test-Sessions Testdatenselektion Testkonzeption: Festlegung der Testarten, Testszenarien, Testplanung Testkonzeption: Festlegung Testarten, Testumfang, Testszenarien, grobe Testplanung Testmodellerstellung Testmodellerstellung/-pflege Testpriorisierung und Testplanung Testrelevante Schnittstellen in Architektur einbringen, Frühzeitig für automatische Testbarkeit sorgen (unit- & regressiontest) Testsystem wird i.d.r. mit Produktivdaten vorab versorgt. Testsystembeschaffung, Testiterationsplanung, Technische Vorbereitung der Testautomatisierung Testsystemplanung und -bereitstellung Erstellung Testhandbuch, Testkonzept, Nutzungskonzepte für Werkzeuge Testumgebungsdefinition und -vorbereitung Trennung von Testfall/Testdaten nur bedingt hilfreich Wir unterscheiden Testmodell, Testspezifikation und Testrealisierung - typischerweise immer als Kombination von Daten, Verhalten und Testkonfiguration Umgebungsbereitstellung Teststrategiefestlegung und Erstellung Testkonzept Verfügbarkeit der Testumgebung (nicht der Komponenten, sondern z.b. div. zusätzliche Konfiguration von Firewalls und anderer Infrastruktur) Vorbereitung Testmanagementwerkzeuge Tabelle 4-96: Antworten zu Frage 7.5.1

163 Frage 7.6 Beschreibung der Testfälle Die Testfälle werden Tabelle 4-97: Beschreibung Testfälle frei verbal / textuell Abbildung 4-86: Beschreibung Testfälle frei verbal / textuell

164 148 Tabelle 4-98: Beschreibung Testfälle mit standardisierten Formularen Abbildung 4-87: Beschreibung Testfälle mit standardisierten Formularen

165 149 Tabelle 4-99: Beschreibung Testfälle mit formal textueller Sprache Abbildung 4-88: Beschreibung Testfälle mit formal textueller Sprache

166 150 Tabelle 4-100: Beschreibung Testfälle mit graphischer Modellierungssprache Abbildung 4-89: Beschreibung Testfälle mit graphischer Modellierungssprache

167 151 Tabelle 4-101: Beschreibung Testfälle aus Modellen generiert Abbildung 4-90: Beschreibung Testfälle aus Modellen generiert

168 152 Tabelle 4-102: Beschreibung Testfälle während Testdurchführung Abbildung 4-91: Beschreibung Testfälle während Testdurchführung

169 153 Tabelle 4-103: Beschreibung Testfälle werkzeuggestützt erfasst und verwaltet Abbildung 4-92: Beschreibung Testfälle werkzeuggestützt erfasst und verwaltet

170 Frage 7.7 Personen, die Testfälle erstellen Testfälle werden in der Regel von folgenden Personen erstellt: Tabelle 4-104: Personen, die Testfälle erstellen Abbildung 4-93: Personen, die Testfälle erstellen

171 Frage 7.8 Unterscheidung zw. Testfall- und Testdatenerstellung Wird in Ihren Projekten zwischen der Testfallerstellung und der Erstellung der zugehörigen Testdaten explizit unterschieden? Tabelle 4-105: Explizite Unterscheidung zw. Testfall- und Testdatenerstellung Abbildung 4-94: Explizite Unterscheidung zw. Testfall- und Testdatenerstellung

172 Frage 7.9 Testdaten Die Testdaten Tabelle 4-106: Testdaten Ausführliche Dokumentation Abbildung 4-95: Testdaten Ausführliche Dokumentation

173 157 Tabelle 4-107: Testdaten Erfassung mit standardisierten Formularen Abbildung 4-96: Testdaten Erfassung mit standardisierten Formularen

174 158 Tabelle 4-108: Testdaten (Anonymisierte) Kopie der Produktionsdaten Abbildung 4-97: Testdaten (Anonymisierte) Kopie der Produktionsdaten

175 159 Tabelle 4-109: Testdaten Originalproduktionsdaten Abbildung 4-98: Testdaten Originalproduktionsdaten

176 160 Tabelle 4-110: Testdaten Zusammenfassung in einer Testdatenbibliothek Abbildung 4-99: Testdaten Zusammenfassung in einer Testdatenbibliothek

177 Frage 7.10 Erwartete Testergebnisse Die erwarteten Ergebnisse der Tests Tabelle 4-111: erwartete Ergebnisse Festlegung vor Testdurchführung Abbildung 4-100: erwartete Ergebnisse Festlegung vor Testdurchführung

178 162 Tabelle 4-112: erwartete Ergebnisse Manueller Vergleich Abbildung 4-101: erwartete Ergebnisse Manueller Vergleich

179 163 Tabelle 4-113: erwartete Ergebnisse Automatischer Vergleich Abbildung 4-102: erwartete Ergebnisse Automatischer Vergleich

180 164 Tabelle 4-114: erwartete Ergebnisse Verfügbar für spätere Tests Abbildung 4-103: erwartete Ergebnisse Verfügbar für spätere Tests

181 Frage 7.11 Effektivität der Testfälle Wie schätzen Sie die Effektivität Ihrer Testfälle ein? Tabelle 4-115: Effektivität der Testfälle Abbildung 4-104: Effektivität der Testfälle Abbildung 4-105: Effektivität der Testfälle bei Prozesstrennung [Quelle: Henning12]

182 Frage 7.12 Fehler nach der Auslieferung Nach Auslieferung treten Tabelle 4-116: Fehler nach Auslieferung Abbildung 4-106: Fehler nach Auslieferung Abbildung 4-107: Fehler nach Auslieferung bei Prozesstrennung [Quelle: Henning12]

183 Frage 7.13 Kennzahlen zur Bewertung des Test-Endes Folgende Kennzahlen / Metriken werden zur Teststeuerung und zur Bewertung des Test-Endes eingesetzt: Tabelle 4-117: Kennzahlen zur Bewertung des Testendes Abbildung 4-108: Kennzahlen zur Bewertung des Testendes

184 Frage 7.14 Testendkriterien Zur Beendigung der Tests werden folgende Kriterien verwendet: Tabelle 4-118: Testendkriterien Alle Testfälle sind auszuführen Abbildung 4-109: Testendkriterien Alle Testfälle sind auszuführen

185 169 Tabelle 4-119: Testendkriterien Anforderung mindestens einmal getestet Abbildung 4-110: Testendkriterien Anforderung mindestens einmal getestet

186 170 Tabelle 4-120: Testendkriterien Vorgesehenes Testbudget ausgeschöpft Abbildung 4-111: Testendkriterien Vorgesehenes Testbudget ausgeschöpft

187 171 Tabelle 4-121: Testendkriterien Auslieferungszeitpunkt erreicht Abbildung 4-112: Testendkriterien Auslieferungszeitpunkt erreicht

188 172 Tabelle 4-122: Testendkriterien Für Vertrauen genug Fehler gefunden Abbildung 4-113: Testendkriterien Für Vertrauen genug Fehler gefunden

189 173 Tabelle 4-123: Testendkriterien Geforderte Werte der Kennzahlen erreicht Abbildung 4-114: Testendkriterien Geforderte Werte der Kennzahlen erreicht

190 Frage 7.15 Einhaltung der Testendkriterien Werden die geplanten Testendkriterien eingehalten? Tabelle 4-124: Einhaltung der Testendkriterien Abbildung 4-115: Einhaltung der Testendkriterien

191 Frage 7.16 Bedarf für den Testprozess Abbildung 4-116: Wortwolke der Antworten zu Frage 7.16 Wo sehen Sie Bedarf in Forschung, Entwicklung und Beratung für Ihren Testprozess? (Stichworte reichen aus) "Systematischer agiler" Test Ableitung von negativen Testfällen über Komponenten hinweg Akzeptanz bei Projektleitung und Auftraggeber muss wachsen. anpassung der bestehenden testprozesse (bspw. istqb) an agile methoden (scrum) Anpassung des Testumfangs in Abhängigkeit von den Change Requests, die für das Release implementiert wurden. Anwendung von Testmetriken

192 176 Auomatisierung von Testfällen Messbarkeit von Testprozessen Ausbildung von Testern(!), einheitlicher Testprozess, gemeinsames Vorgehen aller Abteilungen/Systeme Automation der Test ist immer noch ein Problem. Gerade im Zusammenspiel von mehreren Systemen. Automatisierung ALM Automatisierung Metriken und Steuierungswirkung Tests in frühen Phasen Automatisierung, Auswertung Beratung: Mittel-Management Bessere Abstimmung der einzelnen Testphasen, keine zentrale Testabteilung vorhanden bessere Übergabekriterien Bessere Verknüpfung zwischen model based development und model based testing bzgl. Testverbesserungsmethoden Der offiziell definierte Testprozess ist so detailliert und spezifisch, dass er de facto unbrauchbar ist, da nicht praxistauglich. Das zu testende System ist über 30 Jahre gewachsen und nicht dokumentiert - somit eigentlich nicht testbar. Der Testprozess muss stärker als Teil der Vorgabenerstellung und Entwicklung wahrgenommen werden. Derzeit wird er eher als Belästigung wahrgenommen. Der Testprozess richtet sich nach der Branche des Kunden, doch im grundsätzlichen Wesen richtet sich dieser nach ISTQB, nur mit der branchenspezifischen Nomenklatur. Die interne Abteilung entwickelt hier an den Prozessen. Die planerische Komponente im Testprozess wird zu selten eingerechnet. Es wird meistens nur die Zeit der Durchführung gerechnet. Die verstaubten Prozessvorgaben, wie z.b. der von ISTQB, an die reale heutige Zeit anpassen, wo es iterativ, agil, cloudy,... zugeht Effektivitätssteigerung Testentwicklung, Intergration des Testprozesses in den gesamt Prozess Effizienzsteigerung, Priorisierung, Risikominimierung Einfachere, vielleicht automatisierte Lösung zur Erstellung von Testfällen. Empirische Softwaretechnologie (z.b. Effektivität von Tests abhängig von der Testfall- Design-Methode) Entwicklung von neuen, flexiblen, breit gefächerten (Unterstützung von verschiedenen Softwareplattformen/Programmiersprachen) automatischen Testtools Entwicklung zum Thema Cloud-Testing Entwicklung einheitliches konsistentes Schulungsmaterial für die versch. Rollen Detaillierung der Aufgaben inkl. Verantwortung zw. Testmanager und Projektleiter Skillanforderungen der jew. Rollen Erhöhung Abdeckung oder Redundanz zwischen Testphasen, Wiederverwendung? Erhöhung des Vertrauens in die eigenen Testergebnisse Erhöhung des Formalisierungsgrades Erhöhung des Automatisierungsgrades Verbesserung der Zusammenarbeit Tester / Entwickler Verbesserung der Testbarkeit der Software durch entsprechendes Design

193 177 fast überall. Testprozessverbesserungen wie z.b. TPI würden fast überall signifikante Verbesserungen einbringen. fehlende Realitätsnähe Formalisierung, Zentralisierung, Standardisierung, Schulung der Tester Forschung, Entwicklung und Beratung Forschung/Beratung: frühzeitiges, verfahrensübergreifendes Testdatenmanagement; Tools zur zentralen Generierung und Verwaltung der Testdaten in einer von verschiedenen Projekten genutzten Testumgebung; Rücksetzen von Testdatensätzen / Zeitreisen -> Anforderungen an Implementierung/Deployment geeigneter Umfang Sensibilisierung von Mitarbeitern und Kunden für die Notwendigkeit Generell: Abschied vom Formalismus. Speziell in der agilen SW-Entwicklung ist eine Unterscheidung in Teststufen nicht mehr zeitgemäß da quasi alle Teststufen parallel stattfinden können. Eine Testplanung mit den Agile Testing Quadrants von Brian Marick ist deutlich effizienter im Agilen Testen. Testdesign und Testtechniken sind notwendig, aber nicht dafür um die höchstmögliches Test-Coverage zu erhalten (dafür ist in kaum einem Projekt Zeit), sondern dafür den Testern die notwendigen F gleitender Übergang aus den Requirement- und Entwicklungsprozess Offshore-Testen Hinweise für die Wahl der richtigen Teststrategie: exploratives, strukturiertes Testen manuelle, automatische Regressionstests in der Abstufung Smoketests, Einschalt- und Fachtests ich weiß nicht in allen 3 Bereichen Integration des Testprozesses in agile Softwareentwicklungsprozesse wie z.b. SCRUM. just do it kein Bedarf, wir optimieren unsere Prozesse innerhalb des Teams (ggf. mit externer Moderation) keine explizite Aussage keinen Bedarf Kennzahlen, stochastische Methoden Testabdeckung Kommunikation Kommunikation der beteiligten Mitarbeiter untereinander. Kommunikation Tester - Kunde konsequente, frühzeitige und dokumentiert Requirementklärung, genügend Test- Ressourcen lebbare, schlanke Prozesse die skalierbar sind - je nach Branche und Kritikalität des Projektes Medizintechnik Mehr automatisierte Tests mehr Flexibilität im Testprozess bei Erreichen der Budgetgrenzen mehr Systemtests, Massentests mehr Zeit und Budget Metriken Metriken Metriken sind doch nur bei automatischen Tests sinnvoll, oder? Metriken verstärkt einsetzen Standard Testfallkatalog für Regressionstest

194 178 Metriken zur Testfallidentifikation Generierung von automatisierten Tests model based testing Optimieren der Prozessschritte, Verbesserung durch Etablieren Agiles Vorgehen Optimierung, Zeitersparnis Outsourcing von Regressionstests Planung muss verbesserte werden, Change Request nach viel zu lange umgesetzt, Testphase wird nur nach Termine, aber nicht nach Inhalten durchgeführt Planung, Werkzeuge Praxisbezug; Beherrschung von Komplexität Produkt- und Teamübergreifende Standards definieren Projektmarketing, Qualitätsverständnis, Testauswertung Prozess fehlt zum Test Risikobasierte Testentwurfsmethoden Risikoeinschätzung, Auswirkung Fehler auf gesamten Projekterfolg s. vorne: Testautomatisierung muss noch ausgebaut werden Schulung der Tester, sinnvolle, aber zeitlich vorgelagerte Briefings finden oftmals aufgrund knapper Ressoucen (Zeit, Personen, etc.) nicht ausreichend statt sehr hoch und wir versuchen gerade ein neues Testszenario aufzubauen ==> Proof of concept Software müsste früher fertig sein. Eine parallele Bugfix-Phase ist immer schwer zu handeln. Stärkere Formalisierung des Testprozess; QS-Vorgaben für die Durchführung von UNIT Tests Stärkere Testautomatisierung, insbesondere für Embedded Software Strukturierter Testprozess, geplante Vorgehensweise beim Testdesign Test von PL/SQL Anwendungen Testabdeckung Testanfangs- und Endekriterien werden zwar definiert aber aus 'Zeitmangel' nicht eingehalten. Testdatenbeschaffung und Handling Testen wird völlig unterschätzt und für unwichtig befunden Testerausbildung, Testautomatisierungsprüfung, Abdeckung von Kundenerwartungen durch Tests Testing of non-functional requirements, Focus on testabilty in design phase Developer involvement in testing Testkonfigurationsmanagement, Automatisierung Testmetriken Testmetriken, Testbewertung (Erfolg), Testautomatisierung Testprozessautomatisierung Tests müssen früher beginnen, Einbeziehung des Kunden frühzeitig notwendig, Verständnis für Tests auf der Kundenseite notwendig Theorie und Anwendung in der Praxis sind auch heute noch sehr divergent. Transparenz muss immer gewährleistet sein. Überall

195 179 Umsetzung eines einheitlichen und akzeptierten Testvorgehens, das methodisch auf den Entwicklungs- und Integrationsprozess abgestimmt ist. Konzepte dafür liegen vor, nur die Umsetzung findet nicht statt. Ursache dafür sind fehlende Ressourcen und fehlende Zeit, um diesen Change umzusetzen, da parallel die Projekte weiter laufen müssen. Unabhängigkeit des Testprozesses von der Softwareentwicklung Untere Teststufen Unterstützung von Testen und Prüfen durch die Werkzeuge. Kombination in einem Werkzeug meist nur durch Umgehungslösungen möglich. Verbindung der Werkzeuge mit den Entwicklungswerkzeugen oft nur rudimentär, insbesondere bei schnellen Entwicklungszyklen) Konfigurationsmanagement ist oft nur Werkzeugverwaltung. Kombination von KM, TM, Entwicklung, Release Management nur schwach unterstützt (bei Werkzeugen und Modellen). Verbesserung des Vertrauens in die eigenen Testergebnisse Erhöhung der Testeffizienz durch Definition der "richtigen" Testfälle zur Aufdeckung von Fehlerwirkungen Vereinigung mit Entwicklungsprozess begleitendes Testen (Bereitstellung der Anwendung etc.) Vereinheitlichung / Transitionen der Modelle Hilfen zu Testprozessoptimierung Reifegradbestimmung des Prozesses und Teams Verwendung und Erweiterung des Prozesses, damit dieser für jede Software des Unternehmens umgesetzt werden kann, bzw. Erweiterung da viel "Systems of Systems" Tests notwendig sind. Verwendung von Metriken bisher unzureichend (keine Zeit, sich konzeptuell damit auseinanderzusetzen); Risiko-basiertes Vorgehen entsprechend der tatsächlichen Nutzung des Softwareprodukts noch nicht gegeben (Statistiken fehlen) Was kann uns noch helfen? Weiterbildung im Testbereich Weitergehende Automatisierung der Testgenerierung und Testausführung Bessere Unterstützung von GUI-Tests, auch in Kombination mit technischen Tests Werkzeugunterstützung für Tests in kleinen Projekten Werkzeugunterstützung, Testautomatisierung, Transparente Tests, Nachvollziehbarkeit, BugTracker Wie integriere ich den Testprozess und seine Aktivitäten enger in die Entwicklung, wie weise ich nach, dass Maßnahmen eine Verbesserung bringen, wenn vorher keine Referenz gemessen wurde. Wie wirken sich die Güte der ReqEng und die der Reviews/Inspektionen auf die Fehlerfolgekosten aus? Wiederherstellung des entlassenen QA-Teams Wiederverwendbarkeit von Tests Wir verwenden seit ca. 13 Jahren Test-Tools (QARun, Testpartner). Verbesserung der Performance, die Laufzeiten von bia zu Testfällen sind zu lange. Allerdings habe ich keinen Überblick über den aktuellen Tool-Markt. zentralisieren, standardisieren, aufsetzten Voraussetzung: Einsichtigkeit der Unternehmensleitung und Budgetmittel Zugängigkeit aller betreffenden Personen zu aktuellen Spezifikationen Zugänglichkeit und ausreichend genaue Spezifikationen für alle den Test betreffenden Funktionen. Tabelle 4-125: Antworten zu Frage 7.16

196 Fragenkomplex 8 Testverfahren Frage 8.1 Verfahren für den statischen Test (abhängige Frage 4.1) Welche Verfahren für den statischen Test werden in Ihrem Unternehmen eingesetzt? Tabelle 4-126: Verfahren für den statischen Test Abbildung 4-117: Verfahren für den statischen Test

197 Frage 8.2 Verfahren für werkzeuggestützte Analysen Welche Verfahren der werkzeuggestützten statischen Analyse werden in Ihrem Unternehmen eingesetzt? Tabelle 4-127: Verfahren für werkzeuggestützte Analysen Abbildung 4-118: Verfahren für werkzeuggestützte Analysen

198 Frage 8.3 Verfahren für den dynamischen Test Welche Verfahren für den dynamischen Test werden in Ihrem Unternehmen eingesetzt? Tabelle 4-128: Verfahren für den dynamischen Test

199 Frage 8.4 Black-Box Verfahren Welche spezifikationsorientierten Testverfahren werden im Unternehmen eingesetzt? Tabelle 4-129: Black-Box Testverfahren Abbildung 4-119: Black-Box Testverfahren

200 Frage 8.5 White-Box Verfahren Welche strukturorientierten Testverfahren werden im Unternehmen eingesetzt? Tabelle 4-130: White-Box Testverfahren Abbildung 4-120: White-Box Testverfahren

201 Frage 8.6 Erfahrungsbasierte Verfahren Welche erfahrungsbasierten Verfahren werden in Ihrem Unternehmen eingesetzt? Tabelle 4-131: Erfahrungsbasierte Testverfahren Abbildung 4-121: Erfahrungsbasierte Testverfahren

202 Frage 8.7 Bedarf bei statischen und dynamischen Verfahren Abbildung 4-122: Wortwolke der Antworten zu Frage 8.7 Wo sehen Sie Bedarf in Forschung, Entwicklung oder Beratung von Statischen und Dynamischen Testverfahren? (Stichworte reichen aus) Abstimmung der Testaktivitäten in den verschiedenen Teststufen Akzeptanz muss bei den SW entwicklern geschaffen werden. Insofern sollte das Wissen in der Ausbildung intensiver vermittelt werden. Anwendung von Codemetriken, Durchführung von explorativen Testverfahren Aufgrund fehlender Spezifikation ist ein Testverfahren mehr oder weniger nur durch Erfahrung und Zufall überlassen. Aufwandreduzierung und leichtere Zugängigkeit/Verständnis für die Verfahren Ausbildung; Bereitschaft zur Umsetzung, meist vom TOP Management nicht getragen Beherrschung von Komplexität, Übersicht behalten

203 187 Beidem Beratung: Mittel-Management Beratung: Entwicklung-Management bessere Codeabdeckung mehr Fehlerangriffstests Black-Box "Random/Fuzz" Testing fuer Integration, Sicherheit, etc. Brauchbare und bezahlbare Tools zur Testfallgenerierung (White-Box) aus Modellen (nicht nur UML) und (C-)Code da sind wir noch ganz am Anfang und benötigen sicherlich noch Schulungen etc. das ganz große GAP zwischen theoretischen Methoden und praktisch im alltag umsetzbaren Dingen zu schließen den gap zwischen Forschung und Toolherstellen schließen Die Kunden setzen die Testverfahren intuitiv ein, sodass eine spezielle Beratung sich durch Aufzeigen des Übertragens deren Einsatzes von der Theorie in die Praxis als Aha-Effekt genutzt werden kann. Die Tools sollten sich zu einem Dashboard zusammengefasst werden, um ganzheitliche Aussagen zu bekommen. Daraus sollten dann erfahrungs-/domänenbasiert Testende Kriterien ableiten lassen. diese Fragen gingen irgendwie an unserer Praxis vorbei. Ich habe nur die Hälfte dessen verstanden, was hier gefragt wurde. Durchführung statischer Testverfahren Effektivität von verschiedenen Testverfahren Effizienz und bestmögliches Mischungsverhältnis (je Situation) Einführung der Verfahren in den SW-Lebenszyklus. Entwicklung und Beratung Exploratives Testen formalisieren (Abdeckung, Reporting) Exploratives Testen Kombination von Testverfahren Flächendeckender Einsatz ich weiß nicht in allen 3 Bereichen Isolating the test target from its dependencies with minimum effort for test purposes. Patterns for building observability and control into software for testability. Kann man einen Zusammenhang zwischen Codeabdeckung und Anforderungsabdeckung herstellen? keine explizite Aussage Klassenbaumanalyse Codemetriken Kombination zwischen Testbasisüberdeckung und Fehlerabdeckung als Grundlage für eine Testdesignmethode Medizintechnik mehr automatisierte Tests durchführen; Last- und Performancetests werden zu selten durchgeführt; Fehlerinjektion wird gar nicht bei uns beachtet; White Box Tests sind bis auf Unit Tests weitgehend unbekannt mehr White Box tests Methoden zur Testabdeckung, systematische Testfallermittlung Methodensicherheit in der Anwendung QS-Vorgaben für freies Testen s. vorne

204 188 siehe oben Sinnvolle Testendekriterien Spickzettel für Testideen beim Explorativen Testen Stat. Testverfahren: kein Bedarf Dyn. Testverfahren: Akzeptanz hierfür vertiefen Statische Code Analysen für PL/SQL-Code - sind scheinbar weltweit nicht vorhanden weder OpenSource noch commercial. Statische Testverfahren sollten etabliert werden - das System ist Kraut und Rüben, da es keine Standards gibt. statischer test: Test der Wartbarkeit, Einhaltung von Softwarearchitekturkonventionen (Dependencies in C) Testfallermittlung aus unvollständiger Doku Ermittlung der "richtigen" Testfälle, um Fehlerwirkungen effizient aufzudecken Testverfahren sollten mehr bewusster angewendet werden Tooleinsatz, genaue Dokumentation, einheitliche Vorgehensweise Verbreitungstiefe ist noch nicht gegeben Wartung von Systemintegrationstests unter weiterentwickelten externen Schnittstellen, Aufarbeitung des ganzen prozeduralen Testzirkus' (Zweigüberdeckung etc.) für die OO- Welt, Testverfahren für SOA-Architekturen (Test-Interzeptoren, Testadapter, Monitoringtests) Werkzeugunterstützung Wirtschaftlichkeitsbetrachtungen, E-Learning Tabelle 4-132: Antworten zu Frage 8.7

205 Fragenkomplex 9 Testwerkzeuge Frage 9.1 Einsatz von Testwerkzeugen Werden in Ihrem Unternehmen Testwerkzeuge eingesetzt? Tabelle 4-133: Einsatz von Testwerkzeugen Abbildung 4-123: Einsatz von Testwerkzeugen

206 Frage Testwerkzeuge in Planung (abhängige Frage 9.1) Planen Sie, in Ihrem Unternehmen demnächst Testwerkzeuge einzusetzen? Tabelle 4-134: Einsatz von Testwerkzeugen in Planung Abbildung 4-124: Einsatz von Testwerkzeugen in Planung

207 Frage Jährlicher Aufwand für Testwerkzeuge (abhängige Frage 9.1) Wie hoch ist der jährliche Aufwand für Testwerkzeuge (Anschaffung und Wartung) in Ihrem Unternehmen? Jährlicher Aufwand für Testwerzeuge (EUR/CHF)

208 Frage Grad der Automatisierung Wie hoch ist der Grad der Automatisierung in den verschiedenen Teststufen im Vergleich zu manuellen Tests? Tabelle 4-135: Grad der Automatisierung Unittest Abbildung 4-125: Grad der Automatisierung Unittest

209 193 Tabelle 4-136: Grad der Automatisierung Integrationstest Abbildung 4-126: Grad der Automatisierung Integrationstest

210 194 Tabelle 4-137: Grad der Automatisierung Systemtest Abbildung 4-127: Grad der Automatisierung Systemtest

211 195 Tabelle 4-138: Grad der Automatisierung Abnahmetest Abbildung 4-128: Grad der Automatisierung Abnahmetest

212 Frage Testaktivitäten für den Einsatz von Testwerkzeug (Abhängige Frage 9.1) Bei welchen Testaktivitäten setzen Sie Testwerkzeuge ein? Tabelle 4-139: Testaktivitäten für den Einsatz von Werkzeug Abbildung 4-129: Testaktivitäten für den Einsatz von Werkzeug

213 Frage Eingesetzte Kategorien von Testwerkzeugen Welche Arten/Kategorien von Testwerkzeugen werden in Ihrem Unternehmen eingesetzt? Tabelle 4-140: Einsatz von Testwerkzeugen

214 Abbildung 4-130: Einsatz von Testwerkzeugen 198

215 Frage Weitere Arten / Kategorien von Werkzeugen Abbildung 4-131: Wortwolke der Antworten zu Frage Weitere Arten/Kategorien von Werkzeugen: Aufnahmetools für Session-basierte Testmanagement (Screen-Recorder) Automatisierte Oberflächen Tests Bugtracking-Werkzeuge, proprietäre Frameworks Coded UI Tests Continous Integration Server defect tracking, configuration management eigene SW-Testsysteme Excel, Word, Powerpoint Fehlermanagement GUI-Tester

216 200 HIL (Hardware in Loop) In manchen Projekten wird ein Tool zum Anfertigen von Screenshots genehmigt. In anderen nicht, da die 60 Euro/Lizenz als zu teuer angesehen werden. Junit keine keine keine explizite Aussage mock-frameworks Modellbasierte Testwerkzeuge Scripte und Batches Sicherheitstestwerkzeuge simulation von realer anlage Speedtest (Maschinenindustrie, Automation) Testausführung nur als Capture/Replay zu definieren, passt nicht zum Stand der Technik Komparatoren beziehen sich nicht nur auf Daten - auch auf Verhaltensabläufe Mutationstests bewerten eher die Stärke einer Test Suite/einer Testgenerierungsmethode - werden weniger/nicht fuer das eigentliche Testen von Systemen genutzt?! Testausführungswerkzeuge (nicht Capture/Replay) Testausführungswerkzeuge, welche nicht auf Capture & Replay beruhen Testautomationswerkzeuge 3. Generation (Business Dynamische Steuerung) Testautomatisierung UnitTests Unittest-Tools Unittest-Werkzeuge Werkzeug der 4.ten Generation Namens TOSCA Tabelle 4-141: Antworten zu Frage 9.1.6

217 Frage Konkreter Einsatz welcher Testwerkzeuge Abbildung 4-132: Wortwolke der Antworten zu Frage Welche konkreten Testwerkzeuge setzen Sie in Ihrem Unternehmen ein? (Werkzeugname, ggf. Hersteller) alles, was es von HP so gibt Apache JMeter, Cobertura, Sonar, FindBugs, PMD, Eclipse, Selenium BB Test Assistant, ishowu HD, Rapid Reporter, FitNesse, Robot Framework, cucumber, cobertura, FindBugs, PMD, CPD, JUnit, JDepend Berner&Mattner's CTE XL (Classification Tree test case design) Testplant's Eggplant bullseye, hudson,eclipse,visual studio,eigenentwicklung Chipkartensimulator Host-Simulation (Eigenentwicklung) andere Eigenentwicklungen

218 202 Cobertura, ECL Emma Code Coverity, Rational Funktional Tester, Serena TeamTrack, Nunit, Imbus Testbench Coverity cppunit CTE XL die gesamte HP Suite. JUNIT diverse Eigenentwicklungen für Unit-, Integrations- und Systemtests Doors Excel ClearQuest, Mantis, Serena Dimensions RT-Tester, Vectorcast, LDRA, Cantata gdb, ddd eclipse Matlab (SIMULINK) DUnit, TestComplete, AQTime (AutomatedQA) Dynamic Testflow Quality Center Functional Tester eclemma, Sotograph Eigenbau Eigene Entwicklung basierend auf Teststandards von ITU, ETSI, OMG, IEEE eigene Tools, QAC, QAC++, PC-Lint, TestLink, Polyspace, Rational Test Realtime,... Eigenentwicklung Eigenentwicklung Eigenentwicklung.NET Eigenentwicklung unter Nutzung von Standard-SW (MS) HPQC Eigenentwicklungen eigenes Testframework, Rational Functional Tester - IBM, Optim - IBM Selenium -?, Selenium IDE -? Add on Firefox, Dashbord - CAST Emma, Junit, TestNg, SeamTest, EJB3.1 Testing Framework, Jenkins, Ant, Maven, Checkstyle, PMD, Findbugs Excel, TOAD, JUnit, Selenium expect FindBugs, JUnit, Cobertura, QFTest FindBugs, PMD, CheckStyle, Vera++, cppcheck, Diverse eigene batch Scripte basierend auf awk, grep, sed FitNesse, JMeter, soapui, Bugzilla, SpiraTeam, Robotask, Eigenentwicklungen Fitnesse, Selenium, JMeter u.a. FitNesse; JMeter; SpiraTeam GUIdancer GuiDancer (OberflächenTest, RegressionTest über die Oberfläche) hauptsächlich HP QC

219 203 hauptsächlich selbst entwickelte tools, Zabbix HP - QC/QT HP ALM HP Service Center HP Mercury HP Produkte, TOSCA, open Source, HP QC und QTP HP QC IBM Clearquest ProxySniffer eigene Frameworks HP QC QTP Loadrunner HP QC, Bredex GUIDancer HP QC, HP QTP, TMS, OTM, SAP SolMan, SAP ecatt HP QC, HP Quicktest, Silkperformer, JUnit, Beyond Compare, Visual Studio 2010 HP QC, SoapUI, Selenium HP QC, Team Foundation Server HP QTP Professional JMeter TestLink + Jenkins HP Quality Center HP Quality Center HP Quality Center hp Quality Center / Quick Test Professional HP Quality Center + Quick Test Professional Team Foundation Server + MS Test Manager Silkperformer Winrunner hp Quality Center 10 HP Quality Center HP Loadrunner HP Quicktest HP Quality Center HP Loadrunner HP Winrunner HP Quality Center HP QTP IBM RFT HP Loadrunner HP Quality Center HP Quick Test Pro Dynatrace Loadrunner

220 204 HP Quality Center HP QuickTest Pro JUnit eigenerstellte Tools HP Quality Center Load Runner Quickrun etc die gesammte Palette von HP Jira HP Service Center HP Quality Center Quick Test Pro Performancetester Funktional Tester Clear Quest Clear Case HP Quality Center Silk Test HP Quality Center TestDB (Individualsoftware auf Access) HP Loadrunner (für RTE) HP Quicktest Professional (Grad Testautomatisierung < 2%) Java-Klassen auf JUnist-Basis für Lasttests (für EJB) HP Quality Center WinRunner / Quicktest Loadrunner HP Quality Center, Coderunner, Microsoft TFS HP Quality Center, eigene Werkzeuge HP Quality Center, FIT, JFCUnit, eigenes GUI TestAutomatisierungsframework, Checkstyle, Findbugs, NCSS, Emma, JUnit HP Quality Center, HP QTP HP Quality Center, HP Quick Test, Abott, Jira HP Quality Center, HP Quicktest Professional, Ranorex HP Quality Center, HP Quicktest Professional, Selenium, JMeter HP Quality Center, imbus Testbench, tedeso, JUnit, NUnit,Clearquest, Bugzilla, Jira, Doors, Caliber, Enterprise Architect, GForge, Testlink, Team Foundation Server HP Quality Center, JIRA (Test- und Problemmanagement); JUint, JMeter (Unit-Test, Modul-Integartion) HP Quality Center, MS Test Manager HP Quality Center, Quick-Test, Load Runner HP Quality Center, Rational Functional Tester HP Quality Center, Silk test, Jira HP Quality Center, Verschiedene Entwicklungsumgebungen, selbst erstellte Werkzeuge HP Quality Center; HP Quick Test Pro; HP Load Runner. HP QualityCenter HP Qucktest Pro HP PerformanceCenter / LoadRunner hp QualityCenter hp Quick Test Pro HP QualityCenter, Defect Tracking Tool

221 205 HP Qualitycenter, HP Quicktest HP Test Center (Mercury),... HP Toolsuite IBM Rational Suite JMeter Freeware-Testmanagement Tools HP, TRICENTIS, Microsoft HPQC HP-QC hp-qc,... HPQC, CTE-XL HPQC, JIRA, Selenium, HP QTP, Loadrunner,... HP-Qualitycenter, JUnit, generell Unit-Tests aus den verschiedenen IDE's HQPC, SideWalker Hudson, FindBugs, EMMA, QF-Test Hudson, FindBugs, Eclipse IBM Rational Functional Tester / ClearQuest SoapUI FitNesse JUnit IBM Rational Test Tools imbus testbench imbus testbench Imbus Testbench Tivoli Internal tools for test management, simulation, GUI test automation MS Visual Studio for debugging Speedtrace and DotTrace for performance measurement in.net NCover for code coverage in.net Scitech Memory Profiler for memory leak analysis in.net AQTime for code coverage and performance/memory profiling in C/C++ Microsoft debugging tools in general (Windbg, umdh, etc) TT Workbench for communication protocol tests nunit for unit test in.net BOOST.Test for unit test in C/C++ Omicron f JIRA, Confluence, Selenium, eigenentwickelter Testdatengenerator, JMeter Jira, Testopia, Selenium, JUnit, Grinder, YourKit, selbst erstellte Ant- u. Python script und Java-Programme Jira, TRAC, Mantis, Testlink JMeter junit JUnit EasyMock Google Mock

222 206 Matlab/Simulink Findbugs JUnit Hudson JUnit(85%) Hudson(65%) Sonar(65%) Junit, BDD JUnit, Canoo Webtest, Ant, Cruisecontrol, FindBugs, Eclipse IDE, Mockito, HP QualityCenter JUnit, Clover, Selenium, Sonar JUnit, CppUnit JUnit, EasyMock, Technomatrix Plant-Simulator JUnit, EclEmma, Jira, JUnit, EMMA, FindBugs, PMD, Eclipse-Code-Formatting JUnit, Fitnesse, Cucumber, HttpUnit, NUnit, StoryTeller JUnit, Maven, Hudson, Cobertura JUnit, Mockito, Hamcrest, Emma, Clover u.a. JUnit, PHPUnit, Jenkins JUnit, Selenium JUnit, Selenium, FiT Junit, Selenium, Jira, Tosca JUnit, Sonar, JMeter, SoapUI JUNIT, TestDirector (Quality Center) k.a. keine explizite Aussage Klocwork, Selenium, CTE XL, gdb, gcov, winmerge Labview LINT, Purify, TestCocoon, SourceMonitor Mantis Bugtracker Testlink fitnesse Hp quality center Mathworks Polyspace, Parasoft C++test, CTE, Lint Messina, Modena, ProveTech:TA (MBtech), CANoe (Vector) Messina, Modena, uvm. Provetech-TA, CANoe,... MicroFocus Silk Central Test Manager Klocwork K7 Nessus Wurldtech ACHILLES IXIA MicroFocus Testpartner; HP Quality Center; Stressor Microsoft Visual Studio (Testautomatisierung), Team Foundation Server (Testmanagement: Testfallspezifikation, Fehlermanagement) Diverse Tools zur Durchführung und Dokumentation von Tests im Web-Bereich, z.b. Firefox-Plugins (imacros, YSlow...), RoboForm, Charles Web Debugging Proxy, Net Limiter, FastStone Capture, SoapUI u.v.a.m

223 207 Microsoft Visual Studio, Team Foundation Server (Testmanagement, Testautomatisierung, Fehlermanagement) Diverse Tools zur Testausführung im Web-Bereich: Firefox-Plugins (yslow, imacros), RoboForm, Charles Web Debugging Proxy, NetLimiter, automatische Link-Checker u.v.a.m. MKS Test Management MS Visual Studio 2010 für Statische Codeanalyse; AutoIt für automatisierte Smoketests MS VisualStudio 2010 incl. TestManager, LabManagement, etc. NUnit NUnit NCover NDepend Ranorex NUnit, AQTime nunit, junit, TFS NUnit, Moq NUNIT, Rhino-Mocks OmniTracker, HP Quality Center open source test tools Open Source, HP und Silk (jeweils komplett) OpenTest, Vector Informatik GmbH CANoe, Vector Informatik GmbH TestStand, National Instruments TestExec,??? PCLint, FxCop phpunit PHPUnit Selenium (IDE,Grid) JMeter PHPUnit Selenium Tests fireunit (für Javascript) pmd, FindBugs, CheckStyle PRODYNA NABUCCO TestAutomation, JUnit, Selenium, JMeter, EMMA, EclEMMA Project2Web, Selenium QA-C von QA-SYSTEMS Eigenentwicklung QC, QTP QC, QTP, LoadRunner QC, QTP, SilkPerformer QC, TestLink, Silk*, Rational* QFTest QFTest QF-Test, SOAPUI QF-Test, Spiratest, Jira, JUnit QTP, Loadrunner, jmeter, Quality Center Quality Center quality center HP

224 208 Quality Center version 6.0 Quality Center Microsoft Visual Studio Test Center Quality Center QuickTest Professional LoadRunner nunit PMD Quality Center, HP Functional Tester, HP Quality Center, HP Tosca, Tricentis Quality Center, QT Pro, Excel mit Makros, viele selbstgeschriebene oder von den Kunden zur Verfügung gestellte Werkzeuge, viele Tools aus dem Java/J2EE-Umfeld Quality Center, QuickTestProfessional, Jmeter QualityCenter(HP), FunctionalTester(IBM), LoadRunner, WinRunner, diverse Capture&Replay Tools, Eigenentwicklungen für Datenproduktion QualityCenter, HP; QF-Test, QFS; QualityCenter, QTP QualityCenter, QTP, LoadRunner, Cobertura, Checkstyle, Findbugs, PMD, CPD, Surefire, homegrown tools QualityCenter,N unit, Vectorcast Qualtity Center Quicktest Professional Tosca Entwicklersuiten und -werkzeuge QuickTest Professional, Fa. Mercury Interactive Ranorex, Clover, TestStand Ranorex, eigene Test-Suiten, CodeMeter Rational ClearQuest, Rational Manual Tester, Rational Functional Tester, Rational Quality Manager Rational RealTime selbst entwickelte Testumgebung CANOE (Vector) Polyspace QAC ReSharper RTRT, Bugzilla Ruby on Rails Test SAP Solution Manager SAP ecatt HP Quality Center HP Quick Test Professional SAP TAO HP LoadRunner SCTM, SilkTest, SilkPerformer, Loadrunner, QTP, QC Selbst entwickelte (Shell Script / C++) Selenium, FitNesse, JMeter, JUnit, HP Mercury Quality Center, Jira, Ranorex Selenium, Ruby Test::Unit, Cucumber

225 209 Silk Produkte von Borland Silk Test von Microfocus silk u.a. SilkCentral TestManager, SilkTest, SilkPerformer, SilkCentral PerformanceManager (jeweils microfocus); soapui Pro (eviware); Eigenentwicklungen (z.b. zur Spezifikation von Testfällen; zur Überführung von Anforderungen aus Analysemodellen in Testmanagementwerkzeuge) SilkCentral, MicroFocus, CodedUITests, Microsoft, Ranorex, GoogleTest, NUnit Silktest Silktest, Silkperformer, Borland Loadrunner, SOAP-UI SilkTest, SCTM simulationstool für logistik SiTEMPPO (Siemens), TFS 2010 (Microsoft) Sitemppo, Quicktest Pro, Neoload, SoapUI, JUnit Snagit, JMeter, HP QC, syntex serna free soap-ui, junit, mockito, easy-mock Soma Sonar, Sikuli, Selenium, Fake Sotograph, junit, PushToTest Testmaker, Selenium, soapui, Tamper-Data, sahi, eclemma, WebScarab, Nmap, Nessus, Wireshark, Snort SQS SQS Test Professional IBM Rational Tools (alle) sqs-test, qtp, clearquest, datamaker, rpt Tessy, CTE, PROVEtech:TA Test Automation FX, White Testcomplete TestComplete, T-Plan Robot, Eigene Testcomplete, Marathontesting, selbst erstellte Testcomplete, QA-Run Testlink TestLink, QA-C, PC-lint, QFTest Testlink, Squish/Froglogic, Selbstentwickelt TestLink, TOSCA Testlink, Test Track (Seapine) TestMan / PSI AG Squish / froglogic QF-Test / Quality First Software GmbH Eigenentwicklungen TestNG, Selenium, DBUnit TestOffice (SpiritSE), Selenium (OpenSource) Testpartner (Compuware, Micro Focus), CTE Testpartner TFS, MSTest (xunit) TFS, ALM, QTP, WinRunner TMS, Teststand, Labview, ARTS+

226 210 TOSCA Tosca TOSCA TOSCA (Tricentis), TestDirector und WinRunner (Mercury Interactive), Araxis, Progress/OpenEdge interne Werkzeuge, selbst entwickelte Tools etc. Tosca der Firma Tricentis Silkperformer Tosca Testsuite (Tosca Commander, Requirements AddIn, TestCaseDesign AddIn) - Fa. Tricentis TOSCA Testsuite von TRICENTIS TOSCA Testsuite von Tricentis TOSCA Testsuite, Proxy Sniffer TOSCA Tricentis Tosca, Testlink, jira, soapui TOSCA, Tricentis, Omnitracker TTCN-3 überwiegend selbst entwickelte Werkzeuge im Hostumfeld und in den eigenen PC- Frontends JUNIT im Server-Umfeld unity, RTRT, PC-Lint, SourceMonitor (GIMPEL), TTFis, Simulatoren (PC) bevor man auf das HW-Target geht Visual Studio Unit Tests, StyleCop, FxCop Visual Studio, FitNesse VS 2010 Test, TFS, Moq, Quicktest/QualityCenter, firmeneigenes Automation Framework WTF server, Project Analyser z.b. EasyMock, Findbugs, Junit, eigenes c/r tool f. SWT GUI zur Software gehörende, speziell entwickelte Tabelle 4-142: Antworten zu Frage 9.1.7

227 Frage 9.2 Auswahl / Pilotierung durch Testwerkzeug-Labor Wenn Sie in Ihrem nächsten Projekt ein Testwerkzeug beschaffen, würden Sie für die Auswahl und Pilotierung die Hilfe eines herstellerneutralen Testwerkzeug-Labors in Anspruch nehmen? Tabelle 4-143: Auswahl/Pilotierung durch herstellerneutrales Testwerkzeug-Labor Abbildung 4-133: Auswahl durch herstellerneutrales Testwerkzeug-Labor

228 Frage 9.3 Bedarf von Testwerkzeugen Abbildung 4-134: Wortwolke der Antworten zu Frage 9.3 Wo sehen Sie Bedarf in Forschung, Entwicklung oder Beratung von Testwerkzeugen? (Stichworte reichen aus) Abnahmetests, speziell Anwenderverhalten (Eingaben, Ausführung,...) Aufwand zur Einführung Kosten - Nutzen Analyse Auswertung von Testergebnissen (Reports) Automatisierte Generierung von Testfallszenarien auf Basis der bisheriger Testergebnisse automatisierte GUI-Testtools automatisierter Test von User Interfaces Automatisierung - Anwendung, Grenzen, Nutzen und Aufwand Automatisierung ALM Bedarf in Monitoringtools

229 213 Beratung des Managements: auch Testwerkzeuge müssen von guten, geschulten und erfahrenen Mitarbeitern bedient werden. Beratung der Tester: die Verwendung von Testwerkzeugen bedeutet nicht automatisch den Verlust des Arbeitsplatzes Beratung: Mittel-Management Beratung: Entwicklungsmanagement Bessere Integration der verschiedenen Werkzeuge/Tools unter einem Dach, ggfs. über standardisierte Schnittstellen/Services Bessere Integration mit anderen ALM-Produkten (z.b. Issuetracking) Bessere Kooperation der Tools für Anforderungsmanagement, Testmanagement und Ressourcenmanagement (Mitarbeiter) Best-Practise Cases für kleine Unternehmen und success stories Bewusstsein im Management schaffen, dass das nötig ist und etwas bringt branchenbedingt: Capture & Replay im CAD Umfeld. Hier ist bislang nur die Bestimmung der x,y Position möglich. Jedes Zoomen, jede Änderung der Ansicht verhindert eine Reproduzierbarkeit. breiterer Einsatz von Testautomatisierung Capture & Replay!= Testautomatisierung Es wird den Projektleitern so oft das Versprechen abgegeben und es wird nie gehalten. Tests müssen definiert und programmiert werden und Capture kann nur unterstützen. Checkliste für Evaluation von Testwerkzeugen Die Durchgängigkeit der Testwerkzeuge mit Werkzeugen des Anforderungs- und Versionsmanagements, um den kompletten SDLC abzudecken. Dabei soll einerseits die Modularität je nach LC-Phase und die gemeinsame Datenbasis berücksichtigt werden. Die Testautomatisierung ist in der Regel viel zu teuer und aufwändig und bringt nicht den gewünschten Erfolg. Wir haben die Testautomatisierung drastisch reduziert. Testmanagementwerkzeuge sind gut, effektiv und hilfreich. Doors verbessern, durchgängigere Werkzeugketten und weniger Klein Klein Dranbleiben damit Werkzeuge mit der rasanten Entwicklung mithalten können und vor allem FLEXIBEL eingesetzt werden können Effizienter Einsatz der Tools Einsatz von Testautomatisierungstools in der Praxis Entwicklung und Beratung Entwicklung weiterer Werkzeuge für Embedded Entwicklungen Hardwareabstraktion Verbesserung von Simulatoren Werkzeuge zur schnellen Produktion von embedded Testing Hardware zur Unterstützung von Daten- oder statusgetriebenen Testfällen Erfassen von Testmetriken Erhöhung der Benutzerfreundlichkeit vor allem mit dem Ziel die Fachabteilungen einzubeziehen Flächendeckender Einsatz Standardisierung Geht eigentlich schon alles in die richtige Richtung Ggf. mehr Integration der Werkzeuge untereinander / Anpassbarkeit an den eigenen Prozess Genauere Informationen über die Aktualität der Datenbanken.

230 214 Generierung von Testdaten bzw. Vereinfachung und Modularisierung bezogen auf das Anwendungsgebiet Hürde für Einsatz meist sehr hoch; Pflege von Testfällen aufwändig Ich glaube das geht schon alles in die richtige Richtung - interessant wäre eine stärkere Integrationsfähigkeit der Tools bzw. eine Anpassbarkeit an den eigenen Prozess ich weiß nicht Impact Analyse fuer Regression Tests in allen 3 Bereichen auf allen Stufen Informationen über die Aktualität der Datenbanken Integration in den Entwicklungsprozess (Durchgängigkeit, Tracability) Integration in SW Entwicklungsumgebung tzr Sicherstellung der bidirektionalen Traceability, Requirements-Werkzeuge, SW-IDE. Datenbankgetriebene Tools zur Erfassung des Reviewstatus (Q-Status) von Dokumenten, SW-Modulen und anderen Artefakten zur Qualitätsberichterstattung und -verfolgung im Projekt und zur Reviewplanung. Interoperabilität verschiedener Werkzeuge gemeinsame Datenhaltung Verbindung mit agiler Entwicklung (z.b. einbinden ins Scrum Management) Intuitive Bedienung; Übersicht; Beherrschung der Komplexität Intuitive Erstellung von Regressionstest Intuitivität der Testwerkzeuge sollte verbessert werden Komplettsysteme für den gesamten Prozess (vom CaseTool bis zu Testfall + Testdatengenerierung bis hin zum Testdurchführungstool sowie automatisierte Risikoanalyse auf Basis des Cases (UML); flexiblere Systeme für kombinierte Entwicklungen (agil + phasenbasiert / V-Modell) Konfigurationsmanagement Echtzeitfähigkeit Konzepte zur GUI-Testautomatisierung (lohnen die versch. Keyword-Konzepte?) leichte Modellerstellung und Konfigurierbarkeit leichte Bedienbarkeit Man könnte mal brauchbare Tools anschaffen und nutzen. Oder OpenSource-Tools etablieren. Meist krebst man nur planlos rum und fabriziert nicht-praktikable Lösungen. MBT könnte besser eingesetzt werden Metriken im Agilen Bereich MBT-Werkzeuge kombiniert mit Testmanagementwerkzeugen Medizintechnik mehr Automatisierung ist dringend notwendig, aber leider teuer und zuerst zeitintensiv Mehr Stabilität bei GUI Tests gegen Regression Mehr Unterstützung von Testdesigns Model based testing Modellbasierte Testwerkzeuge, Traceability, automatisierte Metriken Modularität, Stabilität, Kompatibilität, Plattformunabhängigkeit Performance-Test-Framework Pflege der Scripte aus der Testautomatisierung Synchronisierung der Tools / Schnittstellen zwischen Tools Pflege ist zu aufwendig. PL/SQL Statische Code Analyse

231 215 Risikoorientierung aus den Requirements sollte sich automatisiert bsi zu den Testfällen fortpflanzen können schnellere Anpassung an aktuelle Software (Betriebssystem, Browser,.NET Stufen) Schnittstellen zwischen den einzelnen Testwerkzeugen und anderen Werkzeugen im Entwicklungsprozess z.b. Modellierung, Generierung von Code Schulungen, Dokumentation Sehr viele spezielle Werkzeuge, nur schwer zu beherrschen und anzuwenden. spezielle Testautomatisierungsframeworks für embedded Systeme entwickeln Standardisierung ständige Adaption der Testwerkzeuge wegen ständig neuer Technologien erforderlich Testautomatisierung von dynamischen Web-Anwendungen, Testmanagementwerkzeuge Testdatengenerierung ist ein offenes Thema Generierung von effizienten Integrationstests ebenso Zudem Testwerkzeuge fuer neue Technologien wie Clouds, MashUps, etc. testdatenmanagement Testdatenmanagement Testfall Klassifikation, Testfallverwaltung Testfallerstellung. Also wie man zu den TEstfällen kommt Testfallgenerierung Tools zur Testfallspezifikation wie CTE XL, model based testing. überall Überladen (Funktionalität, GUI) Gestaltung, Langsam, Unnötig komplex umfangreichere Nutzung Unterstützung bei der Automatisierung für die Generierung und Befüllung von Systemen / Systemlandschaften mit Testdaten (Systembestandsdaten); Werkzeuge, die klar trennen zwischen technischer Testausführung (Übersetzung in Ausführungsumgebung aus einer Test-Notation, z.b. TTCN sowie Testmodellierung / Testspezifikation, z.b. Modell-getriebene Generatoren von Tests in TTCN. Vereinheitlichung von Schnittstellen und standardisierte xml-basierte Beschreibungssprache für Testfälle, Testdaten, Keywords Verknüpfung verschiedener Testwerkzeuge über Herstellergrenzen hinweg Versionierung Release Management (bei HPQC z.b. zu viele Einschränkungen durch Werkzeugvorgaben) Web-basiert, open-source Wenn sich in der Branche, in der wir tätig sind (Bezahlen mit Chipkarte), endlich Schnittstellenstandards durchsetzen würden, gäbe es bald brauchbare Testwerkzeuge von der Stange. Bis dahin sind wir auf Eigenentwicklungen oder sehr teure Spezialsoftware (nur mit Beratungsdienstleistung erhältlich) angewiesen. Wieso sind viele Werkzeuge für das tägliche Testen eine Falle oder gar ein Fluch? zu hoher Aufwand um sie lauffähig zu bekommen und sie lauffähig zu erhalten. Testwerkzeuge sind oft nicht validiert was bei Audits zu Problemen führt zu wenig Erfahrung bisher Zur entscheidungsfindung, wo/wann/wieviel regression testing notwendig ist; wenn in einer komponente eine aenderung gemacht wurde, muss man wissen, welche auswirkungen das haben kann auf das gesamt produkt. Heute ist dieses Wissen in guten Testern verankert. Tabelle 4-144: Antworten zu Frage 9.3

232 Fragenkomplex 10 Qualifizierung und Weiterbildung Frage 10.1 Unterstützung von QS Weiterbildung Wird in Ihrem Unternehmen die Weiterbildung im Bereich der Qualitätssicherung unterstützt? Tabelle 4-145: Unterstützung der Weiterbildung im Bereich QS Abbildung 4-135: Weiterbildung in Bezug zur Unternehmensgröße [Quelle: Henning12]

233 Frage 10.2 Weiterbildung / Informationsbeschaffung Für meine Weiterbildung und Informationsbeschaffung nutze ich Tabelle 4-146: Weiterbildung/Informationsbeschaffung durch [Quelle: Henning12] Tabelle 4-147: Informationsquellen der Tester [Quelle: Henning12] Tabelle 4-148: Informationsquellen der Manager [Quelle: Henning12]

234 Frage 10.3b Treffen Regionalgruppe Deutschland Ich besuche Treffen der Regionalgruppe Deutschland Tabelle 4-149: ASQF Arbeitskreis Software-Qualität und -Fortbildung e.v. Abbildung 4-136: ASQF Arbeitskreis Software-Qualität und -Fortbildung e.v.

235 219 Tabelle 4-150: GI Gesellschaft für Informatik Abbildung 4-137: Abbildung 3 290: GI Gesellschaft für Informatik

236 220 Tabelle 4-151: GI TAV FG Testen, Verifizieren, Analysieren Abbildung 4-138: GI TAV FG Testen, Verifizieren, Analysieren

237 221 Tabelle 4-152: Softwareforen Leipzig Abbildung 4-139: Softwareforen Leipzig

238 Frage 10.3b Treffen Regionalgruppe Österreich Ich besuche Treffen der Regionalgruppe Österreich Tabelle 4-153: ASQF Arbeitskreis Software-Qualität und -Fortbildung e.v. Abbildung 4-140: ASQF Arbeitskreis Software-Qualität und -Fortbildung e.v.

239 223 Tabelle 4-154: ATB SW Test Network Meeting Abbildung 4-141: ATB SW Test Network Meeting

240 224 Tabelle 4-155: ÖGI Österreichische Gesellschaft für Informatik Abbildung 4-142: ÖGI Österreichische Gesellschaft für Informatik

241 225 Tabelle 4-156: STEV Österreich Vereinigung für Software-Qualitätsmanagement Abbildung 4-143: STEV Öster. Vereinigung für Software-Qualitätsmanagement

242 226 Tabelle 4-157: ADV Arbeitsgemeinschaft für Datenverarbeitung Abbildung 4-144: ADV Arbeitsgemeinschaft für Datenverarbeitung

243 227 Tabelle 4-158: Future Network Abbildung 4-145: Future Network

244 Frage 10.3d Treffen Regionalgruppe Schweiz Ich besuche Treffen der Regionalgruppe Schweiz Tabelle 4-159: SI Schweizer Informatik Gesellschaft Abbildung 4-146: SI Schweizer Informatik Gesellschaft

245 229 Tabelle 4-160: STB Swiss Software Tester Forum Abbildung 4-147: STB Swiss Software Tester Forum

246 230 Tabelle 4-161: SwissQ SwissTesting Day Abbildung 4-148: SwissQ SwissTesting Day

247 231 Tabelle 4-162: SwissQ Swiss Testing Nights Abbildung 4-149: SwissQ Swiss Testing Nights

248 232 Tabelle 4-163: bbv QEvent Abbildung 4-150: bbv QEvent

249 Frage 10.4 Bekanntheit ISTQB Ausbildungsschema Frage 10.4 Das ISTQB Ausbildungsschema ist mir bekannt. Tabelle 4-164: Bekanntheit des ISTQB Ausbildungsschemas [Quelle: Henning12] Abbildung 4-151: Bekanntheit des ISTQB Ausbildungsschemas [Quelle: Henning12] Abbildung 4-152: Bekanntheit von ISTQB im Management [Quelle: Henning12]

250 234 Abbildung 4-153: Bekanntheit von ISTQB bei Testern [Quelle: Henning12] Abbildung 4-154: Bekanntheit von ISTQB bei Entwicklern [Quelle: Henning12]

251 Frage ISTQB Foundation Level-Zertifikat (Abhängige Frage 10.4) Ich habe das ISTQB Foundation Level Zertifikat. Tabelle 4-165: Besitz des ISTQB Foundation Level Zertifikats Abbildung 4-155: Besitz des ISTQB Foundation Level Zertifikats Tabelle 4-166: Verbreitung des ISTQB Foundation Level Zertifikats

252 Frage ISTQB Foundation Level fehlende Themen (Abhängige Frage ) Abbildung 4-156: Wortwolke der Antworten zu Frage Vermisst habe ich bei der ISTQB Foundation Level - Ausbildung folgende Themen Agiles Testen Agiles Vorgehen, SCRUM Als Basiswissen für das Softwaretesten war es ausreichend. Die anderen Bereiche des Advanced Level haben die fehlenden Punkte abgedeckt. anpassung an agile methoden (ISTQB FL ist auf das V-Modell ausgerichtet) Automatisierung xunit Berücksichtigung von embedded Software Spezifikas Bezug zur aktuellen realen Welt, sprich : wie tu ich in agilen Projekten Branchenspezifisches

253 237 Continuous Integration (Testen im agilen Projekten) den Praxis-Bezug Den Praxisbezug. Sehr viel Theorie und wenig Ansätze das Gelernte im Unternehmen einzubringen. Die Änderung im Bereich der Grenzwertanalyse im neuen Lehrplan ist wenig sinnvoll. Die in der neuen Version entfallenden TF haben häufig zur Fehlerfindung beigetragen. Die Änderungen im Bereich der Qualitätskriterien sind unklar (Begründung?). Die Zuordnung des Kriteriums "Sicherheit" in wechselnde Bereiche ist immer noch unklar. Organisatorische Rahmenbedingungen (und deren Einforderung). die Ausbildung ist zu sehr "foundation", das Wissen sollte jeder haben; Anwendbarkeit in der Praxis oder tiefergehende, nicht-triviale Beispiele fehlen Die Ausbildung war unnötig, da ich mir das Wissen bereits aus Büchern lange vorher angeeignet hatte, es ging lediglich darum, die korrekten deutschen Bezeichnungen zu lernen. die praktische Umsetzung hinsichtlich Termine und Budgetvorgaben fehlt aus meiner Sicht. Eingehen auf den Prüfungsprozess, Prüfungsprozess nicht durchsichtig Embedded Software Embedded System - sehr Banken- und Versicherungslastig Embedded Test Automatisierung Erstellung von genormter Testdokumentation Es war reines Schlagwörter üben; Es fehlten Themen für das grundsätzliche Verständnis vom Testing. habe nichts vermisst; ISTQB-Zertifizierung wird von den meisten Unternehmen gefordert, die Unternehmen selbst halten sich jedoch kaum an die Vorgaben. Ich habe die Prüfung ohne Schulung durchgeführt... Ich habe mir die Inhalte im Selbststudium angeeignet anhand Lehrplan und Lehrbuch und habe hier alle relevanten Inhalte für die Prüfung vorgefunden - also nichts vermisst :-) im Gegenteil: zu viele Themen enthalten In erster Linie den Erfahrungsaustausch in den Schulungen Informationen zu Anforderungen für Advanced Level intensive Berücksichtigung von Bugtracking/Fehlermanagement: - Klassifikation von Fehlern - Beispiel Zustandsdiagramm (livecycle) eines Fehlerberichtes Ist jedem zu empfehlen: ("Inselbildung der Tester" kann durch dieses Wissen geschehen - verglichen zu den PLs, Management da hier Verständnis (dauerhaft) fehlt und sie auf ihrem Kurs beharren/ kein Interesse an Weiterbildung haben. ISTQB ist nichts anderes als "Testen mit gesundem Menschenverstand". Das Zertifikat sagt NICHTS über die Qualität eines Testers aus, wird aber gerne als solches verkauft. Die besten Tester und Testmanager haben kein Zertifikat - es ist symptomatisch, dass die Leute, die nicht testen können, dieses zertifikat oft haben. keine Ausbildung sondern Selbststudium keine explizite Aussage Keines; Es handelt sich um "Foundation" Konkrete Beispiele der Testfallerstellung und Testdatengenerierung mehr praktische Beispiele zur Anwendung der Techniken Mehr Praxisbeispiele Moderne Testmethodiken wie zb Exploratory Testing - Agil Testing nichts nichts ;-)

254 238 nichts ;-) nichts, es war für die Stufe umfassend genug Nichts, nur wusste ich durch gute praktische Erfahrungen schon alles nichts: Inhalte waren bekannt Praktische Anwendung der vermittelten Inhalte Praxis Praxis Praxisbeispiele, Anwendungsvorschläge, konkrete Testwerkzeuge, Hands-on Praxisbezug Praxisbezug Praxisbezug, es ist lediglich eine Begriffbeigerei Praxisbezug, Mischformen von Entwicklungsmodellen, Testen unter Zeitdruck, was lässt man weg, was besser nicht. Migrationstestszenarien praxisbezug, Übungen für komplexe situationen Praxisnähe Praxisnähe. wie gehe ich große testthemen wie migrationen an? wie teste ich datawarehouse? Praxisrelevanz reale Praxis Realitätsbezug Requirments Engineering Schwerpunkt Automotiv So offensichtlich es klingen mag: zu testen! Es ist kein praktischer Anteil vorgesehen, was sich auf jedenfall ändern sollte. Der theoretische Teil ist leider etwas fern der Praxis und ein Multiple Choice Test sollte nicht für die Aussage einer Qualifikation dienen. Die angebotenen Kurse bieten hingegen in aller Regel ein solides Wissen im Bereich der Testtechniken. Spezielle Anforderungen im Bereich Embedded Systems Spezifische Werkzeuge Test "embedded systems". Testaufwandschätzung, OO-taugliche Whitebox-Tests, Testorga, Testen in agilen Projekten Testautomatisierung Testmethoden für objektorientierte SW Entwicklung, Einbindung in neuere SW Entwicklungsmethodiken wie XP oder SCRUM Testmetriken Testplanung, insb. für Regressionstest Testprozessoptimierungen wie z.b. TPI oder TMMI Vermisst kann man nicht sagen. Die DIN und ISO-Normen sind meines Erachtens völlig überflüssig. Der Test hat zu viele Fragen die sehr spitzfindig sind resp. das muss jedes Unternehmen für sich entscheiden wie es z.b bei einer SW-Evaluation vorgehen will. Hat es zu viel Geld werden eben alle Hersteller zu einer Demo eingeladen. Und das noch mit einer DIN-Nummer versehen! Das interessiert in der Praxis kein Mensch => Forschung soll die Finger von Vorgehensmodellen lasse. Viel mehr Praxisbeispiele einbauen! Vorstellung praxisrelevanter Werkzeuge und Beispiele white box wird überbetont, evtl. optional Wie man überzeugt Geschäftsführung über notwendigen QS-Maßnahmen. Wirklich praxisnahe Fragen. Pures auswendig lernen wird verlangt.

255 239 Zu sehr kaufmännische (SAP) Ausrichtung der Seminare. Technische Systeme unterliegen in der Regel anderen Testvorgehensweisen... Zu viele Definitionen; Das (Mode-) Thema "Agilität" kommt zu kurz. Manchmal seltsame Formulierung von Prüfungsfragen. Zuviel Theorie, blieb nicht haften Tabelle 4-167: Antworten zu Frage

256 Frage ISTQB Advanced Level-Zertifikat (Abhängige Frage ) Ich habe das ISTQB Advanced Level-Zertifikat (Testmanager und/oder Test Analyst und/oder Technical Test Analyst). Tabelle 4-168: Besitz des ISTQB Advanced Level Zertifikats Abbildung 4-157: Besitz des ISTQB Advanced Level Zertifikats

257 Frage ISTQB Advanced Level fehlende Themen (Abhängige Frage ) Abbildung 4-158: Wortwolke der Antworten zu Frage Vermisst habe ich bei der ISTQB Advanced Level - Ausbildung folgende Themen: Advanced Level Kurse (neu 5 tägig) erscheinen wie Geld-Macherei zu viel Theorie, wie es nicht umsetzbar oder realistisch ist Prüfung verlangt Auswendig Lernen und sagt nichts darüber aus, ob jemand ein guter Tester ist. Agiles Testen (SCRUM) Automatisierung, Praxisrelevant, ausbildung techn TA ist zu theoretisch Cloud Testing Der Technical Test Analyst ist zu stark an den TEst Analyst angelehnt, hier kann man keine wirklichen Neuerungen im Umgang / Gebrauch von Werkzeugen lernen, die allerdings die Grundlage sein sollten.

258 242 detto wie bei FL und generell mehr praxisbezug Die Case Studies entsprechen nicht der realität ebenfalls nichts vermisst bisher es hat (zu) viele Repetitionen; die ganze Ausbildung ist zu wenig praxisorientiert, zu viel ideell, nur für Banken geeignet. Fragen teilweise leicht verwirrend (mehrdeutig); macht die Auswahl von Antworten nicht einfacher Ich habe keine Themen vermisst. Alle drei Bereiche des Advanced Levels decken diesen entsprechend ab. Ich habe nichts vermisst, aber um ein guter Tester zu sein, braucht es keine solche Schulung. Ein Zertifikat alleine macht noch lange keinen guten Tester aus. Keine konkrete Fallstudien/Werkzeuge Konsistenz, Praxisbeispiele Mehr Infos zu TestTools. Erfahrung, was können sie, Aufwand Einarbeitung mehr praktische Beispiele mehr praktische Übungen und konkrete Arbeiten im Umgang mit Metriken. Modellbasiertes Testen, Agiles Testen moderne Testmethodiken wie Exploratory Testing oder Agile Testmethoden im Detail nichts, aber es war zu lange und trocken nichts, die Ausbildung war umfassend und gut nix vermißt, aber functional tester / test analyst ist wachsweich in manchen teilen Noch mehr Praxisorientierung. Praktische Anwendung der vermittelten Inhalte Praxis Praxisbezug Realitätsbezug Realitätsnähe Test OO-SW modellbasierter Test (nur Zustandsautomatenbasierter wurde behandelt) Testmanagement im agilem Umfeld Testmethoden für objektorientierte SW Entwicklung, Einbindung in neuere SW Entwicklungsmethodiken wie XP oder SCRUM Übungen mit Hilfe realer Tools (hier würden sich herstellerneutrale Open-Source-Tools anbieten). umfassendere Infos zum Testen im agilen Umfeld Viel zu viele Überlappungen in der neuen Version von Lehrplan und Prüfungen gibt es viel zu viele Überlappungen. Prüfung und Zertifikat wirken dadurch künstlich aufgebläht. Wirkungen: "Es gibt nichts neues mehr." "Viel Text um wenig Inhalt". War für mich eher ein more-of-the-same Feeling gegenüber dem Foundation Level Wie? ich nicht mehr, ist schon eine Weile her. War allerdings besser als der Foundation Level. Vorbedingung, dass zuerst der Foundation-Level gemacht/bestanden werden muss für den Advanced ist reine Gleichmacherei. Wenn jemand das Advanced Wissen hat, weshalb ihn noch dazu zwingen den Foundation-Level zu machen?

259 243 Zu sehr kaufmännische (SAP) Ausrichtung der Seminare. Technische Systeme unterliegen in der Regel anderen Testvorgehensweisen... zu wenig konkrete praktische bsp für testverfahren, die die kriterien und überdeckungsgrade mal vollständig enthalten und zeigen zum Teil etwas eigenartige Fragen und mögliche Antworten beim Schlusstest. zumindest 2007 war die Ausbildung zum Technical Test Analyst fast ausschließlich für prozedurale Software hilfreich --> völlig veraltet die Themen zum Test Manager waren hingegen gut Tabelle 4-169: Antworten zu Frage

260 Frage ISTQB Expert Level wichtige Themen (Abhängige Frage 10.4) Für das ISTQB Expert Level halte ich folgende Themen für wichtig: Tabelle 4-170: Wichtige Themen für ISTQB Expert Level

261 Frage ISTQB Expert Level weitere Themen Abbildung 4-159: Wortwolke der Antworten zu Frage Weitere Themen für das ISTQB Expert Level können sein (Stichworte reichen aus) AUTOSAR Branchensspezifische Softwareproblematiken z. B. im Bereich Banken, Einzelhandel...) Cloud Testing Cloud Testing Der Hinweis das Extreme-Programming und -Testing nonsens ist. Außer Herr Beck kann endlich mal ein nach diesem Vorgehen erfolgreich umgesetztes Projekt vorweisen. Fachbezogene Testthemen, z.b. Medizintechnik, Automotive, Security ISTQB bringt nichts keine explizite Aussage Kommunikation im Betrieb, Einsatzmöglichkeiten Übersichten etc. Kommunikation und Dokumentation mit Fachbereichen und Auftraggebern, Metriken Kostenanalyse

262 246 Last/Performance-Test Leistungstesten Logik? M.E. benötigt ein Tester IMMER auch eine Ausbildung in der Domäne, in der er tätig ist. In meinem Fall: Ohne Banking-Know-how und Programmier-Erfahrung sind die meisten sogenannten Tester nutzlos! Methoden des Risikomanagements Mir wäre lieber, wenn das endlich mal angeboten würde. Der Wettbewerbsvorteil der FAL Zertifizierung ist schon lange nicht mehr gegeben. Mitarbeiterführung; Gruppendynamik; Einzelgespräche; Zusammenarbeit mit anderen Abteilungen (Fachbereich, IT, Entwicklung, PM...) Modellbasiertes Testen kenn ich nicht und kann nicht einschätzen ob es wichtig wäre Modellbasiertes Testen: 1) Alter Wein in neuen Schläuchen. 2) Lässt viele bewährte Bereiche außer Acht. 3) Modeerscheinung => Auf keinen Fall zum Thema machen. Agiles Testen: Da viele Projekte nur der eigenen Wahrnehmung und Bezeichnung nach agil entwickeln, fragt sich, auf was dieses Thema im Testbereich ausgerichtet sein soll: Reale Projektumgebung oder idealtypische agile Entwicklung? Modell um des Modells willens nicht hilfreich. Testautomatisierung und Sicherheitstest: Sehr wichtig, ab Nichfunktionale Test, Risikomanagement, Projektmanagement-Vertiefung, Praktische Teststeuerung und Führung von Test-Teams, Test-Reporting (insbes. für das Management) Outsourcing von Regressionstests Perfomancetesting Strategische Motivation der am Testprozess beteiligten Personen ODER Wie sorge ich dafür, dass "tollen Ideen" von einem von Grund auf Motivierten Team umgesetzt und kontinuierlich weiter verfolgt werden (und diese nicht nach einiger Zeit im Sande verlaufen). Testbereiche aus SPICE und CMMI, sowie TMMI und TPI Testdatenmangement, Testumgebungsmanagement, Abbildung der Teststrategie & - methodik in einem Tool Testing in embedded Systems Testmanagement von Performancetests, dies wird oft unterschlagen Teamaufbau und -weiterentwicklung Changemanagement (Kanban etc.) Testorganisation, Offshore Testprogramme (im Sinne von Testmanagement auf Programmmanagement-Level). Ich bin nicht sicher, ob ein Expert-level sinnvoll ist und könnte mir eher eine weitergehende Spezialisierung als ein Zusammenführen der drei Advanced-Level-Stränge vorstellen. Testtools übergroße spezialisierung (ttcn-3 z.b.) ist schädlich für akzeptanz der kurse und schädlich für tester / testmanager: verfahren und prozesse sind weit wichtiger als technische hilfsmittel weniger Theorie und Details Tabelle 4-171: Tabelle zu Frage

263 Frage 10.5 Bedarf von Aus- / Weiterbildungsmaßnahmen Abbildung 4-160: Wortwolke der Antworten zu Frage 10.5 Wo sehen Sie Bedarf für eine Entwicklung von Aus- und Weiterbildungsmaßnahmen? Agile / Testen in Großprojekten / Testen in verteilten Testprojekten (Offshore) Agile und Modellbasierte Testmethoden in der Umgebung sicherheitskritischer Software agile Vorgehensweisen fachspezifische Problemstellungen z.b. im Bereich Web / Mobile Agiles Testen agiles Testen Agiles testen (keine web-anwendung) Sicherheitstests (keine web-anwendung) Lasttests (keine web-anwendung) Agiles Testen Tests im spezifischen Umfeld, z.b. Webapplikationen, Mobile Applications

264 248 Agiles Testen, Testautomatisierung, TPI An der Zeitnot ausgerichtete Weiterbildungsmöglichkeiten --> Zeitschriftenreihe? --> Internet? um auf dem neuesten Stand zu bleiben An unserer Hochschule wurde das Testen nur angeschnitten... Eigene Module wären sinnvoll. Anwenderschulung Arbeiten im Testteam, Test Driven Development Argumentationshilfen für "Mehrwert" durch die Teilnahme. Aufwandschätzung Testumfang, Ermittlung der relevanten Testfälle Aus- und Weiterbildungsmöglichkeiten im Internet Aus-/Weiterbildungsmaßnahmen gibt es in unserer Firma nicht, da sie vom Management als Geldverschwendung angesehen werden und während solcher Maßnahmen die Man- Power in der Entwicklung fehlt. Ausbildung auf Lehrling-Stufe zum Tester wäre sehr hilfreich. Allgemein Berufsausbildung für den Tester-Beruf wäre sinnvoll. Innerhalb von Informatik-Studien sollte vermehrt auf Quality Assurance ein Thema sein. Ausbildung in den Testmethoden und Techniken Kommunikation / Zusammenarbeit IT und Fachbereiche Agile Ansätze Einsatz von Modellbasierten Techniken und Verfahren Einsatz von Testwerkzeugen Ausbildung in der Praxis. Das theoretische Wissen aus ISTQB hilft im Projekt nur sehr bedingt und führt teilweise zu tief ins Detail. Ganz wichtig: nie den Überblick verlieren Austausch über Best Practices Automatisierte Test, Test-driven-development Automatisierte Tests für Webapplicationen (Capture/Replay) Automatisiertes Testen und Einbinden des Testens als Teil des Entwicklens in einem agilen Vorgehen Testen von besonderen nicht funktionalen Eigenschaften, die nicht in einem agilen Team durchgeführt werden können aufgrund Spezialwissens oder eines zu beachtenden Stageing Prozesses im Deployment aufgrund von z.b. Regulatorien oder Compliance Anforderungen Automatisierung, Testen im Agilem Umfeld verstärken, Bachelor-Studiengang zum Software-Tester (in etwa entsprechend ISTQB Foundation Level) an Hochschulen; Master-Studiengang zum Software-Testingenieur (entsprechend ISTQB Advanced Level) an Hochschulen; Definition eines Berufsbilds Software-Tester durch die GI. basic tester und das zugehöriger Zertifikat ist ein Witz, wie jeder weiss. Jedenfalls bringt es Geld für die Zertifizierer; ansonste ohne jeglichen praktischen Weret; reine Marketingschiene für die Sales Beachtung von fachlichen Testfällen bei der Anforderungsanalyse / Use-Cases Testtools für den Regressionstest Test der Datenübernahme Lasttest Bei den jüngeren Mitarbeitern. In ca 10 Jahren sind wir alle weg. bei Testautomatisierung

265 249 Bereits beim Studium an den UNI'S! Bereits in der Grundausbildung von Informatikern TDD unterrichten. Bereits in der Hochschule als Vorbereitung auf die kommenden Tätigkeiten Berücksichtigung von Tests im Bereich Steuerungsentwicklung und SCADA Systeme Bewusstsein für Sinn und Nutzen von Tests muss bei Entwicklern geschaffen werden. Bewusstsein schaffen Bewusstseinsbildung, kontinuierliches Ziel- und Ergebniskontrolle Bewusstseinsstärkung für IT-Entscheider zur Notwendigkeit von Teststrategien certified tester (foundation level) Certified Tester Kurse Certified Requirements Engineering Cloud Testing cloud, entity framework, share point Continous Integration, korrekte Erstellung von Testfällen Dass Ausbildung laufend mit Fortschritt mithält; Mehr in Richtung: "gut, jetzt hab ich die (ISTQB) Grundlagen - wie zum Teufel kann ich DAS nun in MEIN vorhandenes PROJEKTUMFELD einphasen?" der Bedarf liegt darin, das Management erstmal vom Einsatz von Softwaretests zu überzeugen Der reellen Erfahrungswelt im Mittelstand angepasste Möglichkeiten. => "Chaos"; keine Spezifikationen liegen vor, dauernd ändernde Features, tägliche Builds, etc. Derzeit keine weiteren wie Sie der ASQF und die isqi anbieten. die Dimensionen der praktischen Aufgaben Vorort sollten berücksichtigt werden Die Geschäftsführung sollte daran teilnehmen um die Maßnahmen wenigstens in der Theorie zu kennen. Durchsichtiger Prozess, durchsichtige Prüfungen Eine Experte Qualifikation die wirklich Expert ist Einen Schritt in die Richtung des AST (Association for Software Testing) wäre sicherlich ein guter Weg. Cem Kaner bietet seine Vorträge zu Bug-Advocacy und BlackBox SW Testing ja bereits seit Jahren zur freien Verfügung an, und hat dies nun mittlerweile in günstige bzw. sogar kostenfreie Kurse für AST Mitglieder erweitert. Dies wäre für die GI (Gesellschaft für Informatik) oder das German Testing Board sicherlich auch eine Bereicherung, und genug anerkannte Experten im Gebiet Black-Box S Einen weltweiten einheitlichen Standard. Die verschiedenen Testmethoden sollten >90% übereinstimmen. Einsatz verschiedener Methoden insbesondere für SOA Architekturen E-Learning Erstellungen von Testmodellen zur Steigerung der Testeffizienz und Testtiefe Es gibt ausreichend Qualifizierungsmaßnahmen, auch inhaltlich; Immer auf dem Laufenden zu bleiben (agil, Normen) ist ein anderes Problem fdkgjdfkljgjn firmen-interne Organisation Fokus sollte auf der Sache an sich liegen, nicht im reinen Geldverdienen der Schulungsunternehmen. Viele Schulungsangebote sind überflüssig. Förderung durch Arbeitgeber (nicht nur Kosten sondern auch Zeit) General Management insb. Betriebswirtschaft für Testmanager Speziallisten für Automatisierung und/oder Performance + Lasttest Security- und Usability-Testing

266 250 Generell sollte es ein Standardwissen für Tester/Testautomatisierer geben. Grundlagen: - Was ist das Ziel des Testens? - Bei vielen Kollegen herrscht noch der Irrglaube, ein Test soll die Abwesenheit von Fehlern zeigen. - Grundbegriffe nicht bekannt - Bestimmte Techniken (z. B. randomisierte Testdatengenerierung) werden mit einem Handschlag weggewunken, allgemeines Desinteresse und Ignoranz herrscht vor, weil man sich nicht vorstellen kann, dass man Testfälle ohne konkrete Daten entwickeln kann (z. B. mit Prädikatenlogik). Grundlagenausbildung für alle Entwickler sowie für Projektmanager, Entwicklungsnahes Vokabular in die ISTQB-Kolloquia, Spezialistenausbildung gute effiziente Kommunikation, gute Konzepte schreiben, Stress durchlassen habe keine Erfahrungen Halte relativ wenig davon (graue Theorie). Qualität des Testers wird m.e. durch Social Skills und analytisches Denkvermögen bestimmt - der fachliche Teil ergibt sich in der Praxis. Hilfe bei der Einführung strukturierter und standardisierter Tests in einem Unternehmen was über 20 Jahr fast ohne Tests gearbeitet hat Hochschulausbildung für Software-Testingenieure Hochschulen ich bin bereits ISTQB-zertifiziert. Ich habe vor Jahren an Seminaren teilgenommen, die alle nicht die Art und Weise getroffen haben, wie Standardsoftware getestet werden kann/muss. Alle Seminare waren zu theoretisch. Nicht alles kann mit Testrobotern getestet werden. Ich halte wenig von diesem selbsternannten Zertifizieren. Ich strebe die Weiterbildung zum Advanced Level an Ich suche nach einer praxisnahen Umsetzung von Tests in JEE Umgebungen. Es gibt viel zu viel zum Einstieg und Testen, aber fast nichts Weitergehendes, zu realen Problemen bei größeren Projekten, insbesondere im JEE-Kontext. Ich vermisse stark den Link von der akademischen Welt in die Tester Welt. Hier sollte mehr und näher an der Praxis gearbeitet werden. Evidence Based testing oder management in Zusammenarbeit mit Business Schools ich weiß nicht Im Lehrplan des ISTQB, wirkt nur als Geldmaschinerie. Der Gedanke ist gut, die Umsetzung schwach. Beispiel Expert Level, Begrifflichkeiten der neuen Lehrpläne, fehlerhafte Prüfungsbögen... in allen Bereichen des testens, testen wird sträflichst vernachlässigt Management muß sehr viel sensibler für testen werden In den Universitäten, und auf die dortigen Anwendungsfälle angepasst. Ingenieurmässiges Arbeiten in der Softwareentwicklung (zumeist wird ohne großes Fachwissen munter drauflosprogrammiert) ISTQB FL ISTQB Foundation Level muss als Mindest-Qualifikation gefordert werden ISTQB ist zu theoretisch, Übung /Praxistransfer notwendig. ISTQB Kurse die 5 Tage dauern sind zu umfangreich --> Kein Weiterbildungsbudget (Zeit und Geld) für so lange Kurse. ISTQB Zertifizierung QAMP Zertifizierung ireb Zertifizierung

267 251 kann ich nicht beurteilen Kein Bedarf - gutes firmeneigenes Weiterbildungskonzept kein Bedarf, vorhandene Planungstools für Weiterbildung ausreichend keine keine explizite Aussage keinen klare Weiterbildung mit praktischen Nutzen, d.h. eher in Szenarien aus fachlicher Anforderung und technischen Umgebungen, z.b. Bankenumfeld, große Datenmengen, hohe Sicherheit und über Systeme verkettete Prozesse. konkrete Praktische Beispiele Lernen aus den andern Ingenieurwissenschaften und deren Industrien, die schon länger QM durchführen: Nahrungsmittelindustrie, Maschinenbau,... Informatik leidet an "not invented here"-syndrom, während andere Industriezweige viel mehr auf Standards zurückgreifen. Alleinstellungsmerkmal Tester als Ausbildungsberuf schaffen als Fachkraft ohne vorher Entwickler gewesen zu sein. Management Medizintechnik Mehr Angebote, weitaus praxisnähere Ausbildung Mehr Seminare für Advanced Level mehr Sensibilisierung für das Testen generell. Test first - kein Code ohne Test. Methodenwissen möglichst direkt umsetzbare Schulungsinhalte für alle Rollen in Projekten Momentan kein Bedarf Nein Neue/andere Testmethoden Produktspezifische Testmethoden (ERP, Versicherungsrechner, Web-Shop etc.) spezifische Testmethoden für bestimmte Technologien nicht nur Kompetenzen, sondern Anwendungssicherheit vermitteln Notwendigkeit von Tests - einem 'Manager' verständlich machen können (langfristiges Kosten-Nutzen-Verhältnis) - einem Entwickler verständlich machen (langfristig keine Mehraufwand) Nur organisationsangepasste QS-Konzepte und -Vorgehensweisen für unser Haus entsprechend geltender oder verbreiteter Standards. oft testen Mitarbeiter aus den Fachabteilungen. Eine auf sie zugeschnittene Weiterbildung. Online-basierte Seminare, Fernschulangebote, anerkannte, etablierte Zertifikate! Lernsoftware Pragmatischer Testansatz: Aufwand/Kosten im Verhältnis zum Schaden den ein Fehler verursachen kann (Beispiel: Auto-Pilot mit Gefährdung von Menschenleben im Gegensatz zu einem Unterhaltungsspiel). Praktische Anwendung von Tools praxisbezogen, prozessbezogen... Praxisbezug, Beispiele Praxisnahe Testmanager-Schulungen (ISTQB AL TM ist hier zu abgehoben) Schulungen für Last- und Performanztests Schulungen für Offshore-Test-Governance praxisnaher Überblick neuer Methoden

268 252 Problem: wenn man den Foundation Level nach altem Lehrplan gemacht hat, passen die Begriffe teilweise nicht mehr zum neuen Plan Die Qualität des Kurses ist extrem abhängig vom Kursleiter / Referenten. Wenn dieser nur die 1000 Folien auflegt, bringt der Kurs nicht viel Mehrwert Professionalsierung/Ausbildung von Personen ausserhalb zentraler QS Abteilung Programmiererfahrung und fachliches Know-How sind zwingend erforderlich, um sich sinnvoll als Tester zu spezalisieren. projektbezogene themenstellung und erwarbeitung der lösungen im team mit anderen testern -Qualifizierung muss integraler Bestandteil der Anforderungen beim Auftraggeber sein -Software muss strengen Qualitätsregeln entsprechen zu denen auch die Qualifizierung des Produktionspersonals gehört Qualität der Hochschulabsolventen Reine Testingenieure, Effizient Testen, Integrierte Tests Reporting, Risikomanagement für Testmanager, Soft-Skills für Testmanager Requirements Requirements Engineering Requirements engineering Risikomanagement, Anforderungsmanagement Risikomanagment in Soft/Firmwareprojekten Schätzungen schon erwähnt Sehe keinen Bedarf, der Markt ist sowieso schon überfüllt Senior & C-Level Kommunikation Sensibilisierung des Managements -> Budget für Weiterbildung Sensibilisierung der Entwickler -> Bedarfsanforderungen Sensibilisierung und Wertschätzung von Test(verfahren) beim Management. Sicherheitstest Software allgemein Softwarearchitektur, Testmetriken, Clean Code Softwarearchitekturen, Pattern, Anti-Pattern, Grundwissen Softwarequalität, Prozesse, Objektorientierte Programmierung Softwaretest für Top Management, Testautomatisierung, Anforderungsmanagement Spezialisierung der Qualitätsmitarbeiter in EW Bereichen Spezialisierungen - nicht nur Breitenwissen wie beim ISTQB spezielle Ansprüche für sicherheitsgetriebene Softwareentwicklung für embedded Systems Stärkere Einbeziehung neuer Prozesse und Methoden wie z.b. agiles Testvorgehen in den Advanced Level Regelmäßiges Update der Schulungsinhalte (scheint über Jahre gleich zu bleiben und wirkt daher nicht immer zeitgemäß) Stärkerer Fokus auf Agiles Testen: welche Metriken sind dabei noch gut einsetzbar? wie kann die Dokumentation gültig gehalten werden? Systematische Testfallermittlung bei Entwicklern. Sinn des Testens beim Management Systematisierung des Testmanagements Systemqualität, Servicequalität

269 253 Teilweise haben die Schulungsleiter zur ISTQ Zertifizierung überhaupt keine Ahnung von dem was sie Erläutern sollten. In einem Fall mussten die Teilnehmer dem Mann seine Folien erklären bzw. Fehler in den Folien aufdecken... Die Schulungsanbieter sollten besser qualitätsgesichert werden. Test Automation, BDD Test in einer SOA; Testdatenmanagement (projektübergreifend) Testautomatisierung Testautomatisierung Testautomatisierung, Testautomation Testdriven Development, SCRUM, Clean Code Testen auf Basis von Anforderungen (Systemebene) automatisiertes Testen im Embedded Systemen Beobachten von Reaktionen in embedded Systemen (Target) Grenzen der Simulation in embedded Systemen Testen in agilen Prozessen Tester ist nicht gleich Tester. Hier gibt es vor allem auch noch Aufklärungsbedarf. Das Niveau ist sehr unterschiedlich und muss je nach Einsatz unterschiedlich ausgebildet werden. Testfallentwurf Testgetriebene Entwicklung Erstellung von Testtreibern, zur Protokollsimulation Testing in the Cloud Testkonzepte / Planung Testkonzepte erstellen Testkonzeptionierung Berücksichtigung von QS-Maßnahmen in der Projektplanung (für Projektleiter, Programmmanager, Unternehmensmanagement) Trennung von Tests auf Seiten der Auftraggeber und der Auftragnehmer (unterschiedliche Schwerpunkte und MEthoden) Testmanagement während des laufenden Projekts Testmanager, Tester, Testautomatisation Testmethoden, Tester Soft Skills Testen im agilen Umfeld Testprozess Verbesserung, Modellbasiertes Testen, Testmethodik Test-Requirements definieren Tests von embedded Systemen benötigen nicht nur strukturierte Tests, sondern immer auch Intuitive, die stark persönlichkeitsbezogen sind. Für diese Tätigkeiten gibt es kaum Massnahmen. Es findet jedoch immer auch eine "Abnützung" durch wiederholende Tätigkeiten und Zeitmangel statt. Hier fehlt das Verständnis für eine äusserst wichtige, jedoch nicht "akademisch argumentierende" Tätigkeit. Testtools; Unit Testing Testtoolschulung, ISTQB-Ausbildung Testverfahren, Testwerkzeuge, Qualitätssteigerung Testwerkzeuge und Vorgehen Testwerkzeuge, -verwaltung Tiefergreifende Themen (Cuncurrency, High Performance, Cloud ect. ). SW-Architekturen, System-Architekturen.

270 254 Tool Schulungen Testtheoretische Schulungen, z.b. ISTQB CT Programm, TMAP, TPI agile SW-Entwicklung Vorgehensmodelle, z.b. SCRUM Toolanwendung Toolchain, Integration von Testwerkzeugen mit anderen Entwicklungswerkzeugen Überall UML, Modellierung, Teststragien Umsetzung des Gelernten in die Praxis im Betrieb. Überzeugung der Entscheider, die zumeist solche Ausbildungen nicht mitmachen. Unit-Testing, Refactoring zu testbaren Modulen Erstellen von testbaren Spezifikationen UnitTests stärker in Studium/Ausbildung fördern Testen (speziell UnitTests) auch in der Ausbildung von Personal auf Management Ebene fördern UserGroups, Testing Dojos, Peer-Ausbildung über ein Master-Apprentive Modell von 0 an weg weg vom ISTQB, hin zu einer wissenschaftlich und praxisorientierten Aus- und Weiterbildung. Weg von der theoretischen zur praxisorientierten Ausbildung Weitere ASQF-Fachgruppen Treffen Wie man sinnvolle Testfälle erstellt und welche Aufgaben hier von Beginn der Anforderung an von welchen Rollenträgern zu erfüllen sind. Wie sieht Testing konkret in einem Testing-Musterprojekt aus. Wie werden Werkzeuge in diesem Musterprojekt angewandt. Welche Tools und Techniken gibt es noch, was ich in einem Projekt einsetzen kann. Wie verkaufe ich intern Qualitätsmanagement Wissensvermittlung ist gut, aber Handlungsorientierung ist wichtiger zielgerichtet Testmethoden / Entwicklungsansätze Tabelle 4-172: Antworten zu Frage 10.5

271 255 Fragenkomplex 11 Zur Person Frage 11.1 Geschlecht Geschlecht? Tabelle 4-173: Geschlecht Abbildung 4-161: Geschlecht

272 Frage 11.2 Berufserfahrung in der Industrie Wie umfangreich ist Ihre Berufserfahrung in der Industrie? Tabelle 4-174: Berufserfahrung Abbildung 4-162: Berufserfahrung

273 Frage 11.3 Land der Beschäftigung In welchem Land sind Sie beschäftigt? Tabelle 4-175: Land der Beschäftigung / Tätigkeit Abbildung 4-163: Land der Beschäftigung / Tätigkeit

274 Frage 11.4 Ausbildung Welche Ausbildung haben Sie? Tabelle 4-176: Art der Ausbildung Abbildung 4-164: Art der Ausbildung

275 Frage Studienrichtung Welche Studienrichtung haben Sie studiert? Tabelle 4-177: Studienrichtung Abbildung 4-165: Studienrichtung