Wie gut ist Ihr agiles Testen? - sigs-datacom.de · p 1 4 Woc 2. Agile Basis: Alle Werkzeuge sind...

Wie gut ist Ihr agiles Testen?Testen ist ein zentrales Element in der agilen Entwicklung. Dies drückt sich unter anderem dadurch aus, dass neben Testern auchSoftwareentwickler testen. Obwohl alle am gleichen Ziel arbeiten, ist es für viele Teams eine große Herausforderung, das Testenmit all seinen Facetten reibungslos in den Entwicklungsprozess zu integrieren. Es entstehen Produktivitätsverluste, die durch eineoptimierte Zusammenarbeit vermieden werden könnten. In diesem Artikel stellen wir eine Methode vor, die es erlaubt, den Gradder Professionalität des gesamten Testens in einem Team zu bestimmen und mit Hilfe eines Modells adäquateVerbesserungsmaßnahmen abzuleiten.

n Software-Integration beschleunigen,n Zufriedenheit der Mitarbeiter (Tester)

erhöhen,n Testautomatisierungsgrad erhöhen,n Anzahl der Releases pro Jahr erhöhen,n das Testen beschleunigen,n die vereinbarte Testabdeckung erreichen.

Diese Gründe müssen vor dem Einsatz derMethode aufgenommen und verstandenwerden. Sobald dies der Fall ist, kann dar-aus ein Motivator und ein monetär quanti-fizierbarer Nutzen abgeleitet werden.Damit ist Wirtschaftlichkeit Voraussetzungfür das Vorgehen.

Zur Erinnerung: Das Vorgehen betrach-tet ausschließlich Aspekte des Testens ineinem agilen Entwicklungsprozess.

Professionalität, Idealbildund GrundsätzeProfessionalität ist aus unserer Sicht immerdann gegeben, wenn Arbeiten einem konti-nuierlichen Verbesserungsprozess unterlie-gen und z. B. nach dem „Plan – Do – Check– Act (PDCA)”-Zyklus durchgeführt wer-den. Zunächst wird die Arbeit geplant,dann durchgeführt, sie wird kontrolliert,gegebenenfalls werden Mängel behobenund Lehren daraus gezogen, um die Arbeitdas nächste Mal (noch) besser auszuführen.

dürfte es gelingen, eine Standortbestimmungder Testprozesse mit leichter Modifikationder klassischen Verfahren durchzuführen.Diese Methoden finden aber derzeit nurwenig Verbreitung, weswegen wir diesenAnsatz nicht weiterverfolgen.

Mit dem hier vorgestellten Vorgehen kannaufgezeigt werden, was getan werden muss,um das Testen optimal in agile Teams zu inte-grieren und eine erhöhte Pro duktivität undQualität zu erreichen. Dabei werden zehnThemen abgedeckt wie z. B. Skills, Prozesseund Testtiefe. Der Test prozess wird anhandeines fünf-stufigen Reifemodells eingestuft.Daraus werden geeignete Optimierungs vor -schläge erarbeitet, die dann in konkretenMaßnahmen umgesetzt werden.

AnwendungsgebieteUnser Vorgehen kommt immer dann zurAnwendung, wenn einer der folgenden,monetär quantifizierbaren Motivatorenvorliegt:

n Die Time-To-Market verbessern,n Produktivität erhöhen odern Qualität verbessern.

Gründe, die zu diesen Motivatoren führenund das Testen betreffen, sind u. a.:

AusgangslageViele Unternehmen haben bereits eine agileVorgehensweise eingeführt. Trotzdem blei-ben zu viele Fehler unbemerkt und dieZusammenarbeit im Team ist nicht opti-mal. Dies reduziert in erheblichem Maßedie Vorteile der schnelleren Entwicklung.Die Fehlerbehebung verursacht hoheKosten und die mangelnde Zusammen -arbeit erzeugt Blindleistung. Beides mindertdie Produktivität. Es entsteht somit einBedarf für die effiziente Einbindung vonpassenden Testverfahren.

Testabläufe können bereits heute auf ihreWirksamkeit und Zweckmäßigkeit geprüftwerden. Klassische Verfahren (siehe[Ewji11], [Schw13a]) für die Identifikationvon Test pro zessverbesserungen können nureingeschränkt auf agiles Testen angewendetwerden, weil sie eine von der Entwicklungge trennte organisatorische Einheit voraus-setzen. Weitere Ansätze wie [Schw13b] und[SiAr07] beurteilen die Prozessverbes -serungs fähigkeit von agilen Teams allge-mein. Der spezifische Teil des Testens ist zuwenig ausgeprägt.

