Was eine Testphase beweisen kann — und was nicht

Eine Testphase misst zuverlässig eine einzige Sache: wie sich der Anfang anfühlt. Anmeldung, erster Eindruck, die ersten Handgriffe. Das ist nicht nichts, denn ein Anfang, der sich zäh anfühlt, wird selten besser. Aber es ist eben auch nicht das, wovon Deine Entscheidung abhängt.

Was Deine Entscheidung trägt, ist das Verhalten im Betrieb: unter Zeitdruck, mit gewachsenen Daten, im Ausnahmefall. Genau das bekommt eine Standardtestphase strukturell nicht zu fassen — nicht aus Unehrlichkeit des Anbieters, sondern weil zwei Wochen mit leerer Datenbank ein anderes System sind als zwei Jahre mit voller. Wer das weiß, kann eine Testphase so anlegen, dass sie trotzdem etwas beweist.

Fangen wir mit dem an, was funktioniert, denn es ist mehr, als man denkt. Eine Testphase beantwortet vier Fragen belastbar, und alle vier sind es wert, beantwortet zu werden.

Wie lange dauert der Anfang? Von der Anmeldung bis zum ersten echten Vorgang. Wenn Du nach neunzig Minuten noch keinen Termin angelegt bekommst, ist das ein Befund und keine Anlaufschwierigkeit.

Findest Du Dich ohne Anleitung zurecht? Klick bewusst zuerst ohne Hilfeseiten. Wo Du hängen bleibst, wirst Du auch im Betrieb hängen bleiben — nur dann mit Publikum.

Wie schnell antwortet der Support? Stell in der Testphase eine echte Frage, keine Testfrage. Die Antwortzeit während der Testphase ist üblicherweise die beste, die es je geben wird; sie ist Deine Obergrenze, nicht Dein Durchschnitt.

Wie fühlt sich das an, was Du am häufigsten tust? Nicht die seltene Spezialfunktion, sondern der Griff, den Du zwanzigmal am Tag machst. Zwei Sekunden Unterschied pro Vorgang sind bei zwanzig Vorgängen am Tag rund vierzig Sekunden — an einem Arbeitstag unauffällig, über ein Jahr mit etwa 250 Arbeitstagen aber knapp drei Stunden.

Fast jeder Dienstleistungsbetrieb hat Wochen, die nichts miteinander zu tun haben. Ein Salon im Januar und derselbe Salon in der Woche vor Weihnachten sind zwei Betriebe. Eine Werkstatt im Sommer und dieselbe Werkstatt beim ersten Frost ebenfalls. Eine Schule in der zweiten Novemberwoche und dieselbe Schule zum Halbjahreswechsel erst recht.

Wenn Du eine Software in der ruhigen Woche testest, testest Du sie unter Bedingungen, unter denen fast jedes System funktioniert. Der Test bestätigt Dir dann etwas, das ohnehin nie strittig war, und schweigt zu dem, was Dich später kostet.

Dagegen hilft weniger Aufwand, als man vermutet:

• Leg den Test bewusst in eine belastete Woche, nicht in die Ferien. Lieber unter realen Bedingungen scheitern als unter idealen bestehen.
• Oder frag nach Verlängerung. Die meisten Anbieter verlängern eine Testphase auf Nachfrage, wenn Du den Grund nennst. Diese eine Mail kostet zwei Minuten.
• Oder bau die Spitze nach. Nimm einen echten Samstag aus dem Vorjahr und trag ihn in einer Stunde in das Testsystem ein. Danach weißt Du, wie ein voller Tag aussieht, ohne auf ihn warten zu müssen.

Der letzte Punkt hat einen Nebeneffekt, den man mitnehmen sollte: Du merkst dabei, wie lange das Eintragen selbst dauert. Das ist keine schlechte Übung, denn genau diese Arbeit wirst Du beim Umstieg noch einmal machen.

Ein leeres System ist schnell, übersichtlich und aufgeräumt. Es hat keine Dubletten, keine alten Kundinnen und Kunden ohne Telefonnummer, keine Leistung, die es seit zwei Jahren nicht mehr gibt und die trotzdem in der Liste steht. Genau daraus besteht aber der Alltag.

