SlideShare ist ein Scribd-Unternehmen logo
Uwe Vigenschow : Agiles Testen – Das agile Team im Einsatz ! Was ist ein Scrum-Team? Typische Testprobleme in Scrum-Teams Das agile Team als Lösung Aufgabenverteilung im agilen Test Definition of Done Arbeiten mit Persona und Szenarien
Einstiegsfrage: Wie lautet das agile Manifest?
Das agile Manifest Menschen und Zusammenarbeit   vor Prozessen und Werkzeugen Funktionierende Software   vor umfassender Dokumentation Zusammenarbeit mit dem Kunden   vor vertraglicher Verhandlung Reaktion auf Veränderung   vor Einhaltung eines Plans <rechte Seite>  sind wertvoll, ABER  <linke Seite>  sind wichtiger  und sollen nicht durch  <rechte Seite>  behindert werden. Wie können wir  <rechte Seite>  so einsetzen, dass es  <linke Seite>  unterstützt? Welcher Grad des Einsatzes von  <rechte Seite>  ist hierfür angemessen? http://www.agilemanifesto.org http://www.agilealliance.com
Wichtige agile Prinzipien Höchste Priorität hat die  Zufriedenstellung des Auftraggebers  durch frühe und kontinuierliche Lieferung brauchbarer Software. Die Software wird  inkrementell  und in kurzen Iterationen erstellt. Fachexperten und Entwickler arbeiten möglichst  direkt und täglich  zusammen. Die effizienteste und effektivste Art Informationen zu verbreiten ist die  direkte Kommunikation  von Angesicht zu Angesicht. Funktionierende Software  ist die primäre Kenngröße für den Projektfortschritt. Konzentration auf das Wesentliche  heißt explizit und regelmäßig zu entscheiden, was wegzulassen ist.  Das Entwicklungsteam  reflektiert  in regelmäßigen Abständen darüber, wie es die gemeinsame Arbeit verbessern kann.
Folgerungen aus den agilen Prinzipen Teste oft und früh! Entwickler, Fachexperten und Tester arbeiten direkt und eng zusammen! Entwickler, Fachexperten und Tester bilden ein gemeinsames, agiles Team! Jedes Mitglied des agilen Teams fokussiert darauf regelmäßig  Ergebnisse  zu liefern! die geforderte  Qualität  zu liefern! Geschäftswert  zu liefern! Gemeinsam wird eine Vision und das Projektziel definiert! Die Gesamtplanung erfolgt auf einem abstrakten Niveau auf Basis priorisierter Kundenanforderungen! Detaillierte Anforderungen werden innerhalb einer Iteration aufgenommen, umgesetzt, getestet und abgenommen!
Was ist ein Scrum-Team? Scrum als agiles Projektmanagement-Framework Minimale Anzahl an Rollen Minimale Anzahl an Artefakten Minimaler iterativer Prozess Rollen in Scrum Product Owner Scrum Master Team Artefakte Backlogs Product Sprint Impediment Burndown Chart
Rollen in Scrum: das Scrum Team Auftraggeber / Stakeholder Das Scrum-Team ist selbst dafür verantwortlich seine Arbeit zu organisieren und niemand außerhalb des Scrum-Teams kann ihm vorschreiben, wie es seine Arbeit tun soll. Scrum Master Product- Owner Team Scrum Team
Scrum Master Der Scrum-Master ist dafür verantwortlich, dass die Scrum-Regeln und -Abläufe eingehalten werden und die nötigen Rahmenbedingungen vorhanden sind. Der Scrum-Master unterstützt das Scrum-Team und das Umfeld dabei die Prozesse mit Leben zu füllen und weiterzuentwickeln Der Scrum-Master ist  nicht  der „Chef“, er hat eher eine Coaching- und Unterstützer-Rolle
Produkt Owner Der Produkt-Owner ist die Person die das Produkt-Backlog verantwortet. Er entscheidet unabhängig darüber welche Anforderungen, mit welcher Priorität enthalten sind. Der Produkt-Owner ist für den Nutzen und die Wirtschaftlichkeit der im Produkt-Backlog enthaltenen Anforderungen verantwortlich. Der Produkt-Owner wird in seinen Entscheidungen von niemanden überstimmt. Er alleine setzt die Prioritäten für die Arbeit des Teams.
Das Team Das Team entwickelt aus den Features im Backlog ein funktionierendes Produkt. Das Team organisiert sich selbst. Es gibt im Team keine Titel oder besondere Rollen. Das Team ist so besetzt, dass alle benötigten Fähigkeiten und Fachkenntnisse im Team vorhanden sind Nur das Team selbst legt fest, wie viel Arbeit es in einem Sprint erledigt. Teams sollten nicht größer als 7 Mitglieder sein. Die Team-Zusammensetzung kann - wenn nötig - am Ende eines Sprints geändert werden.
Scrum-Ablaufstruktur Sprint (timeboxed) Daily-Scrum Review Retrospektive Sprint-Planung
Verantwortlichkeiten Kunde Entwickler Anforderungen Schätzung Kunde Entwickler Priorisieren Funktionen Kunde
Die traditionelle Teamauffassung Entwickler reden mit Analytikern und erstellen Software. Fachexperten liefern ihre Information bei den Analytikern ab. Analytiker dokumentieren bzw. modellieren die Anforderungen. Tester lesen die Anforderungen und testen das Ergebnis. Folge: Er wird versucht, Qualität in das Produkt „hineinzutesten“! Entwicklungsteam Fach- experten Tester Program- mierer Analytiker
Simples Scrum Entwickler reden mit einem Product Owner und erstellen Software. Fachexperten diskutieren mit dem Product Owner. Product Owner dokumentieren die Anforderungen und nimmt die Ergebnisse ab. Scrum Master steuert den Prozess sowie die Prozessverbesserung. Folge: Product Owner ist oft überfordert! Entwickler Product Owner Entwicklungsteam Fach- experten Scrum Master
Typische Probleme mit QS und Tests in Scrum Teams Der gesamte Test liegt in der Verantwortung von Team und Product Owner. Der Product Owner testet nur Akzeptanzfälle. Das Team führt nur Entwicklertests durch und implementiert Unittests.    Die Testqualität ist gering, da methodische Systemtests fehlen! Einer übergeordneten Qualitätsmanagement fehlt ein adäquater Ansprechpartner für testmethodische Aspekte und Prozessverbesserungen.    Der Inspect-and-Adapt-Mechanismus im Scrum vernachlässigt Testaspekte! Die Verantwortung für die Ergebnisqualität wird primär aus Entwicklersicht wahrgenommen.    Die fachlichen Sonderfälle und Ausnahmen finden zu wenig Berücksichtigung!
Agiles Testen als Lösungsweg Bereits in der Projektvorbereitung Durchgängig begleitend bis zum Projektende Verteilt auf alle Rollen Entwickler – Testgetrieben vorgehen, Unit Tests, Komponententests, FIT-Automatisierung Fachexperten / Product Owner – Abnahme- und Akzeptanztests erstellen und durchführen Tester – Persona, Szenarien, Testfälle und Integrationstests erstellen und durchführen, FIT-Automatisierung, UI-Testautomatisierung der Regressionstests Treiber für die interne Prozessverbesserung Agiles Testen ist die Integration Qualität sichernder Maßnahmen in den agilen Entwicklungsprozess. Agiles Testen basiert auf einem ganzheitlichen Team-Ansatz.
Rollen in agilen Team: das agile Team Auftraggeber / Stakeholder Das Scrum-Team ist selbst dafür verantwortlich seine Arbeit zu organisieren und niemand außerhalb des Scrum-Teams kann ihm vorschreiben, wie es seine Arbeit tun soll. Scrum Master Product- Owner Team Agiles Team Tester
Tester Der Tester bringt während des gesamten Projektablaufs die Testsicht in das agile Team ein. Der Tester schärft die Anforderungen über Persona und Szenarien bzw. Story Maps. Dabei wird besonders auf die nicht-funktionalen Anforderungen fokussiert. Der Tester unterstützt Entwickler methodisch bei den Unit-Tests Entwickler bei der fachlichen Architektur durch entsprechende fachliche Strukturen in den Tests Product Owner bei der fachlichen Priorisierung Product Owner bei der Abnahme der Iterationsergebnisse Der Tester führt die Integrationstests und die entsprechenden Regressionstests durch und sorgt so von Anfang an für Produktqualität.
Ganzheitliches agiles Team (am Beispiel der Scrum-Rollen) Entwickler erstellen testgetrieben die Software. Product Owner moderiert, organisiert und definiert die Prioritäten. Entwickler, Tester und Fachexperten diskutieren gemeinsam die Anforderungen. Tester führen aussagekräftige, testmethodische Prüfungen durch. Folge: Tests erfolgen auf allen Ebenen früh und oft! Agiles Team Fach- experten Entwick- lungs- team Tester PO SM SWE
Ganzheitliches agiles Team (am Beispiel der Scrum-Rollen) Entwickler erstellen testgetrieben die Software. Product Owner moderiert, organisiert und definiert die Prioritäten. Entwickler, Tester und Fachexperten diskutieren gemeinsam die Anforderungen. Tester führen aussagekräftige, testmethodische Prüfungen durch. Folge: Tests erfolgen auf allen Ebenen früh und oft! Agiles Team Fach- experten Entwick- lungs- team Tester PO SM SWE
Verantwortlichkeiten im agilen Team Agiles Team Fach- experten Entwick- lungs- team Tester Entwicklungsmethodik Analysemethodik Projektplanung Testgetriebenes Design Entwicklungsprozess Projektidee und Vision Fachwissen Nutzen/geschäftlicher Wert Fachliche Prioritäten Testmethodik Testplanung/Testprozess Testautomatisierung (UI) Fachwissen PO SM SWE
Testen im agilen Team Agiles Team Fach- experten Entwick- lungs- team Tester Testgetriebenes Vorgehen Unit-Tests Komponententests Abnahmetests Akzeptenaztests Integrationstests Systemtests (Regressionstests) PO SM SWE
Grundprinzip: Alle gemeinsam an einem Tisch! Anforderungsbezogen Wer sind die richtigen Teilnehmer? Wann ist der richtige Zeitpunkt? Ziele Gemeinsame Übersicht der Inhalte und Prioritäten Gegenseitiger Austausch der unterschiedlichen Sichten
Ein Team bilden! Rollen klären! Verantwortung Aufgaben Rechte und Pflichten Ziele klären! Projekt Team individuell
Ein Team bilden! Rollen klären! Verantwortung Aufgaben Rechte und Pflichten Ziele klären! Projekt Team individuell Übung zur Teambildung: Der Zollstock
Übung: Der Zollstock Fotos: Anton Dumler
Agile Teststruktur Technisch-architekturelle Betrachtung Unterstützung des agilen Teams Q1 ?
Agile Teststruktur Technisch-architekturelle Betrachtung Unterstützung des agilen Teams Q1 Unit Tests Komponententests testgetriebenes Design
Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Q1 Q2 Unit Tests Komponententests testgetriebenes Design ?
Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Q1 Q2 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen
Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen ?
Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests
Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Q4 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests ?
Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Q4 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests Performance Tests Lasttests Sicherheitstests „ böswillige“ Tests
Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Q4 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests Performance Tests Lasttests Sicherheitstests „ böswillige“ Tests
Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts nach: L. Crispin, J. Gregory: Agile Testing. Addison-Wesley, 2009 Q1 Q2 Q3 Q4 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests Performance Tests Lasttests Sicherheitstests „ böswillige“ Tests automatisiert & manuell automatisiert manuell Werkzeuge
Risiken in agilen Testen Vision nicht aus den Augen verlieren! Kleinteiliges, schrittweises Arbeiten an konkreter Anforderung erschwert den Blick auf das Ganze. Symptome wie Verzetteln und inhaltlich im Kreis drehen müssen sofort behandelt werden. Agil ist das Gegenteil von chaotisch! Agilität wird häufig dahingehend missverstanden, chaotisch zu sein. Der Managementaufwand ist in agilen Projekten eher höher als im „Wasserfall“. Sehr hohe Verantwortung im agilen Team! Regeln regelmäßig hinterfragen und Prozesse auf den Prüfstand stellen. Falsch verstandene Agilität wieder auf die geordnete Spur bringen. Hoher Gruppendruck schafft das Risiko von Burnout-Symptomen.
Wann ist etwas fertig Fertig? „ Habe ich fertig getestet, ist integriert und mit Herrn A. durchgegangen.“ „ Läuft in der Produktion, bisher keine Fehlermeldungen.“ „ Bin fertig, muss ich nur noch einchecken.“ „ Bin fast fertig, Morgen bin ich durch.“ „ Also, bei mir auf dem Rechner läufts.“ „ Ist im Integrationtest“ „ Noch nicht ganz, so ca 80%-Fertig.“
Kriterien für die Definition von „Fertig“ Alle Arbeiten im Zusammenhang mit dem Feature sind erledigt (Integration, Test, Dokumentation, [Teil-]Abnahme, ...) Wie können das Feature „von unserer Liste nehmen“, mit Nacharbeiten ist nicht mehr zu rechnen. Wir werden keine „Überraschungen“ mehr mit dem Feature erleben. Die verbliebenen Arbeiten sind geplant und beinhalten kein großes Risiko mehr. Ich würde die Entwickler des Features mit gutem Gewissen jetzt aus dem Projekt entlassen.
Minimierung von unfertiger Arbeit Angefangene und „unfertige“ Arbeit im Projekt Erhöht den Verwaltungsaufwand Macht es schwierig einzuschätzen wo das Projekt steht Erhöht das Risiko von unentdeckten Fehlern und unerwünschten Wechselwirkungen der Lösungen Macht es schwierig auf Problemen zu reagieren Verschleiert den Blick darauf, dass eigentlich nichts fertig ist Unfertige Arbeit ist teuer und schwierig zu managen. Unfertige Arbeit ist so weit wie möglich zu minimieren.
Struktur Anforderung Story, Use Case, Feature, Szenario, ... Iteration bzw. Sprint Release Behinderungen
Struktur und Beispiele für Definition of Done Anforderung Story, Use Case, Feature, Szenario, ... Iteration bzw. Sprint Release Behinderungen Dokumentierter Code Alle Unit-Tests laufen Alle UI-Tests  laufen ... ... ... ... User Acceptance Test O.K. Alle FIT-Tests laufen Alle Release- Test O.K. Intranet-Seiten sind aktualisiert Anwender sind über Änderungen informiert Laufender Code in abhängigen Altsystemen
Persona – konkret und doch abstrakt Ziele der Persona Beruf, Funktion, Verantwortlichkeiten und Aufgaben der Persona Fachliche Ausbildung, Wissen und Fähigkeiten Verhaltensmuster und Vorgehensweisen Werte, Ängste, Sehnsüchte und Vorlieben Allgemeine Computerkenntnisse Kenntnisse über verwandte oder Konkurrenzprodukte sowie Vorgängersysteme Verbesserungspotenzial in der aktuell eingesetzten Lösung (Sicht der Persona) Erwartungen der Persona an die neue Lösung Mit einer  Persona  beschreiben wir einen typischen Vertreter aus einer Kategorie möglicher Anwender so plastisch und greifbar, als ob die Person neben uns stünde.
Persona – eine idealisierte Person zum Leben erwecken! Name, Alter und Geschlecht Beschreibung der markanten Charakterzüge Foto oder Skizze Passende Zitate aus unseren fiktiven Analyse-Interviews Beschreibung eines typischen Tags im Leben der Persona Mit einer  Persona  beschreiben wir einen typischen Vertreter aus einer Kategorie möglicher Anwender so plastisch und greifbar, als ob die Person neben uns stünde.
Beispiel – Anwender einer Textverarbeitung Petra Mitarbeiterin in der Marketingabteilung der Beispiel GmbH 34 Jahre alt, Studium zum Kommunikationswirt Petra ist seit 5 Jahren bei der Beispiel GmbH und arbeit mit ihrem Chef, dem Marketingleiter Klaus eng zusammen. Sie hat vorher bereits 2 Jahre als Marketing-assistentin bei einer Agentur gearbeitet.  Petra arbeitet beinahe täglich mit der Software. Sie erstellt damit Druckvorlagen für die meisten Marketingunterlagen und etwa 1 – 2 mal im Monat gezielte Serienbriefe für ausgewählte Zielgruppen. Sie ist auch für die Pflege der Daten in den verschiedenen Kunden- bzw. Firmendatenbanken verantwortlich. Sie ist mit der Arbeit am PC seit der Schule vertraut und geht mit den notwendigen Programmen virtuos um. Sie hat ein hohes technisches Verständnis, weshalb sie bei ihren Kollegen und ihrem Chef ein hohes Ansehen genießt. Sie wird daher auch primär mit den wichtigen Aufgaben im Umgang mit den verschiedenen Programmen und den Datenbanken betraut. Aus ihrer Arbeit bei der Agentur kennt sie auch das Konkurrenzprodukt  Büroware Version 4.5 . Petra ist es gewohnt unter hohem Zeitdruck schnell qualitativ hochwertige Ergebnisse zu produzieren. Daher arbeitet sie sich intensiv in die notwendigen Programme ein, was ihr auch viel Spaß bereitet. Dabei verlässt sie sich vollkommen auf die Qualität der Software. Solange diese fehlerfrei und schnell arbeitet, ist sie der größte Fan des Produkts ...
Beispiel – Anwender einer Textverarbeitung Peter Sachbearbeiter und Teamleiter bei einer Versicherung 36 Jahre, Ausbildung zum Kaufmann für Versicherung und Finanzen Peter ist sei 14 Jahren bei einer Versicherung angestellt und hat dort in  den 3 Jahren zuvor seine Ausbildung gemacht. Seit 4 Jahren ist er Leiter des Teams und neben der Leitungsaufgabe für die Bearbeitung der schwierigen Fälle verantwortlich. Er kennt das Produkt aus der Firma und benutzt es in der Home-Version auch privat. Sowohl beruflich als auch privat nutzt er das Produkt im Wesentlichen zum Schreiben von Briefen. In der Firma setzt er dafür ein Firmen-Template ein, privat ein unverändertes Standard-Template. Er hat noch nie die Templates verändert, sondern benutzt sie nur als Grundlage für seine Briefe. Sein wichtigsten Werkzeuge sind das Telefon und sein Filofax. Den PC nutzt er berufliche nur für die unvermeidlichen Pflichtaufgaben und das Schreiben von Briefen. Privat nutzt er das Internet als Informationsquelle, zum Online-Banking und Bestellen von Büchern, CDs, DVDs usw. Die Home-Version war beim PC bereits beim Kauf mit dabei. Da er die Software aus der Firma kennt, nutzt er sie gelegentlich zum Schreiben von Briefen ...
Persona klassifizieren Primäre Persona Wir optimieren für deren Bedürfnisse und Anforderungen das Produkt und erstellen die dazu passende Benutzerschnittstelle. Sekundäre Persona Deren Bedürfnisse sind zum größten Teil durch eine primäre Persona abgedeckt. Sie liefert daher daher Ergänzungen bzw. Abweichungen. Ergänzende Persona Deren Bedürfnisse sind bereits vollständig durch eine primäre oder sekundäre Persona abgedeckt. Non-Persona Diese Persona wird explizit nicht berücksichtigt. Daher gibt es keine Optimierungen der Software für diese Persona.
Persona für den täglichen Einsatz – Kurzbeschreibung an der Wand!
Szenario – Interaktion aus Anwendersicht Beschreiben meist das Zusammenspiel von mehrere Anwendungsfällen oder User Stories Realistische Beschreibungen der (zukünftigen) typischen oder extremen Interaktion zwischen Benutzer und System Detaillierte Verlaufsprotokolle Einfache Sätze verwenden, damit ein Szenario sofort erfassbar ist! Schwächen in der formalen Korrektheit sind erlaubt, solange inhaltlich die richtigen Aussagen getroffen werden. Qualitative Anforderungen werden aus dem Kontext heraus deutlich gemacht. Basis für die Entwicklung und die Testfallerstellung Szenarien  bilden die Anwendersicht auf unsere Anforderungen in Form von  Anwendungsfällen oder User Stories ab. Sie schlagen die Brücke zwischen den  strukturierten Anforderungen und deren Umsetzung in einer neuen Lösung!
Beispiel – Anwendung einer Textverarbeitung Szenario 08-15: Serienbrief mit gefilterten Kundendaten Es ist 16 Uhr. Bei Petra klingelt das Telefon und ihr Chef, der Marketingleiter Klaus hat einen dringlichen Wunsch. Er ist bei einem wichtigen Kunden vor Ort und hat gerade davon erfahren, dass der größte Konkurrenz diese Woche gezielt die Kunden der Beispiel GmbH anschreibt, um sie mit einer Rabattaktion abzuwerben. Petra soll noch heute alle aktiven Kunden aus diesem und dem letzten Jahr anschreiben und ihnen einen Treuerabatt von 15 % für die nächsten zwei Jahre anbieten. Die Briefe müssen heute noch in die Post. Petra hat sich alles notiert und startet das Serienbriefmodul SB2.0. Sie entwirft das Schreiben und wählt dazu zuerst ein passendes, bereits an das Corporate Design der Beispiel GmbH angepasstes Template aus der Auswahlliste aus. Jetzt verfasst sie einen ersten Entwurf des Anschreibens. Sie kopiert sich dazu zwei Textblöcke aus älteren Serienbriefen in das noch leere, neue Dokument und erstellt dann das Anschreiben. Abschließend geht sie in die Serienbrief-Adressfunktion und wählt die Kundendatenbank aus. Damit der Serienbrief nur an die aktuellen aktiven Kunden heraus geht, erstellt sie zusätzlich eine Adress-Filterfunktion. Sie stellt den Filter mit dem Regeleditor zusammen und startet einen Testlauf. In der übersichtlich aufbereiteten Darstellung der gefilterten Kunden findet sie sofort noch einen Sonderfall, der nicht in diese Serienbriefaktion mit eingebunden werden darf. Sie passt die Filterregel an und prüft erneut das Ergebnis in einem Testlauf. Dort stehen jetzt noch die 102 gewünschten Kunden ...
Szenarien als Basis für Akzeptanztests Mehrwert durch Persona mit Szenarien Das Team bekommt eine bessere Sicht auf die Bedürfnisse der Anwender. Szenarien sind ein wirkungsvolles Mittel für das Design und den Test der Usability. Aus Szenarien können Akzeptanztests abgeleitet werden. Akzeptanztests liegen zumindest teilweise während des ganzen Entwicklungsprozesses vor. Die Qualität des Abnahmetests durch den Kunden ist hoch. Um den Kundennutzen zu maximieren, sind Persona und Szenarien eines  der effizientesten und effektivsten Mittel. Sie passen daher besonders gut zu einer agilen Softwareentwicklung!
Literatur zum Thema
Film zum Buch – unsere Seminare Wollen Sie genau wissen, wie agiles Testen funktioniert? Dann besuchen Sie doch eines unserer Seminare! Agiles Testen  http://www.oose.de/swe/training/at_agiles_testen.html Testgetriebene Softwareentwicklung http://www.oose.de/swe/training/tdd4_testgetriebene_softwareentwicklung.html   UML für Tester http://www.oose.de/swe/training/umlt_uml_fuer_tester.html   Qualitätssicherung in der Praxis / Certified Tester FL-Zertifizierung http://www.oose.de/swe/training/qsp_qualitaetssicherung_in_der_praxis.html

