So testen Sie Ihre digitalen Produkte und Dienstleistungen vor dem Launch effizient

Kleine Ursachen – große Wirkungen. Die NASA verlor zehn Jahre Entwicklung in der bemannten Raumfahrt, weil ein 50-Cent-Teil an der Weltraumfähre „Columbia“ ausfiel und eine Katastrophe auslöste. Dies zeigt, dass das Testen einer neuen Entwicklung vor dem Start so erfolgskritisch ist wie alle vorherigen Projektstadien.

Und, fast ebenso erfolgskritisch: Entwicklungs- und Test-Team sollten niemals dasselbe Team sein. Warum nicht, wird im folgenden unter anderem erklärt.

Testkonzepte für neue Produkte und Dienstleistungen sind unausweichlich

Je näher der Start eines neuen Produktes oder Angebots rückt, desto hektischer wird es oft. Die Vorfreude auf den Launch und das erhoffte baldige Ende der Anstrengung mischen sich nicht selten mit dem unbestimmten Gefühl, nicht an alles gedacht zu haben und vielleicht sogar einen „Fehlstart“ hinzulegen.

Gern setzt man da die rosa Brille auf und ignoriert die Notwendigkeit eines angemessenen Testings vor dem Start. Schließlich kann man ja nach dem „Bananenprinzip“ („Produkt reift beim Kunden“) jedes Detail auch dann ändern, sobald es einem Kunden auffällt. Oder das Team glaubt tatsächlich, dass es keine wirklich gravierenden Fehler gemacht hat.

Was aber ist überhaupt ein „gravierender Fehler“? Wer bestimmt das eigentlich? Haben überhaupt alle Projektbeteiligten eine klare Vorstellung davon, was für den Kunden „gravierend“ ist? Wie gehen Sie mit dieser Situation um? Wie können Sie alle – oder zumindest alle wichtigen – Bedenken und Risiken ausschließen, ohne gründlich getestet zu haben?

Welche Merkmale hat ein effizientes Testkonzept für Ihre neuen Produkte und Dienste, damit diese in der Praxis reibungsfrei funktionieren – trotz der hohen technischen Komplexität, wie sie die meisten Digitalen Produkte und Services heute haben? Und wie integrieren Sie das Testing, damit es „in time and budget“ klappt? Sie wollen ja endlich launchen und nicht nur testen.

Im folgenden Beitrag lesen Sie:

Umfang: Was Sie testen müssen
Planung: Warum Sie schon in den ersten Projektphasen an das Testen denken müssen
Vorgehen: Wie Sie testen sollten und welche Tools Sienutzen können
Organisation der Tests: Wer ist wofür zuständig?
Testergebnisse richtig einordnen
Bugfixing und Retesting: Sind die Fehler wirklich beseitigt?
Launch-Termin: Wenn es ernst wird
Post-Launch: Nach dem Launch ist vor dem Launch
Ihre Produkttests optimieren

1. Umfang: Was Sie testen müssen

Der Umfang des notwendigen Testings variiert je nach Produkt und Art der Angebote. Einige Basisroutinen sollten Sie allerdings immer sorgfältig befolgen und dokumentieren:

Argestes Testkonzept

01: Usability: Der Kunde ist König – im Laden wie auf dem Bildschirm. Hoffentlich. Die Oberflächen und UX-Konzepte müssen wirklich exzellent sein, wenn Sie die Kunden von heute überzeugen oder gar begeistern wollen. Die große Kunst ist es dabei, hohe Komplexität und Flexibilität in anwendungsfreundlichen Oberflächenkonzepten abzubilden. Es geht dabei schon lange nicht mehr allein um die Platzierung von Schaltflächen und Menüs, sondern um den Gesamteindruck der Kunden, sprich: die User Experience (UX).

