Testen fängt beim Schneiden an

517 Aufrufe

Veröffentlicht am

Anforderungen sind oft viel zu groß und unübersichtlich und dadurch schwierig zu testen. Kleine User Stories vereinfachen den Test, aber auch die Planung, Umsetzung und Dokumentation. Aber wie schneide ich meine User Story richtig? Wie erstelle ich übersichtliche Akzeptanzkriterien, die alle Projektbeteiligte verstehen und gut zu testen sind. Wie kann ich diese, auch bei Änderungen, gut dokumentieren?

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
517
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
29
Aktionen
Geteilt
0
Downloads
9
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Unsicherheit ob das jetzt ein Fehler ist,
  • Alternativen, Ergänzungen,
  • Alternativen, Ergänzungen,
  • Ein Verständnis für den Nutzer
    Die demografischen Kriterien, welche jahrzehntelang das Marketing prägte, würden heute nicht mehr genügen. Mit der Suche nach den Kriterien: männlich, > 60 Jahre, > 1.000.000 Euro Jahreseinkommen, verheiratet, > 1 Kind, lebt in einer Großstadt finden wir Prinz Charles und Ozzy Osbourne, zwei völlig unterschiedliche Charaktere (Beispiel aus Emotional Boosting). Ein Durchschnitt zwischen den beiden Typen trifft unsere Zielgruppe nicht. Inhalte für Prince Charles und Ozzy Osbourne müssen unterschiedlich aufbereitet und vermarktet werden. Wenn der Content nicht trifft – trifft er nicht auf Resonanz. Keine Lesenden ergeben keine Weiter-Empfehlungen, kein Traffic, keine Kundenpflege, keinen (Mehr-)Umsatz.
  • Alternativen, Ergänzungen,
  • User Story ist klar…aber wie sortieren und prioriseren?
  • Mehr als 100
  • Wie erstellen
    Aktivitäten
    Jeder schreibt für sich still auf
    Am besten mit einem Verb beginnen
    Dupletten entfernen
    Aktivitäten gruppieren und Namen geben (Schritte)
  • Wie erstellen
    Aktivitäten
    Jeder schreibt für sich still auf
    Am besten mit einem Verb beginnen
    Dupletten entfernen
    Aktivitäten gruppieren und Namen geben (Schritte)
  • Aktion wird mit dem Team zusammen diskutiert
    Personen stehen fest
    Ziel steht fest
    Wie kommt man dahin? Wie ist der Weg?
  • RUHIG AUSFÜHRLICHER
    Nur Personen mit komischen Puscheln auf de Ohren
    Das wir vorher lecker Mittagessen waren
    Es leider nicht geschafft haben mit der ganzen Gruppe ein Bild zu machen
    Nur ein Skifahrer auf dem Bild ist denn wir mal wieder gemobbt haben


    Urlaubsfoto
    Konservation starten
    Erinnert an diese Unterhaltung und an Details
  • SPÄTER
    Akzeptanzkriterien
    Dem Team sollte klar sein was es bauen soll bevor es startet
    Wann ist eine Story komplett?
    Gehe ich später noch drauf ein, wie man dieses fes

     When are the tests automated?
     The ideal situation is to have them automated before the programmers begin implementing a story. That way, the programmers can get immediate feedback by running the tests against the code as they progress. The second-best situation is when someone is automating the tests while the programmers are implementing the User Story, in parallel. Teams can also automate tests after the User Story has been implemented if they are disciplined about always doing a thorough job. On the other hand, automating after the fact often leads Teams to shortchange the automation of tests, and this can lead to technical debt buildup and waterfall-type behavior. Automated tests act as a long term, real-time verification of correct system behavior, and since the User Story practice encourages very little documentation, leaving the automated testing piece out can be very wasteful and risky.
  • Große Story, kaum in einem Sprint zu schaffen, muss verkleinert werden
  • Große Story, kaum in einem Sprint zu schaffen, muss verkleinert werden
  • Nicht so schneiden
    Kann ich nichts mit anfangen, probieren, schonmal schauen ob Geschmack in die richtige Richtung geht.
  • Davon sollte mindest 5 in enen Sprint passen
  • Nicht ein Team den Teig, das andere die Füllung

     Vielmehr bedeutet die Unabhängigkeit von User Stories, dass der Product Owner die Möglichkeit hat, im aktuellen Sprint das in Story A beschriebene Feature von einem Team realisieren zu lassen, ohne dass das von Story B beschriebene Feature auch realisiert werden muss. Story B kann zu einem beliebigen späteren Zeitpunkt von einem anderen Team realisiert werden. 
  • STORY! Wir können noch darüber diskutieren und sie nach dem Sprint verändern
  • Eine Tüte Mehl erzeugt keinen Wert
    Auch nach dem
    Schneiden muss
    jede User Story
    einen eigenen
    Kundennutzen
    enthalten.
  • Sie ist schätzbar. Sie hat also soviel konkrete Details, dass ein erfahrenes Team deren Umfang schätzen kann.
  • Zu groß, nicht schätzbar. Foto von einer riesigen Torte
  • Wenn ich Zucker ausliefere ist daran nichts zu testen,
  • Beim Story Mapping schon aufgefallen?
  • Backend, Daten einstellen, schon einen Nutzen
  • Auch häufig bei Suchen
  • Mehrere Sprachen
  • Spa dich fit
  • Dimensional Planning
  • Simple Version zuerst, bei einer komplexen Schnittstelle
    Die Selben Daten von unterschiedlichen Schnittstellen, erst ein Teil der Daten der anderen Schittstellen
  • Ich kann mit einer Kreditkarte bezahlen // Ich kann mit allen Kreditkarten bezahlen (falls sich die Prio änderte Dinge mit unterschiedlichen Daten
    Bildbetrachter
  • Datenbrille
  • Datenbrille
  • Schlüsselwörter identifizieren und hervorheben
  • "Given when then" würde ich nicht nur sagen, sondern lesbar machen, ist besser verständlich


    Feature File pro User Story
    Beispiele Szenarien mit Gherkin
    Steps
  • Feature File pro User Story
    Beispiele Szenarien mit Gherkin
    Steps
  • Feature File pro User Story
    Beispiele Szenarien mit Gherkin
    Steps
  • Feature File pro User Story
    Beispiele Szenarien mit Gherkin
    Steps
  • Alternativen, Ergänzungen,
  • Kreditkartenabrechnung

    Er User Stories und dann überführen
    Direkt in den Tests erstellen und mit tags arbeiten -> Toolunterstützung
  • Mssen einfach zu pflegen sein
  • Zu wenig Details, das große Ganze fehlt
    Große Ganz -> Projektstart

    Effekt dass mehrere Folien zurückgesprungen wird?
  • Testen fängt beim Schneiden an

    1. 1. Testen fangt beim Schneiden an Ina Einemann ina.einemann@hec.de @IEinemann ..
    2. 2. ??? Wie kann ich da testen? Tester Tim
    3. 3. Gemeinsames Verstandnis Das ist ein Baum Das ist Schnee Das ist ein Fenster Das ist ein Wald ..
    4. 4. Produktvision OK – was brauch ich um eine gute Vision zu machen?
    5. 5. Personas Zielgruppen erkennen und gruppierenPersona erstellen Ein Verständnis für den Nutzer
    6. 6. Personas > 60 Jahre > 1.000.000€ Gehalt Verheiratet > 1 Kind Lebt in einer Großstadt Ozzy Osbourne & Prinz Charles
    7. 7. Personas Jetzt weiß ich auch wer das System nutzt und welche Bedürfnisse und Probleme er hat
    8. 8. Produktvision  HEC Produkt Vision Poster  Textmuster  Produkt Karton  Cover Story
    9. 9. Produktvision  Textmuster Elevator Pitch
    10. 10. Muster anwenden
    11. 11. Produktvision  Produkt Karton Was Tolles!
    12. 12. Produktvision  Cover Story Zitate Titelseite Dahin soll also die Reise gehen ! Dann kann‘s ja mit den User Stories losgehen…
    13. 13. Backlog Liste unübersichlich Teile passen nicht zusammen
    14. 14. Gibt’s da nicht was besseres um User Stories zu erstellen und zu priorisieren?
    15. 15. Hüttendetails durchsuchen Bezahlen Account managen Hütte anbieten Buchen Bestätigung erhalten Nach Datum suchen Bewertung schreiben Bewertungen einsehen Beschreibungen lesen Skigebietinfos lesen
    16. 16. Persona 1 Bewertungen lesen Persona 2 Persona 3 Nach Datum suchen Hüttendetails durchsuchen Hütten buchen Hütte anbieten Bewertungen einsehen User Story BuchenAnbieten Bewertungen User StoryUser Story Bestätigung erhalten Bewertung schreiben Suchen User Story User Story User Story User Story User Story User Story Bezahlen User Story User Story
    17. 17. User Story User StoryUser Story User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story
    18. 18. Jetzt hab ich einen guten Überblick über meine User Stories… Worauf muss ich eigentlich achten wenn ich User Stories erstelle?
    19. 19. User Story Card eine DinA5 Karte Überschrift und eindeutige Nummer
    20. 20. User Story Rolle muss klar sein! Personas
    21. 21. User Story Erster Vorschlag Wird gemeinsam im Team diskutiert
    22. 22. User Story Was möchte ich erreichen? Was ist die Problemstellung?
    23. 23. User Story Card Conversation
    24. 24. User Story Card Conversation
    25. 25. User Story Card Conversation Confirmation User Stories sind Grundlage der Kommunikation Das bedeutet nicht NICHTS aufzuschreiben Akzeptanzkriterien
    26. 26. Akzeptanzkriterien möglichst objektiv und eindeutig NICHT: - Story-Inhalt wiederholen - Versteckte neue User Story - Einen Workflow beinhalten Zusammenarbeit zwischen PO, Entwicklung und Test
    27. 27. Von der User Story zu Akzeptanzkritieren
    28. 28. Schlusselworter identifizieren .. ..
    29. 29. Fragenkatalog verwenden  Wer muss buchen?  Wann soll buchen stattfinden?  Wann ist buchen komplett abgeschlossen?  Wie kann buchen genau durchgeführt werden?  Wie häufig / oft / groß / schnell soll buchen sein?  Wo / Wie kann geprüft werden, ob buchen durchgeführt wurde?  Wurde sichergestellt, dass buchen alle Daten/Aspekte berücksichtigt?  Was geschieht, wenn man nicht buchen kann?  Was könnte buchen verhindern und was wird dann erwartet?  Welche möglichen Fehleingaben müssen im Zusammenhang mit buchen abgefangen werden?  Welche Inhalte kommen in Ausrüstung vor?  Welche optionalen / verpflichtende Aspekte gelten für Ausrüstung?  Welche Inhalte von Ausrüstung und nach welchen Regeln soll überprüft werden?  Wie sieht das Layout für Ausrüstung aus?
    30. 30. Fragen diskutieren Alle Kunden, die eine Ferienwohnung gebucht haben Snowboard, Ski, Helm und Stöcker Schuhgröße und Körpergröße angeben Bezahlarten auswählen, wie Abrechnung mit Hütte, Barzahlung, Paypal, Kreditkarte Leihzeitraum bestimmen  Wer muss buchen?  Welche Inhalte kommen in Ausrüstung vor?  Welche optionalen / verpflichtende Aspekte gelten für Ausrüstung?
    31. 31. Akzeptanzkriterien  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Und wenn es nicht passt?
    32. 32. Worauf muss ich denn achten wenn ich Stories schneide?
    33. 33.  Independent
    34. 34.  Negotiable
    35. 35.  Valuable
    36. 36.  Estimable
    37. 37.  Small
    38. 38.  Testable
    39. 39. INVEST Kriterien?  Independent  Negotiable  Valuable  Estimatable  Small  Testable
    40. 40. Okay, diese Kriterien müssen nach dem Schneiden erfüllt sein. Aber wie kann ich sie denn nun kleiner bekommen?
    41. 41. Schneiden Workflow Operations Performance Simpel/Komplex Größter Aufwand Veriation der Daten Variation der Geschäftsregeln Variation der SchnittstelleSpike Dateneingabe methode
    42. 42. Workflow  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Snowboard/Ski Details Zeitraum Equipment Bezahlart Versicherung Buchen Leihort Größter Wert -> Anfang und Ende Mittelteil vergrößert nach und nach den Wert
    43. 43. Operations  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Eqipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Buchung erstellen Managen verwalten konfigurieren löschenverändern
    44. 44.  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Vorausgewählter Zeitraum Variation der Geschaftsregeln .. Erst eine Teilmenge der RegelnStart und Endtermin X von y Tagen
    45. 45.  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Snowboard Variation der Daten „Gut genug“ Variante Gleiche Dinge mit unterschiedlichen Daten Skier
    46. 46.  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Snowboard oder Ski ausleihen per Email Simpel Komplex Simple Version, die zuerst erstellt wird Mit Rückmeldung
    47. 47.  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Snowboard oder Ski ausleihen mit Anbindung an einen Leihort Variationen der Schnittstellen Einfacher Kern mit Lernerfahrung, später Erweiterungen Weitere Leihorte
    48. 48.  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Es soll einfach funktionieren Performance Nicht funktionale Anforderungen nachlagern schnell
    49. 49.  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Naheliegende Aufteilung -> Alle gleich groß Egal welche man zuerst umsetzt, diese erste wird den größten Aufwand haben Grosster Aufwand ..
    50. 50.  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Dateneingabemethode
    51. 51.  Der Ferienwohnungs-Kunde kann den Leihort auswählen  Er kann zwischen Snowboard oder Skier auswählen  Er kann seine Schuhgröße und Körpergröße angeben  Er kann den Leih-Zeitraum bestimmen • Die Vorauswahl ist der Buchungszeitraum der Hütte • Er kann alternative Start- und Endtermine angeben • Er kann Optionen wie x von y Tagen wählen  Er kann weiteres Equipment wie Helm oder Stöcker hinzubuchen  Er kann eine Bezahlart bestimmen • Abrechnung mit Hütte • Abbuchung • Paypal • Kreditkarten  Er kann eine Diebstahl-Versicherung hinzufügen  Er kann buchen  Er kann seine Buchung wieder aufrufen, verändern und löschen Spike
    52. 52. Nun hab ich endlich meine kleine Story…. Aber WIE teste ich diese eigentlich?
    53. 53. Akzeptanztest 7 Praktische Anwendung der Akzeptanzkriterien
    54. 54. Szenarien
    55. 55. Szenarien Beschreibt die Vorbedingungen! Was mache ich vor meiner neuen Anforderungen/neuen Funktion? Ausgangssituation
    56. 56. Szenarien Beschreibt die Durchführung/Änderung! Was ist meine Anforderungen / neue Funktion? Aktion
    57. 57. Szenarien Beschreibt die Änderung! Was sind die Auswirklungen meiner Aktion? Was hat sich geändert? Ergebnis
    58. 58. Szenarien Steps können wieder verwendet werden Testautomatisierung schnell erstellt
    59. 59. Spitze, so kann ich also testen bzw. automatisieren. Alles grün … Dann ab zum Review
    60. 60. Aber auf meinem Tablet funktioniert das ja nicht!!! Tablet??? Darüber haben wir nie gesprochen
    61. 61. Interne und externe Qualitat Funktionalität Zuverlässigkeit Wartbarkeit PortabilitätBenutzbarkeit Effizienz Angemessenheit Genauigkeit Interoperabilität Sicherheit Reife Fehlertoleranz Wiederherstell- barkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität Zeitverhalten Verbrauchs- verhalten Analysierbarkeit Änderbarkeit Stabilität Testbarkeit Anpassbarkeit Installierbarkeit Koexistenz Austauschbarkeit Ordnungsmäßig- keit
    62. 62. Fragenkatalog verwenden  Wer muss buchen?  Wann soll buchen stattfinden?  Wann ist buchen komplett abgeschlossen?  Wie kann buchen genau durchgeführt werden?  Wie häufig / oft / groß / schnell soll buchen sein?  Wo / Wie kann geprüft werden, ob buchen durchgeführt wurde?  Wurde sichergestellt, dass buchen alle Daten/Aspekte berücksichtigt?  Was geschieht, wenn man nicht buchen kann?  Was könnte buchen verhindern und was wird dann erwartet?  Welche möglichen Fehleingaben müssen im Zusammenhang mit buchen abgefangen werden?  Welche Inhalte kommen in Ausrüstung vor?  Welche optionalen / verpflichtende Aspekte gelten für Ausrüstung?  Welche Inhalte von Ausrüstung und nach welchen Regeln soll überprüft werden?  Wie sieht das Layout für Ausrüstung aus?
    63. 63. Interne und externe Qualitat Funktionalität Zuverlässigkeit Wartbarkeit PortabilitätBenutzbarkeit Effizienz Angemessenheit Genauigkeit Interoperabilität Sicherheit Ordnungsmäßig- keit Reife Fehlertoleranz Wiederherstell- barkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität Zeitverhalten Verbrauchs- verhalten Analysierbarkeit Änderbarkeit Stabilität Testbarkeit Anpassbarkeit Installierbarkeit Koexistenz Austauschbarkeit Wie häufig / oft / groß / schnell soll buchen sein? Welche möglichen Fehleingaben müssen im Zusammenhang mit buchen abgefangen werden? Wie sieht das Layout für Ausrüstung/buchen aus? Was geschieht, wenn man nicht buchen kann?
    64. 64. Interne und externe Qualitat Funktionalität Zuverlässigkeit Wartbarkeit PortabilitätBenutzbarkeit Effizienz Angemessenheit Genauigkeit Interoperabilität Sicherheit Ordnungsmäßig- keit Reife Fehlertoleranz Wiederherstell- barkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität Zeitverhalten Verbrauchs- verhalten Analysierbarkeit Änderbarkeit Stabilität Testbarkeit Anpassbarkeit Installierbarkeit Koexistenz Austauschbarkeit Zusammenspiel zwischen den testenden System und den vorgegebenen System Unberechtigter Zugriff Wie häufig kommen Fehlerzustände vor? Wie einfach und schnell kann das geforderte Leistungsniveau nach Ausfall wieder hergestellt werden Interne Qualität
    65. 65. Und welche Möglichkeiten haben wir um diese Bereiche zu definieren?
    66. 66. Nichtfunktionale Anforderungen  Planguage  MisUseCase  Produkt Vision  The Furious Four
    67. 67. Planguage Tag Eindeutiger Name der Anforderung Definiton Genaue Beschreibung der Anforderung Scale Maßeinheit, in der die Anforderung gemessen wird (bei Antwortzeiten zum Beispiel Sekunden) Meter Messmethode (zum Beispiel Lasttest oder Nutzerbefragung) Benchmark Vergleichswerte zur Orientierung (zum Beispiel aus Vorgänger- oder Konkurrenzsystemen) Target Vorgabe der Anforderung, das angestrebte Ziel Constraint Zulässige Grenze der Anforderung nach unten oder oben
    68. 68. Planguage Tag Wartbarkeit Definiton Die Leichtigkeit, mit der ein System verändert oder erweitert werden kann. Scale Stunden Meter Durchschnittliche Dauer für die Behebung eines Fehlers. Gemessen wird vom Beginn der Behebung bis zu dessen Lösung. Benchmark - Target 2 Stunden Constraint 4 Stunden kann unübersichtlich werden Über nicht-funktionale Kriterien zu sprechen und diese messbar machen.
    69. 69. MisUse Cases  Anwendungsfällen, die eine missbräuchliche Verwendung des Systems enthalten  Nachteil für einen Stakeholder oder ein Unternehmen  potentielle Sicherheitsrisiken früh erkennen Kunde Registrieren Bot Emailadressen sammelnCaptcha nutzen
    70. 70. Aber wo lasse ich diese Qualitätskriterien nun miteinfließen? In jede User Story?
    71. 71. 7! Definition of Ready Definition of Done & - Sicher sein, dass jeder das Problem versteht Story schneiden Wissen wann eine Story fertig ist Die fertige Story verifizieren dokumentieren ausliefern umsetzen
    72. 72. Definion of Ready ! Szenarien erstellt GUI Mock erstellt Story geschätzt
    73. 73. Definion of Done 7 Entwicklertests & Dokumentation angepasst 8 Manuelle Tests auf mehren Systemen Automatisierte SzenarienCode Reviews
    74. 74. Aber was ist jetzt meine Dokumentation? Die Akzeptanzkriterien? Der Akzeptanztest?
    75. 75. Die Liste der Akzeptanzkriterien ist eine gute Dokumentation Gilt auch für Testfälle Umstrukturieren nach Funktionalität Kein aktueller Stand sondern Historie Erweitert / Ersetzt / Verändert vorherige Stories  Stimmt! Gut lesbar, aber was ist bei neuen Stories?
    76. 76. In den Stories bespreche ich hauptsächlich die funktionalen Anforderungen Kleine Stories sind einfacher zu planen, umzusetzen, durchzusprechen und zu TESTEN Und diese Anforderungen in die Definiton of Done überführen Über Nicht- funktionale Anforderungen müssen wir auch sprechen
    77. 77. Story Map 7 ! Akzepttanztest Specification by Example Szenarien Doku Muster Schneiden Product Vision Persona Gemeinsames Verständis

    ×