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

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 Beispiele 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 bleiben 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.

Der zentrale Faktor dabei ist die sachgerechte Einordnung von erkannten Fehlern hinsichtlich ihrer Kritikalität. Nicht alles, was dem Tester 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.

Wir helfen Ihnen, Signale in Ihren Projekten richtig zu deuten, und entwickeln gemeinsam wirksame Strategien für die Steuerung.