Wie teste ich ein neues Tarifkonzept einer Fluggesellschaft?

Eine Fluggesellschaft führt ein neues Tarifkonzept ein, welches stärker auf die Bedürfnisse der Kunden zugeschnitten ist. Neben vielen anderen Verbesserungen werden drei Tarife in der Economy Klasse (erstens ohne Gepäck und Sitzplatzreservation sowie ohne Umbuchungsmöglichkeit, zweitens ohne kostenfreie Umbuchung oder drittens alle Möglichkeiten enthaltend) angeboten.

SwissQ wurde auf Grund ihrer Kompetenz und Erfahrungen aus einem vorangegangenen Projekt zur Unterstützung des Testings hinzugezogen. Da ich gerade ein anderes Mandat erfolgreich abgeschlossen hatte, konnte ich für dieses spannende Projekt übernehmen.

Check-in ins Projekt

Mein erster Gedanke bei meinem Beginn im Projekt war: „Das kann doch nicht so aufwändig sein!“ Der Zeitplan gab sechs Wochen Testphase vor, was mir als eng, aber machbar erschien. Bereits nach kurzer Zeit merkte ich jedoch, dass diese Zeitspanne doch sehr sportlich war. Die Gründe hierzu lagen in den zahlreichen Variationen bei der Tarifauswahl, die getestet werden sollten:

• Ein Kunde soll für den Hin- und den Rückflug unterschiedliche Tarife wählen können (Hinflug günstigster Tarif, Rückflug flexibelste Möglichkeit).
• Neben den Tarifen sollen verschiedene Sitzplatzkategorien zur Auswahl stehen, z.B. Standard, erweiterte Beinfreiheit, bevorzugte Zone, usw.
• Dazu sollen ggf. noch unterschiedliche Optionen wie Versicherung, spezielles Essen, zusätzliches Gepäck, verbesserter Komfort, etc. ausgewählt werden können.
• Vielflieger sollen noch zusätzliche Vergünstigungen erhalten.
• Selbstverständlich ist auch noch vorgesehen, dass unterschiedliche Zahlungsarten wie Kredit- bzw. Debitkarte, Postfinance, Voucher (der aber nur für den eigentlichen Flugpreis verwendet werden kann), u.a. angeboten werden.

Erschwerend war auch, dass sehr viele Abkürzungen verwendet wurden. Was genau testet der Testfall, wenn sein Titel lautet:

PNR with OB EUL and IB EUF, any SPS and SPEQ, FoP = CC?
(PNR = Personal Name Record; OB = outbound; IB = inbound; EUL = EU Light Tarif; EUF = EU Flex Tarif; SPS = special surprise (z.B. Champagner); SPEQ = special equipment (z.B. Surfbrett); FoP = Form of Payment; CC = Credit Card).

Weiter kam hinzu, dass im Projekt seit kurzem der Team Foundation Server (TFS) von Microsoft als Testfallverwaltungswerkzeug einsetzt wurde und sich die Prozesse noch nicht eingespielt hatten. Unter Berücksichtigung all dieser Faktoren waren die sechs Wochen schon sehr knapp bemessen und jede Ressource musste möglichst optimal und effizient eingesetzt werden.

Nur keine Flugangst

Wie ging ich vor?

1. Ruhe bewahren, die Hektik kommt noch früh genug!
2. Genaues Ziel definieren.
3. Aktuelle Situation analysieren.
4. Wie erreichten wir das Ziel?

Ziel definieren:

Dies ging nur über Gespräche mit den Stakeholdern:

• Welches sind die qualitativen Ziele?
• Was sind deine/Ihre Erwartungen an das Testteam?
• Was verstehst du/verstehen Sie unter Qualität?

Daraus definierten wir die zu erreichenden und messbaren Ziele.

Briefing vor dem Flug

Es stellte sich heraus, dass bereits einige Testfälle in TFS erfasst worden waren, allerdings z.T. nicht vollständig und dazu noch in unterschiedlichsten Formen. Oft waren die Schritte in der Testfallbeschreibung mit fortlaufender Nummerierung (1., 2., 3., etc.) erfasst worden und nicht als echte Testschritte, wie es im TFS eigentlich vorgesehen ist. Ausserdem existierten noch Testfälle in Word und Excel. Die Business Requirements waren definiert und in einem Word-Dokument erfasst. „Sehr gut, das erleichtert die Arbeit für alle Beteiligten!“, dachte ich mir. Die Spezifikationen wurden durch die Entwickler erstellt und in Kloten bzw. beim externen Partner in Serbien entwickelt. Die Entwicklung musste vor dem Teststart komplett abgeschlossen sein. Die meisten Testressourcen wie auch alle Entwickler waren dem Projekt zu 100% zugeteilt.

Flugplan einhalten:

Wie erreichten wir das Ziel?

• Durch die knappe Zeitvorgabe war mir klar, dass wir die vorhandenen Testfälle nicht in der gewünschten Form im TFS übertragen konnten. Daher entschied ich, für jede zu testende Variante (z.B. die Sitzplatzauswahl oder das Zusatzgepäck) einen Testfall zu erstellen, der nur einen Testschritt enthält. Dies erforderte, dass die entsprechenden Testschritte im angehängten Dokument ausgeführt werden mussten. So konnten diese Testfälle einfach weiter verwendet werden. Neu entwickelte Testfälle wurden dann direkt im TFS erfasst.
• Die TesterInnen wurden gemäss ihrem Wissen eingesetzt, d.h. neue und externe Tester konzentrierten sich auf explorative Tests und erstellten Testfälle in klar definierten und gut dokumentierten Bereichen. Die zugeteilten internen Ressourcen kamen aus bestimmten Fachbereichen, was somit zu einer klar geregelten Zuordnung führte.
• Die vielen Kombinationsmöglichkeiten konnten mittels eines Klassifikationsbaumes übersichtlicher gestaltet und dadurch auch die Entwicklung von Testfällen optimiert werden.

Bild 1: Auszug des Klassifikationsbaumes

• Alle Fehler wurden über eine Person an die Entwicklung weitergeleitet, die gleichzeitig auch für das Fehlermanagement verantwortlich war. Sie leitete das täglich stattfindende Bug Triage Meeting, an welchem die an diesem Tag erfassten Fehler gesichtet und beurteilt wurden.
• Zusätzlich habe ich einen doppelseitigen A4 Flyer erstellt, welcher aufzeigte, wie TFS zu verwenden war. Dieser Flyer wurde innerhalb einer kurzen Schulung präsentiert.

Landung:

Mit all diesen Massnahmen sowie einer strikten Kontrolle und regelmässigem Reporting des Testfortschritts ist es uns gelungen, die vorgegebene Zeit einzuhalten und eine gute Qualität zu erreichen. Wir wünschen allen Passagieren (und natürlichen allen SwissQ Kunden) einen guten Flug!