Weitere ähnliche Inhalte

Was ist angesagt?

ISTQB Foundation Agile Tester 2014 Training, Agile SW Development
ISTQB Foundation Agile Tester 2014 Training, Agile SW DevelopmentISTQB Foundation Agile Tester 2014 Training, Agile SW Development
ISTQB Foundation Agile Tester 2014 Training, Agile SW Development
Amr Ali (ISTQB CTAL Full, CSM, ITIL Foundation)
 
What Is A Sprint Planning Meeting
What Is A Sprint Planning MeetingWhat Is A Sprint Planning Meeting
What Is A Sprint Planning Meeting
Vikrama Dhiman
 
Agile scrum fundamentals
Agile scrum fundamentalsAgile scrum fundamentals
Agile scrum fundamentals
Deniz Gungor
 
Agile Process Introduction
Agile Process IntroductionAgile Process Introduction
Agile Process Introduction
Nguyen Hai
 
Agile Metrics
Agile MetricsAgile Metrics
Agile Metrics
Mikalai Alimenkou
 
2017 Scrum by Picture
2017 Scrum by Picture2017 Scrum by Picture
2017 Scrum by Picture
Pawel Lewinski
 
Agile - Scrum Presentation
Agile - Scrum PresentationAgile - Scrum Presentation
Agile - Scrum Presentation
gihanlsw
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
Omar Al-Sabek
 
