4
Agiles Testen in Scrum – Testtypen und Abläufe Agile Methoden werden in der Softwareentwicklung immer häufiger eingesetzt. Eine aktuelle Umfrage ergab, dass Scrum die am weitesten verbreitete agile Vorgehensweise ist, welche die Prinzipien des Agilen Manifests (Agilen Manifesto) umsetzt. Allerdings werden sowohl im Agilen Manifest als auch in der Scrum-Beschreibung die Testaktivitäten sowie die Testorganisation vernachläs- sigt. Es werden zwar die Ansätze des Test Driven Development oder der Continuous Integration empfohlen, doch ein systemati- sches Testvorgehen wird nicht beschrieben. Die Testaktivitäten und die Testorganisation spielen aber eine entscheidende Rolle für den Erfolg der agilen Methoden. Mit diesem Artikel füllen wir diese Lücke und stellen ein Konzept von agilen Testtypen und den dabei durchzuführenden Testaktivitäten vor. Unser Konzept verfolgt die Werte des Manifests für agiles Softwaretesten, weswegen wir es agiles Testen nennen. Eingebettet im Scrum besteht es aus drei Testtypen: (1) dem Entwicklertest, der parallel zu täglichen Aktivitäten der Entwickler durchgeführt wird und einen früheren Start der Testaktivitäten ermöglicht; (2) dem Inkrementtest, der die Integration der wöchentlichen und monatlichen Ergebnisse eines Sprints prüft und dabei auf effiziente Automatisierungs- techniken setzt und (3) dem Release-Test, der nach Abschluss der Entwicklungsarbeiten als ein dedizierter Sprint den End-to- End-Test des Systems vorsieht. Zur Realisierung dieser Testtypen definieren wir in unserem Testkonzept die einzelnen Testaktivitäten basierend auf dem zugrunde liegenden Testprozess und die Einbindung typischer Testrollen in den Scrum-Kontext. Artikels wurde von OBJEKTspektrum in Zu- sammenarbeit mit den Autoren ein gleich- namiges Poster veröffentlicht. Der interes- sierte Leser kann das Poster unter der URL www.sigs-datacom.de/fachzeitschriften/at-poster.html kostenlos bestellen. Das Poster gibt einen Gesamtüberblick zu den Inhalten dieses Artikels. Scrum Scrum wurde von Jeff Sutherland und Ken Schwaber entwickelt, welche regelmäßig einen aktuellen Scrum-Guide [SuS] heraus- geben. Scrum basiert auf Iterationen, den sogenannten Sprints, und am Ende eines jeden Sprints soll das Team ein funktions- fähiges Inkrement liefern (s. Abbildung 1). Die umzusetzenden Aufgaben werden im Product Backlog festgehalten. Ein Sprint beinhaltet verschiedene Ereignisse, wie bei- spielsweise die beiden Planungsmeetings am Anfang [Glo11], bei denen die Auf- gaben und deren Umsetzung festgelegt wer- den. Dem schließt sich die Entwicklung mit einem täglichen Daily Scrum, einem 15- minütigen Stand-Up-Meeting an. Am Ende Integration sowie User Acceptance-Tests empfohlen, aber wie, wann und in welcher Weise wird nicht explizit vorgeschrieben. Im aktuellen Scrum-Guide von Jeff Sutherland und Ken Schwaber [SuS] spielt das Testen selbst keine Rolle, es wird dort nicht speziell erwähnt. Eine Gruppe von Testexperten hat diese Lücke erkannt und das „Manifest für Agiles Softwaretesten“ geschrieben [ATM]. Dort wird agiles Testen mit vier Werten charakte- risiert, u. a. „getestete Software mehr als umfassende Test-Dokumentation“ und „Reagieren auf Veränderung mehr als das Befolgen eines Test-Plans“. Allerdings definiert dieses Manifest keine Testtechniken. Es gibt zwar verschiedene Bücher und Artikel zu Testtechniken – hier sei besonders das Buch von Crispin und Gregory [CuG09] genannt –, die diese Lücke füllen, doch keines definiert einen systematischen Testprozess, der einfach und schnell insbesondere in Scrum umsetz- bar ist. Diese Lücke wollen wir mit diesem Artikel füllen. Passend zu den Inhalten dieses Einleitung Die agilen Methoden gewinnen in der heu- tigen Softwareentwicklung immer mehr an Bedeutung. Das Agile Manifest [AgM] empfiehlt ein leichtgewichtiges Vorgehen, um durch häufige Kommunikation und Selbstorganisation im Team eine iterative und effiziente Entwicklung zu realisieren. Die dabei am häufigsten eingesetzte Me- thode mit 52 % weltweit [Ver11] und 57 % deutschlandweit [Win11] ist Scrum. Obwohl nach aktuellen Erkenntnissen das Testen ein wichtiger Erfolgsfaktor für agile Projekte ist (vgl. [Ver11] und [Win11]), gibt es keinen definierten Test- prozess für agile Vorgehensweisen. Die ver- schiedenen agilen Methoden empfehlen zwar kontinuierliches Testen, aber als eine der wenigen Methoden gibt Extreme Programming [Bec99], kurz XP, als eine mögliche Technik das Test Driven Develop- ment an. Ein expliziter Testprozess wird hier nicht definiert. Scrum wird zwar am häufigsten eingesetzt und von Gloger [Glo11] werden beispielsweise Unit-Tests, kontinuierliche der autor Silke Geisen ([email protected]) arbeitet als wissenschaftliche Mitarbeiterin im s-lab – Software Quality Lab – an der Universität Paderborn. Ihre Forschungsinteressen sind die Anpassung von Software Engineering-Methoden, das Method Engineering sowie im Speziellen die agilen Methoden. Baris Güldali ([email protected]) arbeitet als wissenschaftlicher Mitarbeiter im s-lab – Software Quality Lab – an der Universität Paderborn. Seine Arbeitsschwerpunkte sind modellbasier- tes Testen und Testautomatisierung. Er ist gleichzeitig ein aktives Mitglied des Arbeitskreises „Testen objektorientierter Programme / Model-based Testing“ (TOOP/MBT) in der Gesellschaft für Informatik (GI). 1 www.objektspektrum.de fachartikel