An B2B-Anwendungen werden dabei gelegentlich andere Maßstäbe angelegt als an B2C-Produkte, die sich im Massenmarkt behaupten müssen. Diese Einstellung halten wir für falsch, weil ausnahmslose jeder Anwender seine als Konsument gelernten Ansprüche an optimale Bedienbarkeit und User-Erfahrung aus dem privaten Lebensumfeld auf B2B-Produkte überträgt. Die Usability-Tests müssen daher möglichst früh (auch schon in Scribbles oder Wireframes) erprobt und mit echten Kunden getestet werden. Bitte planen Sie ein, derartige Testkunden frühzeitig auszuwählen und einzubinden. Auch branchenfremde Kunden und speziell unternehmensinterne Kritiker können sehr gute Tester der Oberflächen sein – besonders dann, wenn Projektmanager und Programmierer sich im Verlauf der Entwicklung in diese „verliebt“ haben. Denn Liebe macht bekanntlich manchmal blind…

02: Funktionstests: In den Projektanforderungen sind (hoffentlich) alle relevanten Funktionen des Produktes definiert. Diese können bereits vor der Zusammenstellung der Einzelfunktionen zu einem Gesamtsystem schrittweise entwickelt und inkrementell getestet werden. Wichtig dabei ist ein klarer Termin für einen „Function-Freeze“, da anderenfalls in der Praxis immer wieder zu beobachten ist, dass die Funktionen in der jeweiligen Funktionsgruppe über den festgelegten Umfang hinaus eigenständig weiter entwickelt werden. Diesem Durcheinander muss die Projektleitung mit eindeutigen Definitionen und einem konsequenten Durchgreifen begegnen, sonst passen im nachfolgenden Integrationstest Funktionen nicht zusammen. Terminverschiebungen sind damit quasi vorprogrammiert.

03: Integrationstests: Erst dann, wenn alle Einzelfunktionen entwickelt und auf den (Live-)Systemen zur Verfügung stehen, kann das Zusammenspiel der Einzelfunktionen sinnvoll getestet werden. Das bedingt, dass zum Beispiel bei einem Web-Relaunch alle Serversysteme und Anwendungen konnektiert sein müssen. Dieser Zustand ist häufig erst recht spät erreichbar, da etwa URL-Einträge erst zum Livegang umgestellt werden können. Wichtig ist dabei auch das Testen der Gesamtfunktionen mit verschiedenen Kundenarten und Systemzuständen, zum Beispiel die Simulation des Verhaltens von eingeloggten und nicht eingeloggten Kunden.

04: Migrationstest: Meist ist mit einem Relaunch von Bestandsprodukten die Übernahme von Altdaten aus anderen Systeme notwendig, seien es Kundendaten, Logins oder Bewegungsdaten. Für einen sauberen Launch müssen alle Übertragungen und die Ergebnisse von Schnittstellen- und Migrationsprozessen überprüft werden. Diese Überprüfungen erfolgen je nach Dimension und Kapazitäten stichprobenartig oder vollständig, was bei kundenspezifischen Werten wie Kennworten schwierig werden kann. Zwingend sind die vollständige Auswertung von Logfiles bei der Übertragung von Daten und die Durchführung von Tests mit realen Kunden. Diese müssen frühzeitig engagiert und eingebunden werden.

05: Security und Lasttests: Zahlreiche Beispiel in der Vergangenheit haben gezeigt, wie leicht dieser Punkt zu unterschätzen ist und wie gravierend die Auswirkungen sein können. Schon aus Schutz vor Reputationsverlust oder gar wirtschaftlichen Schäden müssen alle Daten angemessen vor Angriffen geschützt werden. Auch die juristischen Vorgaben wie DSGVO und Datenschutzerklärungen kommen gelegentlich im Eifer der letzten Schritte des Projekts zu kurz. Ein unverzeihlicher Fehler, den es zwingend zu vermeiden gilt.

Wir empfehlen stets externe Experten mit dieser Aufgabe zu betrauen, weil diese mit einem frischen, objektiven Blick auf die Installationen und eingesetzten Technologien schauen.

Auch wenn die meisten Web-Anwendungen heute sehr gut skalieren, sollten ihre Antwortzeiten zeitgemäß, d.h. optimal sein, egal ob es sich um ein internes System oder externe Dienste handelt. Die Messlatte liegt hoch, und der Aufwand zur Verbesserung einer unzureichenden Performance von Einzelanwendungen kann beträchtlich sein – manchmal stellt schlechte Performance sogar das Basiskonzept in Frage. Wichtig ist zu beachten, dass der schwächste Teil eines vernetzten Systems die Performance aller Teile belasten kann. Eine schwierige Situation ergibt sich bei komplexen Architekturen gelegentlich durch historisch „gewachsene“ Backendsysteme und individuelle Schnittstellen.

