Software Tests

Ich möchte etwas über Software Tests sprechen.

In den letzten Jahren gab es eine Bewegung in Richtung Qualitäts-Steigerung im Software-Umfeld.
Ein Resultat davon ist Test Driven Development (TDD). Kurz zusammen-gefasst könnte man sagen, bei Test Driven Development werden die automatisierten Tests erstellt, bevor der Code der Software geschrieben wird.

Es ist zu erwähnen, dass noch andere Konzepte exisitiern, welche vorsehen, zuerst die Tests zu erstellen. Zudem gibt es weitere Methoden, welche eine Qualitäts-Steigerung durch Software-Tests bewirken sollen.

Dieses Vorgehen hat mehrere Gründe. Der Wichtigste ist, dass es einen zwingt, Tests zu erstellen ;-)
Es gibt die grundsätzliche Haltung, dass ein Entwickler nie seinen eigenen Code testen sollte. Es geht dabei darum, dass der Entwickler weiss, wie die Software aufgebaut ist. Er wird deshalb so testen, wie er denkt, dass seine Software korrekt funktionieren wird. Das kann sich jedoch davon unterscheiden, wie der Benutzer sie anwenden wird. Der Benutzer weiss ja nicht, wie die Software aufgebaut ist.

Die richtigen Software Tests decken Fehler auf

 

Problem-Verschiebung

Wenn der Test vor dem Code der Software erstellt wird, wird der Code am Test angepasst. Es gibt jedoch keine Garantie, dass der Test sinnvoll ist. Dadurch werden die Risiken einfach vom Code in den Test verschoben.

Nehmen wir eine Applikation die zwei Zahlen multiplizieren soll. Ein Test gibt 3 und 4 als Parameter ein und das Resultat ist 12. Der Test ist erfolgreich, Arbeit erledigt. Richtig? Was ist aber, wenn das Resultat unabhängig von den Parametern immer 12 zurück gibt?

Ich weiss ich werde gleich auf dem Scheiterhaufen landen. „Das ist ein absolut blödes Beispiel“. Ja ein blödes Beispiel.
Der Sinn von TDD lässt sich für mich damit zusammenfassen, den kleinst-möglichen Aufwand zu betreiben um einen Tests zu erfüllen. Weil der Entwickler den Test kennt und deshalb weiss, dass 3 und 4 als Parameter reinkommen, muss das Resultat 12 sein. Streng genommen ist der kleinst-mögliche Aufwand um den Test zu erfüllen also einfach 12 als Resultat zurück zu geben.

Immer noch blöd?
Damit will ich natürlich nicht sagen, Software-Entwickler wären dämlich. Ich will zeigen, dass diese Methode nicht zwingend zu einer Qualitäts-Steigerung führt. Vor Allem dann nicht, wenn die Tests falsch ausgerichtet sind.

Zusammenfassend entsteht die Gefahr, beim Erstellen von Code vor dem Test, dass der Test so angepasst wird, dass er immer erfüllt wird. Wenn der Test vorher geschrieben wird, wird der Code an den Test angepasst, sodass dieser immer erfüllt ist.
Das Resultat bleibt streng betrachtet dasselbe.

Kunden-Orientierung

Ich habe bereits Qualitäts-Steigerung erwähnt. Was genau bedeutet das, in Hinsicht auf Software-Tests?
Es bedeutet, dass der Kunde erhält, wofür er bezahlt (funktionale Anforderungen). Und natürlich, dass die Applikation einige „weiche“ Qualitäts-Ziele erfüllt (nicht funktionale Anforderungen). Dazu gehören z.B. Benutzer-Freundlichkeit und Stabilität.
Natürlich sind die nicht funktionalen Anforderungen nicht immer einfach zu testen.

Wenn es für die Use-Cases Szenarien gibt, sollten diese als Referenz verwendet werden. Sie bestimmen, ob die Anforderungen erfüllt sind.
Wie das funktioniert?
Anstatt isolierte Funktionen oder Strukturen zu testen, sollten ganze Szenarien mit automatisierten Tests abgebildet werden. Das beinhaltet auch die Fehler-Pfade, welche in einem definierten Fehler-Zustand enden. Oft kann es Sinn machen, mehr als einen Test pro Szenario zu erstellen. Das ist vor Allem dann der Fall, wenn die Szenarien nicht sehr detailliert sind.

Falls sich nun jemand fragen sollte, „Wovon Spricht der Typ da genau?“, dann ist es höchste Zeit Google aufzurufen!