Agiles Testen in Scrum – Testtypen und Abläufe · Agiles Testen in Scrum – Testtypen und Abläufe Agile Methoden werden in der Softwareentwicklung immer häufiger eingesetzt

  • Upload
    vankien

  • View
    283

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Agiles Testen in Scrum – Testtypen und Abläufe · Agiles Testen in Scrum – Testtypen und Abläufe Agile Methoden werden in der Softwareentwicklung immer häufiger eingesetzt

Agiles Testen in Scrum – Testtypen und AbläufeAgile Methoden werden in der Softwareentwicklung immer häufiger eingesetzt. Eine aktuelle Umfrage ergab, dass Scrum die amweitesten verbreitete agile Vorgehensweise ist, welche die Prinzipien des Agilen Manifests (Agilen Manifesto) umsetzt. Allerdingswerden sowohl im Agilen Manifest als auch in der Scrum-Beschreibung die Testaktivitäten sowie die Testorganisation vernachläs-sigt. Es werden zwar die Ansätze des Test Driven Development oder der Continuous Integration empfohlen, doch ein systemati-sches Testvorgehen wird nicht beschrieben. Die Testaktivitäten und die Testorganisation spielen aber eine entscheidende Rolle fürden Erfolg der agilen Methoden. Mit diesem Artikel füllen wir diese Lücke und stellen ein Konzept von agilen Testtypen und dendabei durchzuführenden Testaktivitäten vor. Unser Konzept verfolgt die Werte des Manifests für agiles Softwaretesten, weswegenwir es agiles Testen nennen. Eingebettet im Scrum besteht es aus drei Testtypen: (1) dem Entwicklertest, der parallel zu täglichenAktivitäten der Entwickler durchgeführt wird und einen früheren Start der Testaktivitäten ermöglicht; (2) dem Inkrementtest, derdie Integration der wöchentlichen und monatlichen Ergebnisse eines Sprints prüft und dabei auf effiziente Automatisierungs -techniken setzt und (3) dem Release-Test, der nach Abschluss der Entwicklungsarbeiten als ein dedizierter Sprint den End-to-End-Test des Systems vorsieht. Zur Realisierung dieser Testtypen definieren wir in unserem Testkonzept die einzelnenTestaktivitäten basierend auf dem zugrunde liegenden Testprozess und die Einbindung typischer Testrollen in den Scrum-Kontext.

