Nicht selbstverständlich: Testbarkeit

Nicht selbstverständlich: Testbarkeit

Während Testen als Maßnahme von den meisten Firmen immer professioneller betrieben wird, steht die Gewährleistung der Testbarkeit – oder präziser: Testdurchführbarkeit – weniger im Fokus der Aufmerksamkeit. Da Testbarkeit keine automatisch entstehende Eigenschaft eines Produktes ist, muss sie bei der Entwicklung mitgeschaffen werden. Hier wird gezeigt, dass Testbarkeit als Qualitätsmerkmal vor allem in den frühen Entwicklungsstadien mitgedacht werden sollte und wie weitreichend ihre Voraussetzungen sind: Selbst der interne IT-Support von Firmen zählt dazu.
Die Notwendigkeit eines systematischen Testvorgehens wird kaum noch von einem Unternehmen bestritten. Nach unserer Beobachtung werden Testprozesse auf breiter Front neu implementiert oder umstrukturiert, immer mit dem Ergebnis verbesserter Produktqualität. Die Implementierung dieser Testprozesse (zunächst unabhängig davon zu verstehen, ob klassisch oder agil) indes gestaltet sich in der Praxis sehr verschieden. Hier sind allerdings nicht die produktspezifisch bedingten Unterschiede gemeint, sondern die durch die jeweiligen Wissensstände verursachten sowie eine auch innerhalb von Firmenabteilungen variierende Bereitschaft, sich auf einen professionellen Testprozess einzulassen. Fakt ist auch, dass sich gewisse Unschärfen bei Begrifflichkeiten, beim Vorgehensentwurf sowie der Umsetzung einschleichen können, sofern nicht ausgewiesene Testspezialisten bei der Implementierung von Testprozessen zumindest eine beratende Funktion übernehmen. Das ist nachvollziehbar, da im Laufe der Jahrzehnte sehr viel Erfahrung und Wissen zum Testen aufgebaut wurde, das ohne eine entsprechende Schulung z.B. durch ISTQB-zertifizierte Fachleute nicht intuitiv zur Verfügung steht. Regelmäßig können wir beobachten, dass sich nach Analyse bestehender Testprozesse oder des Testbedarfes langjährig eingespielte, um nicht zu sagen festzementierte Gewohnheiten in der Entwicklung herausstellen, die dem systematischen Testen ebenso systematisch im Weg stehen – ohne dass dies so gewollt wäre, versteht sich. Es ist nicht so, dass nur durch das Vorhandensein eines Produkts dieses automatisch testbar wäre. Dass es den Begriff ‚Testbarkeit‘ überhaupt gibt, ist vielfach die erste große Erkenntnis, über die der Weg zur wirksamen Verbesserung des Testprozesses führt.

Schärfung des Begriffs ‚Testbarkeit‘

Um ‚Testbarkeit‘ vollumfänglich verstehen zu können, betrachten wir zunächst den Begriff ‚Test‘ genau. Ein Test besteht ganz allgemein aus folgenden Schritten:

  • • 1. Das Testobjekt wird in einen definierten logischen Zustand gebracht (Herstellung der Vorbedingung).
  • • 2. Ausführen einer Aktion an dem Testobjekt (eigentliche Testhandlung)
  • • 3. Erfassung des nachtestlichen logischen Zustands (Testergebnis)
  • • 4. Bewertung des Testergebnisses durch Soll-Ist-Vergleich (Testauswertung)

