Insbesondere bei der agilen Entwicklung unter Beibehaltung existierender Daten kann man leicht auf ein Problem stoßen welches ich diskutieren möchte:

Eine Kundenverwaltungsoftware für einen PC Verkäufer wird entwickelt. Die Software läuft gut, aber es häufen sich Betrugsfälle im Rahmen von Garantiefällen. Deshalb wird beschlossen bei dem Hersteller der Hardware die Seriennummer im Garantiefall gegenzuprüfen. Bei der Verwendung des Webservices des Herstellers fällt auf, daß ein Großteil der bereits erfassten Seriennummern falsch sind. Der Hersteller gibt die Validierungsroutine heraus und diese wird in die Software eingebaut. Nun wird beim Verkauf und allen weiteren Geschäftsvorfällen die Nummer geprüft. Ab diesem Zeitpunkt häufen sich die Beschwerden der Mitarbeiter, daß die Anwendung alte Kundendaten nicht mehr speichern kann. Auch das Finanzmodul verweigert jetzt seinen Dienst und kann Zahlungen für Rechnungen nicht mehr speichern.

Das Szenario zeigt, daß Bestandsdaten immer Probleme machen wenn zusätzliche Bedingungen eingeführt werden. Man könnte die Validierung auf das Userinterface beschränken und so das Finanzmodul funktionsfähig halten, jedoch hilft dies für die andere Hälfte der Probleme nicht.

Auch automatische Datenkorrekturen sind nicht immer erfolgreich, da oft Information einfach fehlt.

Ein Patentrezept gibt es leider nicht, jedoch hat sich folgende Prozedur bewährt:

1. Vor dem Hinzufügen der Regel alle Bestandsdaten welche Fehlerhaft sind korrigieren soweit möglich
2. Regeln für einen gewissen Zeitraum nur als Warnung, nicht als Fehler prüfen.
3. Regeln anhand von weiteren Parametern, welche alte Datensätze ausschließen, anwenden
4. Beim Design von Datenfeldern zeitnah Validierung hinzufügen

Was für Erfahrungen habt Ihr gemacht. Gibt es ein Vorgehen welches das Auftreten von solchen Dateninkonsistenzen vermeidet?

Meine Kollegen bei codecentric sind nahezu allesamt Informatiker oder ausgebildete IT-Fachkräfte. Als Mathematiker und Quereinsteiger bin ich – zumindest in unserer Firma – trotz des nach wie vor großen Fachkräftemangels in der Branche immer noch eine Ausnahme. Eine Ausnahme stelle ich bei codecentric auch als spezialisierter Tester dar. Und wie sich das für einen Performance-Spezialisten wie die codecentric GmbH gehört, liegt mein Schwerpunkt auf dem spannenden Gebiet der Last- und Performanz-Tests, also im Bereich des nicht-funktionalen Testens.

Für mich war es faszinierend festzustellen, dass Testen offenbar ein Sammelbecken für Quereinsteiger in der IT-Branche ist. Das trifft bereits auf den Bereich des funktionalen Testens zu. Natürlich findet man dort noch in reichlicher Zahl die obligatorischen Informatiker und Mitarbeiter aus den jeweiligen Fachabteilungen. Aber es gibt doch schon auch in beachtlicher Anzahl IT-Exoten wie z.B. Juristen. Bei einer Schulung zum Thema Last- und Performance-Tests in Köln Anfang 2008 erlebte ich dann einen wahren Berufe-Zoo: Neben mir als Mathematiker fanden sich dort u.a. eine Germanistin und eine Agrar-Wissenschaftlerin, die Dozentin selbst war Meteorologin. Und nicht wenige waren promoviert.

Der Bereich des Testens in der IT ist aus meiner Sicht ideal für Fachfremde geeignet. Natürlich sind IT-Fachkenntnisse gewünscht und nützlich, aber man muss sie nicht in der Spezialisierung und Tiefe meistern und beherrschen wie z.B. als Entwickler. Im Gegenteil, zu tief in den Technologien versunken zu sein, kann einen im klassischen Sinne betriebsblind machen. Oberstes Ziel des Testers ist die Gewährleistung guter Qualität, aber der Maßstab für gute Qualität ist nicht die oft Technologie-verliebte Sichtweise des Software-Entwicklers, sondern der Nutzen des Endprodukts für den Anwender bzw. den Kunden. Und zur Beurteilung dieses Nutzens ist eine gewisse Distanz zur IT oftmals hilfreich. Zumindest aber muss die Fähigkeit vorhanden sein, geistig auf Distanz zu gehen und das Produkt – das Testobjekt, wie der Tester sagt – aus einem anderen Blickwinkel zu betrachten und zu bewerten.

Und genau hier kommen die Qualitäten des Quereinsteigers zum Zug, die meiner Überzeugung nach den höheren Schulungsbedarf und die anfangs geringere Produktivität langfristig mehr als wettmachen. Er ist per Definition kein IT-Insider und tut sich daher wesentlich leichter, die Anwendung oder das IT-System nicht als Selbstzweck, sondern im Hinblick auf die Aufgabe zu betrachten, die es zu erfüllen gilt. Der Quereinsteiger kann seine Erfahrungen aus anderen Branchen und Tätigkeiten einbringen. Dadurch hat er nicht nur eine andere Sicht auf die Dinge, sondern er kann aus der Synthese seiner Erfahrungen oft einen echten Mehrwert für das konkrete Projekt schöpfen sowie in anderen oder größeren Zusammenhängen denken. Bei Last- und Performanz-Tests sind diese Fähigkeiten besonders gefragt, da vor allem zur Konzeption entsprechender Tests Anforderungen und Informationen aus den verschiedensten Bereichen zusammengetragen, analysiert und verknüpft werden müssen. Ansprechpartner für den Lasttester sind natürlich die betroffenen Fachabteilungen, die IT-Entwicklung und IT-Infrastruktur, häufig aber auch z.B. Marketing und Vertrieb, Management und sogar externe Dienstleister. Der Quereinsteiger mit seinem breiten Hintergrund ist bei solch einer Aufgabenstellung oft im Vorteil.

Mein Studium der Wirtschaftsmathematik an der Universität Augsburg stellte bereits eine solche Synthese verschiedener Fachrichtungen dar – Mathematik, Informatik und Wirtschaftswissenschaften. Und schon in meinem ersten größeren Lasttest-Projekt – bei dem Kunden handelte es sich um ein Kfz-Versicherungs-Unternehmen – fand ich genau diesen Querschnitt fast idealtypisch wieder. In der Folge des Diploms führte mich mein Weg an die Universitäten in Berkeley und Jena, wo ich mit der (kombinatorischen) Spieltheorie, Optimierung und Operations Research verschiedenste Gebiete der Mathematik und ihre Anwendungsmöglichkeiten auf ganz reale Fragestellungen genauer unter die Lupe nahm.

Von diesem Hintergrund aus möchte ich zukünftig im Rahmen dieser Kolumne alle möglichen Aspekte der IT-Branche ansprechen und beleuchten. Dabei sollen aktuelle Entwicklungen bewertet oder einfach Beobachtungen aus dem IT-Tagesgeschäft bei codecentric aufgegriffen werden, wobei ein wesentlicher Fokus sicherlich auf dem Gebiet des (Last- und Performanz-)Testens liegen wird. Vor allem aber möchte ich dies mit dem Blick von außen tun, dem Blick des Quereinsteigers und des Mathematikers.