Unit-Tests mit ABAP® Unit

35

4 Motivation für das Testen

»Wir bauen Software wie Kathedralen:

Zuerst bauen wir – dann beten wir.«

Gerhard Chroust

Von einem Praxisbuch erwartet der Leser, dass auf jeden Fall genug praxisrele-

vantes Material enthalten ist. Diese Erwartung finden Sie hier bestätigt. Doch

was ist das Ziel und welches theoretische Fundament ist notwendig, um ausrei-

chend informiert zu sein, damit Sie sich als Leser sofort zurechtfinden können?

Übersicht über das Kapitel:

■ Die Selbstverständlichkeit des Softwaretestens

■ Der Zusammenhang zwischen Testen und Qualität

■ Der Vorteil der Risikominimierung

4 Motivation für das Testen

36

4.1 Tests geben Sicherheit

Möchten Sie in einem Auto sitzen, das nicht fahrtauglich ist? Halten Sie es für

wichtig, dass die Sicherheitsprüfungen bei Ihrer Kreditkarte gemacht werden?

Für welche Bank würden Sie sich entscheiden? Für die Bank, die mit ihrer lang-

jährigen Zuverlässigkeit in puncto Sicherheit wirbt, oder für die Bank, die als

»First Mover« in sehr innovativen IT-Technologien bekannt ist?

Die Entscheidung scheint für Sie persönlich klar zu sein. Aber wieso wird

dem Testen häufig in Projekten kaum Gelegenheit gegeben, zur Ausführung zu

kommen? Die Antwort liegt klar auf der Hand:

■ Software enthält keine Fehler.

■ Programmierer sind unfehlbar.

Oder sieht die Antwort eher so aus?

■ Das Projekt wurde falsch geplant, für die Testaktivitäten stehen keine Res-

sourcen und kein Budget zur Verfügung.

■ Dem Kunden wird eine Beta-Version

1

ausgeliefert, er wird dies schon akzep-

tieren und weiteres Budget zur Verfügung stellen, um dann in der Folgephase,

als Beta-Tester, mögliche Fehler zu entdecken und entfernen zu lassen.

Diese dürfte schon eher der Praxis entsprechen. Solange die Kunden mitspielen

und die Projekte trotz falscher Planung als Erfolg gefeiert werden, ist die Welt

noch in Ordnung…Doch diese Einstellung könnte von kurzer Dauer sein. Sollte

der Kunde diese Methode entlarven, dann könnte dies einen großen Imageverlust

bedeuten – abgesehen vom Ärgernis beim Kunden und der zukünftigen Zusam-

menarbeit mit Ihnen als Softwarelieferant.

Test sind wichtige Maßnahmen zur Qualitätssicherung in allen Prozesspha-

sen der Softwareentwicklung. Doch was wird unter Qualität bzw. in unserem Fall

unter Softwarequalität verstanden? Schauen wir uns an, was die DIN

2

55350 als

Qualität definiert:

Ist Testen die Feststellung von Qualität, oder bedeutet es Fehler zu finden?

»Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden.«

Glenford, J. Myers

1. Eine Beta-Version ist eine unfertige Version eines Computerprogramms. Häufig sind Beta-Versi-

onen die ersten Versionen eines Programms, die vom Hersteller zu Testzwecken veröffentlicht

werden.

2. Deutsches Institut für Normung e.V., Berlin: nationale Normungsstelle der Bundesrepublik

Deutschland

37

4.1 Tests geben Sicherheit

Die internationale Norm DIN ISO

3

9126 definiert folgende Qualitätsmerkmale:

■ Funktionalität

■ Zuverlässigkeit

■ Benutzbarkeit

■ Effizienz

■ Änderbarkeit

■ Übertragbarkeit

Zu den Qualitätsmerkmalen ist es wichtig zu verstehen, dass es nicht immer mög-

lich ist, diese gleichzeitig umzusetzen. Beispielsweise können die Punkte Zuver-

lässigkeit und Effizienz entgegenwirken. Ein sehr robustes, durch viele Sicher-

heitsprüfungen entwickeltes Softwaresystem wird ein höheres Zeitverhalten

(Performance) benötigen. Aus diesem Grund ist eine Priorisierung der Qualitäts-

merkmale bei den Qualitätsanforderungen des Projektes festzulegen.

Testen ermöglich es, die Qualität von Software zu messen, ausgedrückt durch die

Anzahl der gefundenen Fehler. Wenn wenige oder keine Fehler gefunden werden,

kann Testen Vertrauen in das Softwaresystem schaffen. Durch gefundene Fehler

und das Beheben dieser Fehler steigt die Qualität. Und höhere Qualität führt zu

einer höheren Zuverlässigkeit des Softwaresystems.

Qualität

»Die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer

Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht.

Die Erfordernisse ergeben sich aus dem Verwendungszweck des Produktes oder

dem Ziel der Tätigkeit, unter Berücksichtigung der Realisierungsmöglichkeiten.«

DIN 55350, Teil 11

Qualitätsmerkmale

3. Internationale Organisation für Normung. Mitglieder sind staatliche und nicht-staatliche Nor-

menorganisationen.

Testen ist ein Maßsystem für die Softwarequalität. [Spillner 03]

4 Motivation für das Testen

38

4.2 Fehlerfindung und Kosten

Die Frage, die hier gestellt werden sollte, ist, wann an der Fehlerfindung gearbei-

tet werden sollte. Je früher Sie einen Fehler entdecken und diesen beseitigen,

desto weniger kostet der Fehler! Zu dieser Thematik gibt es diverse Untersuchun-

gen und Studien, die sehr aufschlussreich sind. Hier exemplarisch die Studie der

Software Quality Systems Group aus Köln:

Abb. 4–1

Fehlerkosten in IT-Projekten (Quelle: SQS)

Die Praxis sieht so aus, dass die Fehler in den späten Entwicklungsprozessphasen

am teuersten sind. Die Motivation sollte es also sein, die Fehler so früh wie mög-

lich zu finden, denn wer zu spät testet, verschleudert Geld. Doch Unwissenheit,

Budget- und Zeitdruck führen dazu, dass die Phase der qualitätssichernden Maß-

nahmen wie Testen häufig als nicht wichtig empfunden werden. Es wird nicht

intensiv genug getestet, und das Finden der Fehler wird dem Kunden überlassen.

Was kosten Softwarefehler

4

?

■ Geschätzte Verluste durch Softwarefehler in Mittelstands- und Großunter-

nehmen in Deutschland: ca. 84,4 Mrd. EUR pro Jahr

.

Softwaresysteme werden von Menschen entwickelt. Menschen machen Feh-

ler, sodass jedes Softwaresystem Fehler enthält.

4. Untersuchung der LOT Consulting GmbH, Karlsruhe.

Siehe Nachricht des Onlineprotals der Zeitschrift Computerwoche vom 15.02.2001:

http://www.computerwoche.de/nachrichten/519152/

* 1 = 1000 €

Source: SQS – Empirische Daten aus 3000 IT-Projekten

90

48

12

4

1

Betrieb

Abnahme

Einführung

Realisierung

Fein-Konzept

DV-Konzept

Istanalyse

Grob-Konzept

• Kosten* • Inhalt

Umsatzverlust,

Imageschaden

Für zusätzliche

Abnahmekosten,

wiederholtes Rollout

Für zusätliche

Entwicklungskosten

Für Überarbeitung

Geschäftsprozess,

Review, Diskussion

Für Überarbeitung

Geschäftsprozess,

Review, Diskussion