Artikels wurde von OBJEKTspektrum in Zu -sam menarbeit mit den Autoren ein gleich -namiges Poster veröffentlicht. Der interes-sierte Leser kann das Poster unter der URLwww.sigs-datacom.de/fachzeitschriften/at-poster.html

kostenlos bestellen. Das Poster gibt einenGesamtüberblick zu den Inhalten diesesArtikels.

ScrumScrum wurde von Jeff Sutherland und KenSchwaber entwickelt, welche regelmäßigeinen aktuellen Scrum-Guide [SuS] heraus-geben. Scrum basiert auf Iterationen, densogenannten Sprints, und am Ende einesjeden Sprints soll das Team ein funktions-fähiges Inkrement liefern (s. Abbildung 1).

Die umzusetzenden Aufgaben werden imProduct Backlog festgehalten. Ein Sprintbeinhaltet verschiedene Ereignisse, wie bei-spielsweise die beiden Planungsmeetingsam Anfang [Glo11], bei denen die Auf -gaben und deren Umsetzung festgelegt wer-den. Dem schließt sich die Entwicklung miteinem täglichen Daily Scrum, einem 15-minütigen Stand-Up-Meeting an. Am Ende

Integration sowie User Acceptance-Testsempfohlen, aber wie, wann und in welcherWeise wird nicht explizit vorgeschrieben.Im aktuellen Scrum-Guide von JeffSutherland und Ken Schwaber [SuS] spieltdas Testen selbst keine Rolle, es wird dortnicht speziell erwähnt.

Eine Gruppe von Testexperten hat dieseLücke erkannt und das „Manifest für AgilesSoftwaretesten“ geschrieben [ATM]. Dortwird agiles Testen mit vier Werten charakte-risiert, u. a. „getestete Soft ware mehr alsumfassende Test-Dokumentation“ und„Reagieren auf Ver än derung mehr als dasBefolgen eines Test-Plans“.

Allerdings definiert dieses Manifest keineTesttechniken. Es gibt zwar verschiedeneBücher und Artikel zu Testtechniken – hiersei besonders das Buch von Crispin undGregory [CuG09] genannt –, die dieseLücke füllen, doch keines definiert einensystematischen Testprozess, der einfachund schnell insbesondere in Scrum umsetz-bar ist.

Diese Lücke wollen wir mit diesem Arti kelfüllen. Passend zu den Inhalten dieses

EinleitungDie agilen Methoden gewinnen in der heu-tigen Softwareentwicklung immer mehr anBedeutung. Das Agile Manifest [AgM]empfiehlt ein leichtgewichtiges Vorgehen,um durch häufige Kommunikation undSelbstorganisation im Team eine iterativeund effiziente Entwicklung zu realisieren.Die dabei am häufigsten eingesetzte Me -thode mit 52 % weltweit [Ver11] und57 % deutschlandweit [Win11] ist Scrum.

