Wie wird man sich klar darüber, was eigentlich gewollt ist? Mithilfe des HEC Produkt-Visions-Posters werden Anforderungen klar definiert. Ina Einemann zeigt, wie Personas erstellt werden und aus Visionen über die agile Entwicklung innovative Produkte entstehen.

1. Testen fangt beim
Fordern an
Ina Einemann
ina.einemann@hec.de
@IEinemann
..

2. ???
Wie kann ich
da testen?
Tester Tim
Mir fehlt der
Kontext

3. Gemeinsames Verstandnis
Das ist ein
Baum Das ist
Schnee
Das ist ein
Fenster
Das ist ein
Wald
..

4. Produktvision
OK – was brauch
ich um eine gute
Vision zu machen?

5. Personas Zielgruppen erkennen
und gruppierenPersona erstellen
Ein Verständnis
für den Nutzer

6. Personas > 60 Jahre
> 1.000.000€ Gehalt
Verheiratet
> 1 Kind
Lebt in einer Großstadt
Ozzy Osbourne &
Prinz Charles

7. Personas
Jetzt weiß ich auch
wer das System nutzt
und welche
Bedürfnisse und
Probleme er hat

9. Produktvision
 HEC Produkt Vision Poster
 Textmuster
 Produkt Karton
 Cover Story

12. Produktvision
 Textmuster
Elevator Pitch

13. Muster
anwenden

14. Produktvision
 Produkt Karton Was
Tolles!

15. Produktvision
 Cover Story
Zitate
Titelseite
Dahin soll also die
Reise gehen !
Dann kann‘s ja mit
den User Stories
losgehen…

17. Backlog
Liste
unübersichlich
Teile passen
nicht zusammen

18. Gibt’s da nicht was besseres
um User Stories zu erstellen
und zu priorisieren?

19. Hüttendetails
durchsuchen
Bezahlen
Account
managen
Hütte anbieten
Buchen
Bestätigung
erhalten
Nach Datum
suchen
Bewertung
schreiben
Bewertungen
einsehen Beschreibungen
lesen
Skigebietinfos
lesen

20. Sven Bewertungen
lesen
Karl
Hütten-
anbieter
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

21. 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

22. Jetzt hab ich einen guten
Überblick über meine User
Stories…
Worauf muss ich eigentlich
achten wenn ich User Stories
erstelle?

23. User Story
Card
eine DinA5 Karte
Überschrift und eindeutige Nummer

24. User Story
Rolle muss klar sein!
Personas

25. User Story
Erster Vorschlag
Wird gemeinsam
im Team
diskutiert

26. User Story
Was möchte ich
erreichen?
Was ist die
Problemstellung?

27. INVEST Kriterien?
 Independent
 Negotiable
 Valuable
 Estimatable
 Small
 Testable

28. User Story
Card
Conversation

29. User Story
Card
Conversation

30. User Story
Card
Conversation
Confirmation
User Stories sind Grundlage der Kommunikation
Das bedeutet nicht NICHTS aufzuschreiben
Akzeptanzkriterien

31. Akzeptanzkriterien
möglichst objektiv und eindeutig
NICHT:
- Story-Inhalt wiederholen
- Versteckte neue User Story
- Einen Workflow beinhalten
Zusammenarbeit zwischen
PO, Entwicklung und Test

32. Von der User Story zu
Akzeptanzkritieren

33. Schlusselworter
identifizieren
.. ..

34. 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?

35. 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?

36. 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?

37. Schneiden
Workflow
Operations
Performance
Simpel/Komplex
Größter
Aufwand
Veriation der
Daten
Variation der
Geschäftsregeln
Variation der
SchnittstelleSpike
Dateneingabe
methode

38. 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

39.  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

40.  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

41. Nun hab ich
endlich meine
kleine Story….
Aber WIE teste ich
diese eigentlich?

42. Akzeptanztest
7
Praktische Anwendung
der Akzeptanzkriterien
Pro Kriterium:
- Mehrere Testfälle
- Wenige Positivfälle
- Jede Menge Negativfälle

43. Szenarien

44. Szenarien
Beschreibt die Vorbedingungen!
Was mache ich vor meiner neuen
Anforderungen/neuen Funktion?
Ausgangssituation

45. Szenarien
Beschreibt die
Durchführung/Änderung!
Was ist meine Anforderungen /
neue Funktion?
Aktion

46. Szenarien
Beschreibt die Änderung!
Was sind die Auswirklungen
meiner Aktion? Was hat sich
geändert?
Ergebnis

47. Szenarien
Steps können wieder
verwendet werden
Testautomatisierung
schnell erstellt

48. Spitze, so kann ich also testen bzw.
automatisieren.
Alles grün … Dann ab zum Review

49. Aber auf meinem
Tablet funktioniert
das ja nicht!!!
Tablet???
Darüber haben wir
nie gesprochen

50. 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

51. 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?

52. 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?

53. 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

54. Und welche
Möglichkeiten haben
wir um diese Bereiche
zu definieren?

55. Nichtfunktionale
Anforderungen
 Planguage
 MisUseCase
 Produkt Vision

56. 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

57. 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.

58. MisUse Cases
 Anwendungsfällen, die eine missbräuchliche Verwendung des Systems enthalten
 deren Auftreten zu einem Nachteil für einen Stakeholder oder ein Unternehmen führen kann
 potentielle Sicherheitsrisiken früh erkennen
Kunde
Registrieren
Bot
Emailadressen
sammelnCaptcha
nutzen

60. Aber wie teste ich meine
nichtfunktionalen
Anforderungen nun
übersichtlich?
???

61. 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

62. Definion of Ready
!
Szenarien erstellt GUI Mock erstellt
Story geschätzt

63. Definion of Done
7
Entwicklertests
&
Dokumentation angepasst
8
Manuelle Tests auf
mehren Systemen
Automatisierte SzenarienCode Reviews

64. 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

65. Story Map
7
!
Akzepttanztest
Specification by Example
Szenarien
Muster
Schneiden
Product Vision
Persona Gemeinsames Verständis