Experience. nr.54. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. september 2012

Transkript

1 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.54 september 2012 TesTINg Auch der Tester muss agil sein Die agile Entwicklung verlangt flexible und reflektierte Testing-Methoden

2 Auch Der TesTER muss agil sein Die agile Entwicklung verlangt flexible und reflektierte Testing-Methoden Agile, leichtgewichtige Entwicklungsansätze wie beispielsweise Scrum versprechen eine höhere Effizienz, kürzere Release-Zyklen und qualitativ bessere Software. Sie bedeuten aber auch einen Paradigmenwechsel in Sachen Software-Testing. Von SEVErin DiETSchi und Edon Berisha Agile Entwicklungsmethoden wie Scrum stellen den künftigen Anwender in den Mittelpunkt: Der Auftraggeber erhält nicht mehr am Ende des Softwareprojekts ein Produkt, das mehr oder weniger seinen Wünschen und Bedürfnissen entspricht. Vielmehr wird er konsequent in den Entwicklungsprozess eingebunden, und geänderte Anforderungen oder Prioritäten werden innerhalb von sehr kurzen Release-Zyklen laufend integriert. Damit ist nach Scrum entwickelte Software in der Regel wesentlich häufiger Änderungen unterworfen als Software aus klassisch organisierten Projekten. Diese Tatsache stellt auch das Testing vor neue Herausforderungen. Bei traditionellen Ansätzen wie dem Wasserfallmodell werden die Softwaretests in der Regel ans Ende des Projekts gestellt. Demgegenüber versteht sich das agile Testen als kontinuierlicher Prozess, der parallel zu anderen Disziplinen wie Entwicklung oder Integration stattfindet. Auf diese Weise können Fehler bereits frühzeitig gefunden und ausgemerzt werden. Dies ist auch aus betriebswirtschaftlicher Sicht von Bedeutung, da die Folgekosten umso niedriger sind, je zeitiger ein Problem gelöst werden kann. SchNEllER und flexibler TesTEN Allerdings muss das Testing dafür auch mit der wesentlich grösseren Geschwindigkeit und Flexibilität des agilen Entwicklungsprozesses Schritt halten können. So müssen zum einen Testfälle schneller erstellt und auch effizienter durchgeführt werden. Dies lässt sich in der Regel nur mit einem hohen Grad an Testautomatisierung abfangen. Zum anderen wird vom Tester selbst erwartet, dass er die gewählten Methoden dem agilen Ansatz entsprechend laufend reflektiert und auch anpasst. Dabei wird er aber nicht alleine gelassen. Denn in agilen Projekten handelt der Tester nicht mehr länger als isolierte Einheit, sondern ist Teil eines interdisziplinären Teams, in dem sämtliche Mitglieder Arbeiten abseits ihrer zentralen Aufgaben übernehmen: Der Entwickler erledigt auch Testingaufgaben und der Tester Entwicklungsaufgaben. Dies ist letztendlich der Qualität des Endresultats förderlich, da alle Beteiligten mehr Verantwortung für das Gesamtprojekt übernehmen. Überdies wird auf diese Weise der in klassischen Projekten oftmals vorherrschende, tendenziell destruktive Umgang zwischen Entwicklern und Testern gemildert. AgilITät im MINI-WassERfall Dass in Grossprojekten der Agilitätsansatz über den gesamten Testprozess hinweg ausgedehnt wird, ist heute allerdings noch mehr die Ausnahme denn die Regel. In der Praxis findet das Testing meist erst am Ende eines s respektive einer Iteration statt. Dies ergibt sich in erster Linie aus dem Umstand, dass zu Beginn der allerersten Iteration oft noch keine Software existiert, die auf ihre Qualität hin untersucht werden kann. Durch diese Verzögerung ergibt sich in der Praxis häufig eine Art Mini-Wasserfallmodell innerhalb der einzelnen Iterationen (Abb. 1). Damit es dabei nicht zu ei-

3 testing 22 23

4 Dass in Grossprojekten der Agilitätsansatz über den gesamten Testprozess hinweg ausgedehnt wird, ist heute allerdings noch mehr die Ausnahme denn die Regel. In der Praxis findet das Testing meist erst am Ende eines s respektive einer Iteration statt. Dies ergibt sich in erster Linie aus dem Umstand, dass zu Beginn der allerersten Iteration oft noch keine Software existiert, die auf ihre Qualität hin untersucht werden kann.