User Stories explained
User Stories explainedUser Stories explained
User Stories explained
Martin Lapointe, M.T.I.
 
What is scrum in Agile methodology?
What is scrum in Agile methodology?What is scrum in Agile methodology?
What is scrum in Agile methodology?
Mario Lucero
 
Practical Guide to Scrum
Practical Guide to ScrumPractical Guide to Scrum
Practical Guide to Scrum
Pavel Dabrytski
 
Scrum in an hour
Scrum in an hourScrum in an hour
Scrum in an hour
Giordano Scalzo
 
Scrum Training
Scrum TrainingScrum Training
Scrum Training
Qasim Mehmood MBA-PM
 
Practical Scrum - one day training
Practical Scrum - one day training Practical Scrum - one day training
Practical Scrum - one day training
Anat (Alon) Salhov
 
Agile Testing Introduction
Agile Testing IntroductionAgile Testing Introduction
Agile Testing Introduction
Hai Tran Son
 
Scrum In 15 Minutes
Scrum In 15 MinutesScrum In 15 Minutes
Scrum In 15 Minutes
Srikanth Shreenivas
 
An Agile Development Primer
An Agile Development PrimerAn Agile Development Primer
An Agile Development Primer
Derek Winter
 
Agile scrum training
Agile scrum trainingAgile scrum training
Agile Scrum Presentation-Detailed
Agile Scrum Presentation-DetailedAgile Scrum Presentation-Detailed
Agile Scrum Presentation-Detailed
Prashaanth T R
 
GetScrumban Game Facilitator Guide
GetScrumban Game  Facilitator GuideGetScrumban Game  Facilitator Guide
GetScrumban Game Facilitator Guide
Ajay Reddy
 

Was ist angesagt? (20)