06: Abnahmetest: Hier geht es weniger um die eigentlichen Testing-Aufgaben, sondern um die Steuerung und Dokumentation von Freigabe-Prozeduren und um die Festlegung, welche Funktionen bei diesem oder einem nachfolgenden Launch des Produkts inkludiert werden sollen. Wir nehmen diese in das Testkonzept mit auf, um sicherzustellen, dass alle Einzeltest sachgerecht abgeschlossen und alle Beteiligten über Feature-Verschiebungen informiert sind. Auch dieser Schritt ist dringend zu dokumentieren und allen Beteiligten transparent zu machen.

Planung: Warum Sie schon in den ersten Projektphasen an das Testen denken müssen

Noch ist keine einzige Zeile Code geschrieben – und schon die Tests planen?

Ja – Testing muss in allen Projekten von Beginn an eingeplant werden. Anderenfalls klappt auch die Meilensteinplanung nicht und Einzelteams entwickeln ihre Funktionen immer über den definierten Rahmen hinaus – oder blieben hinter diesem zurück.

Ein professionelles Testing wie oben beschrieben lässt sich nicht nebenbei oder in einer nächtlichen Gewaltaktion abwickeln. Es sind ausreichende Zeitstrecken und Kapazitäten dazu erforderlich.

Die Testpersonen müssen für ihre Arbeit frisch und motiviert sein. Wenn ein Projektteam, das kurz vor der Erschöpfung steht, zusätzlich selbst testet, wird sich dieser Prozess lang hinziehen – oder er wird hingeschludert und der User-Helpdesk bekommt nach dem Launch den Frust der Kunden ab.

Sie brauchen auch Kapazitäten und Zeit für Retesting, Bugfixing und Freigabe. Wenn Sie diese nicht im Projektplan einplanen, ist der Termin für den Launch schon bei Beginn der Planung hinfällig.

Externe Tester und Kunden müssen frühzeitig eingebunden werden und brauchen ein eindeutiges Briefing. Wenn das nicht erfolgt, findet erfahrungsgemäß kein sinnvoller Test durch Kunden statt – so gewogen sie Ihnen auch sein mögen.

Der Testingprozess muss formal strukturiert und mit geeigneten Tools organisiert werden – und das nicht erst dann, wenn es ans Testing geht. Denn auch die Einführung eines Test-Tools bedeutet eine Systemauswahl, die bei allen Beteiligten Zeit und Know-how beansprucht, das nicht immer vorhanden ist. Zusätzlich müssen Schulung und Einarbeitung an einem Test-Tool eingeplant werden.

Vorgehen: Wie Sie testen sollten und welche Tools Sie nutzen können

Es gibt eine schier unendliche Anzahl von Tools, mit denen sich automatisierte und manuelle Tests planen, durchführen und dokumentieren lassen.

Häufig sind es Erweiterungen oder Ergänzungen zu Projektplanungs- oder Kollaborations-Tools wie zum Beispiel Atlassian JIRA oder Gitlab oder eine Vielzahl von Bug-Trackern. – Aber Vorsicht: Viele Bugtracking-Tools orientieren sich an den Bedürfnissen von Software-Entwicklern und erfüllen nicht zwangsläufig die Erwartungen von marktorientierten Produktmanagern.

Ein Teil dieser Tools ist in der initialen Konfiguration und Datenbefüllung und in der Bedienung recht komplex. Solche Tools lohnen sich zumeist nur bei recht umfangreichen Test-Szenarien.

All diesen Systemen sind aber die folgenden Grundfunktionen gemein:

Tests können mit ihnen geplant und organisiert werden
Alle am Test Beteiligten können über die Tools klare Verantwortlichkeiten erhalten
Strukturierte Testpläne lassen sich erstellen, die Ergebnisse der Tests werden in sinnvoller Weise dokumentiert
Tickets werden zwischen den Beteiligten geroutet, und es lassen sich Aufgaben und Bearbeitungszeiten festlegen
Bearbeitungsstände und benötigte Laufzeiten sind transparent und lassen eine Prognose der Fertigstellungstermins zu