Obwohl nach aktuellen Erkenntnissendas Testen ein wichtiger Erfolgsfaktor füragile Projekte ist (vgl. [Ver11] und[Win11]), gibt es keinen definierten Test -prozess für agile Vorgehensweisen. Die ver-schiedenen agilen Methoden empfehlenzwar kontinuierliches Testen, aber als eineder wenigen Methoden gibt ExtremeProgramming [Bec99], kurz XP, als einemögliche Technik das Test Driven Devel op -ment an.

Ein expliziter Testprozess wird hier nichtdefiniert. Scrum wird zwar am häufigsteneingesetzt und von Gloger [Glo11] werdenbeispielsweise Unit-Tests, kontinuierliche

der au tor

Silke Geisen

([email protected])arbeitet als wissenschaftliche Mitarbeiterin im s-lab – Software Quality Lab –an der Universität Paderborn. Ihre Forschungsinteressen sind die Anpassungvon Software Engineering-Methoden, das Method Engineering sowie imSpeziellen die agilen Methoden.

Baris Güldali

([email protected])arbeitet als wissenschaftlicher Mitarbeiter im s-lab – Software Quality Lab –an der Universität Paderborn. Seine Arbeitsschwerpunkte sind modellbasier-tes Testen und Testautomatisierung. Er ist gleichzeitig ein aktives Mitglied desArbeitskreises „Testen objektorientierter Programme / Model-based Testing“(TOOP/MBT) in der Gesellschaft für Informatik (GI).

1 www.objektspektrum.de

fachartikel

Page 2: Agiles Testen in Scrum – Testtypen und Abläufe · Agiles Testen in Scrum – Testtypen und Abläufe Agile Methoden werden in der Softwareentwicklung immer häufiger eingesetzt

des Sprints gibt es ein Review-Meeting zurBegutachtung des Inkrements und eineabschließende Retrospektive zur Be -sprechung der Arbeit während des Sprints.

Das Scrum-Team besteht aus dem soge-nannten Product Owner, welcher für dasProduct Backlog zuständig und die fachli-che Vertretung des Kunden ist, dem ScrumMaster, welcher dafür sorgt, dass dieScrum-Regeln eingehalten werden, unddem Entwicklungsteam selbst. Zusätzlichsollten bei Gelegenheit noch der Kunde,das Management oder der Endbenutzer miteingebunden werden [Glo11].

In Scrum wird das Liefern eines funk-tionsfähigen Inkrements großgeschrieben.Dafür muss das Inkrement kontinuierlichgetestet werden. Einen großen Anteil bildendabei die Unit-Tests, die kontinuierlicheIntegration und die sogenannten UserAcceptance-Tests [Glo11]. Doch obwohldiese Themen in Scrum [Glo11] angespro-chen werden, nehmen sie nur einen kleinenTeil in dem Gesamtprozess von Scrum ein.

In der Praxis sieht es ähnlich aus. Unit-Tests werden als Technik zwar häufig ein-gesetzt, ebenso wie kontinuierliche Inte -gration, automatische Builds, und ca. einViertel setzen automatische Acceptance-Tests ein [Ver11], doch ein systematischesVorgehen ist bei den wenigsten vorhanden.

In Abbildung 2 ist ein von uns vorge-schlagener angepasster Scrum-Ablauf zusehen. Am Anfang findet eine Phase für dieAnforderungsdefinitionen statt, in der dasProduct Backlog entsteht. In den anschlie-ßenden Sprints finden die beiden TesttypenEntwicklertest (täglich) und ein regelmäßi-ger Inkrementtest (alle 1–4 Wochen mög-lich, je nach Sprintlänge) statt. Abschlie -ßend sollte ein Release-Test stattfinden,welcher analog zu einem typischen Sprintaufgebaut ist.

TestaktivitätenDer fundamentale Testprozess (FTP) isteiner der am verbreitetsten Testprozesseund mittlerweile internationaler ISTQB-Standard [SuL10]. Der Prozess beinhaltetverschiedene Testaktivitäten, welche wäh-rend des gesamten Testprozesses abgedecktsein sollten. Diese Aktivitäten sind dieTestplanung, der Testentwurf, die anschlie-ßende Testimplementierung sowie derenAusführung, eine anschließende Testaus -wertung sowie ein abschließender Testab -schluss.

