Testing in an agile world

Größe: px

Ab Seite anzeigen:

Download "Testing in an agile world"

Hertha Kappel
vor 6 Jahren
Abrufe

1 Testing in an agile world 13. Neu-Ulmer Test-Engineering-Day Dr. Gabriele Haller gt-muenchen GmbH Josef-Beiser-Str München

3 Prinzipien hinter dem Agilen Manifest 1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. 2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. 3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. 4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. 5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. 6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. 7. Funktionierende Software ist das wichtigste Fortschrittsmaß. 8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. 9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. 10. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. 11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. 12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

4 Umsetzung der agilen Prinzipien

5 Umsetzung der agilen Prinzipien Quelle: Komus, Ayelt et al. Studie: Status Quo Agile 2016/2017; Hochschule Koblenz

6 Umsetzung mit Scrum Framework zur Entwicklung und Pflege von komplexen Produkten iterativ inkrementelles Vorgehen Transparenz, regelmäßige Inspektion, Anpassung hohe Kundenorientierung, Mehrwert schaffen leichtgewichtig und einfach zu verstehen (nicht ganz so einfach umzusetzen) geschaffen und weiter entwickelt von Ken Schwaber und Jeff Sutherland Start Mitte der 90er Jahre übersetzt in über 30 Sprachen freier Download auf

7 Umsetzung mit Scrum

Artefakte Product Backlog Sprint Backlog Increment Zitat aus Scrum Guide Vers.

8 Elemente von Scrum Rollen Product Owner Scrum Master Development Team cross-functional self-organized Scrum Events Alle Events time-boxed (= fixer Zeitrahmen) Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Scrum Artefakte Product Backlog Sprint Backlog Increment Zitat aus Scrum Guide Vers. Nov 2017 : Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

die Rolle des agilen Testers Scrum Team = Product Owner + Scrum Master + Development Team Teamgröße: 3 x 9 PO Dev Dev cross-functional: alle Fähigkeiten zum Erledigen der Arbeit im Team vorhanden

9 die Rolle des agilen Testers Scrum Team = Product Owner + Scrum Master + Development Team Teamgröße: 3 x 9 PO Dev Dev cross-functional: alle Fähigkeiten zum Erledigen der Arbeit im Team vorhanden selbstorganisiert kein Chef T SM Dev Tester? Test Manager? RE Zitat aus Scrum Guide Vers. Nov 2017 : Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

die Rolle des agilen Testers Scrum Team = Product Owner + Scrum Master + Development Team Teamgröße: 3 x 9 PO Dev T Dev cross-functional: alle Fähigkeiten zum Erledigen der Arbeit im Team vorhanden

10 die Rolle des agilen Testers Scrum Team = Product Owner + Scrum Master + Development Team Teamgröße: 3 x 9 PO Dev T Dev cross-functional: alle Fähigkeiten zum Erledigen der Arbeit im Team vorhanden selbstorganisiert kein Chef SM Dev RE Test Manager? Zitat aus Scrum Guide Vers. Nov 2017 : Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

11 Fundamentaler Testprozess (nach ISTQB) Beginn Planung Analyse und Entwurf Steuerung Realisierung & Durchführung Auswertung und Bericht Abschluß Ende

Testen in Scrum Testen erfolgt inkrementell sprintweise - parallel zur Entwicklung Sprint Backlog Inkrement - es sind noch nicht alle Requirements spezifiziert, wenn

12 Testen in Scrum Testen erfolgt inkrementell sprintweise - parallel zur Entwicklung Sprint Backlog Inkrement - es sind noch nicht alle Requirements spezifiziert, wenn man mit der Codierung beginnt nur diejenigen für den aktuellen Sprint (Sprint Backlog) - noch nicht alle Testfälle spezifiziert nur diejenigen für den aktuellen Sprint

13 User story Als <User> möchte ich, damit Akzeptanzkriterien: Beispiel: Als Kundin des Online Bankings möchte ich stets meinen Kontostand angezeigt bekommen, damit ich beim Ausfüllen einer Überweisung nicht versehentlich mein Konto überziehe Akzeptanzkriterium: Kontostand in jedem Screen an derselben Stelle erkennbar. - aus Sicht eines Users geschrieben - kurze, einfache Beschreibung einer Funktionalität (nicht mehr als 2 Sätze) - jede User Story wird auf einer Karte notiert - keine Lösung in einer User Story - jede User Story wird mit Akzeptanz Kriterien ergänzt

14 Testen in Scrum Für jeden Sprint / für jedes Inkrement: 1. die Requirements dieses Sprints verstehen (=user stories mit Akzeptanz Kriterien) 2. täglicher Austausch mit den Entwicklern darüber, wie codiert und wie getestet wird 3. Testfälle werden auf der Basis der Akzeptanzkriterien entworfen 4. Testfälle ausführen, Fehler dokumentieren, täglich Feedback geben 5. Fehler beheben 6. Retrospective im Team Lessons Learned fließen in nächsten Sprint ein Notwendige Changes(an Requirements, Code oder Testfällen) bereits im nächsten Sprint fail fast, fail cheap

15 Testpyramide explor. Testen Manuelle Fehlersuche autom. Testszenarien Unit Tests autom. UI Test autom. Abnahmetest Unit Tests klassisch: Fehler finden agil: Fehler vermeiden

16 Exploratives Testen kein zufälliger, willkürlicher Test Nur bedingt erfahrungsbasierter Test gute Testing Kenntnisse erforderlich keine eigenen Methoden erforschen des Testobjekts kann partiell geplant werden Ziel: Lernen

17 Test driven development Grundidee: Tests werden vor der Codierung entworfen REFACTORING GREEN RED RED: zunächst einen Testfall schreiben, der fehlschlägt. GREEN: soviel Code implementieren, dass der Test erfolgreich durchläuft. REFACTORING: Test und Produktivcode werden refaktorisiert

18 Teststufen im traditionellen Testing Acceptance test System test Integration test Komponenten test Die Teststufen werden hintereinander ausgeführt es gibt Übergabe Gates

19 Die 4 Quadranten des agilen Testings Business Business orientierte Tests, die das Team unterstützen Business orientierte Tests, die das Produkt betrachten Team Technologie orientierte Tests, die das Team unterstützen Technologieorientierte Test, die das Produkt betrachten Produkt Technologie Idee ursprünglich von Brian Marick

20 Die 4 Quadranten des agilen Testings manuell & automat. Prototypen Simulationen Business Exploratives Testen Usability Testing User Acceptance Testing Beta Test manuell Team Unit Tests Komponenten Tests Integrations Tests Performance Testing Load Testing Security Testing Reliability Testing Produkt weitgehend automat. Technologie mit Tools Idee ursprünglich von Brian Marick

21 Die hybride Welt des Testens

22 Zusammenfassung Das Entscheidende beim agilen Testing ist: verstehen, was Agilität bedeutet!!! verstehen, was Agilität für das eigene Projekt bedeutet myagile es gibt nicht DIE agile Lösung / den Standard für Alles die agile Prinzipien leben großer Change im mindset keine neuen Test-Tools, keine neuen Test-Methoden

Ähnliche Dokumente

MURCS Wir machen jetzt Scrum, aber das Meeting passt leider nicht und einen PO haben wir irgendwie auch nicht...

MURCS Wir machen jetzt Scrum, aber das Meeting passt leider nicht und einen PO haben wir irgendwie auch nicht... Ina Einemann @IEinemann Ulf Mewe @mewflu 2 Praxisbeispiele Tourismus Logistik 3 ANALYSE