In einer zunehmend digitalen Welt wird qualitativ hochwertige Enterprise Software immer wichtiger. Die Software-Qualitätssicherung (QS) ist entscheidend für die Gewährleistung höchster Qualitätsstandards. Angesichts dieser Anforderungen müssen Unternehmen jedoch den Spagat für die Qualitätssicherung von Enterprise Software zwischen maximaler Qualität und minimalen Aufwänden meistern.

In dieser Artikelserie zeige ich Lösungsansätze auf, die zu einem optimalen Gleichgewicht zwischen Exzellenz und Effizienz in der QS führen können.

Teil 1: Wichtige Herausforderungen, die bei der Qualitätssicherung auftreten können

Im strengen Takt der Softwareentwicklung wird die Qualitätssicherung zur Achillesferse, wenn sich Herausforderungen und Risiken häufen. Beide Faktoren können beträchtliche Zeit und Ressourcen in Anspruch nehmen und die Qualität mindern. Eine sorgfältige Auseinandersetzung mit diesen Aspekten ist daher unerlässlich. In diesem ersten Teil der Artikelserie werde ich einige Herausforderungen und Hindernisse beleuchten, die sich direkt auf die Produktqualität, den Zeitaufwand und die Ressourcen auswirken und mit denen QS-Teams zu kämpfen haben.

Hilfe! Ich muss Testfälle schreiben

Nehmen wir folgende Situation an: Mir wurde ein Ticket zugeteilt. Ich soll mir gute Testfälle zu einer Anforderung überlegen. Aber was sind „gute Testfälle“ und woran werden sie gemessen? Mein Verständnis für die Fachlichkeit ist etwas schwammig, um nicht zu sagen mangelhaft. Es werden viele Begriffe verwendet, mit denen ich nichts anfangen kann. Zu viele Prozesse, Details und Besonderheiten! Hilfe! Ich beschränke mich lieber genau auf die Ticketbeschreibung und überlege mir etwas dazu. Beim Schreiben der Testfälle fällt es mir schwer, ein Ziel zu definieren. Muss ich jeden Klick im Testfall beschreiben? Was kommt in die Testfallerwartung? Ich teile die Klicks in mehrere kleine Testfälle auf. Wow, jetzt habe ich locker 20 Testfälle! Das ist mehr als genug für ein einziges Ticket. Meine Testfälle sind sicher gut, schließlich prüfe ich die Korrektheit mehrerer Klicks.

Herzlichen Glückwunsch! Sie haben Ihre Tests unnötigerweise um 20 Testfälle aufgebläht. Damit haben Sie die Testausführungszeit und die Testwartungsarbeiten für einen minimalen Mehrwert erhöht, leider nicht nur für den aktuellen Sprint, sondern auch für die künftigen Sprints. Schlimmer noch, Sie haben jetzt eine versteckte Testlücke, die potentielle Schwachstellen unentdeckt lässt und langfristig die Stabilität und Zuverlässigkeit des Software-Produkts beeinträchtigen. Durch die Bearbeitung des Tickets haben Sie tatsächlich die Qualität verringert, anstatt sie zu erhöhen.

Mit zunehmender Anzahl an “aufgeblähten” Testfällen nimmt die Qualität ab, während die Aufwände ansteigen.

Viele Gründe für Qualitätsverluste in der Qualitätssicherung

Ziel einer jeden QS ist selbststrebend eine Verbesserung der Qualität etwa von Material, Produkt und Prozessen. In der QS von Enterprise Software kommt es aber nicht selten zu Qualitätsverlusten. Das kann unterschiedliche Gründe haben:

• Ungenügende oder fehlende Erfahrung in der Qualitätssicherung
• Fehlende oder falsche Teststrategie und Testanalyse
• Fehlende oder falsche Prioritätensetzung und Risikobewertung
• Mangelhafte Testentwurfsverfahren und geringe Überdeckung
• Falsche Auswahl der Testdaten
• Schlechte Umsetzung der Testfälle
• Langsame und/oder falsche Fehleranalyse
• Mangelndes oder fehlendes Verständnis der Fachlichkeit
• Mangelhafte oder fehlende inhaltliche Tiefe der Tests
• Mangelndes oder fehlendes Kombinieren von Fachwissen
• Fehlender Gesamtblick
• Langsame Testausführung
• Schlechte, fehlende, wiederkehrende oder kontinuierlich zunehmende Wartung der Tests

Wenn eine QS unter Qualitätsverlusten leidet, wird sie mit der Zeit teuer und ineffizient. Es ist deshalb entscheidend, diese Verluste zu identifizieren und wirksam zu beheben.