Natürlich kann es Sinn machen, Tests tiefer zu unterteilen.
Nehmen wir irgendeinen FTP-Client als Beispiel. Der Client wurde selbst-ständig erstellt. (Ich meine damit, er wurde nicht gekauft oder herunter geladen.) In diesem Fall ist es sinnvoll, den Client zuerst isoliert zu testen.
Hier wurde die Applikation jedoch nicht genügend in Module unterteilt. Der FTP-Cient ist etwas, was bereits für sich einen Wert für einen Kunden haben könnte (vgl. das Zwiebel-Prinzip).

Kunden-Wert

Es heisst, Tests sollten so einfach als möglich sein, um keine Fehler-Quelle darzustellen.

Falls die Applikation einfach strukturiert ist, gibt es normalerweise auch nur wenige Kontakt-Punkte.
Nehmen wir einen Kunden, der einen neuen Eintrag in einer Datenbank anlegen möchte. Z.B. eine Adresse. Es genügt einige Felder abzufüllen und den Speicher-Button zu drücken.
Das ist im Übrigen ein komplettes Szenario.
Mit einen Web-Service, welcher die Daten entgegen nimmt, wäre der Test sehr einfach. Richtig?
Um das Resultat zu validieren, kann nun der Service aufgerufen werden, der die Daten zum Anzeigen zurückgibt. Oder aber, die Daten können direkt in der Datenbank verglichen werden.

Zur Erinnerung, der Kunde bezahlt nicht dafür, was in der Software geschieht. Der Kunde bezahlt für das Verhalten der Webseite. Dafür, was am Ende wieder herauskommt, wenn er die Felder abfüllt und den Speicher-Knopf drückt.
Vielleicht werden die Daten auf dem Browser verschlüsselt und an den Server gesendet. Nun könnten Sie auf dem Server fälschlicher-weise nochmals verschlüsselt, anstatt entschlüsselt werden.
Das ist das Problem des Entwicklers! Den Kunden kümmert das nicht. Wenn die Daten beim Auslesen wieder zweimal entschlüsselt werden, wird der Kunde davon nichts mitbekommen.
In diesem Fall ist der Test erfolgreich, weil für den Kunden die Anforderungen erfüllt sind.

Erfüllte Anforderungen

Die Anforderungen waren, dass dieselben Daten beim Auslesen wieder angezeigt werden, die vorher gespeichert wurden. Die andere Anforderung, dass die Daten niemals unverschlüsselt durch das Internet versendet werden dürfen, ist ebenso erfüllt.

Ist schwer zu verstehen, ich weiss. Aber der Kunde bezahlt genau dafür.
Er interessiert sich nicht für Kodierung, Komprimierung, Kompostierung oder Embedded Linux auf Grossmutters Zahnbürste.
Das ist der Job des Entwicklers. Das ist der Grund warum er die Applikation kauft und nicht selber baut.

Natürlich kann man argumentieren, dass Verschlüsselung wichtig für den Kunden sei. Ist es auch. Aber es ist nicht sein Bedürfnis! Sein Bedürfnis ist die Sicherheit der Daten. Wie der Entwickler das gewährleistet ist dem Kunden völlig egal.

Möglicherweise gibt es eine Anforderung, dass die Daten nicht von Fremden gelesen werden dürfen. Dann baut man ein Szenario und erstellt einen Test dafür. Voilà, Sicherheit gewährleistet, Anforderung erfüllt.

Auf den Kundenwert fokussieren, das ist das Ziel. Er bestellt Wert, Verhalten, Lösungen. Alles andere ist irrelevant.

Software Tests mit dem richtigen Fokus

Falls das nun zu schnell ging, um es zu verstehen, will ich es nochmals kurz erläutern.

Ich will niemanden für oder gegen Test Driven Development aufbringen. Ehrlich gesagt spielt es für mich keine Rolle, welches Werkzeug verwendet wird. Wichtig ist für mich auch nicht, ob die Tests vor oder nach dem Code geschrieben werden.
Wichtig ist nur, dass dabei auf den Kundenwert geachtet wird. Was ist das echte Bedürfnis des Kunden. Wofür bezahlt er?

Es ist absolut in Ordnung, Schnittstellen innerhalb der Applikation zu testen. Vor Allem dann, wenn es wahrscheinlich ist, dass die Applikation in naher Zukunft erweitert oder geändert wird. Es geht nicht darum, dass nicht auch Tests innerhalb der Software – also abgesehen von Scenario Tests – durchgeführt werden dürfen. Es geht lediglich darum, dass dies kein Muss sein soll. Es ist dem Entwickler freigestellt.

Wichtig ist nur, dass auf die echten Kundenbedürfnisse fokussiert wird, wenn die Applikation auf Korrektheit überprüft wird.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.