Manche agile Methoden bieten die Werk -zeuge für ein effektives Testmanage ment imganzen Projekt wie z. B. „Driving StrategyDelivering More“ [DSDM] und „AgileUnified Process” [AUP]. In diesen Fällen

der au tor

Dr. Ferdinand Gramsamer

(ferdinand.gramsamer@bbv.ch)leitet seit 2007 den Kompetenzbereich Testing bei der bbv Software ServicesAG. Von 2002 bis 2009 arbeitete er als Lead-QA Engineer bei der bbv SoftwareServices AG in Luzern und war dort als Testautomatisierer und Testmanagerin mittleren bis großen Projekten für Kunden in verschiedenen Branchentätig. Sein Hauptinteresse liegt unter anderem bei den Themen mobilesTesten, Testautomatisierung und Testprozessverbesserungen. Er begleitetKundenprojekte in diesen Themen und ist für deren Qualitätssicherungzuständig.

1 www.objektspektrum.de

advertorial

Erfahrungen gehen also nicht unter, manlernt. Es ist ein kontinuierliches Lernen.

Selbstverständlich trifft dies auch fürArbeiten in einem Team zu. Ein Team istebenfalls einem ständigen Lernprozessunterworfen und wird somit über die Zeitbesser – Professionalität vorausgesetzt.

Unser Idealbild des agilen Testens basiertauf vollständiger Teamarbeit. Release-Testen und das Deployment in dieProduktion sind innerhalb eines Tagesdurchführbar. Regressions-Testen wirdmehrmals täglich vollständig durchgeführtund beinhaltet funktionale wie nicht-funk-tionale Tests.Die Tester arbeiten nach Grundsätzen, diesich aus dem agilen Manifest [Agile] ablei-ten lassen:

n laufend Rückmeldung über Fortschrittgeben,

n Fokus auf Kundennutzen,n direkte Kommunikation als primärer

Weg der Rückmeldung,n einfache Lösungen bevorzugen,n Raum für kontinuierliche Optimierung

schaffen,n Flexibilität,n Selbstorganisation und Zusammen ar -

beit im Team,n Personen stehen im Vordergrund.

Wie sind diese Grundsätze von Testernumzusetzen? Was bedeuten diese Grund -sätze für das Testen? In diesen Frage -stellungen liegt die Schwierigkeit, mitdenen das Testen in vielen Entwick lungs -teams konfrontiert ist. Mit unserer vorge-schlagenen Methode versuchen wir,Antwort zu geben, indem wir strukturiertzu Professionalität, Idealbild und Arbeitennach den oben genannten Grundsätzen hin-führen. Wir wollen damit eine hohe Pro -duktivität bei gleichzeitig hoher Qualitäterreichen.

Unsere MethodeUnsere Methode hat daher zum Ziel, einehohe Produktivität bei gleichzeitig hoherQualität zu erreichen. Die primäreZielsetzung liegt also nicht im Testen perse, sondern im Ergebnis der einzelnenArbeitsprodukte und somit am Ergebnisdes gesamten Teams. Es steht ein gesamt-heitlicher Ansatz im Vordergrund. DasTesten ist Teil des produktiven Prozesses.

Wir legen daher unserer Methode dasModell eines produktiven Prozesses alsAuslegeordnung zugrunde. In [PlPoe11] ist

ein solches Modell entwickelt worden, daswir nun für unsere Zwecke verwenden. Eshilft uns, einen geeigneten Rahmen vorzu-geben und unsere Fragen innerhalb desModells auf Vollständigkeit zu überprüfen. Es besteht aus acht Faktoren, die inAbbildung 1 dargestellt sind. Nach demModell ergeben sich aus den Anfor -derungen die Aufgaben, die zu erledigensind. Diese werden nach einem Warte -schlangensystem abgearbeitet. DieAbarbeitungszeit hängt vom Team und sei-nen Mitgliedern sowie von Umgebungs -faktoren ab. Die Arbeiten werden nacheinem bestimmten Vorgehen erledigt. Nunzeigt sich die Qualität. Es gibt Arbeiten, dienachgearbeitet werden müssen (z. B.Fehler), oder es gibt Funktionen, die unnö-tigerweise gebaut wurden (Verschwen -dung). Nacharbeiten (Rework) sindbesonders produktivitätsmindernd, da sieKapazität wegnehmen, neue Aufgabenabzuarbeiten. Diese Tatsache wird anhanddes Modells recht deutlich. Fehler müssenalso vermieden oder unmittelbar entdecktund bearbeitet werden.

Man arbeitet auf ein Ziel hin. Das ganzeVorhaben wird durch diverse Vorbe reitungs-und Planungsaktivitäten und Prüfung desStatus gesteuert (Steuerung). In einem agilenVorgehen wird diesen Aktivitäten z. B. durchGrooming, Sprints oder Burn-down ChartsRechnung getragen.

