Scrum & Testing: Erfahrungsbericht von SwissQ und Liip für Vanilla.ch von Ringier

4

An einer Informationsveranstaltung präsentieren die Firmen Liip AG und SwissQ Testing-Verfahren mit der Projektmethodik Scrum am Beispiel des Ringier-Projektes www.vanilla.ch

Scrum und Testing, Tonio Zemp, Liip AG

Tonio Zemp von Liip AG stellt das Web-Projekt vanilla.ch von Ringier vor.

Beispielprojekt Vanilla.ch von Ringier

Vanilla.ch Aktionen und Coupons mit Mobile Payment

Vanilla.ch ist eine Website für Aktionen und Coupons. Retailern steht neben automatisierten Feeds ein B2B-Interface zur Verfügung, um ihre Aktionen einzuliefern.

Voransicht: Retailer-Portal von Ringier's vanilla.ch

Ein weiterer Aspekt des Projektes ist Mobile Payment: In der Vanilla-App gibt man einen sechsstelligen Code ein und bezahlt mit dem erscheinenden Strichcode.

Payment-Verfahren der Gutschein-Website vanilla.ch von Ringier Prämien-Shop bei vanilla.ch von Ringier

Das System ist vor und hinter einer grossen Firewall (rot) organisiert.

Vanilla.ch System-Layout mit Firewall gemäss Liip AG

Security wird entsprechend grossgeschrieben, die Strichcodes werden erst auf dem Handy lokal entschlüsselt. Dieses hält immer zehn Codes als Reserve im Speicher für den Fall, dass man einmal irgendwo bezahlen will, wo man keinen Handy-Empfang hat.

Im Projektverlauf von 8 Monaten war der Scope zuerst auf Aktionen und Coupons, dann auf einem Portal und Mobile, dann auf Mobile Payment, dann auch auf Loyalty.

Fokus auf Aktionen und Coupons und später Mobile-Payment

Das heisst Agilität war von Anfang an wichtig, weil das Storyboard dynamisch ist und viele Disziplinen involviert sind: U.a. Usability, Security, Schnittstellen, Testing. Trotz der Neuanforderungen während der Projektlaufzeit musste der Produktlaunch nur um wenige Monate und nicht um Halbjahre verschoben werden.

In diesem Projekt wurde die Wasserfall-Methodik parallel neben Scrum verwendet: Analyse, Design, Programmierung, Testing laufen dabei üblicherweise sequenziell, was der Scrum-Methodik eigentlich zuwiderläuft.

V-Modell wie es bei der Wasserfall Projektmethodik verwendet wird.

Das Projekt dauerte nur 8 Monate, obwohl 3 Firmenumgebungen mit verschiedenen Projektkulturen und viele involvierte Partner zusammenarbeiteten und diverse Schnittstellen mit hohen Anforderungen (Security) zu integrieren waren.

Ein Setup-Sprint von 2 Wochen diente der Entwicklerinfrastruktur. Das Admin- und Retailer-Interface, Registration und Profil wurden in je zwei Wochen entwickelt (Sprints). Portal und Mobile beanspruchten je zwei Sprints, Bugfix und weitere Module wieder nur einen Sprint von je 2 Wochen.

Scrum-Sprints bei vanilla.ch von Liip für Ringier während 8 Monaten

Mitten in die Entwicklungsphase im zweiten Monat kam die Anforderung an Mobile Payment, was die Integrationsaufwände erhöht und das Profil aufwendiger macht.

Im vierten Monat kam die Anforderung eines Loyalty-Programms dazu.

Prämien-Shop der Gutschein-Website vanilla.ch von Ringier

Die Methodik SCRUM unterstützt Agilität. Innerhalb eines Sprints wird aber entwickelt gemäss Spezifikation und nicht davon abgewichen. Während dieser Zeit soll der Kunde keinen Einfluss nehmen.

