Qualitätssicherung

Die Problematik bei der Qualitätsmessung von Legacy Code

Seite: 2/3

Anbieter zum Thema

Gründe für den Test von scheinbar bewährten Codes

1. Zunehmend kommt von Abnehmern zugelieferter Software, ob innerhalb eines Konzerns oder zwischen unabhängigen Zulieferern, die Anforderung von Qualitätsnachweisen sowohl des gelieferten Produkts als auch der Prozesse (Zertifizierung) und der beteiligten Mitarbeiter.

2. Bewährung von Programmlogiken im Feld gibt keinesfalls die Sicherheit, bei Übertragung in neue Umgebungen oder auf neue Plattformen Fehlfunktionalitäten ausschließen zu können. Im Gegenteil sind gerade solche Umzüge aus verschiedenen Gründen gerne fehleranfällig: Zum einen wird der alte Code neuen Parametrisierungen ausgesetzt, die unter Umständen bislang nie auftraten und dadurch Fehler aufdecken können.

Zum anderen ist der überlieferte Code in den Fällen, um die es hier geht, eben nicht durch Kommentare oder Spezifikationen erklärt, so dass bei der Anpassung an neue Schnittstellen leicht Fehler gemacht werden können.

3. Einen Testprozess einzurichten oder zu verbessern, ein verbessertes Wissen und Mindset zu schaffen kann mehrere Monate bis zu anderthalb Jahren oder länger dauern. Es ist daher von Vorteil, rechtzeitig für die Fälle 1. und 2. vorbereitet zu sein.

4. Tests in Form von Code-Reviews haben unter anderem den Vorteil, dass die Wissensbasis in der Entwicklermannschaft wesentlich verbreitert wird. Zusätzlich können sie, adäquat umgesetzt, als eine Art Schulung und Transfer von Know-how dienen.

5. Eine nachprüfbare Qualitätsaussage über ein Produkt ist ausschließlich über einen systematischen Testprozess zu erhalten.

Der Kunde, ob Endverbraucher oder weiterverarbeitender Zwischenabnehmer, braucht im komplexen Marktgeschehen ein zuverlässiges Merkmal, an dem er sich orientieren kann. Aus diversen, einsichtigen Gründen ist es dem Kunden vielfach nicht möglich, Prüfungen des Produkts selbst vorzunehmen. Gleichzeitig steigen die Ansprüche, weswegen die Notwendigkeit von Qualitätsaussagen in der Zukunft mit Sicherheit weiter zunehmen wird.

Ursachen für das Wuchern logischen Gestrüpps

Welche Umstände führen dazu, dass statt wohlstrukturiertem und testbarem Code ein schwer handhabbares logisches Gestrüpp entsteht? Es wurde bereits zusammengefasst: Die Vorgaben für das Was und das Wie der Entwicklungstätigkeit werden nicht beachtet. Unter „Was“ können alle Zielvorgaben für das zu bauende Softwareprodukt subsummiert werden: welche Funktionalitäten werden erwartet, welche Schnittstellen gibt es, welche Eingabebereiche sind als gültig zu definieren, wie ist mit ungültigen Eingaben umzugehen - nur um einige Beispiele zu nennen.

Das „Wie“ definiert die Vorgaben, deren Einhaltung die Erreichung dieser Vorgaben mit einem hohem Maß an Qualität erreichen lassen sollte: Codier-Richtlinien, Fristen und Checklisten für Codereviews, ein klar definierter Prozess für dynamische Softwaretests und dergleichen.

Eine Einhaltung dieser Vorgaben setzt voraus, dass sie existieren und dass ihre Einhaltung eingesehen und gelebt wird. Aber selbst wenn diese Voraussetzungen gegeben sind, kann mangelnde Kommunikation zwischen den Akteuren sowie Zeitdruck wegen Markt- oder Kundenanforderungen zu Unterschlagungen führen. Schließlich bedingt eine nicht ausreichende Bemannung, dass beispielsweise die Rolle des Reviewers oder des Testers nicht adäquat ausgefüllt wird.

Hinzu kommt, dass ein systematischer Softwaretest ein Mindestmaß an Wissen zu Testmethodiken voraussetzt. Gleiches gilt im Übrigen für den systematischen Test der gesamten internen Logik eines Produkts. Es besteht nach meiner Erfahrung kaum ein Unterschied zwischen den Entwicklungsmannschaften kleiner mittelständischer Betriebe mit zwei bis zwölf Entwicklern und den zuliefernden Abteilungen innerhalb von Großfirmen: In beiden können ähnliche Entwicklungsdynamiken entstehen, in deren Verlauf Code aus dem Augenblick heraus und auf Zuruf heranwächst, ohne größere Abstimmung mit anderen Mitarbeitern oder übergeordneten Anforderungen.

Bei näherer Untersuchung stellt sich die Arbeitsweise bei solchem Vorgehen wie folgt dar: Geprägt durch einen traditionell antrainierten Arbeits- und Kommunikationsstil, der bei weniger komplexen Logiken in der Vergangenheit noch nicht an seine Grenzen gestoßen war, setzt sich der Entwicklungsprozess unverändert in die zunehmende Komplexität (neue Plattformen, steigende Anzahl von Produkten und Rückwärtskompatibilität) fort.

Anstatt diesen inadäquat gewordenen Entwicklungsprozess zu reformieren, treten typischerweise lokale Verdrängungs- und Überbrückungsmethodiken auf: An Fehlstellen des Codes werden unsystematische, nur einen Spezialfall behebende Patches eingebaut, nur einige Anwendungsfälle werden getestet. Mehrarbeit und Überstunden mit entsprechender geringerer Produktivität und höherer Fehleranfälligkeit oder unsystematische Teil-Redesigns unter hohem Zeitdruck sind die Folge. Diese Vorgehensweise bietet das beste Klima für das Wuchern logischen Gestrüpps.

Artikelfiles und Artikellinks

(ID:43694157)

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung