zur Übersicht

Unternehmen investieren kräftig in Produkte und Dienstleistungen. Um diese Investitionen langfristig zu schützen, muss sich jede Organisation mit dem Thema Qualitätssicherung (engl. Quality Assurance) auseinandersetzen. Ein effektives und effizientes Qualitätsmanagement begrenzt das Risiko, objektive Qualitätsanforderungen oder subjektive Erwartungen nicht zu erfüllen und so die Nutzer zu enttäuschen oder gar zu verlieren. Dies gilt auch für Softwareprodukte, deren hohe Qualität die Basis für das Vertrauen in das Produkt und das Unternehmen ist.

In der Softwareentwicklung ist das Testen der Software ein qualitätsbestimmender Faktor. Das Testen setzt dabei die geforderte Funktionalität, Zuverlässigkeit und Benutzbarkeit der Lösung voraus. Als Testumgebung für Softwareprodukte dient ein Rechner, auf dem spezifische Testfälle abgewickelt werden. Das ist die Grundlage, um Fehler zu bestimmen, zu bereinigen, zu korrigieren oder für das sogenannte Debugging (von Käfern befreien).

Hauptaufgabe des Testens ist es, Fehler auf Basis von beschriebenen Testfällen oder Szenarien zu erkennen und zweckdienlich zu beschreiben. Die Zweckdienlichkeit orientiert sich dabei daran, dass die Entwickler das Fehlverhalten nachvollziehen und die Mängel beheben können. In der Praxis kommt es vor, dass durch die Korrektur eines Fehlers wieder neue Fehler «hineinprogrammiert » werden. Ein anderes Phänomen betrifft Fehler, die erst durch die Fehlerkorrektur «ermöglicht» werden.

Die Testprozesse sind somit Bestandteil der Qualitätssicherung eines Produkts. Mit erfolgreichen Tests wird die Basis für das Vertrauen der Kunden und Nutzer in eine funktionierende Softwarelösung gelegt und damit auch die Kundenbindung gefestigt.

Positive Erfahrungen mit ISO -Standard 9126

Um das Testen angemessen zu strukturieren und auch wirtschaftlich ausgestalten zu können, sollten Rahmenwerke zurate gezogen werden. Ist Testing als Teil der Qualitätssicherung positioniert, sind Rahmenwerke für die Softwarequalität naheliegend. Typischerweise bieten unterschiedliche Organisationen verschiedene Modelle an. In der Projektpraxis hat Parexa mit dem ISO-Standard 9126 bereits mehrfach positive Erfahrungen gesammelt. Dieser ISO-Standard ist umfassend konzipiert und bezieht auch Merkmale wie die Attraktivität für Benutzer oder die Modifizierbarkeit für Verbesserungen einer Software ein. In weiteren Projekten beabsichtigt Parexa, den aktuelleren ISO-Standard 29119 auf seine praktische Anwendbarkeit näher zu prüfen.

Testen im klassischen Wasserfall-Vorgehen

Die klassische Produktentwicklung wird in der Softwarebranche als Wasserfall-Vorgehen bezeichnet. Solche Vorgehensweisen beinhalten klar definierte Phasen oder Entwicklungsstufen, die erst bei Erfüllung von Abnahmekriterien überschritten werden. Die Abnahmekriterien können dabei Planungen, Konzepte, Spezifikationen, Betriebs- oder Bedienungsanleitungen oder auch Software mit entsprechenden Eigenschaften umfassen.

Diese Abnahmekriterien gewährleisten ein systematisches Vorgehen. Oft wirkt dies schwerfällig und gegenüber Kunden und Benutzern dauert es häufig (zu) lange, bis sie ein erstes Stück der Software sehen, die sie bestellt bzw. beauftragt haben. Dennoch sind solche Wasserfall-Vorgehen etabliert und erfreuen sich nach wie vor einer gewissen Beliebtheit.

Alle Modelle definieren eine Systematik zur geordneten Projektabwicklung. Meist werden Phasen bzw. Arbeitsabschnitte festgelegt, die mit einem bestimmten Ergebnis in Form eines Dokuments abzuschliessen sind. Ein Phasenabschluss (Meilenstein) ist dann erreicht, wenn alle geforderten Dokumente fertiggestellt sind und den festgelegten Qualitätskriterien genügen.