Für eine hohe Produktivität ist alsoRework und Verschwendung zu vermeiden.Man muss zielgerichtet arbeiten und klareVorgaben haben. Es braucht ein definiertesVorgehen und ein befähigtes Team in einerpassenden Umgebung. So einfach diese

Dinge klingen, so schwierig ist es dennoch,sie in der Praxis umzusetzen.

Basierend auf diesem Raster ist einKriterienkatalog entstanden, der sich inThemen und Unterthemen, sowie konkreteFragen aufteilt. Wir haben uns für geschlos-sene Fragen entschieden, um die Befragungüber verschiedene Coaches und Kundengleichermaßen durchführen zu können, umdie Befragten zu einer Entscheidung zuzwingen und um die anschließende Aus -wertung rasch durchführen zu können. DieStruktur aus den Faktoren des Modellssowie der Themen und Unterthemen ist inAbbildung 2 dargestellt. In Anlehnung an die Reifegrade im CMMI(1 - Initial, 2 - Managed, 3 - Defined, 4 -Quantitatively Managed und 5 – Opti -mizing) haben wir die Stufen, die „agilenReifegrade“ 1 – 5, definiert und dieseReifegrade grob beschrieben:

1. Agile Ansätze: Continuous Integrationwird rudimentär angewendet. DieAnforderungen werden direkt zu UserStories transformiert. Iterationen dau-ern prinzipiell 1 bis 4 Wochen.

2. Agile Basis: Alle Werkzeuge sind vor-handen, um Continuous Integrationkomplett umzusetzen. User Stories wer-den erarbeitet, sind aber oft zu großund nur teilweise mit Akzeptanz -kriterien versehen. Die Program -mierung wird mittels Test-DrivenDevelopment (TDD) vollständig durch-geführt. Release-Testen wird parallelund unabhängig vom Entwicklungs -team durchgeführt und ist nachgela-gert. Regressions-Testen wird ebenfalls

2Online-Themenspecial Testing 2014

Online-Themenspecial Testing 2014 advertorial

Abb. 1: Modell produktiver Prozesse nach Plewan und Poensgen [PlPoe11]

Development (ATDD) durchgeführt.User Stories sind skaliert und innerhalbeiniger Tage umsetzbar. Es existierenscharfe Akzeptanzkriterien. Release-Testen wird in einer eigenen Iterationabgehandelt. Regressions-Testen wirdregelmäßig und mindestens wöchent-lich vollständig durchgeführt.

4. Repeated Continuous Delivery: An for -derungen führen direkt zu automatisier-ten Tests (z. B. mittels Business-DrivenDevelopment). Die dadurch entstehendeautomatisierte Testab de ckung ist sehrhoch. Entwicklungs teams sind autonomund die Release-Pla nung basiert auf agi-len Grund sätzen. Regressions-Testingwird mindestens täglich vollständigdurchgeführt.

5. Constant Continuous Delivery: Derauto matisierte nicht-funktionaleTestan satz ist sehr weit fortgeschritten.Release-Testing und Deployment in diePro duk tion ist innerhalb eines Tagesdurch führbar und ist vollständigeTeamarbeit.

Der Kriterienkatalog dient dazu, eineStandortbestimmung in der Arbeitsweisevon Teams vornehmen zu können. DieStandortbestimmung wird durch einen„agilen Reifegrad“ ausgedrückt. Basierendauf diesen Ergebnissen können geeigneteVerbesserungsmaßnahmen abgeleitet wer-den, um das Ziel, Stufe 5 „ConstantContinuous Delivery“, zu erreichen. DieVerbesserungsmaßnahmen lassen sichimplizit aus den gestellten Fragen ableiten.

Die Fragen des Kriterienkatalogs sindunter Berücksichtigung von Professionali -tät und Idealbild, wie im vorangegangenenKapitel beschrieben, und unter Berück -sichtigung der Zielsetzung der einzelnenStufen abgeleitet worden.

Als einfaches Beispiel gibt es zum ThemaTeamorganisation folgende Fragen:

Stufe 1: Sitzt das Team beieinander?Stufe 2: Ist die Größe des Teams zwischen

3 und 12 Personen?Stufe 3: Wird der Scrum-Master bei der

Auswahl der Teammitglieder ein-gebunden?

Stufe 4: Wählt das Team seine Team mit -glieder aus?

Stufe 5: Organisiert sich das Team selber?

Wird die 3. Frage mit Nein beantwortet,Fragen 1 und 2 aber mit ja, ist für diesenFragekomplex Stufe 2 erreicht.

3. Agiles Vorgehen: Scrum oder ein ande-res agiles Vorgehen ist vollständigumgesetzt. Der Prozess wird nach denPrinzipien von Acceptance Test-Driven