Operativ hat sich im Projekt die Rolle eines Product Owner Assistants bewährt: Nicht alle Kunden haben 100% Zeit oder eine Zertifizierung als Scrum Product Owner. Der Assistant unterstützt den Product Owner administrativ in der Vorbereitung der User Stories (Spezifikation), damit die Entwickler danach strukturiert und effizient arbeiten können.

Strategisch hat sich bewährt, einen Mitarbeiter von Liip im Steering Board zu haben. So kann rechtzeitig Einfluss genommen und auf mögliche Konsequenzen von Entscheiden hingewiesen werden.

Die Kommunikation in so einem umfangreichen Projekt ist sehr anspruchsvoll. Transparenz ist Voraussetzung, der Product Owner muss allwissend sein.

Technische Hintergrundinformationen finden sich im Blog von Liip AG.

Testing für Vanilla.ch, Adrian Zwingli, SwissQ

Die Herausforderungen waren zahlreich
– Hoch dynamisch, es ändert sich stets etwas
– Spezielle Kombination aus Medienhaus und Finanzwesen
– Ansprechpartner stark ausgelastet
– Kleines Budget mit kurzer Zeitvorgabe

Es gab keine Zeit für
– Testkonzept (gemäss ISTQB)
– Grosse Testanalyse und „upfront“ Testdesign

Adrian Zwingli von SwissQ über Testing im Projekt vanilla.ch

Fehler sollten so früh wie möglich gefunden (und behoben) werden
– Dies senkt die Fehlerkosten
– Ermöglicht tiefe Belastung der Entwicklungsteams
– Budget einhalten
– Projektstand schnell einschätzen können

Das Risiko soll durch frühe Fehleranalyse abgesichert werden, die Durchgängigkeit und Korrrektheit der Lösung kann so gewährt werden.

Die Scope-Analyse der Ausgangslage gemäss Quality Attributes der ISO 9126 waren hilfreich
– Funktionalität
– Zuverlässigkeit
– Benutzbarkeit
– Effizienz
– Wartbarkeit
– Ãœbertragbarkeit

SwissQ Testing Quality-Attributes gemäss ISO-9126

Sprint Tests, System Tests des Mobile-Portals und des Web-Portals und End-to-End Tests aller Funktionen (Zahlung, Lieferanten, etc.) waren die Komponenten des Testings.

software-testing-scrum-vanilla-ringier-swissq-adrian-stoll

Low Level Tests werden von Entwicklern selbst gemacht. Nach jedem Sprint (2 Wochen) gab es Integrationstests. High Level Tests wurden von SwissQ durchgeführt.

Die Acceptance-Tests wurden innerhalb des Sprints durchgeführt und Fehler gleich behoben. Ãœblicherweise geschieht dies erst später durch den Kunden und bedeutet so mehr Aufwand und höhere Wiedereinarbeitungszeit des Entwicklers, wenn dann der Fehler erst viel später rapportiert wird. Ein Embedded Acceptance Tester beim Entwicklerteam ist viel effizienter: Er verfügt über Testing Spezialwissen, ist objektiv und unabhängig. Er hat den Software-Code nicht geschrieben und ist dadurch unbefangen.

End-to-End Tests

– Jede Partei hat ihre Sprache und Sicht der Dinge
– Stubs (Mock-Ups) bergen Gefahren, weil sie sich anders verhalten als die Realität im Produktivsystem
– Eskalationsstufen sollen vorgängig eingeplant werden und nicht erst wenn es brennt
– Jede Schnittstelle so früh wie möglich testen
– Strukturiertes Testdesign lohnt sich: Die Testszenarien für die Schnittstellen wurden in nur 2 Tagen erstellt und haben sich bewährt.

Beispielhaftes Test-Szenario gemäss SwissQ

