mittendrin oder nur dabei – wie gut sind ihre tester in ihren agilen … · 2020-03-20 ·...

© 2013 imbus AG www.imbus.de

Mittendrin oder nur dabei – wie gut sind Ihre Tester in

Ihren agilen Prozess integriert?

Dr. Christian Brandes, imbus AG Testing Day Franken, 24.9.2013

© 2013 imbus AG www.imbus.de Folie 2

imbus

Vorstand imbus AG

!   Spezialisierter Lösungsanbieter für Software-Qualitätssicherung und Software-Test

!   Innovativ seit 1992

!   Erfahrung und Know-how aus über 4.000 erfolgreichen Projekten

!   200 Mitarbeiter an fünf Standorten in Deutschland


Kurze Vorbemerkung zu Begriffen

Scrum kennt ausdrücklich nur „Teammitglieder“! Im Folgenden reden wir aber bewusst von Testern und Entwicklern in einem Scrum-Team.

Scrum ist das „Tempo“ unter den agilen Taschentüchern: Wir werden „agil“ stets am Beispiel Scrum illustrieren.

Quelle: Spillner/Vosseberg, „Wie agil sind wir?“, Vortrag am QS-Tag 2013


Der Auslöser: Test-Antipatterns in agilen Projekten

Fehlende oder nicht testbare Akzeptanzkriterien

Definition of Ready ohne Forderungen zur Testbarkeit

Definition of Done ohne Beschreibung von „Test=DONE“

Testautomatisierung erzeugt mehr&mehr „technische Schuld“

Kein Einsatz systematischer Testmethoden

Keine definierte Teststrategie

Tester sind räumlich getrennt vom Team

Keine Beteiligung der Tester an Teammeetings

Testen beginnt nicht frühzeitig („Waterscrum“)

„Test-Sprints“ als Normalfall


Das GAAA (Größte Anzunehmende Agile Antipattern)

Authentisches Zitat eines Softwareentwicklers in einem SCRUM-Projekt:

„Ich will mich in meiner DONEness nicht vom Test

behindern lassen!“

Siehe: http://de.wikipedia.org/wiki/Fazialpalmieren


Test-Antipatterns „aus der Totalen“

TEST(ER) NICHT IN DEN AGILEN PROZESS INTEGRIERT

Mögliche Ursachen:

!   Teammitglieder vorher in „Silos“

!   Agiler Prozess oft von Entwicklern definiert und getrieben

!   Tester sind nicht auf Veränderungen im Agilen vorbereitet


Überlegung: Können bewährte Reifegrad- Modelle auch in agilen Projekten helfen?


Beispiel: SE-Referenzmodell ISO/IEC 12207

ACQ SPL OPE ENG

MAN PIM RIN REU

SUP

CA

PAB

ILIT

Y D

imen

sion

PROCESS Dimension

Level 1

Level 4 Level 3 Level 2

Level 0 Management 1.1

2.1 2.2 3.1 3.2 4.1 4.2 5.1 5.2

Für jedes Prozess-Attribut PA1.1 bis PA5.2

Prozess-Assessment Indikatoren für Prozess-Reifegrade 1 bis 5 bezogen auf jedes Prozess-Attribut - GP: Generic Practices - GR: Generic Resources - GWP: Generic Work Products

Level 1 Weitere Indikatoren der Prozess-Performance - BP: Base Practices - WP: Work Products

Level 5


Beispiel: Fähigkeitsstufen der ISO 15504

Durchgeführt Der Prozess wird umgesetzt und der Prozesszweck erfüllt.

Stufe 1 „Performed Process“ PA.1.1 Process performance

Stufe 0 „Incomplete Process“

Stufe 2 „Managed Process“ PA.2.1 Performance management PA.2.2 Work product management

Stufe 3 „Established Process“ PA.3.1 Process definition PA.3.2 Process deployment

Stufe 4 „Predictable Process“ PA.4.1 Process measurement PA.4.2 Process control

Stufe 5 „Optimizing Process“ PA.5.1 Process innovation PA.5.2 Process optimization

Voraussagbar Der Prozess wird innerhalb definierter Grenzen durchgeführt.

Etabliert Definierter Prozess auf Basis eines Standard-Prozesses.

Geleitet Der Prozess wird geplant und gesteuert.

Unvollständig Nicht realisiert oder erfüllt nicht seinen Zweck

Optimierend Der Prozess wird fortlaufend verbessert, um gegenwärtige und zukünftige Projektziele ein- zuhalten.


Beispiel: TPI Matrix

Prozessreife erhöhen

20 K

ernbereiche


Erkenntnis: Im Prinzip ja...

Denn: Kontinuierliche Prozessverbesserung ist im Agilen essenziell! („inspect & adapt“) Nutzenpotenzial bestehender Reifegradmodelle: ü  Liefern Systematik für die

Reihenfolge von Retrospektive-Maßnahmen

ü  Mögliche QS der Maßnahmen (Review gegen Base Practices/Work Products)

ü  Zusätzliche Motivation für Maßnahmen

§  schwergewichtig und aufwändig im Einsatz

