Kay
Grebenstein
Test Manager
/ Coach /
Technical
Champion
QAla kay.grebenstein
@saxsys.de
www.so-geht-
software.de
Das Unternehmen
• IT-Beratungs- und Technologieunternehmen
• Gesamtleistung 2015: 26 Mio. Euro
• 230 feste Mitarbeiter
• 6...
Product
Backlog
Sprint
Backlog
Shippable
Product
Daily Scrum
Meeting
24 h
2 – 4 weeks
PO T
TE
E
E
E
SM
ProjektmanagementPM
Projekt
Management
Plan
Anforderungen
Analyse Entwicklung Test
T
T
T
T
T
T
AN
Code
Tests
TM
E
E E E E
...
Testprozess nach International Software Testing
Qualifications Board (ISTQB):
• Die Tests erfolgen nach der eigentlichen E...
Agiler Test- und Entwicklungsprozess:
• Tester sind Teil des Teams
• Das Team analysiert die Aufgabe, entwickelt die Story...
TM
Produc
t
Backlo
g
Sprint
Backlo
g
Shippable
Product
Daily Scrum
Meeting
24
h
2 – 4 weeks
PO T
TE
E
E
E
SM
T
T
T
T
T
T
A...
Testpolitik
Qualitäts-
Strategie
Qualitäts- und
Testrichtlinie
Integration von
Referenz-
modellen und
Standards
Testprozes...
OperativeEbene
Testkonzeption
Testumsetzung
Test-
management
Product
Backlog
Sprint
Backlog
Shippable
Product
Daily Scrum
...
Testkonzeption Testumsetzung Testkoordination
Testkonzept
Teststrategie
Qualitäts-
merkmale
Testzyklen und
Meilensteine
Ze...
SM
Fachliche
Qualität
Kollaborative
Qualität
Handwerkliche Qualität
Scrum Team
KPO
Projekt Team
Firma
Qualität der
Arbeits...
Estimation Planning 1 Planning 2 Sprint Review
Acceptance
Criteria
Story
Test
Tasks Test-
skripte
Testfälle
Schneiden
Defi...
Sprint-
Backlog
• VCS
• Gemeinsame
Code Basis
• Code Review
• Unit-Tests
• Statische CodeAnalyse
• CI / CD
• Staging:
Prod...
Gemeinsame Definition
von Regeln, Normen und
Abstimmungen des Teams.
 „Definition of READY“
(DoR)
 „Definition of DONE“
...
Product
Backlog
Sprint
Backlog
Shippable
Product
Daily Scrum
Meeting
24 h
2 – 4 weeks
PO T
TE
E
E
E
SM
Agile Werkzeuge und...
Testpolitik
Qualitäts-
Strategie
Qualitäts- und
Testrichtlinie
Integration von
Referenz-
modellen und
Standards
Testprozes...
Testpolitik
Qualitäts-
Strategie
Qualitäts- und
Testrichtlinie
Integration von
Referenz-
modellen und
Standards
Testprozes...
ssss
ssss
Geschäfts-
führung
CIO
CQO
FirmaVertrieb
Einkauf
Facility
Management
Personal-
management
Qualitäts-
management
...
Strategische Ebene Operative Ebene
TM
Klassisch
Strategische Ebene Operative Ebene
Scrum
T
T
SM
PO
Projekt 1 Projekt 2
T
T
SM
PO
T
T
SM
PO
T
T
PO
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
SM
T
T
SM
PO
Projekt 1 Projekt 2
T
T
SM
PO
T
T
SM
PO
T
T
PO
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
SM
Gilde A
Gilde B
Gilde C
Gilde /
Kompetenz
-team
Fachliche
Heimat
Wissens-
management
Weiter-
bildungs-
planung
Coding /
Testing Dojos
Vertriebs-
u...
Kompetenz-
team QA
Strategische
Initiativen
für QA / QM
Wissens-
austausch
Weiter-
bildungs-
planung
Testing Dojos
Projekt...
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016
Nächste SlideShare
Wird geladen in …5
×

Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016

141 Aufrufe

Veröffentlicht am