Wesentlicher als das Tool sind die konkreten Testpläne. Dafür eignet sich auch Excel in einer Kollaborations-Umgebung recht gut, sofern die erstellten Vorlagen gut sind. Bei größeren Projekten empfiehlt sich allerdings der Einsatz spezialisierter Testing-Tools.

Organisation der Tests: Wer ist wofür zuständig?

Was Sie festlegen müssen, um komplexe Test-Szenarien und -Routinen sicher zu organisieren:

Wer hat welche Aufgaben beim Testing?
Wie sollen die Ergebnisse dokumentiert werden?
Wer ist für welche Freigaben formal verantwortlich?
Wie und in welchen Systemen wollen Sie mit den Dienstleistern zusammenarbeiten?
Wer organisiert und betreut die externen Tester? Wie erhalten diese Feedback?
Wer entscheidet über einen eventuellen Abbruch des Produkt-Launch?

Testergebnisse richtig einordnen

Es wäre eine Illusion, zu erwarten, dass Sie nach einem komplexen Test-Prozess überall grüne Häkchen sehen – egal, wie sorgfältig geplant und entwickelt wurde. Dafür sind heutige Anwendungen zu komplex. Daher ist es erforderlich, die Dutzende oder Hunderte von Testergebnissen richtig zu bewerten.

Female Engineer Sitting on a Car

Der zentrale Faktor dabei ist die sachgerechte Einordnung von erkannten Fehlern hinsichtlich ihrer Kritikalität. Nicht alles, was dem Testen auffällt kann und darf den Launch behindern oder verhindern. Hier muss es eindeutige Absprachen und Regelungen geben, was für den Launch missionskritisch ist, also welche Funktionen mindestens zuverlässig zur Verfügung stehen müssen und welche Fehler nicht auftreten dürfen, ohne dass ein Launch abgebrochen werden muss. Dazu gehört auch eine Vereinbarung, welche Fehlersituation akzeptabel ist und welche nicht.

Eine korrekte Einordnung von Fehlern erfordert also eine eindeutige und mit allen Projektbeteiligten abgestimmte Klassifikation von Fehlern in den verschiedenen Stufen des Projekts und eine gemeinsame Bewertung von Fehlersituationen, die in der Praxis etwas schwierig sein kann.

Bugfixing und Retesting: Sind die Fehler wirklich beseitigt?

Es versteht sich von selbst, dass auch der beste Test allein noch nicht für ein fehlerfreies System sorgt. Die gefundenen Fehler – „Bugs“ – müssen behoben werden.

Meldet der zuständige Entwickler „Fehler behoben!“, heißt es Retesting – erneutes Testen. Denn immer wieder tritt der Fehler erneut auf oder wurde durch einen anderen Fehler ersetzt – entweder weil der Entwickler, was menschlich ist, gepatzt hat oder weil der Fehler nicht bzw. nicht nur in dem anzupassenden System lag oder weil die Anweisung, wie der Fehler zu beheben sei, Interpretationsspielraum aufwies und der Entwickler nicht in die gewünschte Richtung gedacht hat.

Sehr wichtig ist in dieser Phase ein gemeinsames Vorgehen zwischen Entwicklung, Testern und Projektmanagement, die festlegen müssen, wie lange es dauern darf, bis Fehler behoben werden.

Hilfreich ist es hier, feste Reaktionszeiten festzulegen und Antworten auf Statusveränderungen verpflichtend zu machen.

Sofern ein Tool eingesetzt wird, in dem sich diese Zeiten und die Verläufe mit geringem Aufwand nachhalten lassen, lassen sich auch sehr einfach nach wenigen Iterationen auf Basis der gewonnenen Erfahrungswerte recht aussagekräftige Prognosezahlen bilden, wann welche Testzyklen und Bugfixings voraussichtlich abgeschlossen sein werden.

Launch-Termin: Wenn es ernst wird

