Autoren: Rosalinde Schuster & Christoph Legat, Berner & Mattner Systemtechnik GmbH<\/p>\n
Um in einem dynamischen, internationalen Markt wettbewerbsf\u00e4hig zu bleiben, streben Unternehmen nach stets k\u00fcrzeren und flexibleren Entwicklungszyklen. Im Zuge dieser Entwicklung gewinnen agile Entwicklungsmethoden zunehmend an Bedeutung [1]. Entsprechend dem sogenannten Agilen Manifest [2] wird dabei Individuen und deren Interaktionen, ein funktionierender Produktstand, die Zusammenarbeit mit dem Kunden und die Reaktion auf Ver\u00e4nderungen mehr Gewicht beigemessen als Prozessen und Werkzeugen, einer umfassenden Dokumentation und der Stabilit\u00e4t eines einmal erstellten Plans.<\/strong><\/p>\n Demgegen\u00fcber steht jedoch die Anforderung, spezifischen Normen f\u00fcr den Entwicklungsprozess und\/oder Produkten zu entsprechen. Eine Norm ist dabei eine Leitlinie, welche Informationen zur Vereinheitlichung \u00fcber ein Produkt oder einen Prozess enth\u00e4lt und einen anerkannten Stand der Technik beschreibt [3]. Dies f\u00fchrt zu einem Spannungsfeld zwischen Agilit\u00e4t und der durch Normen geforderten durchg\u00e4ngigen Dokumentation qualit\u00e4tssichernder Ma\u00dfnahmen. Dennoch bieten einige h\u00e4ufig in der agilen Entwicklung eingesetzten Elemente bereits eine solide Grundlage f\u00fcr die Erf\u00fcllung von Normen und damit einer Zertifizierung, wenn diese geeignet genutzt und ad\u00e4quat angepasst werden.<\/p>\n In diesem Zusammenhang stellt Scrum [4] einen einfachen, weit verbreiteten Rahmen f\u00fcr die Organisation der Arbeit in agilen Teams dar: eine fixe L\u00e4nge von Iterationen (sog. Sprints) mit jeweils einem laufff\u00e4higen Inkrement als Produktversion. Scrum wird daher im Folgenden als Ausgangspunkt f\u00fcr ein erweitertes Vorgehensmodell – Scrum QA – genutzt, welches Vorteile agiler Entwicklung mit der Zielsetzung vereint, eine Grundlage f\u00fcr eine Zertifizierung durch Festlegung von Anforderungen und regelkonforme Verifizierung des Entwicklungsartefakten durch Test und R\u00fcckverfolgbarkeit zu schaffen.<\/p>\n Nachfolgend wird eingangs ein \u00dcberblick \u00fcber den Scrum QA zugrunde liegenden Entwicklungsprozess und dessen Aktivit\u00e4ten gegeben. In den anschlie\u00dfenden beiden Abschnitten werden die Rollen und Artefakte des vorgeschlagenen Vorgehensmodells detailliert beschrieben. Der Beitrag schlie\u00dft mit einer Zusammenfassung und gibt einen Ausblick \u00fcber weitere Entwicklungen.<\/p>\n Um eine normgerechte Entwicklunge und angestrebte Zertifizierung geeignet zu ber\u00fccksichtigen, m\u00fcssen die in Scrum genutzten Aktivit\u00e4ten (siehe hierzu beispielsweise Schwaber und Sutherland [4]) entsprechend der Anforderungen, die sich aus etwaigen Normen ergeben, erg\u00e4nzt werden. Einen \u00dcberblick \u00fcber den durch den Scrum QA zu Grunde gelegten Entwicklungsprozess gibt Abbildung 1 (siehe\u00a0PDF<\/a>).<\/p>\n Entsprechend Scrum werden initiale Vorbereitungen in\u00a0Sprint\u00a00<\/strong>\u00a0durchgef\u00fchrt. W\u00e4hrend dieser Sprint im klassischen Scrum optional durchgef\u00fchrt werden kann, ist er f\u00fcr die Entwicklung im normativ regulierten Umfeld essentiell. Bereits hier kann die Grundlage f\u00fcr eine sp\u00e4tere Zertifizierung gelegt werden: So werden im Zuge von Sprint\u00a00 geeignete \u00dcberwachungsma\u00dfnahmen zur Erkennung zuf\u00e4lliger Fehlern und Ma\u00dfnahmen zur Verhinderung systematischer Fehlern in der Entwicklung definiert. Ferner werden aus den zugrunde gelegten Normen entsprechende Qualit\u00e4tsanforderungen, Risikobeseitigungs- und Risikominimierungsstrategien sowie Anforderungen hinsichtlich der Architektur des Gesamtsystems (z.B. zur Sicherstellung der Testbarkeit wird in Normen zur funktionalen Sicherheit eine konsequente, modulare Architektur gefordert) abgeleitet. Darauf basierend kann ein ad\u00e4quates Testkonzept, welches der Testplanung mit Beschreibung der entsprechenden Testobjekte und der zugeh\u00f6rigen Testaufgaben entspricht, erstellt werden. Die sogenannte „Definition of Done“, welche eine Liste von Fertigstellungskriterien (z.B. Qualit\u00e4t, Skalierbarkeit) des Produktes darstellt, wird ferner um die \u00fcblicherweise in Normen geforderten Aspekte hinsichtlich Begutachtung und Dokumentation erweitert.<\/p>\n Das sogenannte\u00a0Product Backlog<\/strong>\u00a0bildet in Scrum die zentrale Datenbasis etwaiger zu realisierender Funktionen und Zielsetzungen. Bereits bei der Erstellung von Eintr\u00e4gen des Backlogs kann die Testbarkeit geeignet sichergestellt werden. Hierdurch k\u00f6nnen h\u00e4ufige Herausforderungen bei der Zertifizierung \u2013 z.B. der Nachweis der funktionalen Sicherheit \u2013 zielgerichtet ber\u00fccksichtigt werden.<\/p>\n Entsprechend dem klassischen Scrum werden die Entwicklungen im Zuge einzelner Iterationen (Sprints<\/strong>) mit vorgegebener L\u00e4nge durchgef\u00fchrt. Zielsetzung jedes Sprints ist stets ein lauff\u00e4higes Produkt, entsprechend den f\u00fcr einen Sprint aus dem\u00a0Product Backlog<\/strong>\u00a0ausgew\u00e4hlten, zu realisierenden Funktionen zu entwickeln. In das\u00a0Sprint Backlog<\/strong>\u00a0werden bei der Sprintplanung die im Rahmen eines Sprints zu erledigende Aufgaben \u00fcbernommen und abgearbeitet. Daher ist im Zuge jedes Sprints eine Vorbereitung und (automatische) Durchf\u00fchrung von Komponenten- und Integrationstests notwendig. Wird die Sprintdauer zu kurz gew\u00e4hlt, k\u00f6nnen diese f\u00fcr eine sp\u00e4tere Zertifizierung notwendigen Aktivit\u00e4ten als Teil der ben\u00f6tigten Regressionsteststrategie nicht geeignet durchgef\u00fchrt werden. In der Praxis erwies sich deshalb eine Sprintdauer von 30\u00a0Tagen als geeignetes Mittelma\u00df zwischen Agilit\u00e4t und Kontinuit\u00e4t.<\/p>\n Bedingt durch die Dokumentationspflicht, die sich aus den Normen ergibt, hat sich der\u00a0Stabilisierungssprint<\/strong>\u00a0als Sonderform eines Sprints bew\u00e4hrt, welcher \u00fcblicherweise vor einem gr\u00f6\u00dferen Release eingeschoben wird. W\u00e4hrend in klassischen Sprints die Realisierung spezifischer Funktionalit\u00e4t fokussiert wird, dient der Stabilisierungssprint dem Nachweis der Normkonformit\u00e4t des Produktes und der Dokumentation. So werden im Zuge dieses Sprints auch fehlende Nachweise zur Erf\u00fcllung etwaiger Sicherheitsanforderungen (soweit ben\u00f6tigt) erg\u00e4nzt bzw. an ge\u00e4nderte Funktionalit\u00e4ten angepasst. Den Stabilisierungssprint charakterisieren eine vermehrte Durchf\u00fchrung von Inspektionen und Reviews sowie deren entsprechende Dokumentation. Auch etwaige R\u00fcckmeldungen durch\u00a0Gutachter<\/strong>\u00a0in Bezug auf die Normeneinhaltung werden eingearbeitet und finden damit Ber\u00fccksichtigung in der Realisierung \u2013 d.h. in die Entwicklungsartefakte, wie der Quellcode in der Softwareentwicklung \u2013 und dessen Dokumentation.<\/p>\n An dieser Stelle sei ferner noch die Bedeutung geeigneter Werkzeugumgebungen betont, welchen im Kontext einer agilen Entwicklung und speziell im normativ regulierten Umfeld f\u00fcr die Qualit\u00e4tssicherung eine besonders gro\u00dfe Bedeutung zukommen: Um eine kontinuierliche Qualit\u00e4tssicherung zu gew\u00e4hrleisten und die regelm\u00e4\u00dfige Aktualisierung notwendiger Dokumentation f\u00fcr eine sp\u00e4tere Zertifizierung effizient erstellen zu k\u00f6nnen, ist neben einem Konfigurationsmanagement, um die Verfolgbarkeit von \u00c4nderungen \u00fcber den Lebens- bzw. Entwicklungszyklus sicherzustellen, eine automatisierte Testumgebungen f\u00fcr die effiziente Wiederholbarkeit von Test (Regressionsstrategie) essentiell. W\u00e4hrend die sog. Continuous Integration \u2013 die fortlaufende Zusammenf\u00fchrung entwickelter Teilkomponenten und Funktionen \u2013 in der Softwareentwicklung bereits im praktischen Einsatz weit verbreitet ist [1], stellen automatisierte Erstellungs- und Testprozesse in interdisziplin\u00e4ren Systementwicklungsprozessen noch stets eine individuelle Herausforderung dar.<\/p>\n Die Verwendung von Rollen und Verantwortlichkeiten f\u00fcr einzelne Aktivit\u00e4ten resultiert in klare Zust\u00e4ndigkeiten f\u00fcr die Umsetzung bestimmter, wichtiger Aufgaben \u2013 insbesondere solcher, um zu Grunde gelegte Normen und eine entsprechende Zertifizierung erreichen zu k\u00f6nnen. Daher werden im Folgenden die Anpassungen und Besonderheiten von Rollen und Verantwortlichkeiten des hier vorgeschlagenen Vorgehensmodells Scrum QA beschrieben.<\/p>\n Der\u00a0Product Owner<\/strong>\u00a0zeichnet sich f\u00fcr die Produktentwicklung verantwortlich und stimmt sich hierf\u00fcr mit allen relevanten Stakeholdern ab, um Entscheidungen treffen zu k\u00f6nnen. Im Scrum QA Prozess ist er zus\u00e4tzlich verantwortlich f\u00fcr das Risikomanagement und nimmt Kontakt zu entsprechenden externen\u00a0Gutachtern<\/strong>\u00a0f\u00fcr die Zertifizierung auf.<\/p>\n Der\u00a0Scrum Master<\/strong>\u00a0ist der Coach, Moderator und Vermittler f\u00fcr alle Prozessbeteiligten. Zu seinen Aufgaben bei der Unterst\u00fctzung des Teams geh\u00f6rt auch die Bereitstellung verwendeter Normentexte und entsprechender Vorlagen zur normenkonformen Dokumentation. Aufgrund seiner Kommunikationsf\u00e4higkeiten kann der Scrum Master auch als Moderator bei durch Normen geforderten Inspektionen und Audits eingebunden werden.<\/p>\n Das\u00a0Team<\/strong>\u00a0zeichnet sich f\u00fcr Umsetzung verantwortlich. In Abh\u00e4ngigkeit der durch die zugrunde gelegten Normen gestellten Anforderungen werden \u2013 sofern m\u00f6glich \u2013 Tests unter Ber\u00fccksichtigung der in Sprint\u00a00 bereits festgelegten Qualit\u00e4tskriterien (z.B. spezifische Testabdeckungen) getestet. Ebenso f\u00e4llt die Erstellung der Dokumentation in den Aufgabenbereich des Teams, um die R\u00fcckverfolgbarkeit von Anforderung bis zum Test sicherzustellen.<\/p>\n Erg\u00e4nzend zu den drei in Scrum \u00fcblicherweise verwendeten Rollen fordert Scrum QA den Einsatz eines\u00a0Testmanagers<\/strong>, dessen Hauptaufgabe die Einhaltung der Normen und die Qualit\u00e4tssicherung als unabh\u00e4ngige Instanz darstellt [3]. Zus\u00e4tzlich fungiert der Testmanager als Ansprechpartner bei Fragen hinsichtlich technischer oder organisatorischer Anforderungen, die sich aus den zugrunde gelegten Normen ergeben. Die Definition des Testkonzepts unter Ber\u00fccksichtigung etwaiger durch Normen implizierter Anforderungen geh\u00f6rt ebenfalls zu seinen Aufgaben. So ist er beispielsweise im Falle von funktionaler Sicherheit, f\u00fcr die Erg\u00e4nzung technischer Berichte mit den Ergebnissen der Qualit\u00e4tssicherungsma\u00dfnahmen, wie z.B. Tests, Durchf\u00fchrung von Reviews und Inspektionen f\u00fcr den Nachweis von Fehlerfreiheit verantwortlich.<\/p>\n Die Ergebnisse von Aktivit\u00e4ten innerhalb des Entwicklungsprozesses werden als Artefakte bezeichnet. Bei der Erstellung des\u00a0Inkrements<\/strong>, welches in Scrum nur implizit genannt wird, bei Scrum QA jedoch als explizites Artefakt genutzt wird,\u00a0 ist darauf zu achten, dass etwaige Entwicklungsartefakte instrumentalisierbar sind, d.h. dass das Design durch geeignete Ma\u00dfnahmen f\u00fcr unterschiedliche Teststufen pr\u00fcfbar gemacht werden kann.<\/p>\n F\u00fcr die Nachverfolgbarkeit von der Anforderung bis zum Testergebnis \u2013 und letztendlich f\u00fcr eine erfolgreiche Zertifizierung \u2013 werden zus\u00e4tzliche\u00a0Dokumentationen<\/strong>\u00a0ben\u00f6tigt und in Scrum QA als Artefakt explizit genutzt. Die Erstellung geforderter, detaillierter Dokumentation widerspricht dabei teilweise dem Agilen Manifest, ist jedoch in normativ reguliertem Umfeld unumg\u00e4nglich. So werden durch Normen beispielweise Risikolisten oder Ergebnisdokumentationen von Tests funktionaler und nicht-funktionaler Anforderungen gefordert. Werden ferner spezifische funktionale Sicherheitsanforderungen gestellt, m\u00fcssen die Ergebnisse von Verifikation \u00a0(d.h. Nachweis der richtigen Erstellung des Entwicklungsergebnisses) und Validierungstests (d.h. Pr\u00fcfung des Entwicklungsergebnisses hinsichtlich Erf\u00fcllung der Anforderungen bez\u00fcglich beabsichtigter Nutzung) ebenso wie andere qualit\u00e4tssichernden Ma\u00dfnahmen in einem technischen Sicherheitsbericht zusammen mit sicherheitsrelevanten Kennwerten des Systems verkn\u00fcpft werden. Dieser Bericht dient dem durch den Product Owner beauftragten Gutachter als Basis f\u00fcr die Zertifizierung.<\/p>\n Im Rahmen dieses Beitrags wurde Scrum QA als eine Erweiterung von Scrum f\u00fcr die agile Entwicklung in normativ reguliertem Umfeld beschrieben. Durch Erweiterung der Aufgaben bereits existierender Rollen sowie der Einf\u00fchrung zus\u00e4tzlicher Rollen kann eine kontinuierliche agile Qualit\u00e4tssicherung und letztendlich eine erfolgreiche Zertifizierung sichergestellt werden.<\/p>\n Agile Teams in normativ reguliertem Umfeld ben\u00f6tigen eine hohe Testerfahrung und\u00a0 methodische Testexpertise, um die durch Normen geforderten Test(automatisierungs)-Strategien zu bestimmen und entsprechend der relevanten Normen und Richtlinien anzuwenden. Als wesentlich erweist sich dabei die durchg\u00e4ngige Sicherstellung der Testbarkeit von Design bis Realisierung. Aufgrund der Agilit\u00e4t des Vorgehens und der damit verbundenen erh\u00f6hten Kommunikation zwischen Beteiligten k\u00f6nnen Test-Management-Umgebungen schlanker gehalten werden; kontinuierliche Integration entwickelter L\u00f6sungskomponenten und durchg\u00e4ngiges Konfigurationsmanagement stellen wesentliche Eckpfeiler f\u00fcr die Dokumentation und Zertifizierung dar.<\/p>\n In der Praxis konnte positiv evaluiert werden, dass das in diesem Beitrag beschriebenes Vorgehen sowie damit verbundene Ma\u00dfnahmen einen positiven Einfluss auf eine effiziente Projektdurchf\u00fchrung mit erfolgreicher Zertifizierung aufweist. Als erfolgskritisch erwies sich dabei jedoch die geeignete Auswahl von Projektbeteiligten in Bezug auf der korrekten Ableitung und Auswahl von Ma\u00dfnahmen zur Qualit\u00e4tssicherung aus den zugrunde gelegten Normen sowie deren geeignete agile Evolution.<\/p>\n [1] Frank Simon, Manuel Fischer, Karin Vosseberg, Andreas Spillner, Kai Lepler und Mario Winter: „Management-Summary der GTB Softwaretestumfrage 2015\/2016“ , April 2016 Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Agil & Scrum.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Agil & Scrum steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nScrum QA-Prozess: Aktivit\u00e4ten im \u00dcberblick<\/h2>\n
Rollen und Verantwortlichkeiten im Scrum QA<\/h2>\n
Artefakte von Scrum QA<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n
Literaturverzeichnis<\/h2>\n
\n[2] Peter Hruschka und Chris Rupp: „Agile Softwareentwicklung f\u00fcr Embedded Real-Time Systems mit UML“, Carl Hanser Verlag M\u00fcnchen Wien, 2002.
\n[3] Andreas Spillner, Thomas Ro\u00dfner, Mario Winter und Tilo Linz: „Praxiswissen Softwaretest Testmanagement“, dpunkt.verlag, 4. Auflage, Mai 2014.
\n[4] Ken Schwaber und Jeff Sutherland: „Der Scrum Guide. Der g\u00fcltige Leitfaden f\u00fcr Scrum: Die Spielregeln“, Juli 2013.<\/p>\n
\nAgil & Scrum – unsere Trainings & Coachings<\/h2>\n
\nAgil & Scrum – Fachwissen<\/h2>\n