• Save
Agiles Testen
Upcoming SlideShare
Loading in...5
×
 

Agiles Testen

on

  • 4,263 views

"Agiles Testen" wird gerade intensiv diskutiert. ...

"Agiles Testen" wird gerade intensiv diskutiert.
Was steckt dahinter? Was für Konsequenzen ergeben sich daraus für unsere Scrum-Teams? Oder verbirgt sich gar eine neue Testmethode hinter diesem Begriff?

In diesem Vortrag erläutern wir den Weg vom Scrum-Team hin zu einem Agilen Team, wie Crispin und Gregroy es nennen. Sie geben damit die Antwort auf die Frage, wie die Rolle der QS in einem Scrum-Team wahrgenommen werden kann. Wir zeigen, welche Konsequenzen sich daraus für die Teammitglieder und ihre Aufgaben ergeben und wie Sie Ihr Agiles Team zum Fliegen bekommen!

Statistics

Views

Total Views
4,263
Views on SlideShare
4,086
Embed Views
177

Actions

Likes
0
Downloads
0
Comments
0

4 Embeds 177

https://confluence.gameduell.de 84
http://www.oose.de 78
http://localhost 14
https://jira.gameduell.de 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agiles Testen Agiles Testen Presentation Transcript

  • 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