Blog

Gastbeitrag: Testbarkeit im Softwareentwicklungsprozess – Besser früher als nie!

Abstract

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.

In diesem Beitrag 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

Der Begriff Testbarkeit ist nach ISTQB-Standard der Grad der Effektivität und Effizienz, zu dem Tests für eine Komponente oder ein System entworfen und durchgeführt werden können [1]. Bei genauer Betrachtung dieser Definition, drängt sich einem die Frage auf: Welche Gesichtspunkte stecken hinter dem “Grad der Effektivität und Effizienz..” ? Mit anderen Worten bezeichnet die Testbastbarkeit die Gesamtheit der Maßnahmen und Merkmale sowie Funktionalitäten, die einen Testprozess kostengünstiger bzw. kostenintensiver machen.

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. Hierzu gehört die Sicherstellung, dass Testbarkeit durch enge und regelmäßige Zusammenarbeit mit allen Teammitgliedern im Softwareentwicklungsprozess ganzheitlich verwirklicht und entwicklungsbegleitend überwacht wird. 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 [2]). In diesem Fall handelt sich um einen zwangsläufigen Softwarezustand, in dem jede Softwareanpassung bzw. Fehlersuche  mit enorm großem Aufwand einhergeht. Dies lässt sich erfahrungsgemäß hauptsächlich darauf zurückführen, dass nicht optimale Entscheidungen zu Beginn und während der Softwareentwicklung getroffen werden, die zu technischen Schulden führen. Dazu werden in der Praxis üblicherweise folgende technische Schulden aufgenommen: komplexe Softwarearchitektur, mangelhafter Testprozess, untestbare Anforderungen,  schlechter Programmcode (Spaghetticode), mangelnde Unittests und Verwenden von Anti-Patterns sowie fehlende Dokumentation etc. Werden diese regelmäßig nicht abgebaut, häuft das Entwicklungsteam sie immer mehr an. Dies ist unweigerlich die Folge davon, dass die Softwarearchitektur sich im Laufe des Softwareentwicklungsprozesses wegen zunehmender Komplexität vom Korridor[1] (Siehe Abbildung 1  [2]) immer so weit entfernt, bis sie irgendwann erodiert.

 

Der Effekt von technischen Schulden  © Dr. Carola Lilienthal [2]

 

Testorientierte Softwarearchitektur beginnt bei der Anforderungsermittlung

 

Der Begriff “Softwarearchitektur” ist nach Helmut Balzert [3] eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen. Ziel dabei ist es, aus den Softwareanforderungen eine softwaretechnische Lösung in Form eines “Bauplans” zu schaffen, wie ein Softwaresystem entwickelt werden soll. Liegen der Softwarearchitektur testbare Softwareanforderungen zugrunde, lässt sich dann ein leicht wartbares und tesbares Softwaresystem entwickeln. Des weiteren erscheint es 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. Dies veranschaulicht folgende Abbildung (Abbildung 2 [7] ).

Abbildung 2: Fehlerbehebungskosten in Abhängigkeit von der Latenzzeit

Demzufolge lässt sich gute Softwarearchitektur dadurch entwerfen, wenn Aspekte möglichst aller Stakeholder gemeinsam sowie gewisse Qualitätsmerkmale berücksichtigt werden. Neben den Anforderungen an die Software, nämlich die Kundenwünsche, gelten diejenigen Anforderungen aus Sicht des Softwaretesters und zwar die sogenannten Testbarkeitsanforderungen als Grundvoraussetzung zur Erreichung hohes Grads an Testbarkeit. Es lassen sich folgende Testbarkeitsanforderungen festlegen:

  • Verständlichkeit: (understandability) Testobjekte sollen ausreichend dokumentiert und nachvollziehbar sein. Dazu zählt auch eine ausreichend dokumentierte Testbasis[2].
  • Einfachheit: (simplicity) Einfachheit bei den Problemlösungen sollte ein erstrebenswertes Ziel sein.“The less things we need to test for, the better.” [4]. Das KISS-Prinzip[3] [5] ist hier zu empfehlen.
  • Beobachtbarkeit: (observability) Das Softwaresystem soll nötige Informationen über seine Zustände bereitstellen. Es lassen sich Informationen über Testergebnisse z.B. per Logging-Ausgaben jederzeit liefern.
  • Kontrollierbarkeit: (controllability) Das Softwaresystem soll sich leicht in einen gewünschten Zustand bringen.
  • Automatisierbarkeit: (automatability) Tests und deren Auswertung sollen sich automatisieren lassen.
  • Trennung der Zuständigkeiten: (Separation of concerns [8]) Testobjekten sollen klare Aufgaben zugeordnet werden.
  • Verfolgbarkeit: Der Grad, zu dem eine Beziehung zwischen zwei oder mehr Arbeitsergebnissen hergestellt werden kann. [1]
  • Robustheit: Im Fehlerfall soll die Ausführung nachfolgender und parallel laufender Tests nicht abgebrochen werden.
  • Anonymisierbarkeit: Personenbezogene Daten sollen sollen sich zu Testzwecken leicht anonymisieren lassen.
  • Stabilität: (stability) Nach ISTQB-Standard ist Stabilität der Grad, zu dem eine Komponente oder System effektiv und effizient geändert werden kann, ohne dabei Fehlerzustände einzubauen oder die Qualität zu mindern.[ISO 25010] [1]
  • Operabilität (operability) Gut und durchdacht entwickelte Softwaresysteme neigen dazu, wenige Fehler zu enthalten. Je besser ein Softwaresystem funktioniert, desto effizienter kann es getestet [4]
  • Modulare Zerlegbarkeit: (Decomposability [4]) Testobjekte können isoliert getestet werden, wenn das Softwaresystem möglichst modular aufgebaut ist. Demzufolge lassen sich präzise Informationen und Testergebnisse liefern, wenn Softwaremodule abgetrennt voneinander getestet werden können. Des Weiteren lassen sich Fehlerzustände leichter lokalisieren.

