Mitarbeiter lässt man unter schlechter Software leiden

Im Regelfall würden gar nicht alle Möglich­keiten komplett ausgetestet, verrät Johannes Bergsmann vom österreichischen Software Quality Lab. Ein höherer Testaufwand – bis zu 80 Prozent des gesamten Projektbudgets – würde dann getrieben, wenn Personenschäden auftreten könnten oder sogar Menschenleben auf dem Spiel stünden. Auch Kernbanken­systeme müssten, aus naheliegenden Gründen, einen aufwendigeren Testparcours absolvieren.

Generell seien alle Funktionalitäten, die nach aussen zum Kunden gingen, eher kritisch und die Tests fallen entsprechend intensiver aus. Bei nach innen gerichteten Funktionalitäten wie Berichten oder Reports lässt man anscheinend gerne mal fünf gerade sein, und die Firmenmitarbeiter leiden darunter. Denn "ob ein Bericht ein paar Sekunden länger oder kürzer dauert, das beschädigt das Image der Firma nicht", meint Bergsmann. "Die Standardtestverfahren decken nur etwa 10 bis 20 Prozent aller Use Cases ab, aber die typischen, die 95 Prozent aller Endanwender benutzen."

Da bleibt noch viel Raum für Fehler. Firmen stellen eine knallharte Kosten-Nutzen-Kalkulation an und überlegen sich, wie viel ihnen qualitativ hochwertige, intuitiv bedienbare und sichere Software wert ist. Manche Auftraggeber nehmen Fehlfunktionen, die in selteneren Use Cases auftauchen können, billigend in Kauf, weil ihnen sonst das Projekt zu teuer wird. Kostenüberlegungen beeinflussen nicht nur die Testqualität, sondern auch den Entwicklungsprozess.

Es gebe prinzipiell vier Ansätze, mobile Apps für unterschiedliche Geräte und Betriebssystemversionen zu ent­wickeln, sagt Zühlkes Kerry Lothrop. Der zeitaufwendigste und teuerste: Software-Architekten programmieren nativ, also in Objective-C/Swift für iOS, in C# für Windows Phone und in Java für Android. Die App muss also dreimal programmiert werden, nutzt aber die Eigenheiten der jeweiligen Plattform optimal aus.

Der zweite, preiswerte Ansatz, der mittlerweile aus der Mode kommt: Der User ruft die App über einen Browser auf, es handelt sich also eigentlich eher um eine mobile Webseite. Die dritte, elegante Option nutzt sogenannte Cross Compiler (zum Beispiel Xamarin): Programmierer entwickeln die Applikation in der Programmiersprache der einen Plattform und kompilieren sie danach (nativ) auf die anderen.

Der vierte ist der hybride Cross-Plattform-Ansatz, der sich ausschliesslich an Webstandards wie HTML, CSS und JavaScript bedient, die über ein Toolkit in einer nativen App dargestellt werden. Die App läuft dann auf allen Plattformen. Native Funktionen, die es nur auf Apple- oder Android-Geräten gibt, werden über nativ programmierte Plug-Ins eingebunden.

"Es gibt keinen klaren Gewinner, in der Regel erstellen wir eine Feature-Matrix und treffen dann unsere Entscheidung für oder gegen eine bestimmte Entwicklungsmethodik", sagt Bergsmann diplomatisch, gibt aber zu: "Soll die App auf allen Plattformen gleichzeitig laufen, dann führt der hybride Cross-Plattform-Ansatz mit räsonablem Kosten-Nutzen-Verhältnis am schnellsten zum Erfolg."