ISTQB Foundation Agile Tester 2014 Training, Agile SW Development
ISTQB Foundation Agile Tester 2014 Training, Agile SW DevelopmentISTQB Foundation Agile Tester 2014 Training, Agile SW Development
ISTQB Foundation Agile Tester 2014 Training, Agile SW Development
 
What Is A Sprint Planning Meeting
What Is A Sprint Planning MeetingWhat Is A Sprint Planning Meeting
What Is A Sprint Planning Meeting
 
Agile scrum fundamentals
Agile scrum fundamentalsAgile scrum fundamentals
Agile scrum fundamentals
 
Agile Process Introduction
Agile Process IntroductionAgile Process Introduction
Agile Process Introduction
 
Agile Metrics
Agile MetricsAgile Metrics
Agile Metrics
 
2017 Scrum by Picture
2017 Scrum by Picture2017 Scrum by Picture
2017 Scrum by Picture
 
Agile - Scrum Presentation
Agile - Scrum PresentationAgile - Scrum Presentation
Agile - Scrum Presentation
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
 
User Stories explained
User Stories explainedUser Stories explained
User Stories explained
 
What is scrum in Agile methodology?
What is scrum in Agile methodology?What is scrum in Agile methodology?
What is scrum in Agile methodology?
 
Practical Guide to Scrum
Practical Guide to ScrumPractical Guide to Scrum
Practical Guide to Scrum
 
Scrum in an hour
Scrum in an hourScrum in an hour
Scrum in an hour
 
Scrum Training
Scrum TrainingScrum Training
Scrum Training
 
Practical Scrum - one day training
Practical Scrum - one day training Practical Scrum - one day training
Practical Scrum - one day training
 
Agile Testing Introduction
Agile Testing IntroductionAgile Testing Introduction
Agile Testing Introduction
 
Scrum In 15 Minutes
Scrum In 15 MinutesScrum In 15 Minutes
Scrum In 15 Minutes
 
An Agile Development Primer
An Agile Development PrimerAn Agile Development Primer
An Agile Development Primer
 
Agile scrum training
Agile scrum trainingAgile scrum training
Agile scrum training
 
Agile Scrum Presentation-Detailed
Agile Scrum Presentation-DetailedAgile Scrum Presentation-Detailed
Agile Scrum Presentation-Detailed
 
GetScrumban Game Facilitator Guide
GetScrumban Game  Facilitator GuideGetScrumban Game  Facilitator Guide
GetScrumban Game Facilitator Guide
 

Andere mochten auch

Agile testing quadrants discussion
Agile testing quadrants discussionAgile testing quadrants discussion
Agile testing quadrants discussion
Mary Jiang
 
Innovationskennzahlen - Kann man Innovation messen?
Innovationskennzahlen - Kann man Innovation messen?Innovationskennzahlen - Kann man Innovation messen?
Innovationskennzahlen - Kann man Innovation messen?
Maria Tagwerker-Sturm
 
Agiles PM –Evidenzbasiertes PM -Ansätze zur Produktenentwickung
Agiles PM –Evidenzbasiertes PM -Ansätze zur ProduktenentwickungAgiles PM –Evidenzbasiertes PM -Ansätze zur Produktenentwickung
Agiles PM –Evidenzbasiertes PM -Ansätze zur Produktenentwickung
Ayelt Komus
 
Dkv 18 Jan2010 innovabia innovation
Dkv 18 Jan2010 innovabia innovationDkv 18 Jan2010 innovabia innovation
Dkv 18 Jan2010 innovabia innovation
Osama Ghanim
 
Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]
Martin Gaedke
 
Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...
Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...
Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...
Ayelt Komus
 
Agile Projectmanagement
Agile ProjectmanagementAgile Projectmanagement
Agile Projectmanagement
Manfred Rieder
 
'The Real Agile Testing Quadrants' with Michael Bolton
'The Real Agile Testing Quadrants' with Michael Bolton'The Real Agile Testing Quadrants' with Michael Bolton
'The Real Agile Testing Quadrants' with Michael Bolton
TEST Huddle
 
Personas - Die Arbeit mit archetypischen Nutzern in der Produktentwicklung
Personas - Die Arbeit mit archetypischen Nutzern in der ProduktentwicklungPersonas - Die Arbeit mit archetypischen Nutzern in der Produktentwicklung
Personas - Die Arbeit mit archetypischen Nutzern in der Produktentwicklung
uxHH
 
Agiles Projektmanagement: Kanban vs. Scrum
Agiles Projektmanagement: Kanban vs. ScrumAgiles Projektmanagement: Kanban vs. Scrum
Agiles Projektmanagement: Kanban vs. Scrum
TWT
 
Einführung zur Projektmanagement mit Scrum
Einführung zur Projektmanagement mit Scrum Einführung zur Projektmanagement mit Scrum
Einführung zur Projektmanagement mit Scrum
Pierre E. NEIS
 
Agile Testing Framework - The Art of Automated Testing
Agile Testing Framework - The Art of Automated TestingAgile Testing Framework - The Art of Automated Testing
Agile Testing Framework - The Art of Automated Testing
Dimitri Ponomareff
 
Agile Testing by Example
Agile Testing by ExampleAgile Testing by Example
Agile Testing by Example
Mikalai Alimenkou
 
Agile Testing Overview
Agile Testing OverviewAgile Testing Overview
Agile Testing Overview
Elisabeth Hendrickson
 
#LFMF: Tales of Test Automation Gone Wrong
#LFMF: Tales of Test Automation Gone Wrong #LFMF: Tales of Test Automation Gone Wrong
#LFMF: Tales of Test Automation Gone Wrong
Elisabeth Hendrickson
 
Agile Quality and Risk Management
Agile Quality and Risk ManagementAgile Quality and Risk Management
Agile Quality and Risk Management
Elisabeth Hendrickson
 
Die richtige Projektmethode
Die richtige ProjektmethodeDie richtige Projektmethode
Die richtige Projektmethode
BERATUNG JUDITH ANDRESEN
 
Das Agile Team
Das Agile TeamDas Agile Team
Das Agile Team
Christoph Mathis
 

Andere mochten auch (18)

Agile testing quadrants discussion
Agile testing quadrants discussionAgile testing quadrants discussion
Agile testing quadrants discussion
 
Innovationskennzahlen - Kann man Innovation messen?
Innovationskennzahlen - Kann man Innovation messen?Innovationskennzahlen - Kann man Innovation messen?
Innovationskennzahlen - Kann man Innovation messen?
 
Agiles PM –Evidenzbasiertes PM -Ansätze zur Produktenentwickung
Agiles PM –Evidenzbasiertes PM -Ansätze zur ProduktenentwickungAgiles PM –Evidenzbasiertes PM -Ansätze zur Produktenentwickung
Agiles PM –Evidenzbasiertes PM -Ansätze zur Produktenentwickung
 
Dkv 18 Jan2010 innovabia innovation
Dkv 18 Jan2010 innovabia innovationDkv 18 Jan2010 innovabia innovation
Dkv 18 Jan2010 innovabia innovation
 
Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]
 
Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...
Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...
Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...
 
Agile Projectmanagement
Agile ProjectmanagementAgile Projectmanagement
Agile Projectmanagement
 
'The Real Agile Testing Quadrants' with Michael Bolton
'The Real Agile Testing Quadrants' with Michael Bolton'The Real Agile Testing Quadrants' with Michael Bolton
'The Real Agile Testing Quadrants' with Michael Bolton
 
Personas - Die Arbeit mit archetypischen Nutzern in der Produktentwicklung
Personas - Die Arbeit mit archetypischen Nutzern in der ProduktentwicklungPersonas - Die Arbeit mit archetypischen Nutzern in der Produktentwicklung
Personas - Die Arbeit mit archetypischen Nutzern in der Produktentwicklung
 
Agiles Projektmanagement: Kanban vs. Scrum
Agiles Projektmanagement: Kanban vs. ScrumAgiles Projektmanagement: Kanban vs. Scrum
Agiles Projektmanagement: Kanban vs. Scrum
 
Einführung zur Projektmanagement mit Scrum
Einführung zur Projektmanagement mit Scrum Einführung zur Projektmanagement mit Scrum
Einführung zur Projektmanagement mit Scrum
 
Agile Testing Framework - The Art of Automated Testing
Agile Testing Framework - The Art of Automated TestingAgile Testing Framework - The Art of Automated Testing
Agile Testing Framework - The Art of Automated Testing
 
Agile Testing by Example
Agile Testing by ExampleAgile Testing by Example
Agile Testing by Example
 
Agile Testing Overview
Agile Testing OverviewAgile Testing Overview
Agile Testing Overview
 
#LFMF: Tales of Test Automation Gone Wrong
#LFMF: Tales of Test Automation Gone Wrong #LFMF: Tales of Test Automation Gone Wrong
#LFMF: Tales of Test Automation Gone Wrong
 
Agile Quality and Risk Management
Agile Quality and Risk ManagementAgile Quality and Risk Management
Agile Quality and Risk Management
 
Die richtige Projektmethode
Die richtige ProjektmethodeDie richtige Projektmethode
Die richtige Projektmethode
 
