ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?

Thema: Testmanagement und Agile Testing – klassische Vorgehensweise vs. Agile

Herzlich Willkommen Fachgruppe Software-Test, Dresden

Referenten

Kay Grebenstein

(Saxonia Systems AG)

[email protected]

René Spengler

(ANECON Software Design und Beratung GmbH)

[email protected]

mailto:[email protected]


innovativer Knowhow-Transfer• Über 100 Veranstaltungen jährlich

• 12 Fachgruppen mit 36 Regionalgruppen

• Publikation von Fachwissen

grenzenloser Wissensvermittler• internationale Standards

• netzwerkübergreifende Kommunikation

• Gesellschafter des iSQI

attraktives Kompetenznetzwerk

• Über 1.250 Mitglieder im DACH-Gebiet

• 66 aktive Fachgruppenmitarbeiter

• Netzwerk von fast 10.000 deutschsprachigen Kontakten

©

Ridofranz_istockphoto.c

om

Die ASQF-Themenin 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

• SQ-Mag

SQ-Magazin, Ausgabe September

Auch zum DOWNLOADEN unter www.asqf.de

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

Arbeitskreis Software-Qualität und -FortbildungFACHGRUPPEN

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

http://www.asqf.de/

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!

Wir wünschen Ihnen einen angenehmenund informativen Abend

Ihr ASQF e.V.

Kontakt

Fachgruppenleiter:

Matthias Schneider

(T-Systems Multimedia Solutions GmbH)

[email protected]

--------------------------------------

stellvertretender Fachgruppenleiter:

Michael Kieser


[email protected]



Thema: Testmanagement und Agile Testing – klassische Vorgehensweise vs. Agile

Herzlich Willkommen Fachgruppe Software-Test, Dresden

Referenten

Kay Grebenstein


[email protected]

René Spengler

(ANECON Software Design und Beratung GmbH)

[email protected]



Testmanagement und Agile Testing

Ausgangssituation (I)

http://www.softwaretest-umfrage.de

http://www.softwaretest-umfrage.de/


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.


Die Frage

Klassische Vorgehensweise

Agile Vorgehensweise

Agile Transition Grenzbetrachtung


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


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

TT

PL ges.

E

E

E

E

TT

PL E

Gesamtprojektleiter

EEEE

TM

Testpolitik

Qualitäts-management

Qualitäts- und Testrichtlinie

Integration von Referenz-

modellen und Standards

Testprozess-optimierung

Standards, Normen und Methoden

Test ProcessImprovement