Testing-Tipps
– Umgehend Mehrwert des Testteams generieren (und aufzeigen)
– Falls ein Problem nicht direkt einer Person zugeteilt werden kann, für dieses selbst den Lead übernehmen (den Letzen beissen die Hunde)
– Trotz Druck ist die Verwendung von Teststrategien, Testfallherleitung, etc. möglich
– Resultate transparent kommunizieren
– Dort testen, wo es den grössten Business-Impact hat

Testing Trends, Tjeerd Olk, SwissQ

Testing ist eine Schlüsselaktivität in der Software-Entwicklung.

Tjeerd Olk von SwissQ über das Testen in Scrum

Klassisches Testvorgehen fokussiert auf Prozesse und deren sauberen Ablauf. In Scrum ist der Tester Bestandteil des Entwicklerteams, man testet laufend. Die Testpläne umfassen nur das Minimum. Testfälle werden oft „nur“ ad-hoc resp. „explorativ“ durchgeführt: Geübte Tester finden Probleme auch ohne Test-Cases. Die Automatisierung der Testfälle erfolgt während der Software-Entwicklung und nicht erst nach Projektabschluss.

Traditionell (Wasserfall-Modell) wird Testing erst spät im Projekt involviert.

Testing-Zeitpunkt im Wasserfall-Vorgehen vs Scrum

Bei Scrum wird in jedem Sprint getestet, da fertige Software-Inkremente abgeliefert werden sollen.

Unit-Test, Integrationstest, Systemtest, Akzeptanztest gemäss SwissQ

Die Integrationstests sind auch in die Sprints zu integrieren: Funktionieren die Inkremente denn auch als Ganzes (Beispiel Crash-Tests bei Autos)?

Testing in Scrum- und im Wasserfall-Modell

Die Automatisierung von low und high Level Tests ist eine Grundbedingung, um den Aufwand auf immer gleich tiefem Niveau zu halten: Mit jedem Sprint nimmt der Aufwand für Regressionstests zu, ohne Automatisierung (z.B. Selenium als Plugin für Firefox) explodiert der Testaufwand.

Explodierender Aufwand für Regressionstests in Scrum gemäss SwissQ

In Scrum testet man die laufend neu anfallende Funktionalität zuerst „explorativ“, d.h. ohne strukturierte Testfälle. Mit dieser Erfahrung werden dann für die Regressionstests die Dokumentation und die Automatisierung erstellt.

Dies ist allerdings oft auch problematisch, da die Funktion von einem Sprint zum nächsten stark ändern kann und deshalb die Testfälle und allfällige Testscripts nicht mehr funktionieren.
Deshalb empfiehlt sich eine Test-Automation auf tiefem (granularem) Level: Bei Änderungen müssen nur noch Teile des Test-Scripts geändert werden.

High-Level vs Low-Level Test-Automation gemäss SwissQ

Entsprechend sollte die Testautomatisierung in die Sprints integriert werden:
Integration der Tests in die Sprints gemäss SwissQ

4 Schritte zum erfolgreichen Testen in Scrum

– Man muss den „Wasserfall“ Mindset ablegen
– Tester sind ins Entwicklerteam zu integrieren (Embedded Tester)
– Die Test-Strategie ist dem vorliegenden Scrum-Projekt anzupassen
– Low- und High-Level Testing sind zu automatisieren

Walter Schärer, Jobup AG und Tonio Zemp, Liip AG

Alle Bilder und Grafiken mit freundlicher Genehmigung von Liip AG oder SwissQ.

Wer sich zum Tester ausbilden lassen will, findet bei SwissQ einen 2-tägigen Kurs.

Medienmitteilung von Medienmitteilung-Ringier-Vanilla-ch (PDF, 24 kB).

Danke fürs teilen meines Beitrags ;-)

Wer schreibt hier?

Walter Schärer bloggt über neuste Internet-Trends im Online Marketing, Social Media, Blogs, Web Analytics, SEO, Mobile und so.

4 Kommentare

Hinterlässt Du einen Kommentar?