Wie schon oben angedeutet, wird sehr selten ein Produkt völlig fehlerfrei gelauncht. Immer und auch bei noch so guter Vorbereitung besteht ein Restrisiko, dass Fehler übersehen werden.

Die sollen in keinem Fall akzeptiert und etwa a priori nach dem „Bananenprinzip“ eingeplant werden. Der Kunde ist schließlich kein Versuchskaninchen. Dennoch gilt es bei allen Beteiligten ein Verständnis für dieses Restrisiko zu wecken. Klar muss auch sein, dass diese Fehler, wenn sie während des Launch sofort erkennbar werden, entsprechend schnell gefixt werden müssen.

Für die Praxis heißt das, dass ein Produktlaunch besser nicht in einer Zeit erfolgt, in der die Beteiligten nicht vollzählig verfügbar sind. Ein Launch ist daher in den „ruhigen“ Randzeiten des Tages und an Wochenenden oder gar Feiertagen dringend zu vermeiden.

Wenn aber der Launch zu Hauptarbeitszeiten erfolgt, beeinträchtigen die Arbeiten manchmal ungeachtet aller Bemühungen, sie im Verborgenen zu erledigen, die ordnungsgemäß performante Funktion des Systems, wie sie die Kunden gewohnt sind: Es kommt zu

kurzen Ausfällen,
verlängerten Antwortzeiten infolge erhöhter Serverlast,
unverständlichen Anzeigetexten,
Abbrüchen von Transaktionen,
ähnlichen Störungen.

Sofern es daher absehbar ist, dass die Kunden spürbar beeinträchtigt werden, muss ihnen dies zwingend beizeiten mitgeteilt werden. Erfahrungsgemäß haben die meisten Kunden größtes Verständnis für eventuelle Beeinträchtigungen, wenn sie eng und rechtzeitig eingebunden wurden und wenn nach dem Launch der Nutzen des neuen Produktes den des alten überwiegt.

Ein Launch kann also immer „ruckeln“, und alle Beteiligten sollten sich darauf einstellen, dass er so gut wie nie ohne Fehler abgeht. Wenn sie jedoch genug Aufmerksamkeit in das Testkonzept, erprobte Verfahren und eine abgestimmte Organisation investiert haben, werden sie Mittel und Wege finden um diese Fehler schnell zu beseitigen.

Post-Launch: Nach dem Launch ist vor dem Launch

Ist der Launch geschafft, würden sich die meisten Projektbeteiligten nach all der Anstrengung gerne eine Auszeit gönnen, was je nach Projektverlauf auch völlig natürlich und nachvollziehbar ist.

Leider kennt allerdings der Kunde weder deren Situation, noch würde sie ihn besonders interessieren. Aber vielfach ist er plötzlich mit Veränderungen konfrontiert, die er sich vielleicht gar nicht gewünscht hat, meldet sich mehr oder minder aufgeregt beim Customer Helpdesk und fordert Änderungen. Wenn dann nicht schnell an neuralgischen Punkten Abhilfe geschaffen wird, kommt es unweigerlich zu Ärger.

Planen Sie also in jedem Fall auch für die Zeit nach dem Launch ausreichende Kapazitäten ein. Das bedeutet, dass Sie ohnehin projektkritische Kapazitäten doppelt vorhalten und mit internen oder externen Kräften besetzen müssen, dass die Dokumentation optimal sein muss, damit Dritter sich in ihr zurechtfinden und dass alle Beteiligten darüber Bescheid wissen. Ohne diese Vorkehrungen sind Sie bei Änderungswünschen der Kunden nicht ausreichend handlungsfähig.

Neugierig?

Sie wollen wissen, wie Sie Ihre Produkttests optimieren können?

Dann freuen wir uns auf Ihren Kontakt. Vereinbaren Sie hier einen Online-Gesprächstermin.

Wir veranstalten in regelmäßigen Abständen kostenfreie Webinare zu diesem Thema. Lassen Sie uns wissen, welche Anforderungen Sie an Ihre Test-Szenarien stellen und wie wir Sie dabei unterstützen können. Wir freuen uns auf Ihre Kontaktaufnahme.