Zeitfresser in der Qualitätssicherung von Enterprise Software

Zusätzlich zu den potentiellen Qualitätsverlusten können sich Zeitverluste in der QS auch als erheblicher Kostenfaktor erweisen. Jede Minute, die für ineffiziente Testprozesse aufgewendet wird, beansprucht wertvolle Ressourcen und kann zu Verzögerungen im Projektplan führen. Zu den möglichen Zeitfressern in der QS gehören unter anderem:

Bereitstellung der Testumgebung, Testdaten und Testvoraussetzungen

Die Einrichtung der Testumgebung erfordert die präzise Konfiguration einer vielschichtigen technischen Infrastruktur, einschließlich Servern, Netzwerken und virtuellen Maschinen, um beispielsweise eine möglichst realistische Abbildung der Produktionsumgebung zu gewährleisten. Die akkurate Aufbereitung oder Generierung von Testdaten, die sowohl repräsentativ als auch ausreichend umfangreich sind, stellt eine anhaltende Herausforderung dar. Darüber hinaus ist die Identifikation und Verwaltung spezifischer Testvoraussetzungen, z.B. bestimmter Systemzustände oder Konfigurationen, eine komplexe Aufgabe, die wiederholt durchgeführt werden muss. Der Aufwand für die Erstellung und Aufrechterhaltung dieser Testvoraussetzungen kann erheblich sein, da sie sich im Laufe der Entwicklungszyklen ändern können.

Die wiederkehrende Notwendigkeit, die Testumgebung, Daten und Voraussetzungen synchron und aktuell zu halten, erfordert eine kontinuierliche Überwachung, Aktualisierung und Versionierung. Um diese Aufgaben zu bewältigen, bedarf es zudem Ressourcen mit einem tiefen Verständnis der Softwarearchitektur, umfassender technischer Expertise und einer methodischen Herangehensweise. Insgesamt stellt die Bereitstellung der Testumgebung, Testdaten und Testvoraussetzungen eine anspruchsvolle, komplexe, zeitaufwändige, kostspielige und zudem wiederkehrende Aufgabe dar.

Testausführung

Die zeitraubende Natur der Testausführung in der Qualitätssicherung von Enterprise Software resultiert aus der Notwendigkeit, eine umfassende Abdeckung der unterschiedlichen Anwendungsszenarien, Eingabevariablen, Randfälle und Interaktionen zu gewährleisten. Dies erfordert die Konzeption und Implementierung einer breiten Palette von Testfällen und Testdaten, die in verschiedenen Umgebungen mit unterschiedlichen Konfigurationen ausgeführt werden müssen. Für die Ausführung dieser Tests werden beträchtliche Ressourcen und Zeit benötigt, da sowohl die Initiierung der Tests, das Sammeln und Analysieren der Ergebnisse als auch die eventuelle Fehlerdiagnose und -behebung eine nicht unerhebliche Dauer in Anspruch nehmen. Darüber hinaus können die Tests aufgrund von Änderungen in der Anwendungslogik, der Systemarchitektur oder der Testinfrastruktur zusätzliche Komplexität und Zeitaufwand mit sich bringen.

Im Folgenden eine kurze Zusammenfassung möglicher Zeitfresser:

• Klärung, ob ein Fehler tatsächlich ein Bug oder ein gewünschtes Feature ist
• Untersuchung und Analyse der Fehler und Logdateien
• Eingrenzung von nicht leicht nachstellbaren Fehlern
• Erstellung von Fehlertickets mit detaillierten Informationen wie Schritte zum Nachstellen des Fehlers, wichtige Hinweise, Logs, Screenshots oder eine hilfreiche Videoaufnahme
• Folgefehler: Fehler, die durch einen anderen Fehler verursacht wurden. Sie verschwinden von selbst, wenn der ursprüngliche Fehler behoben ist. Die Analyse und Identifikation solcher Fehler ist zeitraubend.
• „Ping-Pong“-Fehler: Zur Behebung eines einzigen Fehlers werden mehrere Builds und Testdurchläufe benötigt.
• Seiteneffekte: Das Beheben eines Fehlers verursacht einen oder mehrere neue Fehler, die wiederum behoben werden müssen.
• Vorwärts- und Rückwärtsänderungen: Es werden in einem Release Änderungen umgesetzt, die aber im nächsten Release rückgängig gemacht werden. Solche Änderungen verursachen unnötige Testanpassungsaufwände.
• Regression: Wiederholung derselben Testfälle mehrmals
• Re-Runs (Release Candidates, Patches etc.): Wiederholung aller Testfälle mehrfach
• Wiederholung von Tests auf unterschiedlichen Umgebungen, unterschiedlichen Browsern etc.
• Wiederholung von Tests auf einem Entwicklungsstand
• Skalierende Aufwände für die Wartung und Ausführung der Tests insbesondere bei komplexen oder langlebigen Enterprise Software.
• Häufige Änderungen an Testplänen oder des Testumfangs
• Hoher Dokumentationsaufwand der Testergebnisse

