Jeder Projekt-, Produkt- oder Qualitätsmanager lernt das: Qualität, Kosten und Zeit bilden zusammen das „magische Dreieck“ der Produktentwicklung. Will man einen Aspekt stärken oder gar maximieren, geht das in der Regel zu Lasten der beiden anderen. Was es erforderlich macht, Kompromisse zu finden, bei denen am Ende immer noch brauchbare Produkte herauskommen.
Wer es jedoch mit Software zu tun hat, könnte zu dem Eindruck gelangen dass der Qualitätsaspekt allzu häufig auf dem Altar der Kostenminimierung und raschen Produktplatzierung am Markt geopfert wird. Wir sind es mittlerweile gewohnt, alle paar Tag Updates und Bugfixes für das Betriebssystem, die diversen Medienplayer und Dokumentenviewer, Runtime-Komponenten, Browser und sonstigen Anwendungen herunterzuladen und einzuspielen. Bugtracker-Listen und CERT-Warnmeldungen werfen täglich mal mehr, mal weniger Meldungen zu publizierten Schwachstellen in verbreiteten Standardanwendungen aus und geben erste Hinweise, was zu tun ist, um das Loch zu stopfen. Und da geht es nur um solche Fehler in Programmen, die zum einen bereits entdeckt wurden und die zum anderen aus Sicht von Fachleuten ein Sicherheitsrisiko darstellen.
Programme auf Fehler und Schwachstellen abzuklopfen ist für manchen Informatiker zu einem lukrativen Nebenjob, wenn nicht gar zum Hauptberuf geworden. Jeder Anbieter von Sicherheitssoftware beschäftigt zahlreiche Leute, die nach Bugs suchen, Code reengineeren, Exploits schreiben und Systeme aller Art zu hacken versuchen. Und lässt sich von Freiberuflern zuarbeiten. Besonders wertvoll sind „frische“, noch unbekannte (Zero-Day-Level) Fehler, die in Form von Exploits an Firmen wie Zero Day Initiative (ZDI) oder iDefense Security Intelligence Services verkauft oder am Datenschwarzmarkt zur bestimmt nicht legalen Weiterverwendung veräußert werden können.
Wie aber kommt es zu diesem „Markt für das Recycling der Fehler anderer Leute“? Zumal Informatiker bereits seit mehr als zwei Jahrzehnten in zunehmendem Umfang mit Methoden der Softwarearchitektur, der IT-Architektur, mit Vorgehensmodellen für komplexe Entwicklungsprojekte, kurz des systematischen ingenieurhaften Entwickelns von Software vertraut gemacht werden.
In anderen Ingenieursdisziplinen werden ja auch Einkaufszentren, Flugzeugträger, Passagierjets oder Industrieanlagen gebaut, ohne dass zwei Tage nach der Inbetriebnahme die ersten Teile wieder abgeschraubt und ausgetauscht werden müssen, weil sonst der Kessel explodieren oder das Schiff untergehen könnte.
So kam die Hamburger Management- und IT-Beratungsfirma Steria Mummert Consulting in einer Untersuchung kürzlich zu der fast schon trivial anmutenden Erkenntnis, dass fast jeder zweite Softwarefehler, der nach Produktivschaltung einer Änderung entdeckt wird, auf Mängeln im Test-Management beruht. Und diese Mängel auf Zeitdruck und „Wir Sparen, koste es was es wolle!“ zurückgeführt werden können. „Husch, husch – time to market – Profit, Profit“ ist da allzu oft die Devise, schnell und schlampig ist oft erwünschter aus ausgereift und funktionierend.
„Die Prognose ist wenig aufbauend. Denn aufgrund regulatorischer Vorgaben werden die IT-Aufwendungen und damit auch der Termindruck in den kommenden Jahren ansteigen“, so Testing-Experte Lars Hinrichsen von Steria Mummert Consulting in einem Interview mit der Computerwoche. Unternehmen versuchen sich auf Kundendruck hin an immer kürzeren Releasezyklen ihrer Produkte. Gleichzeitig stellen enger getaktete Umsetzungsfristen bei Gesetzesanpassungen die IT-Abteilungen auf die Probe. Bei eingespielten Testverfahren wird gespart und stattdessen oft irgendwas improvisiert und das dem eiligen Kunden dann als „agiles Vorgehen“ verkauft.
Das diese Herangehensweise auch richtig voll danebengehen kann, bekommen jedoch immer mehr Firmen zu spüren. So z.B. Neofonie, die 2010 das WeTab als eines der ersten Konkurrenzprodukte zu Apples iPad auf den Markt warfen. Die Software war unausgereift, die Hardware wurde der Eile wegen zusammengestrichen, zahlreiche angekündigte Eigenschaften sollten erst nach Kauf des Tablet-PCs schrittweise nachgeliefert werden. Der Kunde sollte also ein „Bananenprodukt“ erwerben – „Kaufen Sie jetzt ein neues Auto, nächste Woche gibt es das Lenkrad, übernächste Woche dann die hinteren Räder und im nächsten Monat dann den Tank …“. Entsprechend kritisch fielen die Kritiken der ersten Nutzer sowie der Fachpresse aus. Das WeTab verschwand in der Versenkung und wurde nach wenigen Monaten durch ausgereiftere Tablet-PCs anderer Anbieter vom Markt verdrängt. Die darin investierten Gelder dürften daher i.W. verloren sein.
Meiner Ansicht nach liegt das hauptsächlich daran, dass es im Softwarebereich so gut wie keine wirksame Produkthaftung gibt, wie bei Produkten in der realen Welt. Software wird immer noch eher als „geistiges Eigentum“ (ein Kampfbegriff der Verwerterlobby) betrachtet, dass allenfalls „lizenziert“ also wie ein feudales Privileg zuerkannt oder verliehen wird, anstatt als Produkt, das gekauft oder gemietet wird und das so zu funktionieren hat, wie es in der Werbung versprochen und im Vertrag vereinbart wurde.
Allenfalls in hochregulierten Bereiche wie der Finanzwirtschaft, dem Medizinsektor oder der Luftfahrt gelten strengere Anforderungen an die Qualität der Software in Produkten, die von den Herstellern dann auch einschlägig nachzuweisen sind. Weshalb dort auch mehr für Qualitätssicherung und Testmanagement ausgegeben wird und Produkte im Zweifel eher später als defekt auf den Markt kommen.
Was an sich dafür spräche, strengere Standards zur Produktqualität und Produkthaftung auch für „Allerweltsprodukte“ aus dem IT-Bereich festzuschreiben.