Ferner ist es wichtig zu erwähnen, dass aufgedeckte Unklarheiten in der Testbasis wie  z.B. untestbare Anforderungen unverzüglich bei den betroffenen Projektmitgliedern zu melden sind. Die Überarbeitung der Testbasis und die Durchführung von regelmäßigen Softwarearchitekturreviews tragen dazu bei, die Softwarearchitektur zu verbessern und  sie tragfähig zu halten. Darüber hinaus gilt eine testgetriebene Softwareentwicklung als enorm wichtig, um den Grad an Testbarkeit zu erhöhen.

Die Aspekte von Design-für-Testbarkeit [6] sollten systematisch und  so früh wie möglich im Softwareentwicklungsprozess  umgesetzt werden, damit etwaige Qualitätsprobleme frühzeitig aufgespürt und beseitigt werden.

Fazit

Fakt ist, dass leicht beobachtbare und steuerbare Softwaresysteme sich qualitativ einfacher bewerten lassen. Das Thema Testbarkeit umfasst vielseitige Aspekte im Softwareentwicklungsprozess. Werden diese bei der Softwarearchitektur berücksichtigt, lässt sich der Testaufwand unter Kontrolle halten. Deshalb ist es wichtig, bereits in den früheren Projektphasen Vorsorge zu leisten !

Literatur & Links

 

[1] ISTQB® GTB Standardglossar der Testbegriffe Version vom 29.04.2019.

[2] Langlebige Architekturen: Technische Schulden erkennen und beseitigen , 17. Juli 2017, Dr. Carola Lilienthal.

[3] Helmut Balzert: Lehrbuch der Softwaretechnik. Bd. 2: Entwurf, Implementierung, Installation und Betrieb, Spektrum Akademischer Verlag, 2011, S. 580.

[4] Object Oriented Analysis & Design von Atul Kahate, Tata McGraw-Hill Education, 1 Oct 2004

[5] The KISS Principle: Approaches to Building Reliable Systems, Ronald B. Smith, 1983

[6] Design-for-Testability for Object-Oriented Software1 Jeffery E. Payne, Roger T. Alexander, Charles D. Hutchinson, 1997 SIGS PUBLICATIONS, INC.

[7] Software-Prüfung: eine Anleitung zum Test und zur Inspektion: von Karol Frühauf, Jochen Ludewig und Helmut Sandmayr, 2007, S. 20.

[8] What Every Engineer Should Know about Software Engineering, Philip A.Laplante, 25.04.2007, S.85

 

Fußnoten

[1] Korridor ist der Bereich gleichbleibendes Aufwands für Wartung und Erweiterung der Softwarearchitektur

[2] Testbasis nach ISTQB ist alle informationen, die als Basis für die Testanalyse und den Testentwurf verwendet werden können.[1]

[3] KISS ist ein englisches Akronym und steht für “keep it simple, stupid”. Es bedeutet soviel wie “mach es einfach einfach!”. Mehr dazu in [5].

 

Über den Autor

Abdelhamid Barzali (abdelhamid.barzali@sogeti.com) arbeitet als Software-Testexperte bei der Sogeti Deutschland GmbH. Er beschäftigt sich seit mehreren Jahren mit dem Software-Engineering und -Test im agilen Umfeld.

1 Comment

  1. Katrin

    Sehr interessanter Artikel!

Leave a Comment

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