Im klassischen Wasserfall-Vorgehen ist das V-Modell weitläufig anerkannt. Das Modell stellt dar, wann gegen welche Vorgabe getestet wird. Dabei nutzt man für die immer detaillierter werdenden Entwicklungsschritte entsprechende Testgrundlagen (Testfälle, Testdaten, Testszenarien usw.).

Klassisches Wasserfall-Vorgehen: Die Testphase startet erst nach der Implementierung – damit sind Fehlerbehebungen teuer. Denn die Fehler werden erst spät entdeckt.

Testen im agilen Kontext

Viele Projekte oder Initiativen werden heute nicht mehr in klassischen Projektphasen oder Vorgehensmodellen realisiert. Häufig werden in der modernen Projektwelt sogenannte agile Vorgehensmethoden angewendet. Dabei kommen agile Entwicklungsteams zum Einsatz. Diese Teams sind so zusammengestellt, dass sie neue Funktionen oder Prozesse nicht nur analysieren, designen und umsetzen, sondern zusätzlich auch das Testing sicherstellen können. Die Qualitätssicherung ist bei agilen Vorgehensweisen für verschiedene Testverfahren direkt im agilen Entwicklungsteam verankert.

Agile Methoden wurden zu Beginn in kleineren Software-Entwicklungsunternehmen angewendet. Diese Teams waren als sogenannte Scrum-Teams unterwegs und realisierten ihre Software in Sprints. Mit zunehmender Reife und Akzeptanz der Methoden und dank der breiteren Ausbildung der Ressourcen haben mittlerweile auch grosse Unternehmen aus der Bank- und Versicherungsbranche oder aus dem Gesundheitswesen agile Methoden und Modelle eingeführt.

Safe dank SAFe

Ein bekanntes und ausgereiftes Rahmenwerk ist SAFe – das Scaled Agile Framework. SAFe wurde konzipiert, um agile Entwicklungsprozesse von der Strategie bis zur Softwarerealisierung zu skalieren. Dabei müssen die Vorgänge über verschiedene Teams und Stufen hinweg orchestriert werden. Die agilen Teams sind in einem sogenannten Agile Release Train (ART) mit einer gemeinsamen geschäftlichen Mission zusammengefasst. Ein ART ist typischerweise funktionsübergreifend zusammengestellt, sodass die neue Lösung definiert, implementiert, getestet, bereitgestellt, ausgeliefert und betrieben werden kann.

Agile Organisationen gehen inkrementell vor und lernen kontinuierlich aus den Ergebnissen. Diese Überzeugung basiert darauf, dass «die Welt nicht fertig erfunden ist» und es immer wieder Neues zu erlernen und zu verbessern gibt. In einer definierten Kontinuität werden nach und nach nutzbare, werthaltige Inkremente entwickelt und verbessert. So lassen sich mit minimalen Kosten schon frühzeitig erste Ergebnisse kommerzialisieren. Andererseits können unbrauchbare oder nicht akzeptierte Lösungen frühzeitig gestoppt werden.

Alle zu entwickelnden Inkremente durchlaufen die Continuous Delivery Pipeline.

Die Continuous Delivery Pipeline nach SAFe ermöglicht kontinuierliches Lernen und Entwickeln.

Diese beinhaltet alle Zwischenschritte von der ersten Idee bis zum fertigen Release und wird für jede Teillieferung (Inkrement) immer wieder von Neuem durchlaufen. Mittels kontinuierlicher Analyse des Marktes bzw. der Kunden- und Partneranforderungen (Continuous Exploration), kontinuierlicher Entwicklung und Umsetzung (Continuous Integration) und kontinuierlichem Rollout (Continuous Deployment) können Unternehmen Produkte oder Funktionen rasch dem Kunden oder Partner zur Verfügung stellen. Dabei ist es wichtig,  die Entwicklung und die Auslieferung zu entkoppeln und das Prinzip «Release on Demand» zu beachten. Damit wird sichergestellt, dass ein Inkrement aus einem ART dem effektiven Bedarf eines Teams in einem anderen ART entspricht.

