Die Software strotzt nur so vor Funktionen, Möglichkeiten, Einstellungen, Auswertungen, Analysen – “platzsparend” auf eine Bildschirmseite gepfercht. Eine Art Kontrollzentrum für das, was sie laut Beschreibung leisten soll – und noch mehr. Dazu ein inkonsistentes Bedienkonzept. Immer wieder Updates mit neuen Funktionalitäten, die von einem Kunden gewünscht – und jetzt von allen ertragen werden müssen. Installation und Wartung ist sowieso nur noch durch den Hersteller möglich. Der freut sich über den Wartungsvertrag und die zusätzlichen Einnahmen durch Schulungen – denn ohne einwöchiges Training der Anwender ist die Software nicht nutzbar. Das Problem, das die Software eigentlich lösen sollte oder der Prozess, der damit optimiert werden sollte, ist zur Nebensache geworden.
Gibt’s nicht? Doch – leider viel zu oft. Und wir Tester haben da genauso Mitschuld wie die anderen im Entwicklungsprozess. Sogar noch mehr! Der Tester ist die Instanz, die genau auf solche Missstände hinweisen muss. Die Aufgabe eines professionellen Testers kann nicht sein, nur Anforderungen und Regeln auf ihre Einhaltung zu prüfen. Das kann ein Automat irgendwann auch. Der professionelle Tester ist der “Anwalt des Anwenders”. Der Nutzen für den Anwender muss immer im Fokus bleiben. Und dazu gehört mehr als ein Set an funktionalen Anforderungen, z.B. die meist stiefmütterlich behandelte Usability, die sich bestenfalls als Absichtserklärung und Floskel in den Spezifikationen wiederfinden. Und dafür muss es nicht einmal ein übermächtiger Usability-Test sein. Ein Tag zusammen genügt: Prototyp, Kunde, Tester und ein Block zum Mitschreiben. So eine Zusammenarbeit hilft auch bei einem weiteren Versäumnis: dem Verständnis für die Probleme und Hintergründe der Anwender. Der Tester darf sich die Sinnfrage beim Test und in der Applikation gar nicht stellen. Er muss wissen, wofür er hier eigentlich testet, wo die Software verwendet wird, welchen Geschäftsprozess sie unterstützen soll.
Das alles ist harte Arbeit für den Tester. Neben Kreativität und der Entwicklung eines Spürsinns für die Kundenbedürfnisse benötigt er ein großes Maß an Frustresistenz. Der Hinweis auf größere Missstände und die Etablierung von “Weitsicht” im Test wird auf Blockaden stoßen: “Brauchen wir nicht”, “Haben wir immer schon so gemacht”, “Kümmer’ Dich um die Testabdeckung, der Vertrieb weiß schon was der Kunde möchte”, “Was das wieder kostet!”. Es ist dann wie seinerzeit bei der Einführung des Tests als eigenständige Profession. Auch hier hat die Beharrlichkeit schlussendlich gewirkt und eine gesteigerte Qualität ist der Erfolg davon.
Doch taucht jetzt am Horizont unerwartete Rückendeckung auf: Der Kunde wird anspruchsvoll! Die aktuelle Generation von Web-Applikationen und Mobile Apps beschränken sich oft auf das Wesentliche und die Lösung eines Problems. Die Bedienoberflächen sind einfach und klar strukturiert und die Bedienung ist ohne Schulung intuitiv möglich. Die gesamte Komplexität verschwindet in den Hintergrund. Installation und Wartung laufen fast automatisch. Und neben der “User-Experience” macht es einfach Spaß, Apps zu nutzen – was man von klassischer Business-Software oft nicht sagen kann. Natürlich ist die Komplexität nicht zu vergleichen, aber der Anwender gewöhnt sich gerade an die Erfahrung, Bedienung und den fokussierten Nutzen der Apps – und verlangt dies auch immer mehr von “klassischen” Programmen. Es geht dabei nicht darum, althergebrachte Software in Apps zu verwandeln. Das kann nur scheitern – man nimmt alle Probleme in eine neue Technologie mit und muss dazu noch Kompromisse eingehen. Vielmehr muss der “Geist” der Apps in die klassische Software-Entwicklung einfließen: Software muss konzentriert die Bedürfnisse der Anwender adressieren, ihn bei seinen Aufgaben unterstützen und muss intuitiv bedienbar sein. Diesen Satz kann man sich leicht in seine Entwicklungsleitlinien schreiben. Schwer und viel Arbeit ist erst die Umsetzung. Als Tester sitzt man aber an einem machtvollen Hebel, diesen Geist auch in die eigene Software einfließen zu lassen. Jeder darf für sich entscheiden: Stück-für-Stück rüber über den Tellerrand – oder halt einfach weiter gegen die Anforderungen testen.
Häufig gestellte Fragen
Reicht es aus, wenn Tester ausschließlich Anforderungen und Regeln auf ihre Einhaltung prüfen?
Nein. Reines Abprüfen von Anforderungen und Regeln kann irgendwann ein Automat übernehmen. Der professionelle Tester versteht sich als Anwalt des Anwenders: Er hält den Nutzen für den Anwender im Fokus und weist auf Missstände hin, die kein Anforderungsdokument benennt. Dazu gehört auch Usability, die in Spezifikationen häufig nur als Absichtserklärung auftaucht.
Woran erkennt man Business-Software, die den eigentlichen Zweck aus dem Blick verloren hat?
Typische Merkmale sind eine Fülle von Funktionen, Einstellungen und Auswertungen, platzsparend auf eine Bildschirmseite gepfercht, dazu ein inkonsistentes Bedienkonzept. Updates bringen Funktionen, die ein einzelner Kunde wollte und alle anderen ertragen. Installation und Wartung sind nur noch über den Hersteller möglich, und ohne einwöchige Schulung ist die Software nicht nutzbar.
Wie lässt sich Usability prüfen, wenn kein großer Usability-Test möglich ist?
Ein gemeinsamer Tag genügt oft: Prototyp, Kunde, Tester und ein Block zum Mitschreiben. Dieser kleine Aufwand ersetzt keinen vollwertigen Usability-Test, deckt aber Bedienprobleme auf und bringt zugleich Verständnis für die Hintergründe und Probleme der Anwender. Beides fehlt, wenn Tester nur mit Spezifikationen arbeiten.
Warum sollte ein Tester den Geschäftsprozess hinter der Software kennen?
Weil er sonst die Sinnfrage nicht beantworten kann, die sich beim Testen zwangsläufig stellt. Er muss wissen, wofür er testet, wo die Software eingesetzt wird und welchen Geschäftsprozess sie stützen soll. Ohne dieses Wissen prüft er Regeln, ohne beurteilen zu können, ob das Ergebnis dem Anwender tatsächlich hilft.
Mit welchem Widerstand müssen Tester rechnen, die auf grundlegende Missstände hinweisen?
Mit Blockaden aus dem eigenen Umfeld: “Brauchen wir nicht”, “Haben wir immer schon so gemacht”, “Kümmer dich um die Testabdeckung, der Vertrieb weiß schon, was der Kunde möchte”, “Was das wieder kostet!”. Neben Kreativität und Spürsinn für Kundenbedürfnisse braucht es deshalb Frustresistenz. Schon die Etablierung des Tests als eigene Profession setzte sich nur durch Beharrlichkeit durch.
Löst es die Probleme alter Business-Software, sie in eine App zu überführen?
Nein. Wer althergebrachte Software einfach in Apps verwandelt, nimmt alle Probleme in die neue Technologie mit und muss zusätzlich Kompromisse eingehen. Sinnvoll ist stattdessen, den Geist der Apps in die klassische Entwicklung zu holen: konzentriert die Bedürfnisse der Anwender adressieren, bei deren Aufgaben unterstützen, intuitiv bedienbar sein. Der Satz ist schnell geschrieben, die Umsetzung ist die Arbeit.
Warum steigen die Erwartungen der Anwender an klassische Unternehmenssoftware?
Weil Anwender sich an eine andere Erfahrung gewöhnt haben. Web-Anwendungen und Mobile Apps beschränkten sich 2013 oft auf das Wesentliche und die Lösung eines Problems: klare Oberflächen, Bedienung ohne Schulung, Komplexität im Hintergrund, Installation und Wartung nahezu automatisch. Diesen fokussierten Nutzen verlangten Anwender zunehmend auch von klassischen Programmen, obwohl deren Komplexität nicht vergleichbar ist.