(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-

orientierteVerfahren

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

Strategische Ebene Operative Ebene


Aufgaben des Qualitäts- und Testmanagers


Klassische Vorgehens-

weise

Agile Vorgehens-

weise

Agile Transition

Grenz-betrachtung

Product

Backlog

Sprint

Backlog

Shippable

Product

Daily Scrum

Meeting

24 h

2 – 4 weeks



Product

Backlog

Sprint

Backlog

Shippable

Product

Daily Scrum

Meeting

24 h

2 – 4 weeks

T

TE

E

E

EPO

SM



Analyse Design Entwicklung Test

Iteration 1 Iteration 2 Iteration 3

A B A B A B

C C

D

Wasserf

all

Ag

ile



24 h

2 – 4 weeks

PO

24 h

2 – 4 weeks

PO

24

h

2 – 4 weeks

PO

POProduct Backlock,

BurnDownChart,

Iteration Plan

User Stories,

Code, Tests, Bugs,

Doku

User Stories,

Code, Tests, Bugs,

Doku

User Stories,

Code, Tests, Bugs,

Doku

T

TE

E

E

E T

TE

E

E

ET

TE

E

E

E

SM SM SM



SM



weise

Agile Vorgehens-

weise

Agile Transition

Grenz-betrachtung

TestSteuerung

Tes

tPla

nu

ng

Te

stA

na

lys

e&

TestD

esig

n

Test-

Du

rch

füh

run

g

Au

sw

ert

un

g &

Beri

ch

t d

er

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

Te

stb

eri

ch

t

Te

stk

on

ze

pt


Tests in Agile umsetzen

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.

Pla

nn

ing

Steuerung

Abschluss

An

aly

se &

De

sig

n

der

Sto

ry

En

twic

klu

ng

(Co

dTe

ste

n)


Tests in Agile umsetzen

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


Der Agile Tester

Programmieren

Testen

Domäne


Der Agile Tester

Testpolitik


Qualitäts- und Testrichtlinie

Integration von Referenz-

modellen und Standards


Standards, Normen und Methoden

Test ProcessImprovement

(TPI)

Schulung und Zertifizierung


Methoden und Standards

Teststufen-planung

Risiko-

planung

Testrahmen und –Umgebung

Automation und Tools

Metriken

Test-konzeption

Test-

konzept

Test-

strategie

Qualitäts-merkmale




Infrastruktur

Dokumentation

Test-umsetzung

Teststufen-planung





Oberflächentests


Test-management




Test-

evaluierung

Test-priorisierung




Strategische Ebene Operative Ebene


Testmanagement in Agile umgesetzen

ssss

ssss

Geschäfts-führung

CIO

CQO

Stetiger

Wandel

Kundenbedürfnisse

Technologien

Wettbewerber

FirmaVertrieb

Einkauf

Facility Management

Personal-management


Testpolitik



Strategische Ebene


Qualitätsmanagement

ssss

ssss

Geschäfts-führung

CIO

CQO


Verantwortung für Qualitätsmanagement

SM

T

T

PO

E

E

E

E

FirmaVertrieb

Einkauf

Facility Management

Personal-management


Testpolitik



Strategische Ebene

Op

era

tive

Eb

en

e

Test-konzeption

Test-umsetzung

Test-management

Product

Backlog

Sprint

Backlog

Shippable

Product

Daily Scrum

Meeting

24 h

2 – 4 weeks

PO T

TE

E

E

E

SM


Agile Operative Ebene

TM

Produ

ct

Backl

og

Sprint

Backl

og

Shippab

le

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


Agile Transition der operativen Ebene

Testkonzeption Testumsetzung Testkoordination

Test-

konzept

Test-

strategie

Qualitäts-merkmale




Infrastruktur

Dokumentation Story

Planning

Sprint

DoD

Plannin

g

Release

Plannin

g

Meeting

Releas

e

Daily

Backlog

Groomin

gPlanning

DoD

Klassisch Scrum

Teststufen-planung





Oberflächentests





Test-

evaluierung

Testpriorisierung




Test-

Pyramide

Plannin

g

SprintPlannin

g

Test-

Automation

Releasetes

t

Test-

Pyramide

Story

Daily Backlogs

SprintReleas

e

DailyBacklog

Groomin

g

Story

Burn-

Down

Retro-

spektiv

e

DoD Story

ZeroBu

gPolicy

DoD Backlogs

Test-

Pyramide

Klassisch Scrum Klassisch Scrum

Supported byMaria Bär


Agile Transition der operativen Ebene


Die Frage



weise

Agile Vorgehens-

weise

Agile Transition

Grenz-betrachtung

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


Regressionstests und Testautomatisierung


• 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


große Projekte und/oder hohe Integration

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


• Geänderte bzw. unzureichende Anforderungen führen automatisch zu Verzögerungen und BudgetübERschreitung


Anforderungsgüte

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


• TM holt Ergebnisse und Metriken ein -> TM ist somit nicht immer aktuell aussagekräftig

• Trends und Vorabanalysen sind nur vage möglich


Kennzahlen

Agile Entwicklung

• Ein Sprint ist immer gleich lang und am Ende steht ein fertiges Produkt


• Sequenzielle Abarbeitung der Schritte kann bei Verzögerungen in den Vorhergehenden Stufen zu Beeinflussung der Testdurchführung führen


Projektverzögerungen

ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?

Internet

Transcript of ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?