Unsere Idee ist nun, dass jeder der vonuns vorgeschlagenen Testtypen – Entwick -ler test, Inkrementtest und Release-Test – alldiese Testaktivitäten strukturiert in unter-schiedlicher Intensität anwenden soll.

Dabei lassen sich die FTP-Testaktivitätengut in den eigentlichen Scrum-Ablauf ein-

bauen. Wir schlagen deshalb vor, dass dieTestplanung während des Sprint-Planningsund des Daily Scrums, der Testentwurf, dieTestimplementierung und -ausführungwährend des Sprints, die Testauswertungwährend des Sprint-Reviews sowie derTestabschluss während der Sprint-Retros -pektive stattfinden sollen.

Für die einzelnen Testaktivitäten in denjeweiligen Testtypen sollten die folgendenAspekte genutzt werden: eine Testbasis,gegen welche getestet wird (z. B. Anfor -derungen), die Testobjekte, welche getestetwerden (z. B. ein Inkrement), die Teststufenund Testarten, welche durchgeführt werden(z. B. Systemtest als Teststufe und Re -gressionstest als Testart) sowie die ver-schiedenen Testwerkzeuge, welche das Tes -ten unterstützen.

RollenIm FTP gibt es verschiedene Testrollen, dieübernommen werden müssen: den Test -manager, den Tester an sich, den Testplanersowie den Testauswerter. Diese Rollen las-sen sich ebenfalls gut in den Scrum-Ablaufeinbetten. Dabei übernimmt der ScrumMaster die Rolle des Testmanagers, derProduct Owner kümmert sich um dieTestplanung und -auswertung. Die Rolledes Testers übernimmt keine speziellePerson, jeder im Team ist dafür verant-wortlich. Im Folgenden beschreiben wirnun die einzelnen Testtypen.

EntwicklertestDer Entwicklertest findet während der täg-lichen Entwicklungsarbeit statt. Das Test -ziel ist die Validierung der täglichenEntwicklungsergebnisse gegen die Sprint-Tasks. Jeder Entwickler kümmert sich umseine aktuellen Sprint-Tasks, welche hierals Testbasis dienen, aus der die Testfälleabgeleitet werden müssen. Es ist auch mög-lich, dass die Sprint-Tasks gleich Testfällebeinhalten.

Wie in Abbildung 3 zu sehen, findet wieüblich das Daily Scrum statt, es werdenhier allerdings zusätzlich auch die Test -aufgaben und Testfälle besprochen. Wäh -rend der Implementierung finden kontinu-ierlich, am besten stündlich, diever schiedensten funktionalen Tests statt,wie automatische Build-Tests, kontinuierli-che Integration und insbesondere die Unit-Tests.

Die Testobjekte sind dabei die entstande-nen Klassen, Methoden und die täglichenfertigen Ergebnisse, die Daily Results. Die

2Online Themenspecial Agility 2012

Online Themenspecial Agility 2012 fachartikel

Abbildung 1: Standard-Scrum-Prozessnach [SuS]

Abbildung 2: Der erweiterte Scrum-Prozess inklusive Anforderungsdefinition undTesten

Page 3: Agiles Testen in Scrum – Testtypen und Abläufe · Agiles Testen in Scrum – Testtypen und Abläufe Agile Methoden werden in der Softwareentwicklung immer häufiger eingesetzt