Das Agile Team
Das Agile TeamDas Agile Team
Das Agile Team
 

Ähnlich wie Agiles Testen

Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
SwissQ Consulting AG
 
Agilität mit Scrum - Überblick
Agilität mit Scrum - ÜberblickAgilität mit Scrum - Überblick
Agilität mit Scrum - Überblick
Claudia Haußmann 🦋
 
Agile Softwareentwicklung
Agile SoftwareentwicklungAgile Softwareentwicklung
Agile Softwareentwicklung
shabazza
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Digicomp Academy AG
 
SCRUM für Projektleiter
SCRUM für ProjektleiterSCRUM für Projektleiter
SCRUM für Projektleiter
edutrainment company
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
mrdoubleb
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
Tobias Schlüter
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Sascha Böhr
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
HOOD Group
 
Agile Ways of Working @ Migros
Agile Ways of Working @ MigrosAgile Ways of Working @ Migros
Agile Ways of Working @ Migros
Joël Krapf
 
Agile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Agile UX - Wege zur agilen nutzerzentrierten ProduktentwicklungAgile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Agile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Rainer Gibbert
 
Agile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUMAgile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUM
TechDivision GmbH
 
Agile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von ScrumAgile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von Scrum
Zeljko Kvesic
 
Rails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenRails und Scrum in großen Projekten
Rails und Scrum in großen Projekten
Phillip Oertel
 
Scrum Überblick Teil 1
Scrum Überblick Teil 1Scrum Überblick Teil 1
Scrum Überblick Teil 1
Christof Zahn
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
René Spengler
 
XING Agile QA
XING Agile QAXING Agile QA
XING Agile QA
XING AG
 
Scrum - Wissen kompakt
Scrum - Wissen kompaktScrum - Wissen kompakt
Scrum - Wissen kompakt
Frank Dostert
 
Product owner: Wunderkind oder Sündenbock? Sibylle Peter
Product owner: Wunderkind oder Sündenbock? Sibylle PeterProduct owner: Wunderkind oder Sündenbock? Sibylle Peter
Product owner: Wunderkind oder Sündenbock? Sibylle Peter
Corimbus GmbH
 

Ähnlich wie Agiles Testen (20)

Scrum 2009 10_23
Scrum 2009 10_23Scrum 2009 10_23
Scrum 2009 10_23
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
Agilität mit Scrum - Überblick
Agilität mit Scrum - ÜberblickAgilität mit Scrum - Überblick
Agilität mit Scrum - Überblick
 
Agile Softwareentwicklung
Agile SoftwareentwicklungAgile Softwareentwicklung
Agile Softwareentwicklung
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
 
SCRUM für Projektleiter
SCRUM für ProjektleiterSCRUM für Projektleiter
SCRUM für Projektleiter
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
 
Agile Ways of Working @ Migros
Agile Ways of Working @ MigrosAgile Ways of Working @ Migros
Agile Ways of Working @ Migros
 
Agile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Agile UX - Wege zur agilen nutzerzentrierten ProduktentwicklungAgile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Agile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
 
Agile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUMAgile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUM
 
Agile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von ScrumAgile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von Scrum
 
Rails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenRails und Scrum in großen Projekten
Rails und Scrum in großen Projekten
 
Scrum Überblick Teil 1
Scrum Überblick Teil 1Scrum Überblick Teil 1
Scrum Überblick Teil 1
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
 
XING Agile QA
XING Agile QAXING Agile QA
XING Agile QA
 
Scrum - Wissen kompakt
Scrum - Wissen kompaktScrum - Wissen kompakt
Scrum - Wissen kompakt
 
Product owner: Wunderkind oder Sündenbock? Sibylle Peter
Product owner: Wunderkind oder Sündenbock? Sibylle PeterProduct owner: Wunderkind oder Sündenbock? Sibylle Peter
Product owner: Wunderkind oder Sündenbock? Sibylle Peter
 

Mehr von oose

Tiefkühlpizza Softwaretesten und der Mann im Mond
Tiefkühlpizza Softwaretesten und der Mann im Mond Tiefkühlpizza Softwaretesten und der Mann im Mond
Tiefkühlpizza Softwaretesten und der Mann im Mond
oose
 
Management -Das ist sowas von 2019!
Management -Das ist sowas von 2019!Management -Das ist sowas von 2019!
Management -Das ist sowas von 2019!
oose
 
oose. Nein sagen
oose. Nein sagenoose. Nein sagen
oose. Nein sagen
oose
 
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. HalbjahrWertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
oose
 
Feedback geben und nehmen - Abendvortrag_revised
Feedback geben und nehmen - Abendvortrag_revisedFeedback geben und nehmen - Abendvortrag_revised
Feedback geben und nehmen - Abendvortrag_revised
oose
 
Feedback geben und nehmen | oose-Vortragsfolien
Feedback geben und nehmen | oose-VortragsfolienFeedback geben und nehmen | oose-Vortragsfolien
Feedback geben und nehmen | oose-Vortragsfolien
oose
 
Gehaltsmodell in Selbstorganisation
Gehaltsmodell in SelbstorganisationGehaltsmodell in Selbstorganisation
Gehaltsmodell in Selbstorganisation
oose
 
Haqoona matata - Die Digitalisierung lebenslangen Lernens
Haqoona matata - Die Digitalisierung lebenslangen LernensHaqoona matata - Die Digitalisierung lebenslangen Lernens
Haqoona matata - Die Digitalisierung lebenslangen Lernens
oose
 
Personalarbeit in selbstorganisierten Teams
Personalarbeit in selbstorganisierten TeamsPersonalarbeit in selbstorganisierten Teams
Personalarbeit in selbstorganisierten Teams
oose
 
Psychologisch sichere Teams | oose-Vortragsfolien
Psychologisch sichere Teams | oose-VortragsfolienPsychologisch sichere Teams | oose-Vortragsfolien
Psychologisch sichere Teams | oose-Vortragsfolien
oose
 
Das Prinzip Verantwortung in selbstorganisierten Teams
Das Prinzip Verantwortung in selbstorganisierten TeamsDas Prinzip Verantwortung in selbstorganisierten Teams
Das Prinzip Verantwortung in selbstorganisierten Teams
oose
 
Wertstiftender Agile Coach - Ausbildung
Wertstiftender Agile Coach - AusbildungWertstiftender Agile Coach - Ausbildung
Wertstiftender Agile Coach - Ausbildung
oose
 
Gehalt und Selbstorganisation: Gehalt neu denken
Gehalt und Selbstorganisation: Gehalt neu denkenGehalt und Selbstorganisation: Gehalt neu denken
Gehalt und Selbstorganisation: Gehalt neu denken
oose
 
Das kleine Einmaleins des agilen Produktmanagements
Das kleine Einmaleins des agilen Produktmanagements Das kleine Einmaleins des agilen Produktmanagements
Das kleine Einmaleins des agilen Produktmanagements
oose
 
DMN - Was gibt es da zu Entscheiden?
DMN - Was gibt es da zu Entscheiden?DMN - Was gibt es da zu Entscheiden?
DMN - Was gibt es da zu Entscheiden?
oose
 
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RESchöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
oose
 
DMN – Was gibt es da zu entscheiden?
 DMN – Was gibt es da zu entscheiden? DMN – Was gibt es da zu entscheiden?
DMN – Was gibt es da zu entscheiden?
oose
 
MARTE – UML für eingebettete Systeme
MARTE – UML für eingebettete SystemeMARTE – UML für eingebettete Systeme
MARTE – UML für eingebettete Systeme
oose
 
A World In Motion
A World In MotionA World In Motion
A World In Motion
oose
 
Produktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellierenProduktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellieren
oose
 

Mehr von oose (20)

Tiefkühlpizza Softwaretesten und der Mann im Mond
Tiefkühlpizza Softwaretesten und der Mann im Mond Tiefkühlpizza Softwaretesten und der Mann im Mond
Tiefkühlpizza Softwaretesten und der Mann im Mond
 
Management -Das ist sowas von 2019!
Management -Das ist sowas von 2019!Management -Das ist sowas von 2019!
Management -Das ist sowas von 2019!
 
oose. Nein sagen
oose. Nein sagenoose. Nein sagen
oose. Nein sagen
 
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. HalbjahrWertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
 
Feedback geben und nehmen - Abendvortrag_revised
Feedback geben und nehmen - Abendvortrag_revisedFeedback geben und nehmen - Abendvortrag_revised
Feedback geben und nehmen - Abendvortrag_revised
 
Feedback geben und nehmen | oose-Vortragsfolien
Feedback geben und nehmen | oose-VortragsfolienFeedback geben und nehmen | oose-Vortragsfolien
Feedback geben und nehmen | oose-Vortragsfolien
 
Gehaltsmodell in Selbstorganisation
Gehaltsmodell in SelbstorganisationGehaltsmodell in Selbstorganisation
Gehaltsmodell in Selbstorganisation
 