5 testing Abb. 1: 1 Mini-Wasserfall pro Iteration I1 I2 I3 Ia Zeit A A A D D D P P P T T T Abb. 2: Verzögerungen aus anderen Aktivitäten kumulieren sich zur Testing-Aktivität Anforderung Verzögerung = a a Entwicklung Verzögerung = a + b a + b Test Verzögerung = a + b + c a + b + c nem Teststau kommt, der im schlimmsten Fall den weiteren Entwicklungsprozess behindert oder sogar verunmöglicht, sollte zeitnah auf solche Verschiebungen reagiert werden. So gilt es, die Projektleitung für die Thematik zu sensibilisieren. Diese muss mit einer vorausschauenden Planung sicherstellen, dass Zeit für alle notwendigen Testaktivitäten vorhanden ist. Hinken diese zu stark hinterher, sollten der Test- und/oder der Funktionsumfang der zu liefernden Software angepasst werden (Abb. 2). RisikobasIERTE PRIorisIERung Eine Methode, um diese zeitlichen Engpässe abzufangen, stellt das Risk-based Testing dar. Hierbei richtet sich die Testintensität nach dem Risiko eines fehlerhaften Verhaltens. Die Basis dafür bildet eine Priorisierung der einzelnen Testfälle, wobei sich die Priorität für einen Testfall nach der Wichtigkeit der Anforderung richtet. Reicht am Ende einer Iteration die Zeit nicht mehr für die Abarbeitung sämtlicher Testfälle aus, werden jene mit der jeweils tiefsten Priorität gestrichen. Diese können zu einem späteren Zeitpunkt nachgearbeitet werden. Auf diese Weise erhöht sich die Testeffizienz, während eine maximale Systemstabilität gewährleistet bleibt. Entscheidend für das Risk-based Testing ist aber, dass die Prioritätensetzung vom Kunden abgesegnet wird. Nur so kann die

6 Bei traditionellen Ansätzen wie dem Wasserfallmodell werden die Softwaretests in der Regel ans Ende des Projekts gestellt. Demgegenüber versteht sich das agile Testen als kontinuierlicher Prozess, der parallel zu anderen Disziplinen wie Entwicklung oder Integration stattfindet. Auf diese Weise können Fehler bereits frühzeitig gefunden und ausgemerzt werden. Dies ist auch aus betriebswirtschaftlicher Sicht von Bedeutung, da die Folgekosten umso niedriger sind, je zeitiger ein Problem gelöst werden kann. Abb. 3: Scrum-Modell Planning Teil 1 Teil 2 Backlog Backlog Tasks (durch das Team ausgearbeitet) Product Backlog (priorisiert durch Product Owner) Daily Scrum 24h (... Tage) Abb. 4: Iteration der Software-Releases bei Scrum-Projekten Review Potenziell auslieferbares Produktinkrement Iteration 1 Iteration 2 Daily Scrum Daily Scrum Daily Scrum Planning 24h Planning 24h Planning 24h Teil 1 Teil 2 Teil 1 Teil 2 Teil 1 Teil 2 Review Review Review Backlog Tasks (durch das Team ausgearbeitet) (... Tage) Backlog Tasks (durch das Team ausgearbeitet) (... Tage) Backlog Backlog Backlog Backlog Tasks (durch das Team ausgearbeitet) (... Tage) Product Backlog (priorisiert durch Product Owner) Potenziell auslieferbares Produktinkrement Product Backlog (priorisiert durch Product Owner) Potenziell auslieferbares Produktinkrement Product Backlog (priorisiert durch Product Owner) Potenziell auslieferbares Produktinkrement

