Testen fängt beim Fordern an

Testen fangt beim Fordern an

Ina Einemann

ina.einemann@hec.de

@IEinemann

..

???Wie kann ich

da testen?

Tester Tim

Mir fehlt der

Kontext

Gemeinsames Verstandnis

Das ist ein

Baum Das ist

Schnee

Das ist ein

Fenster

Das ist ein

Wald

..

Produktvision

OK – was brauch ich um eine gute

Vision zu machen?

Personas Zielgruppen erkennen und gruppierenPersona erstellen

Ein Verständnis für den Nutzer

Personas > 60 Jahre> 1.000.000€ GehaltVerheiratet> 1 KindLebt in einer Großstadt

Ozzy Osbourne &Prinz Charles

PersonasJetzt weiß ich auch

wer das System nutzt und welche

Bedürfnisse und Probleme er hat

Produktvision

HEC Produkt Vision Poster

Textmuster

Produkt Karton

Cover Story

Produktvision

Textmuster

Elevator Pitch

Muster anwenden

Produktvision

Produkt Karton Was Tolles!

Produktvision

Cover Story

Zitate

Titelseite

Dahin soll also die Reise gehen !

Dann kann‘s ja mit den User Stories

losgehen…

Backlog

Liste unübersichlich

Teile passen nicht zusammen

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

Hüttendetails durchsuchen

Bezahlen

Account managen

Hütte anbieten

Buchen

Bestätigung erhalten

Nach Datum suchen

Bewertung schreiben

Bewertungen einsehen Beschreibungen

lesen

Skigebietinfos lesen

SvenBewertungen lesen

Karl

Hütten-anbieter

Nach Datum suchen

Hüttendetails durchsuchen

Hütten buchen

Hütte anbieten Bewertungen einsehen

User Story

BuchenAnbietenBewertungen

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

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

Jetzt hab ich einen guten Überblick über meine User

Stories…

Worauf muss ich eigentlich achten wenn ich User Stories

erstelle?

User Story

Card

eine DinA5 Karte

Überschrift und eindeutige Nummer

User StoryRolle muss klar sein!

Personas

User Story

Erster Vorschlag

Wird gemeinsam im Team diskutiert

User Story

Was möchte ich erreichen?

Was ist die Problemstellung?

INVEST Kriterien?

Independent Negotiable Valuable Estimatable Small Testable

User Story

Card

Conversation

User Story

Card

Conversation

User Story

Card

Conversation

Confirmation

User Stories sind Grundlage der Kommunikation

Das bedeutet nicht NICHTS aufzuschreiben

Akzeptanzkriterien

Akzeptanzkriterienmöglichst objektiv und eindeutig

NICHT: - Story-Inhalt wiederholen- Versteckte neue User Story- Einen Workflow beinhalten

Zusammenarbeit zwischen PO, Entwicklung und Test

Von der User Story zu Akzeptanzkritieren

Schlusselworter identifizieren

.. ..

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?

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?

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öschenUnd wenn es nicht passt?

Schneiden

Workflow

Operations

Performance

Simpel/Komplex

Größter Aufwand

Veriation der Daten

Variation der Geschäftsregeln

Variation der SchnittstelleSpike

Dateneingabemethode

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/SkiDetails

Zeitraum

Equipment

Bezahlart

Versicherung

Buchen

Leihort

Größter Wert -> Anfang und Ende

Mittelteil vergrößert nach und nach den Wert

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 derGeschaftsregeln

..

Erst eine Teilmenge der RegelnStart und Endtermin

X von y Tagen

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

Nun hab ich

endlich meine

kleine Story….

Aber WIE teste ich

diese eigentlich?

Akzeptanztest

7

Praktische Anwendung der Akzeptanzkriterien

Pro Kriterium:- Mehrere Testfälle

- Wenige Positivfälle - Jede Menge Negativfälle

Szenarien

Szenarien

Beschreibt die Vorbedingungen!Was mache ich vor meiner neuen Anforderungen/neuen Funktion?

Ausgangssituation

Szenarien

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

Aktion

Szenarien

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

Ergebnis

Szenarien

Steps können wieder verwendet werden

Testautomatisierung schnell erstellt

Spitze, so kann ich also testen bzw.

automatisieren.

Alles grün … Dann ab zum Review

Aber auf meinem

Tablet funktioniert

das ja nicht!!!

Tablet???

Darüber haben wir

nie gesprochen

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

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?

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?

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 werdenInterne Qualität

Und welche

Möglichkeiten haben

wir um diese Bereiche

zu definieren?

Nichtfunktionale Anforderungen

Planguage

MisUseCase

Produkt Vision

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

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.

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

BotEmailadressen

sammelnCaptcha nutzen

Aber wie teste ich meine

nichtfunktionalen

Anforderungen nun

übersichtlich?

???

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

Definion of Ready

!

Szenarien erstellt GUI Mock erstellt

Story geschätzt

Definion of Done

7

Entwicklertests

&

Dokumentation angepasst

8

Manuelle Tests auf mehren Systemen

Automatisierte SzenarienCode Reviews

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

Story Map

7

!

AkzepttanztestSpecification by ExampleSzenarien

Muster

Schneiden

Product VisionPersona Gemeinsames Verständis