Die Testbasis sind im Gegensatz zum Ent -wicklertest nicht nur die einzelnen Sprint-Tasks, sondern das gesamte Sprint-Back -log, welches das zu liefernde Inkrement,hier auch das Testobjekt, definiert.Zusätzlich wird in der Sprintplanung einesogenannte „Definition of Done“ (DoD)vom Team festgelegt. Diese besagt, wannein Task wirklich fertig ist, wozu u. a. auchdas Testen gehört. Im abschließendenReview Meeting, wird diese „Definition ofDone“ vom Team zusammen mit demProduct Owner ausgewertet, ob sie für dieEntwicklung und das Testen des Inkre -ments erfüllt wurde.

Zur Testdurchführung gehören imInkrementtest als Teststufen neben demEntwicklerintegrationstest insbesondereauch der Systemtest, der prüft, ob das ent-sprechende Inkrement als ein Ganzes funk-tioniert und so vom Benutzer akzeptiertwird. Als Testarten gehören zu diesemTesttyp nicht nur die funktionalen Testsund Regressionstests, sondern insbesonde-re auch die nicht-funktionalen Tests, wiebeispielsweise Performanztests, Usability-Tests usw.

Als entsprechende Unterstützung für dieTests können neben den bereits genanntenUnit-Testwerkzeugen auch Testwerkzeugefür GUIS (bei GUI-basierten Anwen -dungen) sowie Last- und Performanz-Test -werkzeuge eingesetzt werden.

Release-TestDer Release-Test ist ursprünglich in Scrumnicht vorgesehen. Doch gerade dieser wirdin der Praxis als relevant und wichtig ange-sehen, weil dabei das Produkt in seinerGesamtheit getestet werden kann. In einerälteren Version des Scrum-Guides [SuS]wurde dieser ebenso wie eine Release-Planung vorgeschlagen, aber leider in deraktuellen Version gestrichen.

Der Release-Test findet, wie in Abbil -dung 2 dargestellt und in Abbildung 5 ver-feinert, abschließend nach den Inkre -menttests in Form eines dedizierten Sprintsstatt. Häufig wird eine Software in poten-ziell fertigen Inkrementen entwickelt, wel-che aber anschließend zu einem gesamtenRelease zusammengefasst wird. Am Anfangwird geplant, nach wie vielen Sprints einRelease üblicherweise fertig sein soll.

Der Release-Test kann nun ebenfalls –wie in Abbildung 5 zu sehen – als einSprint aufgebaut werden und ist damit wei-ter Scrum-konform. Die Testbasis ist hier

■ Erstens soll die korrekte Funktions -weise des im Sprint entwickeltenInkrements und des korrekten Zusam -menspiels mit früher entwickeltenInkrementen gezeigt werden.

■ Zweitens soll sichergestellt werden,dass frühere Inkremente nicht verän-dert wurden. Der Test kann je nachSprintlänge nach einer Woche oderauch erst nach vier Wochen durchge-führt werden. Abbildung 4 zeigt, dasshier gegen Ende des Sprints einRegressionstest sehr wichtig ist, damitdie alte Funktionalität immer nochrichtig läuft, nachdem neue Funktio -nalität hinzugefügt wurde.

Aktivitäten im Entwicklertest ähneln denAktivitäten im klassischen Unit-Test, wobeizur Unterstützung hier insbesondere ent-wicklungsnahe Unit-Testwerkzeuge einge-setzt werden sollten.

InkrementtestWo der Entwicklertest im täglichen Rah menstattfindet, wird der Inkrementtest erst gegenEnde eines Sprints durchgeführt, wenn dasInkrement fertig wird. Obwohl Aktivitätenim Entwicklertest eine kontinuierlicheQualitätsüberwachung des Inkre mentsermöglichen, ist am Ende eines Sprints eindedizierter Inkrementtest notwendig, um fol-gende Testziele zu gewährleiten:

fachartikel

3 www.objektspektrum.de

Abbildung 3: Der tägliche Entwicklertest

Abbildung 4: Der regelmäßige Inkrementtest während des Sprints

Page 4: Agiles Testen in Scrum – Testtypen und Abläufe · Agiles Testen in Scrum – Testtypen und Abläufe Agile Methoden werden in der Softwareentwicklung immer häufiger eingesetzt