Agile Verfahren wie Scrum ändern den Prozess der Softwareentwicklung grundlegend, aber ihre Auswirkungen sind nicht nur auf die Softwareabteilungen beschränkt. Am Beispiel der Rolle des Testmanagers und des Testmanagements wird aufgezeigt, dass neben der Umgestaltung der Prozesse und Aufgaben des Entwicklungs- und Testteams auch andere Bereiche des Unternehmens eine agile Transition erfahren müssen, um die effektive Qualitätssicherung der agilen Verfahren sicherzustellen.
Der Vortrag beantwortet als erstes, die Frage „ob ein Testmanager im agilen Projekten benötigt wird“ mit einem klaren Nein und geht dann auf die damit einhergehenden Änderungen für den Test- und Entwicklungsprozess ein. Dazu werden agile Werkzeuge wie Kompetenzteams oder agile Strategiemanagement vorgestellt, die die Lücken des Testmanagers in der Projekt- und Organisationsstruktur schließen. Darüber hinaus wird auf die Problemstellung bei der Arbeit mit mehreren Scrumteams eingegangen und deren Abstimmung.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
141
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
5
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Agile Verfahren wie Scrum ändern den Prozess der Softwareentwicklung grundlegend, aber ihre Auswirkungen sind nicht nur auf die Softwareabteilungen beschränkt. Am Beispiel der Rolle des Testmanagers und des Testmanagements wird aufgezeigt, dass neben der Umgestaltung der Prozesse und Aufgaben des Entwicklungs- und Testteams auch andere Bereiche des Unternehmens eine agile Transition erfahren müssen, um die effektive Arbeit der agilen Verfahren sicherzustellen.
    Der Vortrag beantwortet als erstes, die Frage „ob ein Testmanager im agilen Projekten benötigt wird“ mit einem klaren Nein und geht dann auf die damit einhergehenden Änderungen für den Test- und Entwicklungsprozess ein. Dazu werden agile Werkzeuge vorgestellt, die die Lücken des Testmanagers in der Projekt- und Organisations-struktur schließen aber auch das Management beeinflussen. Darüber hinaus wird auf die Problemstellung bei der Arbeit mit mehreren Scrumteams eingegangen und deren Abstimmung.
  • Vorstellung des Speakers
  • Zahlen, Daten & Fakten über Saxonia Systems AG
  • Wenn notwendig kurz Scrum erklären…
  • Klassische Projekte arbeiten Sequentiell und Arbeitsteilig
  • 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 durchzufü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
  • 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.
    Das Team ist für die Verwaltung ihrer eigenen Tests 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)
    ScrumBoard, Stories und DoD lieferen Auskunft über Fortschritt der Entwicklung + Test
  • Agile Teams beinhalten alle Rollen.

    Das funktioniert leider nicht 1 zu 1 … Da es Unterschieder in der Vorgehensweise gibt
  • Was sind die Aufgaben eines Testmanagers? Um die Fragen zu beantworten, ist es notwendig erst einmal festzustellen, welche Aufgaben ein Testmanager im klassischen Test- und Qualitätssicherungsprozess wahrnimmt. Laut dem International Software Testing Qualifications Board (ISTQB), der Zertifizierungsstelle für Tester, gehen die Aufgaben und Einsatzgebiete des Testmanagers über die Steuerung des Testprojektes hinaus. Er leitet die Testabteilung oder das Testteam und damit die Ressourcen für die Tests. Er erstellt Berichte, eskaliert in Richtung Entwicklung, Fachabteilung und Projektleitung, schätzt Testprojekte, setzt die Einhaltung der Qualitätsprozesse und -verfahren des Unternehmens durch, beschafft die Testing-Tools für die Organisation und überprüft die Testpläne, sowie die Testfälle.

    Die Aufgabenebenen lassen sich in zwei Felder aufteilen: strategisch und operativ (siehe Abbildung 2). Die operative Ebene beschäftigt sich mit der Planung und Konzeption der Testfälle und Tests, der Steuerung der Testdurchführung, sowie der Kommunikation innerhalb des Projektes. Die strategische Ebene beinhaltet die Aufgaben des Qualitätsmanagements.  Besonders in kleinen Unternehmen liegt dies auch beim Testmanager.
  • Die operativen Aufgaben können nicht vom Scrum Master oder Product Owner übernommen werden. Der Product Owner mischt sich nicht in die Umsetzung ein und der Scrum Master nicht in die Entwicklung. Die Testaufgaben werden in der agilen Entwicklung durch das Team übernommen. Und nach der Definition und Aufteilung der Aufgaben des Testmanagers ist es nun möglich zu untersuchen wie diese in den agilen Prozess eingebracht werden können. Es ergibt sich aber ein Problem: Eine klare Zuordnung zu einer Person ist nicht möglich, da in Scrum alle Aufgaben auf das agile Team verteilt werden.
    Die Lösung des Problems liegt im Framework Scrum selbst. Es stellt ein umfangreiches Paket an Werkzeugen und Artefakten bereit. Und diese lassen sich den Aufgaben des Testmanagers gegenüberstellen. Wir haben in unseren Scrum Teams eine vollständige agile Transition[3] der Aufgaben durchgeführt und festgestellt, dass Scrum jeder Aufgabe des Testmanagers ein Werkzeug oder Artefakt gegenüberstellen lässt.
  • Wenn das Team sich die Scrum-Werkzeuge und –Artefakte umsichtig und diszipliniert nutzt, dann wird für die operativen Aufgaben des Testens kein Testmanager mehr benötigt.
  • Beispiel des Testmanagers lässt sich die Herausforderung der agilen Transition sehr schön nachvollziehen. Die Frage lautet: Wenn wir in Scrum keinen Testmanager benötigen, wer übernimmt seine Aufgaben? Der Product Owner? Der Scrum Master? Das Team?
    Nach der Scrum Alliance ist der Product Owner die Person, die für die punktgenaue und pünktliche Erstellung des Produktes verantwortlich ist. Der Product Owner füllt und verfeinert das Product Backlog und stellt sicher, dass jeder weiß was darin enthalten und mit welcher Priorität es versehen ist. Damit ist er in der Regel am nächsten an der „Business-Seite“ des Projekts. Scrum erfordert, dass das Entwicklungsteam eine nach Funktionen gemischte Gruppe ist – die alle notwendigen Fähigkeiten vereint – die für die Entwicklung des Produktes notwendig sind. Das Team organisiert sich selbst: das heißt es wählt selbständig den umzusetzenden Inhalt des Sprints und kümmert sich um die Planung, Steuerung und Umsetzung. Der Scrum Master ist der „Lotse“ durch die Untiefen des Scrum Frameworks. Er hilft dem Rest des Scrum Teams bei der Einhaltung der Scrum-Regeln. Eine weitere Aufgabe des Scrum Masters ist es, Hindernisse für den Fortschritt des Teams aus den Weg zu räumen.

  • Big Picture des Entwicklungsprozesses mit der Testpyramide und Testwerkzeugen…
  • Jeder Aufgabe des Testmanagers lässt sich also ein agiles Werkzeug oder Artefakt gegenüberstellen. Damit ist die vollständige agile Transition der Aufgaben eines Testmanagers erreicht. Unter der Voraussetzung, dass das Scrum Team das notwendige Testwissen für die Umsetzung der anstehenden Entwicklungs- und Testaufgaben besitzt, wird für kleine Projekte kein Testmanager benötigt. Steht das Wissen noch nicht zur Verfügung muss das Team ausreichend gecoacht werden.
  • Ob eine Firma nach klassischen oder agilen Methoden entwickelt, das Qualitätsmanagement bleibt in der Verantwortung der Geschäftsführung des Unternehmens. Dieser Aufgabenbereich kann, sollte und darf nicht vom Scrum Team übernommen werden.
  • Auf den ersten Blick ändert sich grundsätzlich nichts in Organisation und Aufgabenteilung. Auf dem zweiten Blick ergibt sich eine Problemstelle für agile Firmen. In der klassischen Welt diente der Testmanager als Schnittstelle zwischen operativer und strategischer Ebene. Er verteilte die Informationen zwischen dem Management und der operativen Ebene, übermittelte strategische Vorgaben und Methoden in die Testteams oder spielte Entwicklungen und Verbesserungen in Richtung Management.
  • Aber wie kommen Informationen im agilen Umfeld von der strategischen Ebene in die operative und zurück? Die Antwort ist: Die agile Transition ist nicht mit der Zuordnung der operativen Tasks des Testmanagers an das Scrum Team abgeschlossen. Die Lösung für die agile Transition der „Schnittstelle“ zwischen den Ebenen ist gleich der agilen Transition der operativen Aufgaben des Testmanagers. Für die vorhandenen Aufgaben der Unternehmenskommunikation stehen neue Konzepte und Werkzeuge bereit.
  • Sie sind als Matrixorganisation aufgebaut und stehen neben der normalen Unternehmensstruktur. Die Gilden haben die Aufgabe die Knowhow-Träger des Unternehmens zu bündeln und bieten den Mitarbeitern einen Platz zum Austausch von Wissen oder der Umsetzung von Weiterbildungsmaßnahmen oder stimmen übergreifende Projektentscheidungen wie Testumgebungsaufbau oder Codequalitätsregeln ab. Je nach Zielsetzung des Unternehmens können der Aufbau und die Gliederung der Gilden unterschiedlich sein: So können die Gilden sich nach Kompetenzfeldern aufteilen wie Java-Entwicklung, .NET-Entwicklung, Test oder Prozessanalyse. Es können aber auch komplette Scrum Teams in Gilden zusammengefasst werden, die sich im Projekt gemeinsam einem bestimmten Thema widmen wie QA, Datenbankanbindung, GUI oder Schnittstellen
  • Die Gilden arbeiten nach folgenden Muster: Für jeden Mitarbeiter wird seine primäre Rolle (zum Beispiel Entwickler, Tester (QAlas), Product Owner und Scrum Master), die er im täglichen Arbeitsleben wahrnimmt, ermittelt. Mit dieser Rolle wird er einer passenden Gilde zugeordnet. Hier tauschen sich die Mitglieder nach Aufgabenfeldern aus, führen interne Schulungen durch, sammeln das vorhandene Wissen in Portalen oder tauschen sich über Best Practice in einzelnen Projekten aus. Die Moderation und Koordination innerhalb der Gilde übernimmt ein Gildenmeister. Er besitzt nach dem Motto „primus inter pares“[1] keine höheren Rechte als seine Gildenkollegen und wird aus dem Kreis der Gildenmitglieder gewählt. Der Gildenmeister ist zentraler Ansprechpartner für seine Gildenmitglieder, die anderen Gildenmeister und das Management. Dies ist notwendig, da die Gilden sich aktiv interdisziplinär austauschen, aber auch Feedback aus der operativen Ebene wie neue Entwicklungen oder Technologien an den Vertrieb weitergeben oder Hinweise für Schulungen an das Personal geben sollen.
  • Für das Kompetenzteam QA (welchen ich angehöre) ergeben sich diese speziellen Aufgaben in unserer Firma…
  • Die grundlegende Ausrichtung der Saxonia Systems wurde in einer Strategy Map fest gehalten, die ein Strategieteam, bestehend aus Führungskräften und ausgewählten Fachexperten, seither in regelmäßigen Abständen überprüft und adaptiert. Doch nicht nur das: Mitglieder des Strategieteams verantworten die Umsetzungsinitiativen und schaffen eine Einheit von Strategieentwicklung und -Umsetzung. Alle Mitarbeiter haben die Möglichkeit, sich in die Weiterentwicklung der Vision einzubringen und werden über das eteoboard an allen Standorten über Entscheidungen und Fortschritte informiert.
  • Analog zu anderen agilen Vorgehen erfolgen die Iterationen
  • Transparenz durch Veröffentlichung und Meetings
    Freie Mitarbeit für Kollegen  Ansteuerung und Steuerung durch die Kompetenzteams
  • Aber nach all diesen Überlegungen und der agilen Transition der Aufgaben des Testmanagers?

    Wer ist in agilen Projekten für die Qualität verantwortlich?
  • Wie es eigentlich schon immer sein sollte: Alle!!!!
  • Testmanagement in der agilen Transition - Kay Grebenstein @ DWX2016

    1. 1. Kay Grebenstein Test Manager / Coach / Technical Champion QAla kay.grebenstein @saxsys.de www.so-geht- software.de
    2. 2. Das Unternehmen • IT-Beratungs- und Technologieunternehmen • Gesamtleistung 2015: 26 Mio. Euro • 230 feste Mitarbeiter • 6 Standorte
    3. 3. Product Backlog Sprint Backlog Shippable Product Daily Scrum Meeting 24 h 2 – 4 weeks PO T TE E E E SM
    4. 4. ProjektmanagementPM Projekt Management Plan Anforderungen Analyse Entwicklung Test T T T T T T AN Code Tests TM E E E E E E E E E
    5. 5. Testprozess nach International Software Testing Qualifications Board (ISTQB): • Die Tests 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 Testfälle bis der Testfokus abgedeckt ist • Das Testteam führt (versucht) alle vordefinierten Testfälle durch • 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 TestSteuerung TestPlanung TestAnalyse& TestDesign Test- Durchführung Auswertung& Berichtdertests TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF TF Testbericht Testkonzept
    6. 6. 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. • Das Team ist für die Verwaltung ihrer eigenen Tests verantwortlich. • Die Tester fördern Aktivitäten, die die Qualität ausbauen (wie acceptance criteria, unit testing, automated acceptance testing, story testing and exploratory testing) • ScrumBoard, Story und DoD liefern Auskunft über Fortschritt der Entwicklung + Test Planung Steuerung Abschluss Analyse&Design derStory Entwicklung (CodTesten)
    7. 7. TM Produc t Backlo g Sprint Backlo g Shippable Product Daily Scrum Meeting 24 h 2 – 4 weeks PO T TE E E E SM T T T T T T Agile Werkzeuge Klassisch Scrum
    8. 8. Testpolitik Qualitäts- Strategie 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 Risikoplanung Testrahmen und –Umgebung Automation und Tools Metriken Testkonzeption Testkonzept Teststrategie Qualitätsmerkmale Testzyklen und Meilensteine Zeit- und Ressourcen- planung Pass-Fail-Kritierien Infrastruktur Dokumentation Testumsetzung Teststufenplanung Test- implementierung Struktur- /Spezifikations- orientierte Verfahren Komponenten-, Service- und Oberflächentests Verifikation und Validierung Test- koordination Projekt-/Test- organisation Testzyklus- management Risiko-analyse und – bewertung Testevaluierung Testpriorisierung Qualitätsgrad- bemessung Abweichungs- management Berichtswesen / Dokumentation Strategische Ebene (Qualitätsmanager) Operative Ebene (Testmanager)
    9. 9. OperativeEbene Testkonzeption Testumsetzung Test- management Product Backlog Sprint Backlog Shippable Product Daily Scrum Meeting 24 h 2 – 4 weeks PO T TE E E E SM
    10. 10. Testkonzeption Testumsetzung Testkoordination Testkonzept Teststrategie Qualitäts- merkmale Testzyklen und Meilensteine Zeit- und Res- sourcenplanung Pass-Fail- Kritierien Infrastruktur Dokumentation Story Plannings Sprint DoD Release Planning Sprint Planning Release Daily Grooming Planning DoD 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 Testevaluierung Testpriorisierung Qualitätsgrad- bemessung Abweichungs- management Berichtswesen / Dokumentation Test- Pyramide Planning Sprint Planning Test- Automation Releasetest Test- Pyramide Story Daily Backlogs Sprint Release Daily Grooming Grooming Burn- Down Retro- spektive DoD Story ZeroBug- Policy Board BurnDown- Chart Test- Pyramide Klassisch Scrum Klassisch Scrum Planning Sprint Review
    11. 11. SM Fachliche Qualität Kollaborative Qualität Handwerkliche Qualität Scrum Team KPO Projekt Team Firma Qualität der Arbeits- umgebung Qualität der Anforderungen M Architektonische Qualität A T T Entwicklungsteam E E E E
    12. 12. Estimation Planning 1 Planning 2 Sprint Review Acceptance Criteria Story Test Tasks Test- skripte Testfälle Schneiden Definieren Erstellen& Durchführen Demonstrieren& Ausprobieren Abnahme Testsplanen (autom.&manuell)
    13. 13. Sprint- Backlog • VCS • Gemeinsame Code Basis • Code Review • Unit-Tests • Statische CodeAnalyse • CI / CD • Staging: Produkt- Inkrement Code- Repository Build Durchführung der System- und Service- Tests (Manuelle und Autom.) Entwicklung der System- und Servicetest System Service Unit / TDDTest Implementierung Refaktorisierung manuellautomatisiert Testfall- Repository Testfall- Repository
    14. 14. Gemeinsame Definition von Regeln, Normen und Abstimmungen des Teams.  „Definition of READY“ (DoR)  „Definition of DONE“ (DoD)  „Definition of TEST“ (DoT)  … Retrospektive (Test-) Verbesserungsprozess Kompetenz- team Projekt & Team Charta
    15. 15. Product Backlog Sprint Backlog Shippable Product Daily Scrum Meeting 24 h 2 – 4 weeks PO T TE E E E SM Agile Werkzeuge und Testerfahrung
    16. 16. Testpolitik Qualitäts- Strategie 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 Risikoplanung Testrahmen und –Umgebung Automation und Tools Metriken Testkonzeption Testkonzept Teststrategie Qualitätsmerkmale Testzyklen und Meilensteine Zeit- und Res- sourcenplanung Pass-Fail-Kritierien Infrastruktur Dokumentation Testumsetzung Teststufenplanung Test- implementierung Struktur- /Spezifikations- orientierte Verfahren Komponenten-, Service- und Oberflächentests Verifikation und Validierung Test- koordination Projekt-/Test- organisation Testzyklus- management Risiko-analyse und – bewertung Testevaluierung Testpriorisierung Qualitätsgrad- bemessung Abweichungs- management Berichtswesen / Dokumentation Strategische Ebene (Qualitätsmanager) Operative Ebene (Testmanager)
    17. 17. Testpolitik Qualitäts- Strategie 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 Risikoplanung Testrahmen und –Umgebung Automation und Tools Metriken Testkonzeption Testkonzept Teststrategie Qualitätsmerkmale Testzyklen und Meilensteine Zeit- und Res- sourcenplanung Pass-Fail-Kritierien Infrastruktur Dokumentation Testumsetzung Teststufenplanung Test- implementierung Struktur- /Spezifikations- orientierte Verfahren Komponenten-, Service- und Oberflächentests Verifikation und Validierung Test- koordination Projekt-/Test- organisation Testzyklus- management Risiko-analyse und – bewertung Testevaluierung Testpriorisierung Qualitätsgrad- bemessung Abweichungs- management Berichtswesen / Dokumentation Strategische Ebene (Qualitätsmanager) Operative Ebene (Testmanager) Product Backlog Sprint Backlog Shippable Product Daily Scrum Meeting 24 h 2 – 4 weeks PO T TE E E E SM Agile Werkzeuge und Testerfahrung
    18. 18. ssss ssss Geschäfts- führung CIO CQO FirmaVertrieb Einkauf Facility Management Personal- management Qualitäts- management Testpolitik Testprozess- optimierung Testprojekt- leitfaden Strategische Ebene SM T T PO E E E E
    19. 19. Strategische Ebene Operative Ebene TM Klassisch
    20. 20. Strategische Ebene Operative Ebene Scrum
    21. 21. T T SM PO Projekt 1 Projekt 2 T T SM PO T T SM PO T T PO E E E E E E E E E E E E E E E E SM
    22. 22. T T SM PO Projekt 1 Projekt 2 T T SM PO T T SM PO T T PO E E E E E E E E E E E E E E E E SM Gilde A Gilde B Gilde C
    23. 23. Gilde / Kompetenz -team Fachliche Heimat Wissens- management Weiter- bildungs- planung Coding / Testing Dojos Vertriebs- unterstützung Management- unterstützung
    24. 24. Kompetenz- team QA Strategische Initiativen für QA / QM Wissens- austausch Weiter- bildungs- planung Testing Dojos Projekt- vorbereitung TPI

    ×