7 testing Business-Relevanz gewährleistet werden. Ebenfalls für Entlastung bei Termindruck kann die Einführung einer zusätzlichen Testebene sorgen beispielsweise in Form eines Embedded Testers. Dieser fungiert als objektive Instanz und nimmt eine Schnittstellenfunktion zwischen verschiedenen Teams wahr. Je nachdem wo es im Projekt harzt, kann er verschiedene Testmethoden wie exploratives Testing oder die erste Abnahme der User Stories durchführen. So können Fehler bereits innerhalb der Iteration beseitigt werden, in der sie entstanden sind, und werden nicht als Altlasten in den nächsten Zyklus mitgeschleppt. Beispiel SchNEllERE Feedbacks dank EINbETTung In einer Industriefirma war ein nach Scrum (Abb. 3) geführtes Entwicklungsprojekt ins Stocken geraten. Dieses war in Iterationen à drei s mit einer Länge von jeweils drei Wochen aufgeteilt, was zu äusserst langen Feedbackloops geführt hatte. Die einzelnen Produktinkremente wurden nur rund alle zwei Monate vom Entwicklungs- an das für die Produkttests verantwortliche Softwareintegrationsteam geliefert. So verstrich von der Entstehung der Fehler über ihre Entdeckung und Meldung bis zu ihrer Behebung wertvolle Zeit. Die weitreichende Folge der Verzögerung: Das Projekt verlor zunehmend an Agilität. Der Aufwand für die Fehlerbeseiti-

8 Eine Methode, um diese zeitlichen Engpässe abzufangen, stellt das Risk-based Testing dar. Hierbei richtet sich die Testintensität nach dem Risiko eines fehlerhaften Verhaltens. Die Basis dafür bildet eine Priorisierung der einzelnen Testfälle, wobei sich die Priorität für einen Testfall nach der Wichtigkeit der Anforderung richtet.

9 testing gung wurde immer grösser, da die Entwicklung zwischenzeitlich bereits weiter vorangeschritten war. Überdies mussten sich die Entwickler jedes Mal wieder neu in bereits abgearbeitete Themen hineindenken (Abb. 4). Teams während der Retrospektiven und liefert Anhaltspunkte für künftige Verbesserungen. Nach einer eingehenden Analyse durch die Spezialisten entschied sich das Unternehmen für die Einführung einer zusätzlichen Testinstanz in Form eines sogenannten Embedded Testers. Dieser fungiert heute als Schnittstelle zwischen dem Systemintegrationsund dem Entwicklungsteam. Er verfasst unter anderem die Akzeptanzkriterien für die User Stories, anhand deren er entscheiden kann, ob die Implementierungen tatsächlich den Anforderungen entsprechen und damit abgenommen werden können. Der in das Projekt integrierte Embedded Tester führt im Weiteren kontinuierlich explorative und Blackbox-Tests durch und ist auch für das Issue Management verantwortlich: Er meldet Fehler umgehend dem Entwicklerteam und verifiziert im weiteren verlauf deren Beseitigung. Unterm Strich konnte mit der Einführung des Embedded Testings eine markante Produktivitäts- und Effizienzsteigerung erzielt werden. So hat sich der Feedbackloop verkürzt, was zu einer wesentlich schnelleren Fehlererkennung und -beseitigung führte. Im Weiteren konnte auch das Qualitätsmanagement verbessert werden. Am Ende jedes s gibt ein aussagekräftiger Report des Embedded Testers Aufschluss über die Qualität der umgesetzten User Stories. Dies ermöglicht eine präzisere Reflexion innerhalb des ERNI Innovation in Process and Technology SEVErin Dietschi severin.dietschi@erni.ch Beratertätigkeit: Test Engineering & Test Management Support, Requirements Engineering Edon Berisha edon.berisha@erni.ch Beratertätigkeit: Testing

10 IMPREssum Herausgeber ERNI Management Services AG Zürich Bern Baar Lausanne München Frankfurt Barcelona Bratislava Redaktion Adela Novotná, ERNI (Slovakia) s.r.o. Tel leserservice@erni.ch Lektorat Daniel Meierhans, inhalte.ch GmbH, Zürich Ruedi Häuptli, Sprachagentur Bahia, Salvador BR Konzept/Layout Dieter Nafzger, Katarína Beinrohrová Produktion von Ah Druck AG, Sarnen Auflage Expl. dt., 2500 Expl. en. Erscheint quartalsweise ISSN Copyright 2012 by ERNI Management Services AG Alle Rechte vorbehalten.

11

12