nun das gesamte Product Backlog, da hiernicht nur ein Inkrement nach einem Sprint,sondern das gesamte Produkt das Test -objekt ist.

Anstatt eines Sprint-Backlogs kann ana-log ein sogenanntes Test-Backlog erstelltwerden, welches die gesamten Release-Testsenthält. Als Teststufen enthalten dieseRelease-Tests Systemintegrationstests, In be -trieb nahmetests und insbesondereAkzeptanztests. Im Release-Test können dieTestfälle aus den Inkrementtests wieder ver-wendet werden, sodass für den Testentwurfkein erheblicher Zusatzauf wand entsteht.

Als Testart ist hier neben den funktiona-len und nicht-funktionalen Tests auch dassogenannte End-To-End-Testing zu finden,welches über das gesamte System und Pro -dukt im Zusammenspiel aller Kompo -nenten stattfindet. Für die Durchführung

der Tests wird das Test-Backlog analogzum Sprint-Backlog in Test-Tasks aufge-teilt, welche täglich entwickelt und durch-geführt werden.

Weiterhin findet ein Daily Scrum statt,um die Arbeit zu besprechen. Auf stünd-licher Basis findet neben den Tests auch dasDebugging statt, um Fehler zu finden undzu beheben. Am Ende des Tages steht einTest-Report an. Am Ende des Sprints fin-det nicht nur eine Auswertung der speziel-len Definition of Done bezüglich desReleases statt, sondern ebenfalls die finaleKundenabnahme des Produktes. ZurUnterstützung der Release-Tests könnenebenso wie beim Entwicklertest GUI-Testwerkzeuge, Last- und Performanz-Testwerkzeuge usw. zum Einsatz kommen.

ZusammenfassungObwohl in Scrum heutzutage Testen alsbesonders wichtig angesehen wird, fehleneine systematische Vorgehensweise und einstrukturierter Testprozess. Mit diesemArtikel haben wir versucht diese Lücke zuschließen, indem wir eine Dreiteilung derTesttypen integriert in den Scrum-Ablaufvorschlagen. Die drei Testtypen – Ent wick -lertest, Inkrementtest und Release-Test – ver-wenden dabei die typischen Scrum-Doku - mente, wie Product Backlog, Sprint Backlogund das neue Test Backlog, als Testbasis unddie entstehenden Ergebnisse als Testobjekt

Ebenso lassen sich die Testarten, Test -stufen und Testaktivitäten des fundamenta-len Testprozesses mit unserem Vorschlag inScrum vereinbaren. Dadurch liefern wir einstrukturiertes und systematisches Vorgehenfür das Testen in Scrum nach dem interna-tionalen Standard. ■

4Online Themenspecial Agility 2012

Online Themenspecial Agility 2012 fachartikel

Abbildung 5: Der abschließende Sprint zum Release-Test

Referenzen

[AgM] Agile Manifesto: www.agilemanifesto.org

[Ver11] VersionOne: State of Agile Development – Survey, 2011,

www.versionone.com/state_of_agile_development_survey/11/

[Win11] Peter Haberl, Andreas Spillner, Karin Vosseberg, Mario Winter: Umfrage 2011:

Softwaretest in der Praxis, dpunkt.verlag, 2011 - www.softwaretest-umfrage.de

[Bec99] Kent Beck: Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999

[Glo11] Boris Gloger: Scrum, Hanser Verlag, 2011

[CuG09] Lisa Crispin, Janet Gregory: Agile Testing, Addison-Wesley, 2009

[SuS] Ken Schwaber, Jeff Sutherland: ScrumGuide, www.scrum.org

[ATM] Agile Testing Manifesto: www.agiletestingmanifesto.de

[SuL10] Andreas Spillner, Tilo Linz: Basiswissen Softwaretest, Ausgabe 4, dpunkt Verlag, 2010