Gastbeitrag: Testbarkeit in der Softwareentwicklung – Besser früher als nie!

Publish date:

Wenn sich ein Softwaresystem nur schwer testen lässt, wird es meist kompliziert und teuer. Wie frühe Vorsorge Aufwand und Kosten spart

Abdelhamid Barzali,  Sogeti

Vorsorge ist besser als Nachsorge! Dies gilt auch für Softwareentwicklung. Wird die Testbarkeit auf der Ebene der Softwarearchitektur betrachtet, lässt sich das Softwaresystem dann leichter testen. Denn eine testfreundliche Softwarearchitektur verspricht eine Minimierung des Testaufwands während des Softwareentwicklungsprozesses und hält dadurch die Qualitätskosten unter Kontrolle.

Im Gastbeitrag „Testbarkeit im Softwareentwicklungsprozess – Besser früher als nie!“ im ASQF (Arbeitskreis Software-Qualität und -Fortbildung e.V.) wird zum einen der kausale Zusammenhang zwischen mangelnder Testbarkeit und Testaufwand kurz beleuchtet und zum anderen werden ihre Aspekte aus Testsicht betrachtet.

Mangelnde Testbarkeit wird zur technischen Schuld

Dass sich ein Softwaresystem leicht bzw. schwer testen lässt, hängt davon ab, welche Testbarkeitsaspekte bereits bei der Anforderungsanalyse bzw. Softwarearchitektur mitberücksichtigt wurden. Deshalb ist es zwingend notwendig, dass man als Softwarearchitekt adäquat über den Tellerrand blickt und Testbarkeit als unentbehrliches Projektziel sieht.

Fällt die Testbarkeit als Qualitätsmerkmal vor allem während der ersten Projektphasen bewusst oder unbewusst unter den Tisch, fallen dem Entwicklungsteam lästige technische Schulden zur Last, die vielleicht bereits bei der Anforderungsanalyse bzw. im Softwareentwurf zu vermeiden wären. Will man z.B. in einer späteren Projektphase Test-Schnittstellen oder Testadapter in ein Softwaresystem einbauen, die in der Softwarearchitektur bzw. im Datenmodell nicht mitbedacht wurden, muss man mit hohem Refaktorierungsaufwand rechnen. Im Ernstfall wären nachträgliche Implementierungen und Nachbesserungen der Testbarkeit nur schwer möglich oder sogar so sehr kostenintensiv, dass es sich leider wirtschaftlich nicht mehr lohnt, sie noch vertretbar zu verwirklichen! Hier spricht man von einer Softwareerosion (siehe rote aufsteigende Pfeile in der Abbildung 1). In diesem Fall handelt sich um einen zwangsläufigen Softwarezustand, in dem jede Softwareanpassung bzw. Fehlersuche  mit enorm großem Aufwand einhergeht.

Abbildung 1: Der Effekt von technischen Schulden  [Quelle: Langlebige Architekturen: Technische Schulden erkennen und beseitigen, 17. Juli 2017, Dr. Carola Lilienthal.]

Testorientierte Softwarearchitektur beginnt bei der Anforderungsermittlung

Es erscheint sinnvoll, die Testbarkeit möglichst früh in den Softwareentwicklungsprozess einzubringen, da nachträgliche Korrekturen der Softwarearchitektur und des Quellcodes meistens mit großem Aufwand zu verwirklichen sind. In der Praxis steigen Fehlerbehebungskosten nämlich exponentiell über die Projektphasen eines Softwareentwicklungsprozesses. Je später die Fehler im Laufe der Projektphasen aufgespürt werden, desto teurer sind die Korrekturkosten:

 

Abbildung 2: Fehlerbehebungskosten in Abhängigkeit von der Latenzzeit

 

Erfahren Sie im ASQF Gastbeitrag, welche Testbarkeitsanforderungen als Grundvoraussetzung zur Erreichung eines hohen Grads an Testbarkeit gelten.

 

cookies.

Mit dem Fortsetzen des Besuchs dieser Website akzeptieren Sie die Verwendung von Cookies.

Für mehr Informationen und zur Änderungen der Cookie-Einstellungen auf Ihrem Computer, lesen Sie bitte Privacy Policy.

Schließen

Cookie Information schließen