Ein Test ohne Vorbedingung ist nicht denkbar. Selbst der einfachste Test, z.B. der bloße Startversuch einer ausführbaren Datei, setzt ihr Vorhandensein voraus. Ebensowenig kommt ein Test ohne Vergleich des Ergebnisses mit einem vorher festgelegten Sollwert aus. Testbarkeit beschreibt den Zustand des Testobjekts sowie der Umstände, welche die Durchführbarkeit dieser vier Elementarschritte bedingen. Testbarkeit ist dann gegeben, wenn alle Elementarschritte ausführbar sind. Es ist klar, dass Tests in der Praxis je nach Testobjekt, Testziel usw. über eine kaum überschaubare Vielzahl von Methodiken realisiert werden. Ebenso vielfältig sind demnach die Bedingungen, welche die Testbarkeit negativ oder positiv beeinflussen: Es ist sowohl die Beschaffenheit des Testobjekts selbst – das erscheint in Beratungen oft als triviale Aussage -, aber auch eben die des gesamten Entwicklungsgeschehens. Dies wird im Folgenden an einigen Beispielen skizziert. Unter ‚Testobjekt‘ soll entweder lauffähige Software z.B. auf einem PC ohne funktionalen Hardwarebezug gemeint sein oder embedded Software auf der Zielhardware. Es können Units (die kleinste, sinnvoll testbare Softwareeinheit wie eine Klasse oder eine Funktion) ebenso sein wie integrierte Teil- oder Gesamtsysteme.

Testbarkeit als Eigenschaft des Testobjektes

Betrachten wir dazu zuerst die grundlegenden Eigenschaften eines Testobjektes, die für eine Testbarkeit gegeben sein müssen:

  • • 1. Kontrollierbarkeit: Das Testobjekt kann in den Zustand gebracht werden, der als Vorbedingung für den Test unabdingbar ist.
  • • 2. Beobachtbarkeit: Der nachtestliche Zustand kann beobachtet und ausgelesen werden.

Diese Grundbedingungen für Testbarkeit können z.B. in den Fällen problematisch werden, in denen Teile lizenzpflichtiger oder aus sonstigen Gründen nicht zugänglicher Codes Bestandteil des Testobjekts sind. Die Beobachtbarkeit interner Zustände wird durch fortschreitende Integration von Softwarekomponenten zu einem System regelmäßig durch (sinnvolle) Abschirmungs-, Abfang- und Sicherheitsmechanismen verhindert. Gerade bei den immer zu empfehlenden Schlechtfällen, bei denen die korrekte Reaktion des Systems auf Fehlerzustände abgeprüft wird, können äußere abschirmende logische Schichten zum Problem werden. Testbarkeit kann also im Widerspruch zu geforderten Sicherheitsarchitekturen stehen. Dies ist überdies eines der wichtigsten Argumente für wenigstens eine tieferliegende Testebene (z.B. Komponententest), bevor Integrations- und Systemtests in Angriff genommen werden. In der Regel sind noch folgende Eigenschaften notwendig:

  • • 3. Isolierbarkeit: Wenn das Testobjekt ein Baustein einer größeren Einheit ist, z.B. eine Klasse, ein funktionelles Softwaremodul o.ä., muss es isoliert getestet werden können. Gibt es logische Abhängigkeiten wie andere Softwarekomponenten, Interfaces, Headerfiles müssen diese Komponenten entweder substituiert oder bereitgestellt werden. Bereitstellung genügt bei statischen Komponenten, die dem Testobjekt keine Berechnungen oder andere Ergebnisse liefern. Falls die Umgebungskomponenten dynamisch sind, also je nach Eingabe ihrerseits verschiedene logische Zustände annehmen, müssen sie entweder zuvor ausreichend getestet sein oder durch eine Leerkomponente (Dummy, Stub, Mock) ersetzt werden, die dem Testobjekt lediglich die zum Test notwendigen Daten liefert. Dies setzt voraus:
  • • 4. Wohldefinierte Verantwortlichkeit: Das Testobjekt ist hinsichtlich seiner Funktion scharf umgrenzt. Weder wird eine Funktionalität unnötig auf mehrere Komponenten verteilt, noch vereinigt eine Komponente logisch nicht zusammengehörige Funktionalitäten auf sich.
  • • 5. Möglichst geringe modulare Kopplung: Nicht bei jeder aus Modulen bestehenden Software sind Einzelkomponenten gleich gut für Testzwecke isolierbar. Je höher die Anzahl der zu substituierenden Schnittstellen desto aufwendiger der Zugriff auf das Testobjekt.
  • • 6. Verständlichkeit: Der Code ist hinreichend gut dokumentiert, sodass Isolierung einer Komponente und Schnittstellensubstitution keinen unnötigen Untersuchungsaufwand erfordern.
Mixed Mode GmbH
www.mixed-mode.de

Das könnte Sie auch Interessieren