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
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
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
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
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
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
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
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: 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!