Bei steigenden Zeitfressern wird die Qualitätssicherung immer kostspieliger und zeitaufwendiger. Dies birgt insbesondere während der Testphasen ein erhöhtes Risiko.

Herausforderungen in der Testphase: Ein Blick auf Risiken aus der Perspektive der Qualitätssicherung

Während der Testphase können Umstände auftreten, die ein potenzielles Risiko für die Qualitätssicherung darstellen und möglicherweise die termingerechte Auslieferung der Software gefährden können. Nachfolgend werden einige potenzielle Risiken aufgezeigt:

• Es kommt zu einem ungeplanten Ausfall von QS-Ressourcen.
• Es liegen Hardwareprobleme vor, z. B. ein VM-Ausfall.
• Der Code-Freeze wird nicht eingehalten.
• Das QS-Team wird nicht oder zu spät über eine Änderung informiert.
• Die Testphase wird verkürzt, z. B. weil eine Anforderung sehr spät aufgenommen wurde oder die Umsetzung länger dauert als geplant.
• Beim Fixen von Bugs werden neue Bugs verursacht.
• Beim Fixen von Bugs werden trotz Code-Freeze neue Features oder Änderungen mitgeliefert.
• Der Bug-Fix verursacht Anpassungsaufwände im QS-Bereich.
• Der Bug-Fix umfasst einen Blocker für die Testausführung. Zum Beispiel: Die Erkennung einer zentralen Komponente auf der UI ist nicht mehr möglich und die automatisierten UI Tests können nicht mehr ausgeführt werden.
• Es werden mehr Testdurchläufe benötigt als geplant.
• Die Anzahl der gefundenen Bugs nimmt nicht ab.
• Es werden am Ende der Testphase weiterhin Blocker oder kritische Bugs gefunden.

Die in der Testphase unentdeckten Risiken können zu erhöhten Kosten führen und die Testeffizienz beeinträchtigen. Deshalb ist es wichtig, aufkommende Risiken frühzeitig zu identifizieren und geeignete Maßnahmen zu ergreifen, um mögliche Auswirkungen zu reduzieren oder zu verhindern.

Zwischenfazit

Zusammenfassend verdeutlichen die aufgezeigten Herausforderungen und Risiken eindrücklich, dass sie zu spürbaren Einbußen in Bezug auf Qualität, Zeit und Ressourcen führen können. Eine sorgfältige Auseinandersetzung mit diesen Aspekten erweist sich daher nicht nur als unverzichtbar, sondern auch als strategische Investition, um nachhaltig effiziente Software-Qualitätssicherung gewährleisten zu können.

Wie stelle ich mir eine effiziente QS vor?

Eine effiziente Qualitätssicherung muss kostengünstig, schnell und gut sein.

Was bedeutet kostengünstig?

• Wenig Ressourcen
• Kurze Testausführungszeiten
• Minimale Wartungsarbeiten

Wie definiert sich schnell?

• Schnelle Fehleranalyse
• Schnelle Testergebnisse
• Schnelle Testreports

Was ist gut?

• Risikominimierung
• Gute Testabdeckung

Wie viele QS-Ressourcen benötige ich im Durchschnitt?

• In einem Team von sechs Entwicklern benötige ich durchschnittlich eine Ressource für QS.
• Auf eine manuelle QS-Ressource, benötige ich im Durchschnitt eine halbe QS-Ressource für die Testautomatisierung.

Was erwarte ich?

• Alle Anwendungsfälle (Use Cases) werden von Anfang bis Ende durchgetestet.
• Trotz steigender Anforderungen bleibt die Testphase idealerweise gleich kurz.
• Es werden keine (kritischen) Bugs in der Produktion gefunden, insbesondere nicht unmittelbar nach der Auslieferung.

Um die Effizienz in der QS zu steigern, bedarf es zunächst einer strategischen Überlegenheit. Die gezielte Ausrichtung auf Qualitätsstrategien ermöglicht nicht nur eine Steigerung der Produktqualität, sondern auch eine bemerkenswerte Optimierung des Zeit- und Ressourcenverbrauchs.

Mehr dazu erfahren Sie in Teil 2 „Strategische Überlegenheit“.