Deshalb ist die wirksamste Maßnahme in jeder Testphase, echte Daten hineinzubringen — wenigstens einen Ausschnitt. Zweihundert Kundendatensätze und drei Monate Terminhistorie reichen, um die Fragen zu beantworten, die mit fünf Testdatensätzen unsichtbar bleiben: Wie sieht die Suche aus, wenn vier Personen ähnlich heißen? Was passiert mit einem Datensatz ohne E-Mail-Adresse, wenn das System eine Bestätigung verschicken will? Lassen sich zwei Dubletten zusammenführen, ohne dass die Historie verloren geht?

Zwei Dinge dabei sind wichtig. Erstens: Auch ein Testsystem ist ein System, in dem echte personenbezogene Daten liegen. Die Verarbeitung braucht dieselbe Grundlage wie im Echtbetrieb, und wenn der Anbieter für Dich verarbeitet, braucht es dafür einen Vertrag zur Auftragsverarbeitung — im EU-Rahmen der DSGVO ist das Artikel 28, und der gilt ab dem ersten Testdatensatz und nicht erst ab der Rechnung.

Zweitens: Verlang schon in der Testphase, dass die Testdaten löschbar sind. Wenn Du Dich gegen den Anbieter entscheidest, willst Du diese zweihundert Datensätze wieder aus der Welt haben. Ein System, das das nicht selbstständig kann, hat Dir eine Antwort auf eine viel größere Frage gegeben.

Der häufigste Grund, warum Testphasen ergebnislos verstreichen, ist nicht Zeitmangel. Es ist, dass niemand vorher festgelegt hat, was getestet werden soll. Man klickt herum, findet alles ganz ordentlich, und am vierzehnten Tag steht die Frage unverändert da.

Ein brauchbarer Plan passt auf eine halbe Seite und besteht aus drei echten Vorgängen, die Du vom Anfang bis zum Ende durchspielst — nicht angetestet, sondern zu Ende gebracht. Für die meisten Betriebe sind das:

1. Der komplette Standardvorgang. Von der Anfrage über den Termin bis zum bezahlten Beleg, so wie er bei Dir wirklich abläuft.
2. Der Ausnahmefall. Kurzfristige Absage, Verschiebung, Storno, Teilzahlung, nachträgliche Korrektur einer Rechnung. Ausnahmefälle machen einen kleinen Teil der Vorgänge aus und den größten Teil des Ärgers.
3. Der Blick zurück. Was war letzten Monat los? Wer war seit einem Jahr nicht mehr da? Wenn Du eine Auswertung nicht in zwei Minuten findest, wirst Du sie nie ansehen.

Dazu kommt eine Pflichtübung, die keine zehn Minuten dauert und die fast niemand macht: Löse einmal einen vollständigen Datenexport aus und öffne die Datei. Nicht, um sie zu brauchen, sondern um zu sehen, was drinsteht. Das ist der einzige Zeitpunkt, an dem diese Prüfung nichts kostet, und der einzige Befund der Testphase, der später über den Rückweg entscheidet.

Abbruchkriterien wirken übertrieben, solange man sie nicht braucht. Sie schützen aber vor dem stärksten Effekt jeder Testphase: Nach zehn investierten Stunden will niemand mehr hören, dass die Software nicht passt. Man hat dann keine Software getestet, sondern eine Entscheidung verteidigt.

Schreib deshalb vor dem ersten Login zwei oder drei Sätze auf, bei denen Du aufhörst. Sie sollten so konkret sein, dass ein Außenstehender sie prüfen könnte. Zum Beispiel: „Wenn ich einen Standardtermin nicht in unter dreißig Sekunden anlegen kann." Oder: „Wenn der Export die Terminhistorie nicht enthält." Oder: „Wenn auf meine Supportfrage nach zwei Werktagen keine Antwort da ist."

Solche Sätze machen den Abbruch billig, und das ist ihr ganzer Zweck. Sie ersparen Dir außerdem die unangenehmste Variante: den Vertrag, der zustande kommt, weil die Testphase abgelaufen ist und niemand widersprochen hat. Prüf deshalb am ersten Tag, ob Dein Testzugang automatisch in ein kostenpflichtiges Abonnement übergeht und wo genau Du das abstellst. Diese Information gehört an den Anfang der Testphase, nicht an ihr Ende.

Und wenn Du abbrichst: sag dem Anbieter kurz, woran es lag. Das ist kein Gefallen, den Du erweist — es ist die einzige Rückmeldung, aus der ein Produkt tatsächlich lernt.