Haqoona matata - Die Digitalisierung lebenslangen Lernens
Haqoona matata - Die Digitalisierung lebenslangen LernensHaqoona matata - Die Digitalisierung lebenslangen Lernens
Haqoona matata - Die Digitalisierung lebenslangen Lernens
 
Personalarbeit in selbstorganisierten Teams
Personalarbeit in selbstorganisierten TeamsPersonalarbeit in selbstorganisierten Teams
Personalarbeit in selbstorganisierten Teams
 
Psychologisch sichere Teams | oose-Vortragsfolien
Psychologisch sichere Teams | oose-VortragsfolienPsychologisch sichere Teams | oose-Vortragsfolien
Psychologisch sichere Teams | oose-Vortragsfolien
 
Das Prinzip Verantwortung in selbstorganisierten Teams
Das Prinzip Verantwortung in selbstorganisierten TeamsDas Prinzip Verantwortung in selbstorganisierten Teams
Das Prinzip Verantwortung in selbstorganisierten Teams
 
Wertstiftender Agile Coach - Ausbildung
Wertstiftender Agile Coach - AusbildungWertstiftender Agile Coach - Ausbildung
Wertstiftender Agile Coach - Ausbildung
 
Gehalt und Selbstorganisation: Gehalt neu denken
Gehalt und Selbstorganisation: Gehalt neu denkenGehalt und Selbstorganisation: Gehalt neu denken
Gehalt und Selbstorganisation: Gehalt neu denken
 
Das kleine Einmaleins des agilen Produktmanagements
Das kleine Einmaleins des agilen Produktmanagements Das kleine Einmaleins des agilen Produktmanagements
Das kleine Einmaleins des agilen Produktmanagements
 
DMN - Was gibt es da zu Entscheiden?
DMN - Was gibt es da zu Entscheiden?DMN - Was gibt es da zu Entscheiden?
DMN - Was gibt es da zu Entscheiden?
 
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RESchöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
 
DMN – Was gibt es da zu entscheiden?
 DMN – Was gibt es da zu entscheiden? DMN – Was gibt es da zu entscheiden?
DMN – Was gibt es da zu entscheiden?
 
MARTE – UML für eingebettete Systeme
MARTE – UML für eingebettete SystemeMARTE – UML für eingebettete Systeme
MARTE – UML für eingebettete Systeme
 
A World In Motion
A World In MotionA World In Motion
A World In Motion
 
Produktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellierenProduktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellieren
 

