15. März 2021

Shift-Left-Testing anwenden und verstehen: Ausgangssituation & Motivation

"The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten." — Anonymous

In der Softwareentwicklung gibt es zwei entschiedene Komponenten, die miteinander konkurrieren: Geschwindigkeit und Qualität. Wer bei der Entwicklung auf Geschwindigkeit setzt, riskiert Einbußen in der Qualität und wer auf Qualität setzt, braucht zu lange. Es gibt verschiedene Ansätze, um die Entwicklung qualitativ hochwertiger Software sicherzustellen – bspw. das Shit-Left-Testing. In diesem ersten Beitrag der Shift-Left-Testing-Reihe möchte ich Ihnen aber zunächst das traditionelle Vorgehen vorstellen.

Qualitätssicherung in traditionellen Entwicklungsvorgehen

Bei der Mehrheit der Projekte im SAP Entwicklungsumfeld werden Anpassungen und Neuentwicklungen erst sehr spät getestet. Es scheint zunächst natürlich einfacher, sich erstmal nur auf die Entwicklung zu konzentrieren und das Testen auf eine „kurze“ Phase vor dem Go Live zu verschieben. Durch dieses Vorgehen finden die Entwickler Fehler aber häufig erst sehr spät – der Go Live verzögert sich.

Fehler finden: Je früher, desto besser

Das Testen auf einen späten Entwicklungsschritt zu schieben, birgt nicht nur zeitliche Herausforderungen. Je später Entwickler einen Fehler in der Software finden, desto teurer wird das Projekt. Die Kosten, die ein Software-Fehler verursacht, steigen im Verlauf der Entwicklungsphasen sogar exponentiell an.

Diagramm - Kosten bei Fehlern nach Entwicklungsschritten

Diagramm – Kostenverlauf bei Fehlern in den Softwareentwicklungs -Phasen

Dieser Anstieg ist vor allem auf die Auswirkungen und Umfang der nötigen Nacharbeiten zurückzuführen. Erst spät entdeckte Programmfehler resultieren somit in einem erhöhten Arbeitsaufwand für die Behebung. Wenn sich beispielsweise ein gravierender Designfehler in der Konstruktionsphase des Projektes eingeschlichen hat und erst in der Testphase entdeckt wird, sind die Kosten für die Behebung sehr hoch: Der Fehler ist in dem Fall schon die Phasen Design, Entwicklung und Testen durchlaufen. Wird der Fehler hingegen in der Phase entdeckt, in der er entstanden ist und sofort behoben, können Überarbeitungen minimiert und der Entwicklungsplan besser eingehalten werden.

Traditionelles Qualitätsmodell

Diagramm – Traditionelles Qualitätsbewusstsein

Beim traditionellen Qualitätsmodell hingegen wird der Fokus erst sehr spät auf die Softwarequalität gelegt. Folgende Punkte sind hierfür typische Charakteristika:

Software-Tester sind nicht in frühen Planungs- und Designphasen von neuen Projekten involviert.
Viele Architekturanforderungen und Designfehler werden erst spät erfasst und korrigiert, wodurch Implementierungen verloren gehen/unbrauchbar werden.
Gegen Ende des Projekts steht nur noch eingeschränkt Zeit für die Fehlerbehebung zur Verfügung.
Testzeiten werden sukzessive verringert, wodurch diese schnell zum Flaschenhals für neue Funktionen werden.

Zur Minimierung von erhöhten Kosten in späten Projektphasen gibt es verschiedene Vorgehen und Strategien für mögliche Lösungsansätze. Grundsätzliche können sich dazu folgende Fragen stellen:

Lassen sich Defekte frühzeitig erkennen oder sogar verhindern?
Können Qualitätssicherungs- und Testaktivitäten in frühere Phasen der Softwareentwicklung eingebunden werden?
Wie lassen sich die Entwicklungs- und Testkosten senken?
Wie sieht ein effizientes Entwickler-Team aus?

Die Lösung: Der Shift-Left-Testing-Ansatz

Wer also bei Entwicklungsprojekten auf Geschwindigkeit setzt, riskiert die Qualität der Software, wer auf Qualität setzt, zieht das Projekt womöglich zu sehr in die Länge. In den kommenden Wochen möchte ich Ihnen mit einer Blogbeitragsreihe eine Lösung für dieses Problem vorstellen: den Shift-Left-Testing-Ansatz. Von der Ausgangssituation in der traditionellen Softwareentwicklung über die grundlegenden Prinzipien bis zum Einsatz in der Praxis erfahren Sie alles, was Sie zum Thema wissen müssen. Im Hinterkopf habe ich dabei immer das Ziel, stets stabile Softwareprojekte zu entwickeln und flexibel auf Probleme oder Anforderungsänderungen reagieren zu können.

Sie beschäftigen sich gerade mit dem Thema Shift-Left-Testing? Warum tauschen wir uns nicht persönlich darüber aus? Zögern Sie nicht, mich jederzeit zu kontaktieren. Ich freue mich drauf!