nachgelagert zur Entwicklung in regel-mäßigen, aber großen Abständen (nichtin allen Iterationen) vollständig durch-geführt.

advertorial

3 www.objektspektrum.de

Abb. 2: Kriterienkatalog zur Bewertung des agilen Testens

Im Vorgehen werden nun einzelne Team -mitglieder mit Hilfe des Kriterienkatalogesbefragt. Daraus ergibt sich für jeden„Stakeholder“ eine Übersichtsmatrix, wiesie in Tabelle 1 dargestellt ist. Daraus wirdeine Gesamtsicht erstellt, wobei für dieErreichung einer Stufe im Zweifelsfall dieExpertise des Coaches maßgebend ist.

In der Praxis hat sich für eine fundierteBewertung auch eine Beobachtung derTeams in seiner Arbeitsweise, z. B. amDaily Scrum oder an einem Grooming,bewährt.

VerbesserungsmaßnahmenWir haben zu unserem Vorgehen einenVerbesserungskatalog erstellt, der demCoach hilft, Verbesserungsmaßnahmen zuformulieren. Der Katalog beinhaltet vorallem das „Was“, da das „Wie“ sehr vomUmfeld abhängt und von Kunde zu Kundevariieren kann.

In einer Analyse bei einem Kunden kamz. B. heraus, dass die Bereiche

n Teststrategie (Testtiefe, Prozess,Planung, Metriken) und

n Methodik/Ausbildung (Skills)

verbessert werden müssen. Dies wird nunim Rahmen eines Coaching für einen neuernannten Testmanager, spezifischerSchulungsmaßnahmen und dem Erarbeiteneiner Teststrategie umgesetzt. Ergebnisse,dass das Vorgehen eine Verbesserungbewirkte, liegen noch nicht vor.

Zusammenfassung undnächste SchritteDie vorgestellte Methodik findet unter derVoraussetzung von WirtschaftlichkeitAnwendung. Das Testen wird als Teil einesproduktiven Prozesses angesehen. Anhandeines fünf-stufigen Reifemodells wird einTeam über zehn Themenbereiche hinweg

eingestuft. Ein Verbesserungskatalog gibtHilfestellung zur Definition geeigneterMaßnahmen. Anhand der Erfahrung auskonkreten Projekten wird das Vorgehenweiter verbessert werden. Es steht derzeiteine Zusammenfassung und Reduktion derfünf Stufen in Diskussion, um diese auftypische Projektkonstellationen besserabbilden zu können. Ferner wird derFragenkatalog noch weiter ausgebaut.

DanksagungDie Arbeiten für die vorgestellte Methodikwurden im Jahr 2013 vom bbv-TestingTeam durchgeführt, wobei die Erfahrungaus verschiedensten Projekten und Kundenmit eingeflossen ist. Der Autor bedanktsich bei allen Teammitgliedern für ihr per-sönliches Engagement und Begeisterung beider Arbeit. n

4Online-Themenspecial Testing 2014

Online-Themenspecial Testing 2014 advertorial

Literatur & Links

[Agile] Manifest für Agile Softwareentwicklung, siehe: http://agilemanifesto.org/iso/de/

[AUP] S. Ambler, The Agile Unifed Process (AUP), Ambysoft, siehe:

http://www.ambysoft.com/unifiedprocess/agileUP.html

[DSDM] DSDM Consortium, DSDM Atern Handbook, siehe:

http://www.dsdm.org/dig-deeper/book/dsdm-atern-handbook

[Ewji11] A. van Ewjik, B. Linker, M. van Oosterwijk, B. Visser, G. d. Vries, B. Wilhlmus, TPI

NEXT – Geschäftsbasierte Verbesserung des Testprozesses, dpunkt.verlag, 2011

[PlPoe11] H. Plewan, B. Poensgen, Produktive Softwareentwicklung, dpunkt.verlag, 2011

[Schw13a] T. Schweigert, D. Vohwinkel, M. Blaschke, M. Ekssir-Monfared, TestSPICE and Agile

Testing - Synergy or Confusion, in: Comm. in Computer and Information Science, 154-164, 2013

[Schw13b] T. Schweigert, D. Vohwinkel, M. Korsaa, R. Nevalainen, M. Biro, Agile Maturity

Model: A Synopsis as a First Step to Synthesis, in: 20th European Conference, EuroSPI 2013,

Dundalk, 2013

[SiAr07] A. Sidky, J. Arthur, Disciplined Approach to Adopting Agile Practices, in: Innovations in

Systems and Software Engineering, 203-216, 2007

Tab. 1: Die Auswertungsübersicht gibt den Stand des agilen Testens an