Agiles Testen

  • 1. Uwe Vigenschow : Agiles Testen – Das agile Team im Einsatz ! Was ist ein Scrum-Team? Typische Testprobleme in Scrum-Teams Das agile Team als Lösung Aufgabenverteilung im agilen Test Definition of Done Arbeiten mit Persona und Szenarien
  • 2. Einstiegsfrage: Wie lautet das agile Manifest?
  • 3. Das agile Manifest Menschen und Zusammenarbeit vor Prozessen und Werkzeugen Funktionierende Software vor umfassender Dokumentation Zusammenarbeit mit dem Kunden vor vertraglicher Verhandlung Reaktion auf Veränderung vor Einhaltung eines Plans <rechte Seite> sind wertvoll, ABER <linke Seite> sind wichtiger und sollen nicht durch <rechte Seite> behindert werden. Wie können wir <rechte Seite> so einsetzen, dass es <linke Seite> unterstützt? Welcher Grad des Einsatzes von <rechte Seite> ist hierfür angemessen? http://www.agilemanifesto.org http://www.agilealliance.com
  • 4. Wichtige agile Prinzipien Höchste Priorität hat die Zufriedenstellung des Auftraggebers durch frühe und kontinuierliche Lieferung brauchbarer Software. Die Software wird inkrementell und in kurzen Iterationen erstellt. Fachexperten und Entwickler arbeiten möglichst direkt und täglich zusammen. Die effizienteste und effektivste Art Informationen zu verbreiten ist die direkte Kommunikation von Angesicht zu Angesicht. Funktionierende Software ist die primäre Kenngröße für den Projektfortschritt. Konzentration auf das Wesentliche heißt explizit und regelmäßig zu entscheiden, was wegzulassen ist. Das Entwicklungsteam reflektiert in regelmäßigen Abständen darüber, wie es die gemeinsame Arbeit verbessern kann.
  • 5. Folgerungen aus den agilen Prinzipen Teste oft und früh! Entwickler, Fachexperten und Tester arbeiten direkt und eng zusammen! Entwickler, Fachexperten und Tester bilden ein gemeinsames, agiles Team! Jedes Mitglied des agilen Teams fokussiert darauf regelmäßig Ergebnisse zu liefern! die geforderte Qualität zu liefern! Geschäftswert zu liefern! Gemeinsam wird eine Vision und das Projektziel definiert! Die Gesamtplanung erfolgt auf einem abstrakten Niveau auf Basis priorisierter Kundenanforderungen! Detaillierte Anforderungen werden innerhalb einer Iteration aufgenommen, umgesetzt, getestet und abgenommen!
  • 6. Was ist ein Scrum-Team? Scrum als agiles Projektmanagement-Framework Minimale Anzahl an Rollen Minimale Anzahl an Artefakten Minimaler iterativer Prozess Rollen in Scrum Product Owner Scrum Master Team Artefakte Backlogs Product Sprint Impediment Burndown Chart
  • 7. Rollen in Scrum: das Scrum Team Auftraggeber / Stakeholder Das Scrum-Team ist selbst dafür verantwortlich seine Arbeit zu organisieren und niemand außerhalb des Scrum-Teams kann ihm vorschreiben, wie es seine Arbeit tun soll. Scrum Master Product- Owner Team Scrum Team
  • 8. Scrum Master Der Scrum-Master ist dafür verantwortlich, dass die Scrum-Regeln und -Abläufe eingehalten werden und die nötigen Rahmenbedingungen vorhanden sind. Der Scrum-Master unterstützt das Scrum-Team und das Umfeld dabei die Prozesse mit Leben zu füllen und weiterzuentwickeln Der Scrum-Master ist nicht der „Chef“, er hat eher eine Coaching- und Unterstützer-Rolle
  • 9. Produkt Owner Der Produkt-Owner ist die Person die das Produkt-Backlog verantwortet. Er entscheidet unabhängig darüber welche Anforderungen, mit welcher Priorität enthalten sind. Der Produkt-Owner ist für den Nutzen und die Wirtschaftlichkeit der im Produkt-Backlog enthaltenen Anforderungen verantwortlich. Der Produkt-Owner wird in seinen Entscheidungen von niemanden überstimmt. Er alleine setzt die Prioritäten für die Arbeit des Teams.
  • 10. Das Team Das Team entwickelt aus den Features im Backlog ein funktionierendes Produkt. Das Team organisiert sich selbst. Es gibt im Team keine Titel oder besondere Rollen. Das Team ist so besetzt, dass alle benötigten Fähigkeiten und Fachkenntnisse im Team vorhanden sind Nur das Team selbst legt fest, wie viel Arbeit es in einem Sprint erledigt. Teams sollten nicht größer als 7 Mitglieder sein. Die Team-Zusammensetzung kann - wenn nötig - am Ende eines Sprints geändert werden.
  • 11. Scrum-Ablaufstruktur Sprint (timeboxed) Daily-Scrum Review Retrospektive Sprint-Planung
  • 12. Verantwortlichkeiten Kunde Entwickler Anforderungen Schätzung Kunde Entwickler Priorisieren Funktionen Kunde
  • 13. Die traditionelle Teamauffassung Entwickler reden mit Analytikern und erstellen Software. Fachexperten liefern ihre Information bei den Analytikern ab. Analytiker dokumentieren bzw. modellieren die Anforderungen. Tester lesen die Anforderungen und testen das Ergebnis. Folge: Er wird versucht, Qualität in das Produkt „hineinzutesten“! Entwicklungsteam Fach- experten Tester Program- mierer Analytiker
  • 14. Simples Scrum Entwickler reden mit einem Product Owner und erstellen Software. Fachexperten diskutieren mit dem Product Owner. Product Owner dokumentieren die Anforderungen und nimmt die Ergebnisse ab. Scrum Master steuert den Prozess sowie die Prozessverbesserung. Folge: Product Owner ist oft überfordert! Entwickler Product Owner Entwicklungsteam Fach- experten Scrum Master
  • 15. Typische Probleme mit QS und Tests in Scrum Teams Der gesamte Test liegt in der Verantwortung von Team und Product Owner. Der Product Owner testet nur Akzeptanzfälle. Das Team führt nur Entwicklertests durch und implementiert Unittests.  Die Testqualität ist gering, da methodische Systemtests fehlen! Einer übergeordneten Qualitätsmanagement fehlt ein adäquater Ansprechpartner für testmethodische Aspekte und Prozessverbesserungen.  Der Inspect-and-Adapt-Mechanismus im Scrum vernachlässigt Testaspekte! Die Verantwortung für die Ergebnisqualität wird primär aus Entwicklersicht wahrgenommen.  Die fachlichen Sonderfälle und Ausnahmen finden zu wenig Berücksichtigung!
  • 16. Agiles Testen als Lösungsweg Bereits in der Projektvorbereitung Durchgängig begleitend bis zum Projektende Verteilt auf alle Rollen Entwickler – Testgetrieben vorgehen, Unit Tests, Komponententests, FIT-Automatisierung Fachexperten / Product Owner – Abnahme- und Akzeptanztests erstellen und durchführen Tester – Persona, Szenarien, Testfälle und Integrationstests erstellen und durchführen, FIT-Automatisierung, UI-Testautomatisierung der Regressionstests Treiber für die interne Prozessverbesserung Agiles Testen ist die Integration Qualität sichernder Maßnahmen in den agilen Entwicklungsprozess. Agiles Testen basiert auf einem ganzheitlichen Team-Ansatz.
  • 17. Rollen in agilen Team: das agile Team Auftraggeber / Stakeholder Das Scrum-Team ist selbst dafür verantwortlich seine Arbeit zu organisieren und niemand außerhalb des Scrum-Teams kann ihm vorschreiben, wie es seine Arbeit tun soll. Scrum Master Product- Owner Team Agiles Team Tester
  • 18. Tester Der Tester bringt während des gesamten Projektablaufs die Testsicht in das agile Team ein. Der Tester schärft die Anforderungen über Persona und Szenarien bzw. Story Maps. Dabei wird besonders auf die nicht-funktionalen Anforderungen fokussiert. Der Tester unterstützt Entwickler methodisch bei den Unit-Tests Entwickler bei der fachlichen Architektur durch entsprechende fachliche Strukturen in den Tests Product Owner bei der fachlichen Priorisierung Product Owner bei der Abnahme der Iterationsergebnisse Der Tester führt die Integrationstests und die entsprechenden Regressionstests durch und sorgt so von Anfang an für Produktqualität.
  • 19. Ganzheitliches agiles Team (am Beispiel der Scrum-Rollen) Entwickler erstellen testgetrieben die Software. Product Owner moderiert, organisiert und definiert die Prioritäten. Entwickler, Tester und Fachexperten diskutieren gemeinsam die Anforderungen. Tester führen aussagekräftige, testmethodische Prüfungen durch. Folge: Tests erfolgen auf allen Ebenen früh und oft! Agiles Team Fach- experten Entwick- lungs- team Tester PO SM SWE
  • 20. Ganzheitliches agiles Team (am Beispiel der Scrum-Rollen) Entwickler erstellen testgetrieben die Software. Product Owner moderiert, organisiert und definiert die Prioritäten. Entwickler, Tester und Fachexperten diskutieren gemeinsam die Anforderungen. Tester führen aussagekräftige, testmethodische Prüfungen durch. Folge: Tests erfolgen auf allen Ebenen früh und oft! Agiles Team Fach- experten Entwick- lungs- team Tester PO SM SWE
  • 21. Verantwortlichkeiten im agilen Team Agiles Team Fach- experten Entwick- lungs- team Tester Entwicklungsmethodik Analysemethodik Projektplanung Testgetriebenes Design Entwicklungsprozess Projektidee und Vision Fachwissen Nutzen/geschäftlicher Wert Fachliche Prioritäten Testmethodik Testplanung/Testprozess Testautomatisierung (UI) Fachwissen PO SM SWE
  • 22. Testen im agilen Team Agiles Team Fach- experten Entwick- lungs- team Tester Testgetriebenes Vorgehen Unit-Tests Komponententests Abnahmetests Akzeptenaztests Integrationstests Systemtests (Regressionstests) PO SM SWE
  • 23. Grundprinzip: Alle gemeinsam an einem Tisch! Anforderungsbezogen Wer sind die richtigen Teilnehmer? Wann ist der richtige Zeitpunkt? Ziele Gemeinsame Übersicht der Inhalte und Prioritäten Gegenseitiger Austausch der unterschiedlichen Sichten
  • 24. Ein Team bilden! Rollen klären! Verantwortung Aufgaben Rechte und Pflichten Ziele klären! Projekt Team individuell
  • 25. Ein Team bilden! Rollen klären! Verantwortung Aufgaben Rechte und Pflichten Ziele klären! Projekt Team individuell Übung zur Teambildung: Der Zollstock
  • 26. Übung: Der Zollstock Fotos: Anton Dumler
  • 27. Agile Teststruktur Technisch-architekturelle Betrachtung Unterstützung des agilen Teams Q1 ?
  • 28. Agile Teststruktur Technisch-architekturelle Betrachtung Unterstützung des agilen Teams Q1 Unit Tests Komponententests testgetriebenes Design
  • 29. Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Q1 Q2 Unit Tests Komponententests testgetriebenes Design ?
  • 30. Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Q1 Q2 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen
  • 31. Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen ?
  • 32. Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests
  • 33. Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Q4 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests ?
  • 34. Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Q4 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests Performance Tests Lasttests Sicherheitstests „ böswillige“ Tests
  • 35. Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts Q1 Q2 Q3 Q4 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests Performance Tests Lasttests Sicherheitstests „ böswillige“ Tests
  • 36. Agile Teststruktur Technisch-architekturelle Betrachtung Geschäftswert und Nutzen Unterstützung des agilen Teams Kritische Analyse des Produkts nach: L. Crispin, J. Gregory: Agile Testing. Addison-Wesley, 2009 Q1 Q2 Q3 Q4 Unit Tests Komponententests testgetriebenes Design Funktionale Tests Beispiele Story Tests Use Case Tests Prototypen Simulationen Exploratives Testen Persona und Szenarien Usability Tests User Acceptance Tests Alpha-, Beta-Tests Performance Tests Lasttests Sicherheitstests „ böswillige“ Tests automatisiert & manuell automatisiert manuell Werkzeuge
  • 37. Risiken in agilen Testen Vision nicht aus den Augen verlieren! Kleinteiliges, schrittweises Arbeiten an konkreter Anforderung erschwert den Blick auf das Ganze. Symptome wie Verzetteln und inhaltlich im Kreis drehen müssen sofort behandelt werden. Agil ist das Gegenteil von chaotisch! Agilität wird häufig dahingehend missverstanden, chaotisch zu sein. Der Managementaufwand ist in agilen Projekten eher höher als im „Wasserfall“. Sehr hohe Verantwortung im agilen Team! Regeln regelmäßig hinterfragen und Prozesse auf den Prüfstand stellen. Falsch verstandene Agilität wieder auf die geordnete Spur bringen. Hoher Gruppendruck schafft das Risiko von Burnout-Symptomen.
  • 38. Wann ist etwas fertig Fertig? „ Habe ich fertig getestet, ist integriert und mit Herrn A. durchgegangen.“ „ Läuft in der Produktion, bisher keine Fehlermeldungen.“ „ Bin fertig, muss ich nur noch einchecken.“ „ Bin fast fertig, Morgen bin ich durch.“ „ Also, bei mir auf dem Rechner läufts.“ „ Ist im Integrationtest“ „ Noch nicht ganz, so ca 80%-Fertig.“
  • 39. Kriterien für die Definition von „Fertig“ Alle Arbeiten im Zusammenhang mit dem Feature sind erledigt (Integration, Test, Dokumentation, [Teil-]Abnahme, ...) Wie können das Feature „von unserer Liste nehmen“, mit Nacharbeiten ist nicht mehr zu rechnen. Wir werden keine „Überraschungen“ mehr mit dem Feature erleben. Die verbliebenen Arbeiten sind geplant und beinhalten kein großes Risiko mehr. Ich würde die Entwickler des Features mit gutem Gewissen jetzt aus dem Projekt entlassen.
  • 40. Minimierung von unfertiger Arbeit Angefangene und „unfertige“ Arbeit im Projekt Erhöht den Verwaltungsaufwand Macht es schwierig einzuschätzen wo das Projekt steht Erhöht das Risiko von unentdeckten Fehlern und unerwünschten Wechselwirkungen der Lösungen Macht es schwierig auf Problemen zu reagieren Verschleiert den Blick darauf, dass eigentlich nichts fertig ist Unfertige Arbeit ist teuer und schwierig zu managen. Unfertige Arbeit ist so weit wie möglich zu minimieren.
  • 41. Struktur Anforderung Story, Use Case, Feature, Szenario, ... Iteration bzw. Sprint Release Behinderungen
  • 42. Struktur und Beispiele für Definition of Done Anforderung Story, Use Case, Feature, Szenario, ... Iteration bzw. Sprint Release Behinderungen Dokumentierter Code Alle Unit-Tests laufen Alle UI-Tests laufen ... ... ... ... User Acceptance Test O.K. Alle FIT-Tests laufen Alle Release- Test O.K. Intranet-Seiten sind aktualisiert Anwender sind über Änderungen informiert Laufender Code in abhängigen Altsystemen
  • 43. Persona – konkret und doch abstrakt Ziele der Persona Beruf, Funktion, Verantwortlichkeiten und Aufgaben der Persona Fachliche Ausbildung, Wissen und Fähigkeiten Verhaltensmuster und Vorgehensweisen Werte, Ängste, Sehnsüchte und Vorlieben Allgemeine Computerkenntnisse Kenntnisse über verwandte oder Konkurrenzprodukte sowie Vorgängersysteme Verbesserungspotenzial in der aktuell eingesetzten Lösung (Sicht der Persona) Erwartungen der Persona an die neue Lösung Mit einer Persona beschreiben wir einen typischen Vertreter aus einer Kategorie möglicher Anwender so plastisch und greifbar, als ob die Person neben uns stünde.
  • 44. Persona – eine idealisierte Person zum Leben erwecken! Name, Alter und Geschlecht Beschreibung der markanten Charakterzüge Foto oder Skizze Passende Zitate aus unseren fiktiven Analyse-Interviews Beschreibung eines typischen Tags im Leben der Persona Mit einer Persona beschreiben wir einen typischen Vertreter aus einer Kategorie möglicher Anwender so plastisch und greifbar, als ob die Person neben uns stünde.
  • 45. Beispiel – Anwender einer Textverarbeitung Petra Mitarbeiterin in der Marketingabteilung der Beispiel GmbH 34 Jahre alt, Studium zum Kommunikationswirt Petra ist seit 5 Jahren bei der Beispiel GmbH und arbeit mit ihrem Chef, dem Marketingleiter Klaus eng zusammen. Sie hat vorher bereits 2 Jahre als Marketing-assistentin bei einer Agentur gearbeitet. Petra arbeitet beinahe täglich mit der Software. Sie erstellt damit Druckvorlagen für die meisten Marketingunterlagen und etwa 1 – 2 mal im Monat gezielte Serienbriefe für ausgewählte Zielgruppen. Sie ist auch für die Pflege der Daten in den verschiedenen Kunden- bzw. Firmendatenbanken verantwortlich. Sie ist mit der Arbeit am PC seit der Schule vertraut und geht mit den notwendigen Programmen virtuos um. Sie hat ein hohes technisches Verständnis, weshalb sie bei ihren Kollegen und ihrem Chef ein hohes Ansehen genießt. Sie wird daher auch primär mit den wichtigen Aufgaben im Umgang mit den verschiedenen Programmen und den Datenbanken betraut. Aus ihrer Arbeit bei der Agentur kennt sie auch das Konkurrenzprodukt Büroware Version 4.5 . Petra ist es gewohnt unter hohem Zeitdruck schnell qualitativ hochwertige Ergebnisse zu produzieren. Daher arbeitet sie sich intensiv in die notwendigen Programme ein, was ihr auch viel Spaß bereitet. Dabei verlässt sie sich vollkommen auf die Qualität der Software. Solange diese fehlerfrei und schnell arbeitet, ist sie der größte Fan des Produkts ...
  • 46. Beispiel – Anwender einer Textverarbeitung Peter Sachbearbeiter und Teamleiter bei einer Versicherung 36 Jahre, Ausbildung zum Kaufmann für Versicherung und Finanzen Peter ist sei 14 Jahren bei einer Versicherung angestellt und hat dort in den 3 Jahren zuvor seine Ausbildung gemacht. Seit 4 Jahren ist er Leiter des Teams und neben der Leitungsaufgabe für die Bearbeitung der schwierigen Fälle verantwortlich. Er kennt das Produkt aus der Firma und benutzt es in der Home-Version auch privat. Sowohl beruflich als auch privat nutzt er das Produkt im Wesentlichen zum Schreiben von Briefen. In der Firma setzt er dafür ein Firmen-Template ein, privat ein unverändertes Standard-Template. Er hat noch nie die Templates verändert, sondern benutzt sie nur als Grundlage für seine Briefe. Sein wichtigsten Werkzeuge sind das Telefon und sein Filofax. Den PC nutzt er berufliche nur für die unvermeidlichen Pflichtaufgaben und das Schreiben von Briefen. Privat nutzt er das Internet als Informationsquelle, zum Online-Banking und Bestellen von Büchern, CDs, DVDs usw. Die Home-Version war beim PC bereits beim Kauf mit dabei. Da er die Software aus der Firma kennt, nutzt er sie gelegentlich zum Schreiben von Briefen ...
  • 47. Persona klassifizieren Primäre Persona Wir optimieren für deren Bedürfnisse und Anforderungen das Produkt und erstellen die dazu passende Benutzerschnittstelle. Sekundäre Persona Deren Bedürfnisse sind zum größten Teil durch eine primäre Persona abgedeckt. Sie liefert daher daher Ergänzungen bzw. Abweichungen. Ergänzende Persona Deren Bedürfnisse sind bereits vollständig durch eine primäre oder sekundäre Persona abgedeckt. Non-Persona Diese Persona wird explizit nicht berücksichtigt. Daher gibt es keine Optimierungen der Software für diese Persona.
  • 48. Persona für den täglichen Einsatz – Kurzbeschreibung an der Wand!
  • 49. Szenario – Interaktion aus Anwendersicht Beschreiben meist das Zusammenspiel von mehrere Anwendungsfällen oder User Stories Realistische Beschreibungen der (zukünftigen) typischen oder extremen Interaktion zwischen Benutzer und System Detaillierte Verlaufsprotokolle Einfache Sätze verwenden, damit ein Szenario sofort erfassbar ist! Schwächen in der formalen Korrektheit sind erlaubt, solange inhaltlich die richtigen Aussagen getroffen werden. Qualitative Anforderungen werden aus dem Kontext heraus deutlich gemacht. Basis für die Entwicklung und die Testfallerstellung Szenarien bilden die Anwendersicht auf unsere Anforderungen in Form von Anwendungsfällen oder User Stories ab. Sie schlagen die Brücke zwischen den strukturierten Anforderungen und deren Umsetzung in einer neuen Lösung!
  • 50. Beispiel – Anwendung einer Textverarbeitung Szenario 08-15: Serienbrief mit gefilterten Kundendaten Es ist 16 Uhr. Bei Petra klingelt das Telefon und ihr Chef, der Marketingleiter Klaus hat einen dringlichen Wunsch. Er ist bei einem wichtigen Kunden vor Ort und hat gerade davon erfahren, dass der größte Konkurrenz diese Woche gezielt die Kunden der Beispiel GmbH anschreibt, um sie mit einer Rabattaktion abzuwerben. Petra soll noch heute alle aktiven Kunden aus diesem und dem letzten Jahr anschreiben und ihnen einen Treuerabatt von 15 % für die nächsten zwei Jahre anbieten. Die Briefe müssen heute noch in die Post. Petra hat sich alles notiert und startet das Serienbriefmodul SB2.0. Sie entwirft das Schreiben und wählt dazu zuerst ein passendes, bereits an das Corporate Design der Beispiel GmbH angepasstes Template aus der Auswahlliste aus. Jetzt verfasst sie einen ersten Entwurf des Anschreibens. Sie kopiert sich dazu zwei Textblöcke aus älteren Serienbriefen in das noch leere, neue Dokument und erstellt dann das Anschreiben. Abschließend geht sie in die Serienbrief-Adressfunktion und wählt die Kundendatenbank aus. Damit der Serienbrief nur an die aktuellen aktiven Kunden heraus geht, erstellt sie zusätzlich eine Adress-Filterfunktion. Sie stellt den Filter mit dem Regeleditor zusammen und startet einen Testlauf. In der übersichtlich aufbereiteten Darstellung der gefilterten Kunden findet sie sofort noch einen Sonderfall, der nicht in diese Serienbriefaktion mit eingebunden werden darf. Sie passt die Filterregel an und prüft erneut das Ergebnis in einem Testlauf. Dort stehen jetzt noch die 102 gewünschten Kunden ...
  • 51. Szenarien als Basis für Akzeptanztests Mehrwert durch Persona mit Szenarien Das Team bekommt eine bessere Sicht auf die Bedürfnisse der Anwender. Szenarien sind ein wirkungsvolles Mittel für das Design und den Test der Usability. Aus Szenarien können Akzeptanztests abgeleitet werden. Akzeptanztests liegen zumindest teilweise während des ganzen Entwicklungsprozesses vor. Die Qualität des Abnahmetests durch den Kunden ist hoch. Um den Kundennutzen zu maximieren, sind Persona und Szenarien eines der effizientesten und effektivsten Mittel. Sie passen daher besonders gut zu einer agilen Softwareentwicklung!
  • 53. Film zum Buch – unsere Seminare Wollen Sie genau wissen, wie agiles Testen funktioniert? Dann besuchen Sie doch eines unserer Seminare! Agiles Testen http://www.oose.de/swe/training/at_agiles_testen.html Testgetriebene Softwareentwicklung http://www.oose.de/swe/training/tdd4_testgetriebene_softwareentwicklung.html UML für Tester http://www.oose.de/swe/training/umlt_uml_fuer_tester.html Qualitätssicherung in der Praxis / Certified Tester FL-Zertifizierung http://www.oose.de/swe/training/qsp_qualitaetssicherung_in_der_praxis.html