Was ist aber, wenn einfach nur festgestellt werden soll, ob einen Nachricht empfangen werden kann, also ob der Transportweg funktioniert? In Geschäftsanwendungen ist der Nachrichtenaustausch meist an Fachprozesse gebunden. Daher ist es nicht sinnvoll einfach zum Test eine Nachricht zu verschicken, soll auf der Empfangsseite keine Aktion ausgelöst werden. Doch wie kann der Transportweg anders getestet werden?

ping ist ein kleines Programm aus Unix-Urzeiten, mit dem die Erreichbarkeit von Rechnern in Netzwerken überprüfen läßt. Dafür verschickt es eine ICMP-Echo-Nachricht an einen Rechner und erwartet eine Antwort von diesem System, auch Pong genannt. Erhält ping keine Antwort, ist davon auszugehen, daß der Rechner nicht erreichbar ist.

Das gleiche Prinzip kann für Fachanwendungen genutzt werden. Hierzu muß lediglich eine eigene Ping-Nachricht für die Systemschnittstellen definiert werden, wobei folgende Anforderungen zu erfüllen sind:

• Ihre Übermittlung muß vom Zielsystem quittiert werden.
• Sie muß den gleichen Transport-Mechanismus durchlaufen wie die eigentlichen Nachrichten.
• Sie darf keinen fachlichen Prozess auf der Empfängerseite auslösen.

So definiert, steht ein universelles Werkzeug bereit, um den Nachrichtenaustausch leicht und zuverlässig testen zu können.

Dieser Witz ist mir bei der Lektüre von „Adrenalin Junkies und Formular Zombies“ von Tom DeMarco und Co eingefallen, als ich mich gefragt habe, welche Verhaltensmuster ich selber kenne, die aufgeschrieben werden sollten.

Leberwurststullen gibt es dann, wenn die Entwickler in einer Firma niemals mit dem eigenen Produkt arbeiten würden und sich wundern, daß andere es tun. Ein Beispiel hierfür war mein rumänischer Kollege Florian, der sich immer geweigert hatte Online-Banking-Systeme zu benutzen. Auf unsere Nachfrage wieso meinte er nur, daß er in einem Team zur Entwicklung von Online-Banking-Systemen gewesen wäre und wüßte wie diese geschrieben würden. So etwas macht einen dann immer sprachlos. Nach Leberwurst riecht es auch, wenn ein Team mit einer selbstentwickelten Software arbeitet, die es selber für schlecht und unausgereift hält, es aber für Kundenprojekte einsetzt.

Diese beiden Varianten haben den gleichen Ursprung, wenn auch unterschiedliche Auswirkungen. In beiden Fällen haben alle Beteiligten das bewußte oder unbewußte Gefühl, daß etwas mit der Software die entwickelt wird oder dem Softwareentwicklungsprozess nicht stimmt. Daher können sie kein inneres Vertrauen zu ihrem Produkt entwickeln, nutzen es selber nicht und es bildet sich teilweise eine leicht zynische Haltung gegenüber dem Produkt. Das ist vergleichbar mit Bankern, die bei vollem Bewußtsein Kredite an nicht zahlungsfähige Häuslebauer vergeben und uns so die aktuelle Finanzkrise beschert haben.

In unserem Falle sind aber nicht die Entwickler daran schuld. Vielmehr fehlen in solchen Firmen zwei Dinge: Zum einen eine offene Kultur der konstruktiven Kritik und zum anderen ein Bewußtsein für Qualität. Eigentlich schade, den Qualität ist eigentlich gar nicht so teuer, denn auch wenn immer mit Aufwänden argumentiert wird, entsteht Qualität in aller erster Linie durch den Willen dazu.