Blog des deutschen Software-Ingenieurbüro und Unternehmensberatung 4WT Co., Ltd. in Bangkok
Deutsche Ingenieure mit über 35 Jahre praktische Erfahrung remote aus Bangkok. URL: https://it-e-com.de
WhatsApp-Kanal |
RSS-Feed
Die unterschätzte Notwendigkeit: Qualitätssicherung als Erfolgsfaktor in IT-Projekten – Ein Erfahrungsbericht aus 35 Jahren
In meiner über 35-jährigen Tätigkeit als Ingenieur und Berater in der IT-Branche habe ich eine beeindruckende Bandbreite an Projekten begleitet – von kleinen Softwarelösungen bis
zu komplexen, unternehmensweiten Systemen. Über all die Jahre und die Vielfalt der Aufgaben hinweg hat sich jedoch ein Muster immer wieder bestätigt: die oft sträfliche
Vernachlässigung von #Qualitätssicherung (QS) und #Qualitätsmanagement (QM). Es scheint eine Konstante zu sein, dass gerade in diesen entscheidenden Bereichen gespart wird,
oft mit weitreichenden negativen Folgen.
Ein Kernproblem, das ich immer wieder beobachte, ist der Kostendruck. Dieser führt dazu, dass, wenn überhaupt systematisch getestet wird, dies oft auf sehr oberflächlichem Niveau
geschieht. Man beschränkt sich häufig auf simple #JUnit-Tests. Diese stellen zwar sicher, dass einzelne Methoden technisch aufgerufen werden können oder Variablen innerhalb einer
Klasse gesetzt sind, sie bilden aber bei Weitem nicht die Komplexität der realen Anwendung ab. Tests, die das kritische Zusammenspiel mehrerer Klassen oder Objekte überprüfen – sogenannte
Integrationstests – sind schon deutlich seltener. Und Tests, die ganze #Geschäftsprozesse oder Workflows von Anfang bis Ende abdecken und somit die Funktionalität aus Anwendersicht
sicherstellen, werden leider nur in den seltensten Fällen konzipiert und umgesetzt.
Eine weitere, tiefgreifende Schwachstelle liegt darin, wer die Tests schreibt. In meiner Schätzung nach sind es in 99% der Fälle die Entwickler selbst, die für das Testen ihres eigenen
Codes verantwortlich sind. Dies birgt einen inhärenten Nachteil: Entwickler kennen ihren Code, ihre Lösungsansätze und oft auch – unbewusst – dessen Schwachstellen. Die Tendenz, genau
um diese Problemzonen herum zu testen, ist menschlich, aber für die Qualität fatal. Diese Form der 'Betriebsblindheit' – das Phänomen, durch zu große Nähe zum Produkt und zu den
internen Prozessen den Blick für offensichtliche Fehler oder grundlegende Designschwächen zu verlieren – führt dazu, dass etablierte Annahmen seltener hinterfragt und Fehler,
die aus dem gewohnten Denkmuster heraus entstehen, leicht übersehen werden. Man testet, was man erwartet, nicht unbedingt das, was unerwartet passieren kann.
Wenn externe oder dedizierte #Tester hinzugezogen werden, greift man aus Kostengründen häufig auf sehr junge Ressourcen zurück, unter anderem Studenten in unteren Semestern.
Diese sind zwar günstig, ihnen fehlt jedoch in der Regel die tiefgreifende Erfahrung und das Verständnis für komplexe Systemarchitekturen, potenzielle Fallstricke im Betrieb
oder die Wechselwirkungen verschiedener Systemkomponenten. Echte Testingenieure – also erfahrene Softwareingenieure, die selbst über Jahre entwickelt, Software ausgerollt und
betrieben haben – werden leider viel zu selten eingesetzt. Der Nachteil dieser Praxis ist offensichtlich: Es fehlt die strategische Tiefe bei der Testplanung, die Fähigkeit,
komplexe Fehlerszenarien zu antizipieren und die Erfahrung, um effiziente und aussagekräftige Testfälle zu entwerfen, die über das Offensichtliche hinausgehen.
Hinzu kommt ein weiteres, oft unterschätztes Problem bei internen Testern, seien es nun die Entwickler selbst oder dedizierte, aber fest angestellte QS-Mitarbeiter: die Befangenheit.
Als Lohnempfänger des eigenen Unternehmens können sie, bewusst oder unbewusst, in einen Loyalitätskonflikt geraten. Sie könnten sich scheuen, das volle Ausmaß negativer Testergebnisse
schonungslos offenzulegen oder kritische Fehler mit der notwendigen Dringlichkeit zu eskalieren. Die Sorge vor negativen Konsequenzen für das Team, das Projekt, die Beziehung
zu den Entwicklerkollegen oder gar die eigene Position kann dazu führen, dass Probleme heruntergespielt oder Berichte geschönt werden. Es erfordert ein hohes Maß an professioneller
Integrität und oft auch eine außergewöhnlich starke, unabhängige Stellung im Unternehmen sowie Rückendeckung durch das Top-Management, um wirklich kritische Fehler aufzudecken und
klar zu kommunizieren, insbesondere wenn Deadlines drücken oder die Stimmung im Projekt bereits angespannt ist. Diese inhärente Befangenheit und die subtile Angst vor internen
Konsequenzen untergraben die Objektivität, die für eine effektive Qualitätssicherung jedoch absolut unerlässlich ist.
Entsprechend selten trifft man auch auf professionell aufgesetzte, automatisierte Testsuiten, die ganze Workflows abdecken, eine hohe Testabdeckung von beispielsweise über 90 %
erreichen und deren Ergebnisse transparent und nachvollziehbar in Reporting-Tools wie Jira mit XRay einfließen. Solche Systeme sind mächtige Werkzeuge zur kontinuierlichen
Qualitätssicherung, werden aber oft als zu teuer oder zu aufwendig abgetan.
Dabei habe ich immer wieder die Erfahrung gemacht, dass die vermeintlich eingesparten Kosten für ein solides Qualitätsmanagement sich später um ein Vielfaches rächen.
Ja, ein gut durchdachtes QM, das die Entwicklung von Anfang an begleitet, verursacht initiale Kosten. Aber die Gesamtkosten eines Projekts sind mit einer solchen QS deutlich geringer.
Die Kosten für spätere Fehlersuche durch hochbezahlte #Entwickler, die sich mühsam in alten Code einarbeiten müssen, die Kosten durch Ausfallzeiten produktiver Systeme,
der unschätzbare Imageverlust bei Kunden und Partnern sowie direkte Umsatzverluste durch fehlerhafte Software übersteigen die Investitionen in Qualität bei Weitem.
Meine Empfehlung lautet daher klar: Ab einer gewissen Projektgröße und -komplexität sollte die Qualitätssicherung als eigenständiges Projekt oder zumindest als eigener
Verantwortungsbereich mit dedizierten Ressourcen behandelt werden. Ein strukturierter Ansatz mit klaren Testphasen, Metriken und vor allem einem aussagekräftigen Reporting ist
unerlässlich. Ein solches Reporting deckt frühzeitig Schwachstellen, Risiken und Engpässe auf und ermöglicht dem Projektmanagement, rechtzeitig gegenzusteuern,
bevor Probleme eskalieren.
Hierbei stellt sich oft die Frage nach den richtigen Ressourcen. Warum ist es in der Regel kostengünstiger, auf erfahrene externe Softwareingenieure als Testingenieure zu setzen,
anstatt Studenten oder die eigenen Entwickler testen zu lassen? Erfahrene externe Tester bringen nicht nur technisches Know-how und Testmethodik mit, sondern vor allem eine unabhängige,
kritische Perspektive. Sie sind nicht 'betriebsblind', da sie von außen auf das Projekt blicken und nicht durch interne Prozesse, eingefahrene Denkmuster, historische Entscheidungen
oder persönliche Loyalitäten vorgeprägt sind.
Sie hinterfragen Annahmen und decken durch ihre Erfahrung auch nicht-funktionale Aspekte wie Performance, Sicherheit und Usability ab.
Ihre Unabhängigkeit als externe Dienstleister befreit sie von den beschriebenen internen Loyalitätskonflikten und dem Druck, möglicherweise unangenehme Wahrheiten zurückzuhalten oder
abzuschwächen. Sie können und müssen objektiv berichten, was ihre Ergebnisse und Analysen oft ungeschminkter und daher wertvoller macht.
Ihre Effizienz bei der Erstellung robuster Testfälle und bei der Analyse von Fehlern spart wertvolle Entwicklerzeit und reduziert die Gesamtkosten durch eine deutlich frühere und
zuverlässigere Fehlererkennung.
Ein weiterer kritischer Punkt in vielen Projekten ist der Umgang mit Änderungen. Fachbereiche haben oft neue Ideen oder Anforderungen, während die Entwicklung bereits auf Hochtouren läuft.
Solche späten Änderungswünsche können nicht nur bereits geschriebenen Code obsolet machen oder tiefgreifende Anpassungen erfordern, sondern im schlimmsten Fall die gesamte
Softwarearchitektur gefährden. Ein konsequentes Changemanagement ist daher Pflicht. Essenziell ist dabei, das Testteam von Anfang an in diesen Prozess einzubinden.
Testingenieure haben oft ein gutes Gespür für die Stabilität des bestehenden Codes und können frühzeitig auf Risiken hinweisen, die durch Änderungen entstehen.
Sie müssen kontinuierlich informiert sein, um ihre Teststrategien und Testfälle an die sich ändernden Anforderungen anzupassen und die Auswirkungen auf das Gesamtsystem zu überprüfen.
Angesichts der Komplexität und der Notwendigkeit einer unabhängigen, unbefangenen Perspektive stellt sich die Frage, ob es nicht sinnvoll wäre, die Qualitätssicherung vollständig
auszulagern. Anstatt ein eigenes Testteam aufzubauen oder ein separates internes Projekt zu starten, könnte man diese Aufgabe an ein spezialisiertes externes Ingenieurbüro vergeben.
Ein solches Büro bringt nicht nur Expertise und Erfahrung mit, sondern kann auch eine enge, aber garantiert unabhängige und objektive Zusammenarbeit mit der internen Entwicklung und
den Fachbereichen gewährleisten. Es könnte ein regelmäßiges, transparentes Reporting direkt in die Infrastruktur des Auftraggebers (z.B. über Jira/XRay-Integration) liefern.
Ein bedeutender Mehrwert wäre zudem die Möglichkeit, dass der Auftraggeber am Ende des Projekts oder nach wichtigen Meilensteinen ein qualifiziertes Zertifikat über die erreichte
Softwarequalität von diesem unabhängigen Ingenieurbüro erhält. Ein solches Zertifikat wäre ein starkes Marketinginstrument und ein Vertrauensbeweis gegenüber den eigenen Kunden.
Nach 35 Jahren im Feld kann ich nur resümieren: Qualitätssicherung ist kein Luxus und kein notwendiges Übel. Sie ist ein fundamentaler Baustein für den Projekterfolg, die
Kundenzufriedenheit und die Wirtschaftlichkeit der Softwareentwicklung. Die Investition in erfahrene, idealerweise unabhängige, Testingenieure, robuste Prozesse, sinnvolle
Automatisierung und gegebenenfalls die strategische Partnerschaft mit externen Spezialisten zahlt sich auf lange Sicht immer aus. Sie reduziert Risiken, spart Kosten und sorgt
dafür, dass die entwickelte Software das leisten soll, was sie soll – zuverlässig und effizient.
15
26.09.2025
18.09.2025
10.09.2025
27.08.2025
23.08.2025
16.08.2025
11.08.2025
09.08.2025
01.08.2025
29.07.2025
21.07.2025
20.07.2025
15.07.2025
22.06.2025
16.06.2025
16.06.2025
15.06.2025
13.06.2025
11.06.2025
10.06.2025
09.06.2025
03.06.2025
04.05.2025
02.05.2025
30.04.2025
29.04.2025
26.04.2025
25.04.2025
24.04.2025
23.04.2025
