2
Systemtest im agilen Entwicklungsprozess Uwe Hehn, Sebastian Kern Method Park Software AG Wetterkreuz 19a, 91058 Erlangen, Germany Email: {uwe.hehn, sebastian.kern}@methodpark.de Abstract: In der Vergangenheit wurden medizintechnische Projekte typischerweise klassisch gemäß V-Modell durchgeführt. Wir untersuchen, wie die klassische Vorgehensweise mit agilen Elementen kombiniert werden kann, so dass man die Flexibilität des agilen Ansatzes nutzen kann und gleichzeitig die strengen Anforderungen an die Abnahme von Medizinprodukten erfüllt werden können. Das vorgestellte Konzept zum „agilen Systemtest für medizintechnische Produkte“ beruht auf unseren Erfahrungen in einem großen Medizintechnik-Unternehmen. 1 Einleitung Bei der Zulassung medizintechnischer Geräte wird nicht nur das Produkt sondern auch der Prozess geprüft; das betrifft insbesondere das Vorliegen von Entwicklungsdokumenten in hoher Qualität. Viele Unternehmen kombinieren die klassische Vorgehensweise gemäß V-Modell mit agilen Elementen. Man hofft, dadurch sowohl die strengen Anforderungen an die Abnahme von Medizinprodukten erfüllen zu können als auch die Flexibilität nutzen zu können, die der agile Ansatz verspricht. Die folgenden Überlegungen zur Zulässigkeit eines agilen Systemtest für medizintechnische Produkte gründen sich auf aktuelle Erfahrungen in einem großen Medizintechnik-Unternehmen, bei dem ein auf SCRUM [1] basierender agiler Systemtest zur Anwendung kam. 2 Systemtest nach dem V-Modell Wir betrachten im Folgenden den Fall System = Softwaresystem. (Im Falle allgemeiner Systeme überträgen sich die Überlegungen auf den Systemtest der Software-Subsysteme.) Der Systemtest dient dazu, die Erfüllung der Systemanforderungen zu prüfen [3]. Die Norm ISO15504-5, ENG.10 (SPICE) [2] definiert genauer: Der Zweck des Systemtestprozesses ist die Sicherstellung, dass die Implementierung aller Systemanforderungen auf deren Erfüllung getestet wird, und dass das System zur Auslieferung bereit ist. Allgemeine Grundlagen der Qualitätssicherung fordern, dass das Systemtest-Team unabhängig von der Entwicklung sein muss (Vier-Augen-Prinzip). Der Zeitbedarf für den Systemtest ist typischerweise sehr groß. Geschickterweise kann man Aktivitäten wie z.B. den Testentwurf, den Aufbau einer Testumgebung bzw. die Realisierung einer Testautomatisierung schon während der Entwicklung des Systems umsetzen. Die Durchführung des Systemtests ist erst dann möglich, wenn das System vollständig ist (Abbildung 1). Folglich ist in der Praxis die Zeit für den Systemtest oft sehr knapp. Abbildung 1: Aufteilung der Aktivitäten des Systemtests in Phasen Der Einsatz agiler Methoden sollte helfen, dass die Vorbereitung der Durchführung des Systemtests möglichst früh erfolgt. Außerdem erhofft man sich, dass das zeitliche Bottleneck der „Durchführung des Systemtests“ verringert wird.

Systemtest im agilen Entwicklungsprozess

Embed Size (px)

Citation preview

Page 1: Systemtest im agilen Entwicklungsprozess

Systemtest im agilen Entwicklungsprozess

Uwe Hehn, Sebastian Kern Method Park Software AG

Wetterkreuz 19a, 91058 Erlangen, Germany Email: {uwe.hehn, sebastian.kern}@methodpark.de

Abstract: In der Vergangenheit wurden medizintechnische Projekte typischerweise klassisch gemäß V-Modell durchgeführt. Wir untersuchen, wie die klassische Vorgehensweise mit agilen Elementen kombiniert werden kann, so dass man die Flexibilität des agilen Ansatzes nutzen kann und gleichzeitig die strengen Anforderungen an die Abnahme von Medizinprodukten erfüllt werden können. Das vorgestellte Konzept zum „agilen Systemtest für medizintechnische Produkte“ beruht auf unseren Erfahrungen in einem großen Medizintechnik-Unternehmen.

1 Einleitung

Bei der Zulassung medizintechnischer Geräte wird nicht nur das Produkt sondern auch der Prozess geprüft; das betrifft insbesondere das Vorliegen von Entwicklungsdokumenten in hoher Qualität. Viele Unternehmen kombinieren die klassische Vorgehensweise gemäß V-Modell mit agilen Elementen. Man hofft, dadurch sowohl die strengen Anforderungen an die Abnahme von Medizinprodukten erfüllen zu können als auch die Flexibilität nutzen zu können, die der agile Ansatz verspricht. Die folgenden Überlegungen zur Zulässigkeit eines agilen Systemtest für medizintechnische Produkte gründen sich auf aktuelle Erfahrungen in einem großen Medizintechnik-Unternehmen, bei dem ein auf SCRUM [1] basierender agiler Systemtest zur Anwendung kam.

2 Systemtest nach dem V-Modell

Wir betrachten im Folgenden den Fall System = Softwaresystem. (Im Falle allgemeiner Systeme überträgen sich die Überlegungen auf den Systemtest der Software-Subsysteme.) Der Systemtest dient dazu, die Erfüllung der Systemanforderungen zu prüfen [3].