Mehrwert dank Qualitätssicherung

Um die kontinuierliche Integration (Continuous Integration) mit echtem Mehrwert zu ermöglichen, muss eine entsprechende Qualitätssicherung erfolgen. Bei agilen Vorgehensmethoden hat die Qualität des Produkts und der Dokumentation deshalb einen hohen Stellenwert. Bei SAFe ist Qualität mit der Built-in Quality sogar einer der vier Kernwerte des Rahmenwerks.

Der Stellenwert des Testings steigt mit der Anwendung agiler Methoden deutlich, wenn man vom beabsichtigten Nutzen der agilen Entwicklung profitieren will. Um eine ausreichende Qualität und hohe Stabilität der entwickelten Inkremente zu gewährleisten, werden beim Durchlaufen der Pipeline sowohl automatisiert wie auch manuell immer wieder Validierungen und Tests durchgeführt. Diese Testroutinen müssen für jedes Inkrement in der Pipeline bereitgestellt werden. So liegt es in der Verantwortung der Entwicklerteams, dass für neu geschriebene Codes auch die dafür zuständigen Testumgebungen weiterentwickelt werden.

 

Mehrere agile Teams arbeiten zusammen an neuen Funktionalitäten, welche einmal pro Iteration an einer System-Demo demonstriert werden.

 

Es genügt aber nicht, wenn die agilen Teams ihre entwickelten Funktionalitäten nur isoliert testen. Üblicherweise arbeiten mehrere Teams an einer gemeinsamen Lösung. Aus diesem Grund müssen die Entwicklerteams immer basierend auf der neusten Version der Lösung (Mainline) ihre Entwicklungen vorantreiben und die fertigen Komponenten umgehend wieder bereitstellen. Unterstützt werden die verschiedenen agilen Teams durch ein System-Team. Dieses behält das Gesamtsystem mit allen Schnittstellen im Auge. Bei regelmässig stattfindenden Integrationstests und darauffolgenden System-Demos müssen die Entwickler beweisen, dass die neu entwickelten Komponenten auch End-to-End funktionieren.

Je später, desto teurer

Im Testing gilt das Prinzip, dass die Behebung eines Fehlers umso teurer wird, je später er entdeckt wird. Um die Qualität kontinuierlich sicherzustellen, sollte idealerweise ein Systemtest durchgeführt werden, wenn ein neuer Programmcode eingecheckt wird. Aus Ressourcengründen ist es aber nicht sinnvoll, bei jeder Anpassung sämtliche Testfälle manuell durchzuführen. Die Verfügbarkeit von Testumgebungen mit einem hohen Grad an Testautomatisierung ist eine wichtige Voraussetzung für die Effizienz.

Mit solchen automatisierten Tests können die Durchgängigkeit und Systemkompatibilität von neu entwickelten Funktionalitäten direkt bei der Integration sichergestellt werden. Damit leisten sie einen wichtigen Beitrag zur Qualitätssicherung bei agilen Vorhaben. Die Anzahl erfolgreicher bzw. fehlgeschlagener Tests dient auch als Gradmesser für den Entwicklungsfortschritt gegenüber den Auftraggebern und Sponsoren.

Autoren

Jeanine Schor

Project Manager

 

Jeanine Schor ist Physikerin mit langjähriger Projekterfahrung an der Schnittstelle zwischen Business und IT. Als SCRUM Master ist für sie Qualitätssicherung auch bei agilen Vorgehensweisen essentiell.

Remo Negri

Project Manager

 

Remo Negri ist Betriebsökonom mit einem Flair für Informatik und hat über 10 Jahre Projekterfahrung in der Finanzbranche. Als begeisterter Fallschirmspringer ist ihm aktives Risikomanagement nicht nur in Theorie ein Begriff.

Hier den Artikel als PDF downloaden:

Parexa-excellence-2019_7-Kontinuität-in-der-agilen-Welt-erfordert-Qualität