Montag, 13. Februar 2012

Unfertige Tools im Internet


Ich denke nahezu jeder Internetnutzer kennt das Problem. Man surft durchs Internet, findet eine interessante Seite, vielleicht sogar einen Shop, will mehr Informationen haben und findet sich auf einmal nicht mehr zurecht. Denn so wie man die Funktion der Seite erwartet, funktioniert sie nicht.
Mir ist das vor ein paar Monaten mal wieder so gegangen auf der Seite eines kleinen Spezialveranstalters. Ich habe die Buchungsmaske ausgefüllt um sein Angebot einsehen zu können, doch leider hatte ich den Buchungszeitraum zu eng gewählt. Nur war dies auf den ersten Schritt nicht zu sehen. Die Maske leerte sich, und es gab kein Suchergebnis. Erst auf den zweiten Blick sah ich einen rotgeschriebenen Vermerk oberhalb der Buchungsmaschine „Es müssen mind. 2 Tage gebucht werden“.
Ok, verständlich, jetzt würde ich gerne meine Tage entsprechend anpassen, aber wie oben erwähnt hatte sich die Buchungsmaske wieder auf die Ausgangsstellung zurückversetzt. So musste ich alle Angaben erneut eingeben.

Leider sind solche Dinge nicht die Ausnahme sondern eher die Regel im Internet. Selbst auf bekannten Seiten kommt es immer wieder zu Fehlern. Doch woran liegt es? Klar eine Software, und im Prinzip ist eine Internetseite mit Anwendungen nichts anderes, ist eigentlich nie fertig. Sie wird immer erweitert und vor allem von Fehlern befreit. Es ist nun mal so, dass was im Frontend sich mehr oder weniger übersichtlich präsentiert im Hintergrund auf mehreren hundert, teilweise tausenden Zeilen Code basiert. Und sowas ist nun einmal fehleranfällig.

Warum gelangt ungetestete Software an die Öffentlichkeit, wird sich manch einer in so einem Moment fragen. Nun, ich denke dass die Software in den seltesten Fällen wirklich ungetestet ist. Vielmehr wird in erster Linie der Programmcode untersucht und getestet. Und sicherlich werden auch einige Systemtests gemacht, aber nicht selten sind die Testszenarien halt nicht ausreichend. Dies liegt zum einen am Zeitdruck an dem man in der Softwareentwicklung immer leidet (ich habe noch kein Projekt gesehen dass einmal vor der geplanten Zeit fertig war) und auch daran, dass oft die falschen Leute damit beauftragt werden Testszenarien zu entwerfen. So liegt diese Hoheit sehr oft bei den Entwicklern selbst, anstatt in den diversen Fachabteilungen die die Anwendung angefordert haben. Ein Programmierer wird aber immer aus der Programmierersicht gucken und selten aus der Anwendersicht. Somit wird der Programmierer sicherlich die eine oder andere Fehlfunktion herausfinden, aber ob nun die Oberfläche intuitiv bedient werden kann und alles richtig dargestellt wird, fällt dabei oft über den Tellerrand.

Wie kann man das Problem verbessern? In erster Linie bedarf es einer konkreten Anwendungsbeschreibung. Dies kann man in meinen Augen am Besten mit sogenannten Userstories erreichen. In den Userstories wird kurz und bündig aufgeführt welche Funktion man wünscht und wie das Resultat sein soll. Z. B. Funktion: „Ich gebe als ersten Multiplikator eine 5 in das linke Multiplikatorfeld und als zweiten Multiplikator eine 5 in das rechte Multiplikatorfeld ein und klicke den Button berechnen“  Ergebnis: „Die Anwendung multipliziert die beiden Mulitplikatoren und gibt in einem Ergebnisfeld 25 aus“. 

Stufe 1: Mit einer solchen Story weiß der Programmierer genau was er zu tun hat und kann die Anwendung entsprechend testen. Dies erfolgt in der Regel mit automatisierte Unittests.
Nun haben wir das Ergebnis das der Code mit hoher Wahrscheinlichkeit funktionieren wird.

Stufe 2: Sobald dies von der Technik sichergestellt ist, sollte die Anwendung an die entsprechende Fachabteilung aus der die Anforderung kam weitergereicht werden. Hier muss sich nun der Verantwortliche entsprechend Zeit nehmen und das ganze manuell zu prüfen. Das mag bei meinem Beispiel in 5min erledigt sein, aber bei komplizierteren Anwendungen wie z. B. einer Buchungsmaschine oder einem Onlineshop können da schon mal einige Tage draufgehen. Hier ist es dann extrem wichtig, dass man sich einen Kopf über mögliche und unmögliche Szenarien macht. Trotzdem wird es einfach nie gelingen auch wirklich alles zu prüfen.

Stufe 3: Wenn die Fachabteilung dann die Anwendung abgenommen hat, wird es Zeit diese entweder an Testkunden auszuliefern oder aber in einem geschlossenen Test einigen potentiellen Nutzern zu zeigen.
Erst wenn alle 3 Stufen erfolgreich und sorgfältig durchlaufen wurden, wird man eine sehr gut aussortierte Software bereit stellen können.

Allerdings wird dieses Konzept aufgrund von Zeitdruck und nicht selten aus finanziellen Gründen selten angewandt. Denn in den Planungsabteilung sieht man oft eher die Quantiät (in dem Fall die Zeit bis zum Livegang) als die Qualität.

Hier investiert man dann viel Zeit in den Support und die Nacharbeitung, weil der Zeit- und Geldaufwand dann auf einer anderen Kostenstelle gebucht wird und man ja mit dem Produkt live ist. Das dies vor allem zu Kosten der Nutzer geht und dabei nicht selten auch die Kundenzufriedenheit auf dem Spiel steht wird oft ausser acht gelassen.

Es ist Zeit für ein Umdenken und wieder mehr auf Qualität statt auf Quantität zu setzen. Am Ende spart sich man nicht nur Kosten sondern auch Ärger.