ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
•Als PPTX, PDF herunterladen•
2 gefällt mir•3,217 views
Das Testmanagement wird im agilen Entwicklungsprozess wie Scrum vom Team getragen. Doch kann das Scrum-Team die Aufgaben eines Testmanagers vollumfänglich wahrnehmen? Der Vortrag folgt den Aufgaben des Testmanagers und vergleicht die Umsetzung in klassischen und agilen Arbeitsumfeldern. Am Ende steht die Frage, ob man in Scrum noch einen Testmanager braucht. Referenten: Kay Grebenstein, Saxonia Systems AG René Spengler, ANECON Software Design und Beratung GmbH
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
Ähnlich wie ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager? (20)
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
- 1. Herzlich Willkommen Fachgruppe Software-Test, Dresden Thema: Testmanagement und Agile Testing – klassische Vorgehensweise vs. Agile Referenten Kay Grebenstein (Saxonia Systems AG) kay.grebenstein@saxsys.de René Spengler (ANECON Software Design und Beratung GmbH) rene.spengler@anecon.com
- 2. innovativer Knowhow-Transfer • Über 100 Veranstaltungen jährlich • 12 Fachgruppen mit 36 Regionalgruppen • Publikation von Fachwissen
- 3. grenzenloser Wissensvermittler • internationale Standards • netzwerkübergreifende Kommunikation • Gesellschafter des iSQI
- 4. attraktives Kompetenznetzwerk • Über 1.250 Mitglieder im DACH-Gebiet • 66 aktive Fachgruppenmitarbeiter • Netzwerk von fast 10.000 deutschsprachigen Kontakten © Ridofranz_istockphoto.c om
- 5. Die ASQF-Themen in Deutschland, Österreich und Schweiz Agilität Automatisierung Automotive Medizintechnik Modellierung Mobile Quality Crews Projekt Management Requirements Engineering Safety SOA/MW Software-Test Software Product Management
- 6. SQ-Magazin, Ausgabe September Auch zum DOWNLOADEN unter www.asqf.de • SQ-Mag Thema: Erfolgreich mit agilen Methoden • Titelthema: Sind Sie agil genug? • Ergebnisorientierte Entwicklung mit agilem Projektmanagement • Erfolgreich umsteigen – Was Unternehmen bei der Einführung agiler Methoden beachten müssen • Daten erfolgreich immigrieren • Mobile First – Ein cleveres Webdesign führt zu höheren Verkaufszahlen im E-Commerce • 6th World Congress for Software Quality Mitglieder erhalten das Magazin per Post Nicht-Mitglieder können ein Probeabo für 2 Ausgaben anfordern
- 7. Arbeitskreis Software-Qualität und -Fortbildung FACHGRUPPEN Eine Auswahl der nächsten Fachgruppentermine 11.11.2014: Testing - Day Niedersachsen, Gifhorn, 09:00 – 16:30 Uhr 02.12.2014: 2. ASQF Modeling Day, Nürnberg, 08:00 – 20:00 Uhr 04.12.2014: ASQF Quality Day Berlin, 09:00 – 17:00 Uhr u.v.m. - weitere Veranstaltungen und die Veranstaltungsorte finden Sie unter www.asqf.de
- 8. Vorteile der ASQF-Mitgliedschaft Der ASQF – Ihr Netzwerk für Software-Qualität und -Fortbildung Preisnachlass auf Zertifizierungsprüfungen aus dem iSQI-Portfolio, z.B.: ISTQB® Certified Tester | IREB® Certified Professional for Requirements Engineering | iSQI® Certified Professional for Project Management | iSQI® Certified Model Based Tester | uvm. Vergünstigungen auf Konferenzen, z.B.: Agile Testing Days | ASQT | ATAMI | Expertensymposium | iqnite | MED.Software | Objektspektrum Information Days | ReConf | Software Quality Days | uvm. Exklusiver Zugriff auf alle Vorträge aus den ASQF-Fachgruppen und ASQF-Days Kostenlose Teilnahme an allen ASQF-Days und Fachgruppen. Aktive Mitarbeit in den Fach- und Arbeitsgruppen. Abonnement des SQ-Magazins. Ein Netzwerk von über 1.250 Qualitäts-Experten. Werden auch Sie ein Teil davon!
- 9. Wir wünschen Ihnen einen angenehmen und informativen Abend Ihr ASQF e.V. Kontakt Fachgruppenleiter: Matthias Schneider (T-Systems Multimedia Solutions GmbH) matthias.schneider@asqf.de -------------------------------------- stellvertretender Fachgruppenleiter: Michael Kieser (Saxonia Systems AG) michael.kieser@saxsys.de
- 10. Herzlich Willkommen Fachgruppe Software-Test, Dresden Thema: Testmanagement und Agile Testing – klassische Vorgehensweise vs. Agile Referenten Kay Grebenstein (Saxonia Systems AG) kay.grebenstein@saxsys.de René Spengler (ANECON Software Design und Beratung GmbH) rene.spengler@anecon.com
- 11. Testmanagement und Agile Testing Ausgangssituation (I) http://www.softwaretest-umfrage.de
- 12. Testmanagement und Agile Testing Ausgangssituation (II) - Aus dem Agilen Manifest von Ken Schwaber und Jeff Sutherland (2001): Individuen und Interaktionen gelten mehr als Prozesse und Tools. Funktionierende Programme gelten mehr als ausführliche Dokumentation. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.
- 13. Testmanagement und Agile Testing Die Frage Klassische Vorgehensweise Agile Vorgehensweise Agile Transition Grenzbetrachtung
- 14. Testmanagement und Agile Testing klassisches Projektvorgehen (V-Modell) aus Sicht des Test Anforderungs-definition Funktionaler Systementwurf Technischer Systementwurf Komponenten-spezifikation Implementierung Abnahmetest Integrations-test Systemtest Komponenten-test Validierung Verifikation Vorbereitung Abnahmetest Vorbereitung Systemtest Vorbereitung Integrations-test Vorbereitung Komp.-test
- 15. Testmanagement und Agile Testing klassisches Projektvorgehen (V-Modell) aus Sicht des Test Anforderungs-definition Funktionaler Systementwurf Technischer Systementwurf Komponenten-spezifikation Implementierung Abnahmetest Integrations-test Systemtest Komponenten-test Validierung Verifikation Vorbereitung Abnahmetest Vorbereitung Systemtest Vorbereitung Integrations-test Vorbereitung Komp.-test T T PL ges. E E E E T T PL E Gesamtprojektleiter E E E E TM
- 16. Strategische Ebene Operative Ebene Testpolitik Qualitäts-management Qualitäts- und Testrichtlinie Integration von Referenz-modellen und Standards Testprozess-optimierung Standards, Normen und Methoden Test Process Improvement (TPI) Schulung und Zertifizierung Testprojekt-leitfaden Methoden und Standards Teststufen-planung Risiko-planung Testrahmen und –Umgebung Automation und Tools Metriken Test-konzeption Test-konzept Test-strategie Qualitäts-merkmale Testzyklen und Meilensteine Zeit- und Res-sourcenplanung Pass-Fail- Kritierien Infrastruktur Dokumentation Test-umsetzung Teststufen-planung Testimplemen-tierung Struktur- /Spezifikations-orientierte Verfahren Komponenten-, Service- und Oberflächentests Verifikation und Validierung Test-management Projekt-/Test-organisation Testzyklus-management Risiko-analyse und –bewertung Test-evaluierung Test-priorisierung Qualitätsgrad-bemessung Abweichungs-management Berichtswesen / Dokumentation Testmanagement und Agile Testing Aufgaben des Qualitäts- und Testmanagers
- 17. Testmanagement und Agile Testing Klassische Vorgehens-weise Agile Vorgehens-weise Agile Transition Grenz-betrachtung
- 18. Testmanagement und Agile Testing Product Backlog Sprint Backlog Shippable Product Daily Scrum Meeting 24 h 2 – 4 weeks Agile Vorgehensweise
- 19. Testmanagement und Agile Testing Product Backlog Sprint Backlog Shippable Product Daily Scrum Meeting 24 h 2 – 4 weeks T E T E E E PO SM Agile Vorgehensweise
- 20. Testmanagement und Agile Testing Agile Vorgehensweise Analyse Design Entwicklung Test Iteration 1 Iteration 2 Iteration 3 D C C A B A B A B Agile Wasserfall
- 21. Testmanagement und Agile Testing 24 h 2 – 4 weeks PO Agile Vorgehensweise 24 h 2 – 4 weeks PO 24 h 2 – 4 weeks SM PO PO Product Backlock, BurnDownChart, Iteration Plan User Stories, Code, Tests, Bugs, Doku E T User Stories, Code, Tests, Bugs, Doku User Stories, Code, Tests, Bugs, Doku T E T E E E T E E E T E T E E E SM SM SM
- 22. Testmanagement und Agile Testing Klassische Vorgehens-weise Agile Vorgehens-weise Agile Transition Grenz-betrachtung
- 23. Testmanagement und Agile Testing Tests in Agile umsetzen TestSteuerung TestPlanung TestAnalyse & TestDesign Test- Durchführung Auswertung & Bericht der tests TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF Testprozess nach International Software Testing Qualifications Board (ISTQB): • Die Test erfolgen nach der eigentlichen Entwicklung als “abgeschlossenes” eigenes Projekt in einer “abgeschlossenen” eigenen Organisationseinheit (Testteam). • Der Testmanager erstellt einen Projekttestplan (Testkonzept), welcher Testzeitrahmen, Testfokus, Testaufgaben und Testressourcen definiert. • Das Testteam erstellt solange Testfälle bis der Testfokus abgedeckt ist • Das Testteam führt (versucht) alle vordefinierten Testfälle durch(zuführen) • Die Design- und Durchführungsphase wird vom Testmanager überwacht und gesteuert. • Der Testmanager kann (jederzeit) Auskunft Kennzahlen über Fortschritt der Tests und Qualität der Software liefern Testbericht Testkonzept
- 24. Agiler Test- und Entwicklungsprozess: • Tester sind Teil des Teams • Das Team analysiert die Aufgabe, entwickelt die Story, welche auch Akzeptanzkriterien enthält • Entwickler testen auf Code-Level und Tester fokussieren sich auf höhere Tests • Der Testfokus wird durch Explorative Tests erweitert • Die Tests finden jederzeit statt • Das Team ist für die eigene Qualität verantwortlich. • Die Tester treten für die Qualität ein und fördert Aktivitäten, die die Qualität ausbauen (wie acceptance criteria, unit testing, automated acceptance testing, story testing and exploratory testing) • Die Tester sind für die Verwaltung ihrer eigenen Tests verantwortlich. Testmanagement und Agile Testing Tests in Agile umsetzen Planning Steuerung Abschluss Analyse & Design der Story Entwicklung (CodTesten)
- 25. Klassischer Tester • Blackbox getrieben • meist Manuell (evtl. Automatisierung im Regressionstest) • Geschäftsprozess-orientiert • häufig nur die oberen Teststufen (Systemtest, Abnahmetest) Agiler Tester • CI / CD • Stagging Process • Manuell und Automatisiert • Komplete Testpyramide • Unit-, Service- und System-Tests Testmanagement und Agile Testing Der Agile Tester
- 26. Programmieren Testmanagement und Agile Testing Testen Domäne Der Agile Tester
- 27. Strategische Ebene Operative Ebene Testpolitik Qualitäts-management Qualitäts- und Testrichtlinie Integration von Referenz-modellen und Standards Testprozess-optimierung Standards, Normen und Methoden Test Process Improvement (TPI) Schulung und Zertifizierung Testprojekt-leitfaden Methoden und Standards Teststufen-planung Risiko-planung Testrahmen und –Umgebung Automation und Tools Metriken Test-konzeption Test-konzept Test-strategie Qualitäts-merkmale Testzyklen und Meilensteine Zeit- und Res-sourcenplanung Pass-Fail- Kritierien Infrastruktur Dokumentation Test-umsetzung Teststufen-planung Testimplemen-tierung Struktur- /Spezifikations-orientierte Verfahren Komponenten-, Service- und Oberflächentests Verifikation und Validierung Test-management Projekt-/Test-organisation Testzyklus-management Risiko-analyse und –bewertung Test-evaluierung Test-priorisierung Qualitätsgrad-bemessung Abweichungs-management Berichtswesen / Dokumentation Testmanagement und Agile Testing Testmanagement in Agile umgesetzen
- 28. ssss ssss Geschäfts-führung CIO CQO Stetiger Wandel Kundenbedürfnisse Technologien Wettbewerber Firma Vertrieb Einkauf Facility Management Personal-management Qualitäts-management Testpolitik Testprozess-optimierung Testprojekt-leitfaden Strategische Ebene Testmanagement und Agile Testing Qualitätsmanagement
- 29. ssss ssss Geschäfts-führung CIO CQO Testmanagement und Agile Testing Verantwortung für Qualitätsmanagement SM T T PO E E E E Firma Vertrieb Einkauf Facility Management Personal-management Qualitäts-management Testpolitik Testprozess-optimierung Testprojekt-leitfaden Strategische Ebene
- 30. Operative Ebene Test-konzeption Test-umsetzung Test-management Product Backlog Sprint Backlog Shippable Product Daily Scrum Meeting 24 h 2 – 4 weeks E T PO T E E E SM Testmanagement und Agile Testing Agile Operative Ebene
- 31. Klassisch Scrum TM Produ ct Backl og Sprint Backl og Shippab le Product Daily Scrum Meeting 24 h 2 – 4 weeks E T PO T E E E SM T T T T T T Agile Werkzeuge Testmanagement und Agile Testing Agile Transition der operativen Ebene
- 32. Testkonzeption Testumsetzung Testkoordination Klassisch Scrum Test-konzept Test-strategie Qualitäts-merkmale Testzyklen und Meilensteine Zeit- und Res-sourcenplanung Pass-Fail- Kritierien Infrastruktur Plannin g Sprint Planning DoD Dokumentation Story Release Plannin g Meeting Releas e Daily Backlog Groomin g Planning DoD Klassisch Scrum Klassisch Scrum Teststufen-planung Testimplemen-tierung Struktur- /Spezifikations-orientierte Verfahren Komponenten-, Service- und Oberflächentests Verifikation und Validierung Projekt-/Test-organisation Testzyklus-management Risiko-analyse und –bewertung Test-evaluierung Testpriorisierung Qualitätsgrad-bemessung Abweichungs-management Berichtswesen / Dokumentation Test- Pyramide Plannin g Sprint Plannin g Test- Automation Releasetes t Test- Pyramide Story Daily Backlogs Sprint Releas e Daily Backlog Groomin g Burn- Down Story Retro-spektiv e DoD Story ZeroBu gPolicy DoD Backlogs Test- Pyramide Supported by Maria Bär Testmanagement und Agile Testing Agile Transition der operativen Ebene
- 33. Testmanagement und Agile Testing Die Frage
- 34. Testmanagement und Agile Testing Klassische Vorgehens-weise Agile Vorgehens-weise Agile Transition Grenz-betrachtung
- 35. Klassische Entwicklung • Regressionstests sind Bestandteil der entsprechenden Teststufe im Testzyklus • Testautomatisierung sollte für „stabile“ Systeme im Regressionstest eingesetzt werden Agile Entwicklung • Eingliederung von Regression und Integrationstest stellt durch die festen Sprintzyklen eine Herausforderung dar • Testautomatisierung ist zwingend notwendig, setzt aber auch einen hohen Reifegrad der (Test- )Prozesse voraus Testmanagement und Agile Testing Regressionstests und Testautomatisierung
- 36. Klassische Entwicklung • Die Entwicklungs-ergebnisse werden immer zusammen in der Testphase validiert • Unabhängig von der gewählten Integrationsstrategie, ist es möglich immer die Gesamtheit des Produktes zu validieren Agile Entwicklung • Die unterschiedlichen Scrum-Teams müssen aktiv durch Stageing, CI und CD sowie Kommunikation um eine Integration der Ergebnisse kümmern • Ggf. ist es notwendig einen extern Integrationstest parallel zu den Sprints durchzuführen Testmanagement und Agile Testing große Projekte und/oder hohe Integration
- 37. Agile Entwicklung • Product Owner • Product Backlog ist jederzeit anpassbar und durch Priorisierung werden die wichtigsten Punkte in das Sprintbacklog übernommen • Team übernimmt im Sprintplanning die Stories vom Product Owner Klassische Entwicklung • Geänderte bzw. unzureichende Anforderungen führen automatisch zu Verzögerungen und BudgetübERschreitung Testmanagement und Agile Testing Anforderungsgüte
- 38. Agile Entwicklung • Durch fertige Kennzahlen, wie z.B. Burn-Down-Charts ist jederzeit ein aktueller Überblick über den Stand der Entwicklung möglich • Durch Iterationen und gleichbleibende Zusammenstellung des Teams ist eine Vergleichbarkeit und damit eine Aussage über die Entwicklung möglich Klassische Entwicklung • TM holt Ergebnisse und Metriken ein -> TM ist somit nicht immer aktuell aussagekräftig • Trends und Vorabanalysen sind nur vage möglich Testmanagement und Agile Testing Kennzahlen
- 39. Agile Entwicklung • Ein Sprint ist immer gleich lang und am Ende steht ein fertiges Produkt Klassische Entwicklung • Sequenzielle Abarbeitung der Schritte kann bei Verzögerungen in den Vorhergehenden Stufen zu Beeinflussung der Testdurchführung führen Testmanagement und Agile Testing Projektverzögerungen
- 40. Testmanagement und Agile Testing
- 41. Testmanagement und Agile Testing
Hinweis der Redaktion
- Der ASQF veranstaltet branchenübergreifende Netzwerkveranstaltungen in Form von Abendveranstaltungen Diskussionsrunden Arbeitsgruppen Tageskonferenzen Hierfür hat der ASQF 12 aktive Fachgruppen mit 36 Regionalen Gruppen eingerichtet, die sich unterteilen lassen in: klassische SW-Prozessthemen branchenspezifische Themen Spezialthemen aus dem technologischen oder auch methodischen Bereich Innovativ heißt in diesem Zusammenhang: Schon heute das Wissen von morgen zur Verfügung stellen. GANZ NEU: Mobile Quality, in Berlin und Wien. Weitere Gründungen für München und Nürnberg geplant. Oder aber das wichtige Querschnittsthema „Software Product Management“. Ziel ist es, den einzelnen Fachleuten praktische Erfahrungsberichte an die Hand zu geben. Information ist ein immaterielles Gut: Es ist überall und jederzeit auf der Welt verfügbar. Aber auch nutzbar und vor allem vergleichbar? Der ASQF macht mit seinen Themen das SQ-Wissen nutzbar/ anwendbar. Anerkannte Referenten geben in den Veranstaltungen ihr Knowhow über neue Trends, Technologien und Erfahrungen weiter. SQ-Magazin: Der ASQF ist Herausgeber des SQ-Magazins. Das Magazin berichtet quartalsweise zu aktuellen Themen mit Bezug zu Software-Qualität und veröffentlicht unabhängige Fachberichte und Forschungsergebnisse. Das deutschsprachige Magazin richtet sich vor allem an Experten aus dem Bereich der Softwareentwicklung und Qualitätssicherung. Wissen muss aber auch nachhaltig zur Verfügung stehen. nächste Folie DETAILS (ggf. weg lassen…): Die Teilnahme an einer ASQF-Veranstaltung ermöglicht u.a. Wissensgewinn einen Blick über den eigenen Tellerrand Kontakt zu Mitbewerbern und branchenfremden Fachleuten aus dem selben Themengebiet So läuft die Arbeit in einer Fachgruppe ab: 4-6 Fachgruppentreffen pro Jahr pro Region pro Thema Tageszeit der Treffen ca. 17/18 bis ca.19/20 Uhr An den Treffen kann grundsätzlich jeder, unabhängig von einer Mitgliedschaft teilnehmen Pro Treffen werden bestimmte Themen per Vortrag erläutert. Anschließend folgt eine moderierte Diskussion. Im Anschluss wird die Diskussion idR in geselligem Beisammensein mit offenem Ende weitergeführt Die einzelnen Präsentationen und Vorträge stehen den Mitgliedern im Internet zur Verfügung. Die Days sind themenorientierte Tageskonferenzen. Sie Sind Leuchttürme, die die Fachkompetenz einer oder mehrerer Fachgruppe in einer bestimmten Region bündeln. Sie sollen zum einen den Knowhow Transfer innerhalb einer Region befördern, aber auch nach außen strahlen!
- Arbeitsgruppen und Boards: Der ASQF arbeitet zusammen mit den im ASQF versammelten Experten stetig an der Entwicklung und Weiterentwicklung von Standards im Umfeld von Softwarequalität. Der „ASQF-Certified Tester“ ist eines der erfolgreichsten Beispiele. Aktuell betreut der ASQF als Board den ASQF Certified Professional for Project Management. Ein Schema, das sich bereits seit 2004 mit den speziellen PM-Anforderungen in Software-Entwicklungsprojekten (Fokus Faktor Mensch) auseinandersetzt. Im Rahmen der Arbeitsgruppe Testdatenmanagement (aktuell 20 aktive Mitglieder) engagiert sich der ASQF für die Entwicklung eines Standards im Bereich Testdatenmanagement. iSQI: Noch wichtiger sind aber vor allem die Möglichkeiten und Chancen, die sich im Zusammenspiel mit dem iSQI für die ASQF-Community ergeben. Das iSQI ist auf allen Kontinenten, in 90 Ländern und mit 10 Sprachen auf der Welt im Bereich „SQ“ unterwegs. Dieses international ausgerichtete Institut ermöglicht es dem ASQF kontinuierlich, Qualitätstrends aus der ganzen Welt aufzunehmen und weiterzugeben. Vor allem was die Vergleichbarkeit und Standardisierung von Wissen betrifft, hat das iSQI mit seiner Marktposition und den iSQI-High-Five-Kriterien eine herausragende Rolle inne, die der ASQF-Community zu gute kommen. Netzwerkübergreifend: Der ASQF arbeitet dort wo es vor allem für die Community sinnvoll und notwendig ist mit Partner-Netzwerken und Institutionen zusammen. Angefangen von Kooperationen mit relevanten Forschungseinrichtungen wie den Fraunhofer Instituten, über zahlreiche Universitäten (Berlin, Erlangen, Wien, Innsbruck) bis hin zu Verbänden wie die GI, dem STEV oder aber, das ist zumindest das Ziel, der SAQ in der Schweiz. Ein Netzwerk muss offen sein, und zwar in alle Richtungen. Das ist der ASQF nächste Folie
- Global-Player-Unternehmen wie Siemens, IBM, Microsoft oder T-Systems … leistungsstarken Mittelständlern wie der SQS AG, Evosoft, Atos, Capgemini … Hochschulen und Forschungseinrichtungen wie der FAU Erlangen-Nürnberg, TU Dresden, FH Wien, FH Brandenburg, FU Berlin, Fraunhofer IIS (hat MP3 erfunden), FOKUS oder ESK aber vor allem engagierten Fachleuten Das alles zusammen ergibt ein sehr aktives Kompetenznetzwerk von fast 10.000 SQ-Experten. Welchen ZWECK verfolgen wir mit dem ASQF: Kontakte und Erfahrungsaustausch Fortbildung zum Thema Software-Qualität Bildung von Standards und Normen gezielte Anstöße zur Verbesserung des Softwareentwicklungsprozesses Das machen wir über einen innovativen Knowhow-Transfer nächste Folie
- Konkret sind das folgende Fachgruppen: Für Ihre Standorte in Karlsruhe und München stehen ihnen folgende drei Fachgruppen zur Verfügung. Wir planen aktuell in BaWü eine FG RE und Agilität! In München eine zusätzliche RFG Agilität! Wer von Ihnen also Interesse hat, eine solche Fachgruppe mitzugestalten, kann sich gerne an mich wenden!
- Rene: Es gibt Immer mehr agile Entwicklungsprojekte (siehe Softwareumfrage) Umfrage aus dem Jahr 2011 Insgesamt 1.623 Personen (77% DE, 13% CH, 10% AT) Unterschiedliche Rollen bis zu 100 Fragen PL, QMB, TM, T (Tester) BA, DEV, Support (Entwickler) Executive und mittleres Management (Manager) Ein Komplex beschäftigte sich mit den Vorgehensmodellen Fazit: überwiegend klassisches phasenorientiertes Vorgehen (davon >36% nach V-Modell, >22 eigenes Phasenmodell, >13 % W-Modell, 10% Wasserfall) agiles Vorgehen (57% Scrum, 27% eigenes Modell, >5,2% feauture driven, … Interessant, aber nicht zum Thema heute: Vorstudie: QS: 39,5% Ablehnung QS: 38,7% Fachkonzept: QS: 58,8% Ablehnung QS: 16,0% Systementwurf: QS: 60,7% Ablehnung QS: 13,8% Realisierung: QS: 84,0% Ablehnung QS: 5,1% Integration: QS: 87,0% Ablehnung QS: 3,3% Abnahme: QS: 90,1% Ablehnung QS: 3,5%
- Kay: Erklären des agilen Manifest Neue Herausforderungen an Firmen, Entwickler und Tester
- René: Frage: Brauchen wir im agilen Entwicklungsprojekten noch einen Testmanager? um diese Frage zu klären schauen wir uns die Vorgehensweisen an und eine mögliche Transition, sowie die verbleibenden Herausforderungen!
- René: Links: konstruktiver Ast Rechts: validierender/prüfender Ast Frage: Wann ist eine Anforderung endgültig definiert? Fehlerfall im Abnahmetest lässt laut Modell einen Rücksprung zur Anforderungsdefinition zu, danach sind alle Phasen erneut zu durchlaufen
- René und Kay abwechselnd:
- Kay übernimmt mit nächsten Folien Die Abarbeitung der einzelnen Aufgaben erfolgt sequentiell: Erstellung des Testkonzept Testumsetzung nach Abnahme des Testkonzeptes (Detailplanung, Beschaffung und Einrichtung der Infrastruktur, Testfallentwurf, Testdurchführung) Steuernde Aktivitäten sind ein begleitende Tätigkeiten: Überwachung und Einleitung entsprechender Maßnahmen Abweichungsmanagement und Reporting Die TM-Aktivitäten im klassischen Testprojekt sind klar zugeordnet
- Kay:
- Kay:
- Kay:
- Kay:
- Kay übernimmt mit nächsten Folien
- René: erklärt Testprozess
- Kay erklärt änderungen in agilen
- Rene: erklärt Klassichen testers Kay: Erklärt Agilen
- Kay erklärt vertieft agilen / technsichen Tester
- Rene stellt nochmal Aufgaben des testmanagers vor
- Kay erklärt strategische Ebene
- Kay: Und verweist auf Verantwortung der Geschäftsleitung
- Rene: Aber die operative Ebene macht dann das Team, oder? Kay: Ja Rene: Aber wie
- Kay: Erklärt Weg vom Testmanager zum Team das agile Werkzeuge von Scrum nutzt
- Kay: Stellt Bild vor und Rene stellt fragen René: Wie wird die „Bibel“ des Testers (das Testkonzept inkl. seiner Bestandteile [Testplan, Teststrategie, zu testende Qmerkmale) in Scrum umgesetzt? Kay: Erklärung René: Häufige Annahme Agiles Vorgehen = keine Dokumentation, wie werden die Testfälle, Ausführungen und Ergebnisse dokumentiert? Kay: Erklärung René: Im klassischen Vorgehen gibt es i.d.R. eine Planung für die einzelnen Teststufen. Wie ist das im agilen Vorgehensmodell umgesetzt? Kay: Erklärung René: Im klassischen Vorgehen gibt es viele Testfälle, die Anforderungen verifizieren und validieren. Im agilen Vorgehensmodell sind diese nicht vorhanden, wie wird denn da ein Feauture geprüft? Kay: Erklärung René: Im klassischen Vorgehen habe ich regelmäßige (wöchentliche/2wöchentliche) Statusmeetings, zu denen ich die Kennzahlen reporte und eine Risikoanalyse/-bewertung vornehme? Wo finde ich das im agilen Vorgehensmodell umgesetzt? Kay: Erklärung René: Das Abweichungsmgmt. Im klassischen Vorgehen ist ja ganz klar Phasen getrieben (Test Defect Bugfix Deployment Retest) und es werden immer komplette Releases getestet. Und wie funktioniert das agil? Kay: Erklärung René: Wie sieht es mit der Unabhängigkeit des Testens aus? Kay: Erklärung
- Kay: Es lassen sich die Testmanager sparen, wenn konsequent die Agilen Werkzeuge genutzt und gelebt werden … aber es gibt immer Herausforderungen# René: Und wo sind die Ausnahmen/Herausforderungen und Grenzen…
- Kay übernimmt mit nächsten Folien
- Rene: Klassische Entwicklung Regressionstest sind Bestandteil der Testzyklen in den entsprechenden Teststufen Unterstützend wird hier auch Testautomatisierung eingesetzt Kay: Agile Entwicklung Eingliederung von Regression und Integrationstest stellt eine Herausforderung dar Testautomatisierung ist zwingend notwendig, setzt aber auch einen hohen Reifegrad der (Test-)Prozesse voraus
- Rene: Klassische Entwicklung Unabhängig von der gewählten Integrationsstrategie werden alle Entwicklungsergebnisse immer gemeinsam in der Testphase validiert Die Teststufe „Integrationstest“ ist im V-Modell ausdrücklich vorgesehen! Kay: Agile Entwicklung Eingliederung von Regression und Integrationstest stellt eine Herausforderung dar Testautomatisierung ist zwingend notwendig, setzt aber auch einen hohen Reifegrad der (Test-)Prozesse voraus
- Rene: Klassische Entwicklung Die Sequenzielle Abarbeitung der Schritte kann bei Verzögerungen in den Vorhergehenden Stufen zu Beeinflussung der Testdurchführung führen Kay: Agile Entwicklung Eingliederung von Regression und Integrationstest stellt eine Herausforderung dar Testautomatisierung ist zwingend notwendig, setzt aber auch einen hohen Reifegrad der (Test-)Prozesse voraus
- Rene: Klassische Entwicklung TM holt Ergebnisse und Metriken ein und wertet diese aus TM ist somit nicht immer aussagekräftig Durch die unterschiedlichen Ergebnisse in den Testzyklen dind Vorabanalysen nur sehr vage möglich Kay: Agile Entwicklung Eingliederung von Regression und Integrationstest stellt eine Herausforderung dar Testautomatisierung ist zwingend notwendig, setzt aber auch einen hohen Reifegrad der (Test-)Prozesse voraus
- Rene: Klassische Entwicklung …. Kay: Agile Entwicklung Eingliederung von Regression und Integrationstest stellt eine Herausforderung dar Testautomatisierung ist zwingend notwendig, setzt aber auch einen hohen Reifegrad der (Test-)Prozesse voraus
- Schluss: Kay/René: Welches Vorgehensmodell ist dasbessere? hängt von vielen Faktoren ab!