Die Norm ISO15504-5, ENG.10 (SPICE) [2] definiert genauer: Der Zweck des Systemtestprozesses ist die

Sicherstellung, dass die Implementierung aller Systemanforderungen auf deren Erfüllung getestet wird, und dass das System zur Auslieferung bereit ist.

Allgemeine Grundlagen der Qualitätssicherung fordern, dass das Systemtest-Team unabhängig von der Entwicklung sein muss (Vier-Augen-Prinzip). Der Zeitbedarf für den Systemtest ist typischerweise sehr groß. Geschickterweise kann man Aktivitäten wie z.B. den Testentwurf, den Aufbau einer Testumgebung bzw. die Realisierung einer Testautomatisierung schon während der Entwicklung des Systems umsetzen. Die Durchführung des Systemtests ist erst dann möglich, wenn das System vollständig ist (Abbildung 1). Folglich ist in der Praxis die Zeit für den Systemtest oft sehr knapp.

Abbildung 1: Aufteilung der Aktivitäten des Systemtests in Phasen

Der Einsatz agiler Methoden sollte helfen, dass die Vorbereitung der Durchführung des Systemtests möglichst früh erfolgt. Außerdem erhofft man sich, dass das zeitliche Bottleneck der „Durchführung des Systemtests“ verringert wird.

Page 2: Systemtest im agilen Entwicklungsprozess

3 SCRUM und Systemtest

3.1 Fachliche Anforderungen an den Systemtest

Selbstverständlich können die folgenden fachlichen Aspekte des Systemtests nicht außer Acht gelassen werden: Funktioniert die Software? Testspezifikation (Was wurde in welchem

Umfang getestet?) Testergebnisse (Ergebnis der Prüfung) Reagieren auf geänderte Anforderungen Regressionstest-Strategie (Veränderungen ohne

negativen Einfluss?)

3.2 Die Kombination SCRUM und Systemtest

Die von uns vorgeschlagene und beim Kunden eingeführte Vorgehensweise sieht vor, den Systemtest anteilig bereits in den N Entwicklungssprints zu berücksichtigen. In den abschließenden Systemtest-Sprint N+1 wird dafür im Gegenzug auch das Beheben von in den Systemtest-Sprints gefundenen Fehlern eingeplant. Gefundene Fehler werden so bald wie möglich zur Behebung eingeplant (Abbildung 2). Im Idealfall sind im Systemtest-Sprint im zu testenden System nur noch sehr wenige Fehler vorhanden.

Abbildung 2: Smarte Aufteilung der Systemtest-Aktivitäten auf die Folge von Sprints Wie eine effektive Umsetzung im Detail aussieht, wird im folgenden Kapitel erläutert.

4 Einbindung von Systemtests in SCRUM

In der Makrosicht (Roadmap) werden N+2 Sprints vorgesehen. Wir betrachten im Folgenden die Sprints aus dem Blickwinkel des Systemtests; natürlich werden in diesen Sprints außerdem die Entwicklung sowie die Aufgaben der anderen Teststufen angesiedelt sein.

4.1 Überblick über die Aufteilung der Sprints aus Sicht des Systemtests

Der initiale Sprint 0 dient dazu, alle Vorbereitungen zu treffen, damit der Systemtest in den folgenden N Produktiv-Sprints effektiv durchgeführt werden kann (Systemtest-Initialisierung). Die folgenden N Sprints 1-N (Produktiv-Sprints) liefern als Ergebnis ein bereits lauffähiges und getestetes Teilsystem (potentially shippable system). Neben der (Weiter-)Entwicklung des Produkts im Sprint X findet jeweils mindestens ein Regressionstest statt (Abdeckung der Anforderungen der Sprints 1-(X-1)). Schließlich erfolgt der Systemtestentwurf für die im aktuellen Sprint X neu umgesetzten Anforderungen. Das Besondere an den Produktiv-Sprints ist, dass einerseits der Systemtest aller bis zum Vorgänger-Sprint umgesetzten Anforderungen erfolgt, andererseits die Testvorbereitung für den aktuellen Sprint durchgeführt wird. Durch diese enge Verzahnung der Aktivitäten des Systemtests mit der Folge der Sprints ergibt sich eine (potentiell) optimale Zuordnung der Systemtestaktivitäten. Im Abschluss-, Cleanup- oder QS-Sprint (N+1) findet der abschließende Systemtest statt (Testen aller bis inkl. Sprint N umgesetzten Anforderungen).

5 Herausforderungen

Eine zentrale Herausforderung ist die Automatisierung des Systemtests, da nur dadurch genügend Zeit für die verbleibenden manuellen Aktivitäten übrig bleibt. Die vollständige Integration eines vormals unabhängigen Systemtest-Teams in den Entwicklungsprozess ist eine „kulturelle Herausforderung“. Die notwendige Unabhängigkeit kann jedoch auch hier organisatorisch gewahrt bleiben. Referenzen [1] Roman Pichler: SCRUM, dpunkt.verlag, 1.

Auflage 2008, Heidelberg [2] ISO/IEC 15504-5, International standard, Part

5: An exemplar Process Assessment Model, San Francisco, First edition, 2006-03-01, Switzerland

[3] ISTQB: Foundation Level Syllabus (2011), www.istqb.org