§  agiler Wertekanon erfordert Verschiebungen (z.B.: Toolstandards)

§  Abstraktion: sie liefern oft keine konkreten Maßnahmen zu Test-Antipatterns (s.wichtige agile Erfolgsfaktoren wie „integriertes Team, Kommunikation, Zusammenarbeit“; Beispiel: SPICE fordert „Konsistenz“, „Traceability“, „Reviews“, aber z.B. kein Pairing)

§  Testmethodik wenig thematisiert

ABER:


Weil wir nicht fanden was wir suchten: Erstellung eines eigenen Modells

§  Leichtgewichtig §  Liefert operationalisierbare konkrete Maßnahmen in

sinnvoller Reihenfolge §  Fokussiert auf Test(er)-Integration, denn:


Zur Entstehung des Modells

§  Festlegung von Themengebieten („Dimensionen“, vgl. „Kernbereiche“), die für das Ziel relevant sind

§  pro Dimension: Definition von aufeinander aufbauenden „Checkpoints“

§  Untersuchung, inwieweit sich Checkpoints auf existierende Reifegrad-Level abbilden lassen

§  pro Checkpoint „Ja/Nein“-Fragen für Interviews Maßgeblich dabei: Erfolgsfaktoren für agiles Testen ü  frühe Zusammenarbeit im Team ü  „fast feedback“ ü  definierter Test-Mix aus systematischen, automatisierten

und explorativen Tests


Das Ergebnis

TEAM

TECHNIK

TRANSPARENZ TESTMETHODIK

TESTVORGEHEN

Selbstorganisation

Störungsfreiheit

Verantwortung Verantwortung

Integration

Planung

Fortschritt

Fast Feedback

Produktivität

Kommunikation

Effizienz

Wertorientierung

Qualität von Anfang an

Austausch Reife Beschleunigung Teamarbeit Toolset

Testorganisation

Testkoordination

Frühzeitigkeit

Testobjekt

Eingangsartefakte „T5“


Das Ergebnis: Die 5 Dimensionen

!   Team: Verantwortung für Testaufgaben, Integration der Tester, Selbstmanagement

!   Technik: eingesetzte Tools und ihre Teamintegration

!   Transparenz: gemeinsame Ziele & Planung, Informationsfluss

!   Testmethodik: wie und wann wird getestet

!   Testvorgehen: Ablauforganisation, Qualität der Eingangsartefakte


Typischer Ablauf eines T5-Assessments: sprintbegleitend innerhalb 1 Woche

Kick-off: Ziele Inter-view-termine

Ergeb-nis-präsen-tation

Inter-view mit Rolle ...







Vorbereitung: Sichtung Dokumen-tation

Schriftliche Ausarbeitung der Handlungs-empfehlungen


Ein Projekt-Beispiel

Empfohlene Maßnahmen für nächste Retrospektive (u.a.): ! Testbare Definition von Akzeptanzkriterien („examples“), mit Pairing

Product Owner + Tester ! „Definition of Test“ (s. agile Testquadranten), zugleich als Checkliste

im Sprint Planning ! Handling der Task-Karten am Board ! Alle Tests im selben Sprint


Feedback

! Ein Kunde (genauer: Linienvorgesetzter), dessen Scrum-Teams ein T5-Assessment durchlaufen haben, im Anschluss an die Ergebnispräsentation

! Ein Kollege, der jahrelange Erfahrung sowohl mit Reifegradmodellen als auch agilen Projekten hat

„Meine Erwartungen wurden deutlich

übertroffen!“

„Ein richtig cooles Assessment-Schema! Das hätte ich gern schon

in früheren Projekten gehabt.“


Der Fachartikel zum Vortrag: iX-Developer Sonderheft „Bessere Software“

Per Mail

vom Autor


Sinn des Ganzen: „quality built-in from beginning“!


Besten Dank für Ihre Aufmerksamkeit!

© 2013 imbus AG www.imbus.de Kontakt Folie 22

imbus AG imbus AG Kleinseebacher Str. 9 Balanstr. 73 // Gbd. 21a 91096 Möhrendorf 81541 München DEUTSCHLAND DEUTSCHLAND Tel. +49 9131 7518-0 Tel. +49 89 3219909-0 Fax +49 9131 7518-50 Fax +49 89 3219909-50

imbus AG Rathausallee 70 22846 Norderstedt DEUTSCHLAND Tel. +49 40 35731467

Fax +49 9131 7518-50

imbus Rhein-Main GmbH Kirschgartenstr. 15 65719 Hofheim DEUTSCHLAND Tel. +49 6192 92192-0 Fax +49 6192 92192-50

imbus Rheinland GmbH Volksgartenstr. 36 50677 Köln DEUTSCHLAND Tel. +49 221 998788-0 Fax +49 221 998788-50

imbus Shanghai IT Co., Ltd. No. 500 BiboRoad Zhangjiang HT Park Pudong Shanghai 201203 P.R. China Tel. +86 21 50274732 Fax +86 21 50274732-20

[email protected] www.imbus.de

mittendrin oder nur dabei – wie gut sind ihre tester in ihren agilen … · 2020-03-20 ·...

Documents