Software Quality Lab GmbH Gewerbepark Urfahr Linz Austria. info@software-quality-lab.com

Transkript

1

2 Software Quality Lab GmbH Gewerbepark Urfahr Linz Austria info@software-quality-lab.com Published by Software Quality Lab GmbH, January 2015 The editor does not accept any liability for the information provided. The opinions expressed within the articles and contents herein do not necessarily express those of the editor. Only the authors are responsible for the content of their articles. The editor takes pains to observe the copyrights of the graphics, audio documents, video sequences and texts used, to use his own graphics, audio documents, video sequences and texts, or to make use of public domain graphics, audio documents, video sequences and texts. Any trademarks and trade names possibly protected by third parties and mentioned are subject to the provisions of the respectively applicable trademark law and the property rights of the respectively registered owners without restriction. It cannot be inferred from the mere mention of trademarks alone that these are not protected by third-party rights! The copyrights for published materials created by Software Quality Lab GmbH remain the exclusive rights of the author. Any reproduction or use of graphics and texts (also excerpts) without explicit permission is forbidden. Der Herausgeber übernimmt keinerlei Gewähr für die bereitgestellten Informationen. Die in den Artikeln und Inhalten dargestellte Meinung stellt nicht notwendigerweise die Meinung des Herausgebers dar. Die Autoren sind alleine verantwortlich für den Inhalt ihrer Beiträge. Der Herausgeber ist bestrebt, in allen Publikationen die Urheberrechte der verwendeten Grafiken, Tondokumente, Videosequenzen und Texte zu beachten, von ihm selbst erstellte Grafiken, Tondokumente, Videosequenzen und Texte zu nutzen oder auf lizenzfreie Grafiken, Tondokumente, Videosequenzen und Texte zurückzugreifen. Alle genannten und ggf. durch Dritte geschützten Marken- und Warenzeichen unterliegen uneingeschränkt den Bestimmungen des jeweils gültigen Kennzeichenrechts und den Besitzrechten der jeweiligen eingetragenen Eigentümer. Allein aufgrund der bloßen Nennung ist nicht der Schluss zu ziehen, dass Markenzeichen nicht durch Rechte Dritter geschützt sind! Das Copyright für veröffentlichte, vom Autor selbst erstelltes Material bleibt allein beim Autor der Seiten. Eine Vervielfältigung oder Verwendung von Grafiken und Texten (aus auszugsweise) ist ohne ausdrückliche Zustimmung nicht gestattet.

3 CALL FOR PAPER 2016?!

4

5 Requirements Engineering wird als der wichtigste Erfolgsfaktor für Softwareentwicklungsprojekte betrachtet. Wesentlich dabei ist der Weg zu den Anforderungen. Die hier dargestellte U-Methode stellt ein Modell zur Anforderungsermittlung dar. In 7 Aktivitäten, die sich von der Theorie U von Otto Scharmer ableiten, erfolgt die Anforderungsermittlung bis hin zur Dokumentation. Ausgehend vom Downloading (Vergangenes ausgraben), über Seeing (Arbeitsumfeld beobachten) und Sensing (Perspektive wechseln) soll Presencing (kreativ sein) erreicht werden, um das Neue über Crystallizing (zukünftiges Bild entwickeln) und Prototyping (Neues erproben) nach Performing (Neues in die Welt bringen) zu bringen. Die erstmals 2007 in Buchform veröffentlichte Theorie U bezeichnet C. Otto Scharmer als Ergebnis seiner zehnjährigen Forschungsarbeit und Beratungstätigkeit. Der deutsche Titel des Buches impliziert ein Führungsbuch mit dem Ansatz, von der Zukunft her zu führen. Der englische Originaltitel ist hier genauer: Theory U. Leading From the Future as it Emerges. The Social Technology of Presencing. Führungskräfte handeln nicht aus einer noch nicht existenten Zukunft heraus. Sie sollen aber den Fokus auf die sich entwickelnde Zukunft legen und fähig werden, zukünftige Chancen zu erkennen und diese umzusetzen. Es geht um die Schärfung der diesbezüglichen Wahrnehmung und nicht um Spekulation, wie die Zukunft aussehen könnte. Aber nicht nur Führen sondern auch Lernen von der sich entwickelnden Zukunft und ihren Möglichkeiten steckt hinter diesem Ansatz. Es wird ein neues Lernen postuliert, das über das Lernen aus der Vergangenheit hinausgeht. Diese Form des Lernens nennt sich Presencing, d.h., als Anwesendwerden einer essenziellen Möglichkeit, als Ankünftigwerden eines zukünftigen Potenzials. (Scharmer, 2011) Ein weiterer Aspekt beleuchtet den Ursprung des Handelns. Ob Mitarbeitende oder Organisationen, beide handeln aus einer inneren Quelle heraus, derer sie sich aber oftmals nicht bewusst sind. Dies nennt sich der blinde Fleck. Das Erkennen dieses blinden Fleckes und der Umgang damit sind bedeutend für Veränderungsprozesse. Die Theorie U stellt eine soziale Technik dar, hinter der sich die Anleitung für einen Transformationsprozess [verbirgt], der die Menschen aus ihren Vergangenheitsmustern herausholt und sie öffnet für ein integriertes Denken, Fühlen und Wollen, das gemeinsam eine tragfähige Zukunft wachsen lässt. (Wimmer, 2011) Der U-Prozess Ausgehend von den Erfahrungen und Denkmustern aus der Vergangenheit (Downloading), über die Betrachtungsweise von außen (Seeing) wird in der Innensicht reflektiert (Sensing). Es wird nach der Quelle und Energie für das eigene Handeln geforscht (Presencing), um sich seiner gewünschten zukünftigen Situation bewusst zu werden (Crystallizing). Dies ist experimentell zu erforschen (Prototyping), und die neuen Handlungsweisen werden operativ im Tun ausgeübt (Performing). Abbildung 1 - Der U-Prozess nach Scharmer

6 Die U-Methode In Analogie zum U-Prozess von Scharmer stellt sich die U-Methode ebenfalls in U-Form dar. Um den Aspekt des Tuns zu unterstreichen, werden die sieben Phasen in der U-Methode Aktivitäten genannt. Die Bezeichnung der Aktivitäten erfolgt ident zum U- Prozess. Auch wenn die Anordnung der Aktivitäten im U sich wie ein Phasenmodell ausgibt, ist die U-Methode kein linearer Prozess mit der Abfolge Phase Meilenstein Phase. Meilensteine sind keine definiert. Die Aktivitäten können sich überschneiden oder nahtlos ineinander übergehen. Abhängig vom jeweiligen Projektkontext obliegt die Entscheidung dem Requirements Engineer, wie lange eine Aktivität dauert und welche Werkzeuge verwendet werden. Downloading, um Vergangenes auszugraben Scharmer geht von seinen Beobachtungen aus, dass Gespräche in meist stabilen oder gleichbleibenden Mustern verlaufen und nennt eines davon Downloading. Neben der Kommunikation, bei der nicht gesagt werde, was man wirklich denkt, reagiere man auf Vertrautes mit Gewohntem. Wir hören das, was dem Erwarteten entspricht. Wir sehen das, was unsere vorhandenen Urteile bestätigt oder ergänzt. Und das Handeln bleibt in den Mustern der Vergangenheit, wir reagieren. (Bösterling, 2009) Wenn es um die Neuentwicklung oder Ablöse eines Informationssystems geht, wünscht sich ein Kunde oftmals eine 1:1 Umsetzung der bestehenden Arbeitsabläufe. Andererseits soll das neue System genauso funktionieren wie das abzulösende. Dieses Verharren in einem vergangenheitsbezogenen Muster bedeutet Downloading im Sinne von Scharmer. Die Herausforderung liegt darin, dieses Muster durchbrechen zu können und den Kunden dabei aber nicht zu überfordern. In der U-Methode kommt es in dieser Aktivität zur Beschäftigung mit der Vergangenheit. Damit ist gemeint, dass zuerst nach allen verfügbaren Informationen gesucht wird und Stakeholder befragt werden. Es wird der Status quo ermittelt und erste Anforderungen abgeleitet. Seeing, um das Arbeitsumfeld zu beobachten Erst durch das Bewusstwerden der Muster der Vergangenheit ist der nächste Schritt zum Seeing (Hinsehen) möglich. Dabei ist es wichtig, eine Außensicht einzunehmen, um die Realität wahrzunehmen. Gleichzeitig wird die Wahrnehmung genauer. Das bedeutet aber auch, bewusst die gewohnten Gedankenmuster zurückzuhalten und mit offenen Augen hinzusehen. Für die U-Methode heißt dies, die Umgebung, in der das Informationssystem zum Einsatz kommt (spezifischer Kontext), wird betrachtet. Auf die relevanten Stakeholder und deren Abläufe wird vorurteilsfrei und neutral geblickt (innehalten). Durch die Sicht von außen, das heißt, durch die verwendeten Beobachtungswerkzeuge, kommt es Abbildung 2 - Die U-Methode und ihre Aktivitäten zu neuen Erkenntnissen und Verständnis für die Stakeholder. Wobei es wichtig ist, die Fragen, die sich aus dem Downloading ergehen haben, vor der Beobachtung festzuhalten (Klärung der Fragestellung). Sensing, um die Perspektive zu wechseln Durch die Weiterbewegung vom Seeing zum Sensing (Hinspüren) erweitert sich die Sichtweise zur ganzheitlichen Betrachtung. Die Grenze zwischen Beobachter und den Objekten der Beobachtung löst sich auf, es kommt zu einem Perspektiven-wechsel. Es kommt zum Spüren von innen. Drei Prinzipien sind für das Hinspüren hilfreich. Erstens erfolgt ein Eintauchen in das betrachtete Feld. Zweitens verschiebt sich die Aufmerksamkeit durch das Einnehmen einer abwechselnden Perspektive. Und drittens wird durch das Öffnen des Fühlens eine bessere Wahrnehmung aktiviert.

7 Das Wesentliche für die Aktivität Sensing in der U- Methode stellt der Perspektivenwechsel dar. Vom bisher Erfahrenen können sich dadurch Fragen aber auch neue Ideen ergeben. Der Requirements Engineer taucht tiefer in dem Sinne in die Materie ein, indem er auch auf seine Gefühle dabei achtet. Für Stakeholder ist diese Erfahrung ebenso wichtig. Auch sie sollen durch eine andere Perspektive ihre bisherigen Anforderungen und Wünsche hinterfragen und Neues zulassen lernen. Presencing, um kreativ zu sein Presencing ist der tiefste Punkt im U und stellt den Wendepunkt im U-Prozess dar. Das Wort setzt sich aus sensing (spürend, fühlend, wahrnehmend) und presence (Anwesenheit, Gegenwart) zusammen. Es geht um die Wahrnehmung, das Erspüren zukünftiger Möglichkeiten und den Transfer des dabei Entstehenden in die Gegenwart. Ist der Weg zum Presencing geglückt, ist der Zugang zur inneren Quelle als Ort der Kreativität und des Wissens möglich. Scharmer setzt dies auch mit künstlerischen Prozessen gleich. Das Loslassen alter Denkmuster ermöglicht erst Kreativität. Hier ist der Verknüpfungspunkt zur U-Methode. Presencing ist der Ort der Kreativität, wo neue Anforderungen mit kreativen Werkzeugen entstehen. Der Requirements Engineer muss über kommunikative und empathische Fähigkeiten verfügen, da diese für Kreativität erforderlich sind. Kreativität wird als sozialer Prozess verstanden. Die Zusammenarbeit mit Stakeholdern fördert das kreative Potential. Crystallizing, um das zukünftige Bild zu ent-wickeln Presencing hat den Zugang zum inneren Wissen geöffnet. Das neu Entstandene zeigt sich in der Gegenwart. Es verdichtet sich zu einem Bild der Zukunft. Dieses Bild ist aber mehr als eine Vision, die jederzeit entwickelt werden kann. Crystallizing (Verdichten) setzt den Durchgang durch die linke Seite im U voraus. Im Crystallizing fügen sich die bisher erhobenen Anforderungen zu einem zukünftigen Bild zusammen. Durch die vorgeschlagenen Werkzeuge ergibt sich für alle zukünftig Betroffenen die Möglichkeit, sich mit diesen Anforderungen auseinander zu setzen. Diese Beschäftigung mit dem bereits Ermittelten ergibt Änderungen an bestehenden oder neue Anforderungen. Der einbezogene Stakeholder-Kreis erweitert sich. Prototyping, um das Neue zu erproben Das zukünftige Bild aus dem Crystallizing wird experimentell erprobt. Dies geschieht durch Prototypen, an denen gelernt wird. Basis für dieses Lernen sind Rückmeldungen und die daraus resultierenden Änderungen. Diese Rückmeldungen sollen frühzeitig erfolgen und liefern auch Informationen, wie die Stakeholder zum Projekt stehen. Die Erprobung durch Prototypen erfolgt in Gruppen. Wichtig ist die jeweilige Zusammensetzung, das heißt, es benötigt die richtige Auswahl der beteiligten Personen. Eine Gruppe nur aus Experten kann gut Downloading betreiben. Es braucht aber Teilnehmende mit unterschiedlichen Sichtweisen und Betroffenheitsgraden. Die U-Methode verfolgt diesen Ansatz. Anhand von Prototypen holt der Requirements Engineer Feedback zu den prototypisch erprobten Anforderungen ein. Daraus können Verbesserungsvorschläge oder neue Anforderungen entstehen. Der Begriff Prototyping ist im Requirements Engineering ein geläufiger. Prototypen helfen Anforderungen zu ermitteln oder zu verbessern. Es findet auch ein Prüfen von Anforderungen statt. Im Sinne von Scharmer ist Prototyping immer experimentell und evolutionär. In der U-Methode werden Prototyping und diesbezügliche Werkzeuge nach dem Aspekt der Verwendbarkeit betrachtet. Performing, um das Neue in die Welt zu bringen Was im Presencing sich zu entwickeln begann, tritt nun im Performing in die Welt ein. Performing bedeutet somit In die Welt bringen Vom Ganzen her handeln. (Scharmer/Käufer, 2008) In der U-Methode bedeutet dies den Übergang von der Anforderungsermittlung zur Anforderungsdokumentation. Das ersichtliche Ganze stellt die Summe der vorliegenden Anforderungen dar. Dies ist die Basis für die Anwendung von Anforderungsschablonen. Das größere Feld entsteht dadurch, dass die Anforderungen sich nicht mehr alleine im Stakeholder-Umfeld befinden, sie werden nun auch anderen Personenkreisen zugänglich (z.b. externe Dienstleister, internes Auftragsbüro u.a.). Werkzeuge zur U-Methode Zur Auswahl der Werkzeuge ergeben sich zwei Anhaltspunkte. Zum einen hat Scharmer Werkzeuge für den U-Prozess entwickelt. Auf der anderen Seite setzt der Lehrplan der IREB zum CPRE, Elicitation and Consolidation, Advanced Level, Kenntnisse diverser Werkzeuge voraus.

8 Abbildung 3 - Die Werkzeuge zur U-Methode Der Einsatz der Werkzeuge erfolgt situativ und benötigt auch eine entsprechende Anweisung und Einführung der Teilnehmenden. Das jeweilige Werkzeug ist zu erklären und auszuführen, was damit bezweckt wird. Wimmer, R.: Die Steuerung des Unsteuerbaren, in Pörksen, B. (Hrsg.): Schlüsselwerke des Konstruktivismus, Wiesbaden 2011, S weiterführende Literatur siehe auch unter Literaturverzeichnis Bösterling, B.: Theorie U und Presencing im Großgruppenformat, Hannover Scharmer, C.O.: Theorie U: Von der Zukunft her führen. Presencing als soziale Technik, 2. erw. Aufl., Heidelberg Scharmer, C.O./Käufer, K.: Führung vor der leeren Leinwand. Presencing als soziale Technik, in: OrganisationsEntwicklung, 27 (2008), 2, S Günter Köllemann, MAS Günter Köllemann ist seit 2001 in der Informatikabteilung beim Amt der Vorarlberger Landesregierung beschäftigt. Als Projektleiter verantwortet er die Entwicklung neuer Fachanwendungen und deren Betreuung. Er beschäftigt sich seit 2004 mit dem Thema Requirements Engineering. guenter@koellemann.net

9 Agile Methoden ermöglichen es, besser mit sich ändernden Anforderungen umzugehen und die Erwartungen der Kunden genauer zu treffen. Der Schlüssel zum Erfolg liegt auch hier in guten Anforderungen. Dafür können Anforderungstechniken aus der agilen und der klassischen Welt zum optimalen Set kombiniert werden. Die Gliederung des klassischen Requirements Engineerings in Ermittlung, Dokumentation, Prüfung und Verwaltung ist ein guter Leitfaden, um auch in agilen Projekten Requirements Engineering zu etablieren oder zu verbessern. Methoden wie Use Cases und Review-Techniken können in agilen Projekten ergänzend eingesetzt werden, wenn mehr Struktur und Information benötigt wird. 71% aller Softwareunternehmen setzen agile Methoden in der einen oder anderen Form ein. 58% von ihnen tun dies, weil sie so einfacher mit sich ändernden Prioritäten und Anforderungen umgehen können [1]. In vielen agilen Teams ist jedoch der Umgang mit Anforderungen noch nicht ausreichend klar und sicher. Allzu oft wird versucht, alles über User Stories abzubilden, ganz nach dem Motto If the only tool you have is a hammer, every problem looks like a nail. In vielen Projekten ist aber mehr und strukturiertere Information zu den Anforderungen notwendig. Das führt zu Problemen in der Kommunikation zwischen den agilen Teams und den Stakeholdern in den Fachabteilungen. Diese haben oft schon recht gute Vorstellungen, was sie brauchen und möchten das auch vollständig und strukturiert mitteilen. Auf der anderen Seite wünschen sich agile Teams immer wieder mehr Unterstützung und Struktur beim Ermitteln und Dokumentieren der Anforderungen. User Stories alleine reichen dafür nicht aus. Hier hilft eine pragmatische Herangehensweise, in der das Team selbst entscheidet, welche Methoden aus der agilen und klassischen Welt am besten passen. Klassisches Requirements Engineering gliedert sich in vier Haupttätigkeiten: Anforderungen ermitteln, dokumentieren, prüfen und abstimmen und verwalten. Sind diese Hauptaufgaben auch in agilen Methoden relevant? Ja! Sie werden aber sinnvollerweise mit anderen Methoden und Techniken durchgeführt. Ebenso gibt es auch in agilen Projekten einen Requirements Engineer, der für die Anforderungen verantwortlich ist, nämlich den Product Owner. Mit über 97% Marktanteil [1] ist Scrum die am meisten eingesetzte agile Vorgehensweise. Im Folgenden werden daher Rollen, Methoden und Artefakte aus Scrum stellvertretend für agile Methoden genannt. Der Product Owner ist für die Anforderungen und deren Priorisierung verantwortlich. Er schreibt die Anforderungen und trifft als deren Besitzer alle inhaltlichen Entscheidungen in Abstimmung mit den Fachexperten und anderen Stakeholdern. Er sorgt dafür, dass ständig ausreichend Requirements bereit für die Umsetzung sind und das Team kontinuierlich arbeiten kann. Vor jeder Iteration reiht er die Anforderungen und bereitet diejenigen, die umgesetzt werden sollen, dafür vor [3]. Abb. 1.: Wie passen klassisches Requirements Engineering und Agile Methoden (z.b. Scrum) zusammen?

10 Ermitteln von Anforderungen bedeutet, die Anforderungen der relevanten Stakeholder zu erkennen und im benötigten Detaillierungsgrad zu erheben [2]. In agilen Projekten passiert dies nun nicht auf einen Schlag zu Beginn des Projektes, sondern über das gesamte Projekt verteilt. Vor Beginn der Umsetzung wird ein Überblick über die wesentlichen Anforderungen erarbeitet und in einem Backlog aufgelistet. In der Folge werden nur die jeweils in den nächsten 1-2 Iterationen umzusetzenden Anforderungen genauer spezifiziert. Laufend definiert also der Product Owner in der aktuellen Iteration die Anforderungen für die nächsten 1-2 Iterationen. So wird verhindert, dass Aufwand in die Detailspezifikation von Dingen gesteckt wird, die dann vielleicht gar nicht umgesetzt werden. Anforderungen viel leichtgewichtiger erfolgen. 51% aller agilen Teams verwenden User Stories mit Akzeptanzkriterien zur Repräsentation der Anforderungen [1], die genauen Details werden dann mündlich zwischen Product Owner und Team ausdefiniert. Ist es im Projekt erforderlich, entscheidet das Team selbst, ob es zusätzlich noch weitere Spezifikationsartefakte benötigt. Gründe hierfür können sein, dass die Anforderungen sehr komplex sind, dass das Team über mehrere Standorte verteilt ist, die Bearbeitung der einzelnen Anforderungen noch weit in der Zukunft liegt, der Kunden dies einfordert u.ä. Je nach Bedarf können dies Elemente aus der agilen Welt sein wie Abb. 2: Je weiter weg die Umsetzung, desto gröber wird spezifiziert. Nur unmittelbar bevorstehendes wird genau ausdefiniert [3]. Je nach Team und Risiko wird dabei nicht alles schriftlich festgehalten, sondern vieles wird nur mündlich zwischen Product Owner und Team vereinbart, sofort umgesetzt und vom Product Owner begutachtet. Epics und Themes: Zur Zusammenfassung mehrerer User Stories zu einem Thema Features: Zur Gliederung der User Stories aus Kunden bzw. Marketing-Sicht Personas: Zur Beschreibung der Anwendergruppen Eine schriftliche Dokumentation benötigt man immer dann, wenn unterschiedliche Teilnehmer mit den Anforderungen arbeiten müssen und diese Arbeit zeitlich und räumlich stark zersplittert ist. In agilen Projekten versucht man, diese Zersplitterung möglichst zu vermeiden. Das Team und auch der Product Owner arbeiten am selben Ort und ständig gemeinsam am Projekt. Dadurch kann die Dokumentation der Oder aber Elemente aus dem klassischen Requirements Engineering, wie Use Cases: Zur genaueren Beschreibung der Interaktion zwischen Anwender und System Modell: Zur grafischen Darstellung von Abläufen, Datenstrukturen und -Flüssen etc. UI Mockups: Zur Visualisierung der zukünftigen Benutzerschnittstelle

11 Datenbeschreibungen: Für Schnittstellen und Datenstrukturen Ein Use Case (Anwendungsfall) beschreibt immer eine Interaktion mit dem System, die für sich einen Nutzen für den Akteur liefert. Im einfachsten Fall besteht der Use Case nur aus einem Titel, der Angabe der wichtigsten Schritte und den wesentlichen Akzeptanzkriterien. Der Titel kann dabei wie eine User Story formuliert werden: Abb. 3.: Unterschiedliche Artefakte werden je nach Notwendigkeit im Projekt eingesetzt Ziel ist es, das Set an Artefakten zu finden, mit dem das Team am besten arbeiten kann. Gerade Use Cases können in agilen Projekten sehr gut eingesetzt werden. Reduziert man sie auf die wesentlichen Attribute, so ist die Erstellung wenig Aufwand, der Gewinn an Information aber sehr hoch. Markus Unterauer Markus Unterauer arbeitet seit 2012 bei Software Quality Lab als Berater und Trainer. Er ist zertifizierter Scrum Master und hat sich auf die Bereiche Softwareprozesse und Anforderungsmanagement spezialisiert

12 Bedrohungsmodellierung ist eine Aktivität innerhalb des Application Security Managements, die das frühzeitige Erkennen, Bewerten und Behandeln von Sicherheitsproblemen in Softwarearchitekturen ermöglicht. Dadurch kann die Qualität einer Software bereits in der Design-Phase signifikant verbessert werden, was in den späteren Entwicklungsphasen die Kosten zur Behebung von Schwachstellen verringert. Darüber hinaus liefert ein Bedrohungsmodell auch wertvolle Informationen über vorgelagerte und nachfolgende Sicherheitsaktivitäten. In der heutigen Zeit ist es für Unternehmen mit schutzwürdigen Assets oftmals eine Selbstverständlichkeit, ein Informationssicherheitsmanagement (ISMS) nach BSI-Grundschutz, ISO oder vergleichbaren Standards umzusetzen. Dabei wird das Thema Anwendungssicherheit zwar berücksichtigt, die letzten Jahre haben aber gezeigt, dass in der Praxis erfolgreiche Angriffe auf unsichere Anwendungen nach wie vor massive Schäden nach sich ziehen. Die klassischen Security-Management-Prozesse sowie die Standard-Controls sind für sich alleine nicht ausreichend, um das notwendige Sicherheitsniveau von Anwendungen zu erreichen. Daher ist es notwendig das Management der Sicherheit seines Anwendungsportfolios zu überdenken und Application Security Management (ASM) Prozesse in die eigene Prozesslandkarte zu integrieren. Application Security Management (ASM) beschreibt die notwendigen Prozesse und Richtlinien um sicher zu stellen, dass innerhalb einer Organisation alle Anwendungen und die zugehörigen IT-Systeme entsprechend der Wichtigkeit und Kritikalität der involvierten Geschäftsprozesse beschafft, entwickelt und betrieben werden. Es wird dabei auf der einen Seite das gesamte Applikationsportfolio adressiert, auf der anderen Seite wird auch die übergeordnete Security- Governance berücksichtigt, die die Rahmenbedingungen für den sicheren Betrieb von Anwendungen definiert. Das Management-System lässt sich nahtlos in ein bestehendes ISMS nach ISO integrieren. Dadurch wird sichergestellt, dass Sicherheitsinvestitionen zielgerichtet und angemessen erfolgen. Neben den Grundlagen zur sicheren Softwareentwicklung und zum sicheren Betrieb werden auch alle Support- Prozesse berücksichtigt, die im Lebenszyklus benötigt werden. Application Security Management hilft dabei, Richtlinien und Regeln in allen Bereichen festzulegen und dazugehörige Methoden zu etablieren, die den Sicherheitsstandard des Applikationsportfolios des Unternehmens verbessern. Der Schutz von Daten vor Diebstahl, Vernichtung oder Veränderung steht dabei im Vordergrund. Auf lange Sicht wird dadurch die Reputation eines Unternehmens geschützt, Einkommensverluste durch Sicherheitsvorfälle minimiert und dadurch die Vertrauenswürdigkeit aufrechterhalten. Aktivitäten und Prozesse des ASM Der Überbau eines gut funktionierenden Application Security Managements sind die Governance Prozesse. Hier wird die Security-Strategie festgelegt, das richtige Personal den richtigen Aufgaben zugewiesen und die Qualitätsvorgaben nicht nur erstellt sondern auch gemessen. Des Weiteren wird in diesem Bereich auch das Anwendungsportfolio erstellt und verwaltet. All dies stellt den Überbau der anwendungsspezifischen Security-Aktivitäten dar und ergänzt, verfeinert bzw. erweitert bestehende ISMS-Prozesse. Neben diesen Management-Prozessen besteht das Application Security Management noch aus zahlreichen weiteren Aktivitäten, die individuell für jede Anwendung gestaltet werden müssen. Die jeweilige Ausprägung der Aktivität bzw. die Entscheidung über deren Notwendigkeit, hängt stark vom Schutzbedarf der jeweiligen Anwendung ab. Diese Aktivitäten lassen sich in vier Bereiche Gliedern: Demand Management Planning & Development Roll-Out Operations Im Scope der Security-Aktivitäten befinden sich somit alle relevanten Bereiche aus Beschaffung, Entwicklung und Betrieb sicherheitskritischer Anwendungen. Abbildung 1 zeigt die gesamte Prozesslandkarte des Application Security Managements.

13 Abbildung 1 - Prozesslandkarte des Application Security Managements

14 Eine wichtige Aktivität des ASM stellt die Bedrohungsmodellierung dar. Bedrohungsanalysen werden mit dem Ziel durchgeführt, sicherheitsrelevante Aspekte einer Architektur zu bewerten, Bedrohungen frühzeitig zu identifizieren und konkrete Verbesserungsvorschläge für die Implementierung und den Betrieb zu erarbeiten. Mit der Umsetzung der Sicherheitsmaßnahmen soll das Restrisiko auf ein akzeptables Maß reduziert werden. Neben der Reduktion potentieller Schwachstellen kann eine Bedrohungsmodellierung unter anderem durch die nachfolgenden Aspekte die Qualität und damit auch die Sicherheit im Software-Entwicklungsprozess verbessern: Identifizierung von logischen Problemen und Designfehlern Überprüfung der Einhaltung von Sicherheitsanforderungen und Vorgaben an die Architektur Identifizierung sicherheitskritischer Komponenten der Architektur Verbesserung der Planbarkeit und Qualität von Sicherheitstests Bedrohungsmodellierung als Bindeglied zwischen Risikomanagement und technischer Implementierung Ergebnisse als Entscheidungsgrundlage für Sicherheitsaktivitäten Schulung der Mitarbeiter und Weiterentwicklung bestehender Richtlinien und Vorgaben Reduktion der Kosten zur Behebung von implementierten Schwachstellen Rund um das Thema Bedrohungsmodellierung existieren inzwischen zahlreiche praktische und wissenschaftliche Methoden, die sich im Wesentlichen jedoch alle an einem risikomanagement-basierten Prozess orientieren. Generell sollte die Erstellung eines Bedrohungsmodells bereits in der Design Phase erfolgen, da dort verursachte Fehler in der Regel am schwersten zu beheben sind. Solche Fehler können im späteren Entwicklungsprozess einen erheblichen Kostenfaktor bedeuten. Identifikation von Assets und Akteuren In einem ersten Schritt werden schützenswerte Assets, beispielsweise Kundendaten, identifiziert. Diese Assets bilden die Grundlage für die nachfolgende Sicherheitsbetrachtung und sollten anhand der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit identifiziert werden. Anschließend werden involvierte Akteure (reguläre Benutzer und potentielle Angreifer) und deren Berechtigungen identifiziert, welche eine entscheidende Rolle bei der Identifizierung potentielle Bedrohungen spielen. Eine Unterscheidung kann dabei vom anonymen Angreifer aus dem Internet bis hin zum Softwareentwickler getroffen werden. Abhängig von den definierten Akteuren müssen in der Folge unterschiedliche Bedrohungen berücksichtigt werden. Dokumentation der Architektur Ausgehend von bestehender Softwaredokumentation (Architekturdiagramme, User-Stories, Datenhaltungsdiagramme, etc.) wird eine High-Level Architektur erstellt. In dieser Architektur werden sicherheitsrelevante Elemente der Software dokumentiert. Dazu zählen: Zugriffspunkte: Zugriffspunkte (engl. Entry Points) sind Interfaces, über die mit der Applikation interagiert werden kann. Um die Bedrohung für diese Schnittstellen bewerten zu können, müssen diese Punkte mit den zuvor definierten Akteuren der Software verknüpft werden. Externe Abhängigkeiten: Applikationen werden selten als Insellösungen konzipiert, sondern kommunizieren mit verschiedensten anderen Systemen. Um eine Aussage über Datenherkunft und Zugriffe treffen zu können, ist es wichtig solche externen Abhängigkeiten zu dokumentieren. Sicherheitsannahmen: Getroffene Sicherheitsannahmen können einen potentiellen Schwachpunkt in einer Applikation darstellen, da an diesen Stellen ein gewisses Vertrauen in die Architektur bzw. gewisse Komponenten gegeben ist. Deshalb ist es wichtig diese Annahmen zu dokumentieren und entsprechende Prüfungskriterien dafür zu definieren. Erfolgt eine solche Definition nicht, so können beispielsweise neue Softwarefeatures zu erheblichen Sicherheitsproblemen führen. Datenflüsse: Um die Auswirkungen einer identifizierten Bedrohung ermitteln zu können, muss dokumentiert werden, wo die zuvor definierten Assets innerhalb der Architektur gespeichert, verarbeitet und übertragen werden. Vertrauensgrenzen: Sobald alle genannten Komponenten miteinander verknüpft wurden, wird das Modell um Vertrauensgrenzen (engl. Trust- Boundaries) erweitert. Vertrauensgrenzen stellen Punkte in der Architektur dar, an denen Komponenten Informationen austauschen, aber nur eine eingeschränkte Vertrauensbeziehung besteht (z.b. zwischen Benutzer und Webserver). Konkret muss an diesen Grenzen eine strenge Datenvalidierung sowie Authentisierung und Autorisierung erfolgen.

15 Zur Darstellung der Architektur wird zumeist die folgende Syntax verwendet: Element Symbol Beschreibung Prozess Prozessgruppe Externe Entität Datenspeicher Datenfluss Vertrauensgrenze Tabelle 1: Architektur - Syntax Mit einem Prozess wird eine Aktion innerhalb des Systems dargestellt, mit der Daten verarbeitet werden. Um die Komplexität der einzelne Diagramme zu reduzieren, sollten Prozesse zusammengefasst und schrittweise detaillierter analysiert werden. Eine externe Entität ist eine Instanz, die außerhalb des eigentlichen Systems liegt und mit ihm interagiert. Externe Entitäten sind entweder Ziel oder Quelle von Daten, und können sowohl Personen als auch externe Systeme darstellen. Ein Datenspeicher ist für die Speicherung der Daten zuständig (z.b. Datenbank, Registry, Filesystem). Datenflüsse zeigen an, zwischen welchen Komponenten Daten ausgetauscht werden und in welche Richtung sich diese bewegen. Eine Vertrauensgrenze (engl. Trust-Boundary) tritt an Stellen in der Architektur auf, an denen zwei Komponenten Informationen austauschen, aber nur eine eingeschränkte Vertrauensbeziehung besteht. Identifikation von Bedrohungen In der wichtigsten Phase der Bedrohungsmodellierung werden potentielle Bedrohungen für die Architektur betrachtet. Da es zu keinem Zeitpunkt möglich ist, alle potentiellen Angriffe zu betrachten, empfiehlt es sich an dieser Stelle vorgefertigte Bedrohungskataloge zu verwenden bzw. eine Analyse nach Angriffsmustern durchzuführen. Eine bekannte Klassifizierung, die sich für eine erste grobe Betrachtung eignet, stellt das von Microsoft entwickelte STRIDE Modell dar. Es definiert Angriffsmuster anhand bekannter Schutzziele und ermöglicht eine schnelle und einfache Betrachtung der Architektur ohne auf konkrete Bedrohungen und Angriffsvektoren einzugehen. Bedrohung Spoofing Tampering Repudiation Information Disclosure Denial of Service Elevation of Privilege Tabelle 2: STRIDE Schutzziel Authentifizierung Integrität Nicht-Abstreitbarkeit Vertraulichkeit Verfügbarkeit Autorisierung Bewertung von Bedrohungen Um zur Verfügung stehende Ressourcen sinnvoll und zielgereichtet einsetzen zu können, ist es notwendig zuvor identifizierte Bedrohungen zu bewerten. In der Folge ist es dadurch möglich, den Fokus auf kritische Punkte der Applikation zu legen. Abbildung 2 - Beispiel einer einfachen Sicherheitsarchitektur

16 Definition von Maßnahmen In dieser letzten Phase werden Maßnahmen für erkannte Bedrohungen ermittelt. Geplante Maßnahmen müssen in einer weiteren Iteration des Bedrohungsmodells berücksichtigt werden, da diese auch Veränderungen an der Architektur mit sich bringen können. Bedrohungsmodellierung ist ein Werkzeug im Softwareentwicklungsprozess, das eine proaktive Identifizierung, Vermeidung bzw. Behandlung von Bedrohungen und potentiellen Sicherheitslücken ermöglicht. Des Weiteren ist eine Bedrohungsmodellierung die einzige Aktivität, mit der sicherheitsrelevante Designfehler erkannt und adressiert werden können. Durch die frühzeitige Erkennung können Kosten für die Behebung von Schwachstellen reduziert werden und gleichzeitig eine Aussage über das Sicherheitsniveau einer Applikation getroffen werden. Auf Basis der Modellierung können Gegenmaßnahmen und Testanforderungen abgeleitet werden, was zur Verbesserung der Planbarkeit, Abdeckung und Qualität der Sicherheitstests beiträgt. BSI Leitfaden zur Entwicklung sicherer Webanwendungen (2013) banwendungen/index_htm.html Adam Shostack (2014): Threat Modeling. Designing for Security. John Wiley & Sons. Michael Howard, Steve Lipner (2006): The security development lifecycle: SDL, a process for developing demonstrably more secure software. Microsoft Press, Redmond, Washington OWASP (2010): Threat Risk Modeling. Martin Niederwieser, MSc. Martin Niederwieser ist als Security Consultant bei der Firma SEC Consult Unternehmensberatung GmbH ( tätig. Seine fachlichen Schwerpunkte liegen in den Bereichen Application Security Management, Risikomanagement und ISMS. m.niederwieser@sec-consult.com

17 What it means to build quality software has taken a beating over the years. Now with the rise of more Agile ways of thinking, we ve placed the notion of a software requirement under the microscope. What is new is calling out five DevOps constraints as such and putting them in a set that is analogous to the project management Iron Triangle. Furthermore, as DevOps practices mature, teams are likely to want to maintain resilience, continuous testing, and continuous integration and delivery. What it means to build quality software has taken a beating over the years. We re no longer content to strive for defect-free code. We must also make sure the software meets both its functional and nonfunctional requirements. Only now with the rise of more Agile ways of thinking, we ve placed the notion of a software requirement under the microscope, as building flexible, resilient software often trumps checking items off our requirements list. As a result, the tried and true Project Management Iron Triangle has taken its lumps. We ve been trying to bend or rework the Iron Triangle for years, with limited success. Today, thanks to DevOps and Agile Architecture, we finally can. You remember the Iron Triangle: vertices at scope, cost, and time. Any project might fix two, but the third must be allowed to vary. Inadvertently fix all three? Then quality suffers an unacceptable result. Figure 1: The Iron Triangle We ve tried adding quality to the triangle over the years to let us fix the other three constraints, turning it into the Project Diamond, but that move was a rather academic exercise. After all, you can t go to your boss and say we delivered on all the requirements on time and on budget, but sorry, it just doesn t work! People insisted on taking quality as a given, and lived with the triangle as-is. Other additions to the triangle: The Project Management Body of Knowledge (PMBOK) added risk to the triangle helping to expand it to a six-pointed star. Risk, however, is more than a project constraint, as there are many types of risk. In addition to the risk of violating any individual constraint, there are also systemic risks like opening a security hole or violating a regulation. Adding risk, therefore, muddies the purpose of the triangle. The Agile world also contributed a variation of the triangle with Jim Highsmith s Agile Triangle. Highsmith collapsed all the constraints into a single vertex, and differentiated value from quality to populate the other two corners. Quality, according to Highsmith, represents the current quality of the project while value represents future quality can the product continue to deliver value in the future?, according to Highsmith. He explains: responding to the unanticipated future requires adaptability, and the key to adaptability is keeping technical debt low. In other words, software value depends upon its adaptability, and adaptability depends upon lowering technical debt. Highsmith makes some important points, but by collapsing the traditional Iron Triangle constraints, he doesn t provide a clear explanation for how to balance quality, value, scope, cost, and time and now with added implicit constraints of adaptability and technical debt, the resulting model isn t all that useful. There is also widespread confusion about the challenges of both inherent flexibility and good technical debt (be sure to read my discussion of technical debt, if you haven t already). Remember that Hightower ties inherent flexibility to value a critical connection for any Agilist to remember. However, he inadequately addresses the connection between adaptability and technical debt, jumping to the conclusion that keeping technical debt low is always a good thing. In fact, careful and temporary acquisition of technical debt, just like the careful borrowing of money that generated the metaphor is in reality an essential part of Agile development. In my 2013 book The Agile Architecture Revolution, I took a different, but similar approach to extending the Iron Triangle by adding agility to the mix as an explicit constraint, turning the triangle into the Agile Architecture (AA) Quality Star below.

18 Figure 2: The Agile Architecture Quality Star The move to DevOps also introduces additional constraints to our burgeoning Iron Polygon, as individual projects become less distinct. In an environment focused on continuous automated testing as well as continuous integration and deployment, individual iterations become the project unit as organizations establish regular cadences of repeated iterations instead of the discrete, monolithic project releases that characterize traditional waterfall-oriented development. Rethinking the Iron Triangle in terms of DevOps cadences instead of software projects changes everything, as it brings the entire discussion up a level, as shown in the diagram below. In fact, each neighboring pair of constraints on the AA Quality Star leads to a new constraint. In the figure above, the traditional Iron Triangle continues to represent the scope/cost/time tradeoff, while an additional triangle the agility/quality/time Best Effort Triangle represents a separate tradeoff: the more time you devote to quality, the less agile you become. The point to the AA Quality Star is to elevate agility to the status of a metarequirement and thus a constraint to the project, which in turn requires us to rethink how we deal with quality when agility is a priority. While Highsmith s value constraint and my agility constraint both recognize that the ability for software to be inherently flexible that is, the ability to respond to future requirements as well as current ones is an important added constraint to any software that claims to be Agile, neither of us fully explored the fact that inherent flexibility and resilience are actually two separate constraints. Inherent flexibility supports an organization s desire to be more innovative and responsive, which are two of the three elements of business agility. The third element is resilience: the ability to recover from adverse events. In the past, we typically took a brute force approach to building resilience into our software by hammering on it until it passed its performance tests and then hoping it wouldn t break in production. Today, however, we have a deeper understanding of resilience, as cloud computing has forced us to rethink how we deal with failure. It s no longer adequate to build software with the goal of preventing failure. Rather, we must build software that automatically recovers from failure. Expecting and planning for failure, including the graceful degradation of functionality should faults develop what we might call Chaos Monkey Engineering is an essential part of building software that supports the business agility driver. Figure 3: Applying the DevOps Context to the AA Quality Star Scope and agility connect to drive inherent flexibility. Agility and quality lead to resilience. Quality and cost factor into continuous testing. Cost and time drive continuous integration and deployment. And finally, time and scope connect to form the fifth new constraint, technical debt not the bad kind where time constraints lead to sloppy code, but the good kind where the team intentionally introduces shortcuts or missing functionality into the current iteration as part of the overall cadence. Essentially, DevOps doesn t allow us to formally discard the Iron Triangle, but it does let us do an end run around it. Remember, the Iron Triangle says that for a particular project, scope, cost, and time must balance. In contrast, the DevOps way of thinking says don t think about particular projects any more. Instead, think about the cadence. If we can shift elements of scope, cost, and time forward or backward in our cadence a concept that doesn t make sense in Iron Triangle terms we can build better, more flexible software overall. Let us therefore put away the Iron Triangle as well as the AA Quality Star, and introduce the DevOps Drumbeat, shown in the figure below.

19 Figure 4: The DevOps Drumbeat Every cadence consists of drumbeats that set the overall pace of the effort within the context of the constraints in the diagram above. For each drumbeat possibly an individual sprint or other iteration, or perhaps a finer-grained measure the DevOps team must balance the five constraints. This article may be introducing the phrase DevOps Drumbeat, but obviously many of the ideas included in the figure above aren t new. What is new is calling out the five DevOps constraints as such and putting them in a set that is analogous to the Iron Triangle. We re also taking the novel step of representing the drumbeat as a circle, rather than a polygon. After all, DevOps should have no corners! Furthermore, as DevOps practices mature, teams are likely to want to maintain resilience, continuous testing, and continuous integration and delivery. As a result, for each drumbeat, the tradeoff will be between inherent flexibility and good technical debt. This tradeoff is at the heart of Agile software architecture, as the Agile architect (or team members contributing to the Agile architecture role) must decide how much technical debt to take on in order to build inherent flexibility into their software. Placing this decision into the context of the organization s agility-driven digital transformation priorities is a fundamental challenge that Bloomberg Agile Architecture addresses. Want to know more? Drop me a line. The Project Diamond: #mediaviewer/File:PM_DiamondModel.jpg PMBOK Project Star: Beyond Scope, Schedule, and Cost: The Agile Triangle, by Jim Highsmith: Architecture Technical Debt: The Curse of Agile by Jason Bloomberg: The Agile Architecture Revolution by Jason Bloomberg: The Metarequirement of Agility, by Jason Bloomberg: Deconstructing Agile, by Jason Bloomberg: Innovation: The Flip Side of Resilience, by Jason Bloomberg: How to Deal with the Fear of Innovation, by Jason Bloomberg: Failure is the Only Option, by Jason Bloomberg: Agile Enterprise Architecture Finally Crosses the Chasm, by Jason Bloomberg Develop on Cadence, Release on Demand by Scaled Agile Framework, Bloomberg Agile Architecture, The Project Management Iron Triangle: Jason Bloomberg, President, Intellyx Jason Bloomberg is the leading industry analyst and expert on achieving digital transformation by architecting business agility in the enterprise. He is president of Intellyx. jason@intellyx.com

20 Eine kontinuierlich steigende Produktkomplexität gepaart mit immer kürzer werdenden Entwicklungszyklen ist im Moment eine der größten Herausforderungen in der Automobilindustrie. Um dieses Dilemma zu lösen bedarf es neuer Ansätze welche die Effizienz, bei zumindest gleichbleibender Qualität, gravierend steigern. Aber wie auch immer diese Ansätze heißen oder aussehen mögen, der Schlüssel des Problems liegt in der Motivation und im Engagement jedes einzelnen Mitarbeiters. Ansatz, welcher sowohl auf die Maslowsche Pyramide [1] als auch auf McGregors Theory X & Theory Y [2] aufsetzt, wurde von Daniel Pink [3] definiert. Nach Pink s Auffassung gibt es drei Faktoren welche die Motivation, ins besondere von Wissensarbeitern, definieren: Autonomy Mastery Purpose Im Bereich der Softwareentwicklung erhalten agile Methoden gerade sehr viel Aufmerksamkeit. Die Vorstellung flexibler auf Kundenwünsche reagieren zu können und gleichzeitig Effizienz und Qualität zu verbessern klingt sehr verlockend. Besonders im Embedded Systems Bereich, in dem Qualität meistens ein entscheidender Faktor ist und Entwicklungszyklen sich über mehrere Jahre erstrecken können, sollten diese Ansätze, sofern sie funktionieren, gravierende Verbesserungen mit sich bringen. Die Fragen die sich nun stellen sind, ob agile Entwicklungsansätze für die Systementwicklung (bestehend aus mehreren Disziplinen, z.b.: SW, HW, ME) nun geeignet sind, ob man Grundsätze oder einzelne Teile davon adaptieren kann, und ob es nicht vielleicht noch andere Ansätze gibt welche passender erscheinen. In einem ersten Schritt wird die ursprüngliche Fragestellung genauer definiert. Das Ziel, welches es zu erreichen gilt, besteht darin die Qualität und Effizienz der Arbeit zu steigern. Es ist allgemein bekannt, dass die Motivation und das Engagement der Mitarbeiter die größten Einflussfaktoren für hochwertige und produktive Arbeit sind. Wenn man dies nun um die Annahme erweitert, dass Spaß an der Arbeit die Motivation und das Engagement steigern, ist das Ziel bzw. die Vision nun definiert. Im nächsten Schritt stellt sich die Frage wie man Spaß an der Arbeit erzielen kann bzw. welche Einflussfaktoren dabei eine Rolle spielen. Ein wissenschaftlicher Ansatz hierzu ist die Motivationstheorie. Ein neuer Autonomy: Der Mitarbeiter hat Entscheidungsfreiheit bezüglich seiner Arbeit. Dies bedeutet, dass (technische) Entscheidungen selbst getroffen werden und zumindest ein Mitspracherecht darüber besteht, wie die Aufgaben zu erledigen sind. Mastery: Der Mitarbeiter kann sich immer weiter verbessern um ein Experte auf seinem Gebiet zu werden. Purpose: Der Mitarbeiter sieht einen tieferen Sinn in der Tätigkeit und wird dadurch intrinsisch motiviert. Die Bezahlung ist zwar ein Faktor aber nicht mehr der eigentliche Antrieb. Eine weitere Theorie welche sich mit Mitarbeitermotivation und dem Zustand bestmöglicher Arbeit beschäftigt ist die Flow Theorie von Mihály Csíkszentmihályi [4]. Unter bestimmten Bedingungen ist es möglich in den Flow Zustand zu kommen in welchem man sowohl die Umgebung als auch die Zeit aus den Augen verliert und sich mit kompletter Aufmerksamkeit einer Aufgabe widmet. Folgende Kriterien sollen unterstützend wirken um diesen Zustand zu erreichen: Die Aufgabe ist klar definiert Der Weg ist grundsätzlich bekannt Der Fortschritt ist erkennbar Die nächsten Schritte sind klar Die Aufgabe ist eine Herausforderung Spezielle Fertigkeiten sind erforderlich Man kann ungestört arbeiten Basierend auf der Identifizierung dieser erfolgsversprechenden Eigenschaften können nun im Anschluss verschiedene Methoden auf ihre Eignung geprüft werden.

21 Agile und Lean Methoden zur Produktentwicklung sind Ansätze welche höhere Effizienz, bessere Zielerreichung und motivierte Mitarbeiter bei zumindest gleichbleibender Qualität versprechen indem sie den Fokus auf das Team und dessen Prozesse legen. Agile Development: Der Ansatz der agilen Entwicklung stammt aus dem Softwarebereich und die meisten Methoden konzentrieren sich deshalb auch darauf. Besonders die Umsetzung der Engineering Practices macht fast nur im Umfeld der Softwareentwicklung Sinn. Andere Ansätze, wie zum Beispiel Scrum, konzentrieren sich jedoch rein auf Projektmanagement und können und werden auch schon in anderen Gebieten eingesetzt. Will man nun ein agiles Projekt aufsetzen sind für den Erfolg einerseits die gewählten Methoden entscheidend, da diese unbedingt auf die Aufgabe und das Entwicklungsteam abgestimmt werden müssen. Andererseits, und das ist wahrscheinlich der entscheidendste Faktor, müssen die agilen Werte sowohl vom Team aber besonders auch vom Management verinnerlicht werden. Diese Werte sind Flexibilität, Transparenz, kontinuierliche Verbesserung, größtmögliche Vereinfachung, Kommunikation und Kooperation, und eine starke Kundenorientierung. Lean Product Development (LPD): LPD ist ein Ansatz der sich mit der Produktentwicklung im Allgemeinen auseinandersetzt. Der Fokus ist dabei auf dem Management der Arbeitspakete und des Entwicklungsprozesses ohne auf eine bestimmte Disziplin einzugehen. Besonderer Wert wird darauf gelegt, dass der Prozess im Gesamten, also vom Kunden bis zum Kunden betrachtet, und immer weiter verbessert wird. Um dies zu erreichen wird der Prozess zuerst visualisiert und dann versucht Ineffizienzen aufzuspüren und zu entfernen. Desweiteren basiert Lean auf folgenden drei Prinzipien bzw. Fragestellungen [5]: Purpose: Welche Kundenprobleme werden durch die Organisation gelöst? Process: Wie stellen wir sicher, dass jeder Prozessschritt wertschöpfend, passend, flexibel, erfüllbar und verfügbar ist und mittels Mechanismen wie Flow (kontinuierlicher Fluss), Pull (Arbeitspakete werden vom nächsten Prozessschritt gefordert) und Leveling (das System soll in größtmöglicher Balance agieren) miteinander verbunden ist? People: Wie stellen wir sicher, dass jeder Mitarbeiter in der Organisation am selben Ziel arbeitet und zusätzlich den Prozess kontinuierlich verbessert. Um in weiterer Folge nicht immer auf agile Methoden im Speziellen aufmerksam machen zu müssen erlaube ich mir folgende Vereinfachung: Agile Ansätze sind grundsätzlich mit Lean Thinking kompatibel und können auch als Implementierung dessen herangezogen werden. In weiterer Folge werde ich daher nur noch auf Lean Thinking als Konzept eingehen. In diesem Kapitel möchte ich nun auf das Konzept von Lean Thinking eingehen welches von Mary und Tom Poppendieck [6] geprägt wurden und dieses noch um einige Aspekte erweitern. Lean ist grundsätzlich keine Theorie oder Methode sondern ein Mindset. Ziel dieses Konzepts ist es die effizienteste Lösung für eine Produktentwicklung zu finden, welche höchste Qualität sicherstellt und zugleich den Mitarbeitern ermöglicht sich dabei selbst zu verwirklichen. Um dies zu erreichen spielen folgende Werte eine elementare Rolle: Purpose: Wie schon in den vorangegangenen Kapitel beschrieben gibt es mehrere Ansätze um der Arbeit einen tieferen Sinn zu verleihen. Am effektivsten ist der Fall in dem die Aufgaben des Mitarbeiters und deren Werte im Einklang mit den Zielen und Werten des Mitarbeiters sind. Eine sehr anschauliche Erklärung hierzu liefert Simon Sinek in seinem Buch Start with Why [7]. Transparenz: Eine fundamentale Eigenschaft um die Kommunikation und Zusammenarbeit zwischen den Mitgliedern eines Projektteams zu fördern ist absolute Transparenz. Diese Eigenschaft erlaubt es nicht nur den eigenen Prozessschritt zu betrachten sondern einen Big Picture View über das gesamte Projekt zu erhalten. Mit diesem Blick werden einerseits Probleme schneller sichtbar und andererseits startet automatisch ein Gedankenaustausch und somit Peer Learning innerhalb des Teams. Visuelle Kommunikation: Ein besonderer Aspekt von Transparenz ist visuelle Kommunikation. Mithilfe von Wertstromanalysen und Kanban Boards kann die gesamte Prozesskette und der Projektfortschritt visuell dargestellt werden. Dies erhöht die Transparenz und erlaubt den aktuellen Status auf einen einzigen Blick zu erfassen. Arbeitsfluss: Das Ziel für den Fluss von Arbeitspaketen durch die Prozesskette liegt einerseits darin die Pakete so schnell als möglich durch die gesamte Kette zu schleusen und andererseits die Arbeitsleistung auszubalancieren um Druck oder Langeweile entgegenzuwirken. Am besten funktioniert dies mittels dem Pull-Prinzip wobei der nachfolgende sich Arbeitspakete vom vorherge-

22 henden Prozessschritt zieht. Sollten keine Arbeitspakete zur Verfügung stehen wurde möglicherweise ein Bottleneck entdeckt welcher dann gemeinsam gelöst werden kann. Selbstgesteuerte Teams: Sobald man Mitarbeitern mehr Vertrauen schenkt und Freiheiten einräumt wird die Eigenverantwortung erhöht und Teams können sich selbst organisieren und Entscheidungen treffen. Ziel ist es nicht mehr die Personen auszusteuern sondern die Arbeit zu managen. Waste reduzieren: Jegliche Form von Tätigkeit die zu keiner Wertschöpfung für den Kunden führt wird von Mitarbeitern als unnötig empfunden und führt zu Frustration. Des Weiteren hindern diese Aktivitäten dabei das Projekt so effizient wie möglich durchzuführen (siehe Abbildung 2: Waste Reduktion mittels Lean). Abbildung 2: Waste Reduktion mittels Lean Typische Arten von Waste sind: unfertige Arbeit, zusätzliche Features, wiedererlernen von bereits bearbeiteten Aufgaben, Übergaben von Aufgaben, wechseln zwischen Aufgaben, Verzögerungen und Defekte. Kontinuierliche Verbesserung: Der wichtigste Aspekt hierbei ist, dass das Projektteam selbst für die Verbesserung der eigenen Prozesse verantwortlich ist. Das Team identifiziert und analysiert die Probleme, definiert Verbesserungsvorschläge, setzt diese um und überwacht und bewertet die jeweiligen Veränderungen. Dies erlaubt die Probleme dort zu lösen wo sie auftreten und sorgt außerdem dafür, dass das Team sich selbst durch den Change Management Prozess führt und dadurch wenig Widerstand zu erwarten ist. Standardisierung: Damit ist gemeint, dass es standardisierte Prozesse und Vorlagen geben muss, da diese die Basis für kontinuierliche Verbesserung bilden. Ein wichtiger Aspekt hierzu ist jedoch, dass es keine one size fits all Lösung für gesamte Unternehmen geben sollte da jedes Team seine eigenen Ansätze und Methoden hat und auch das Recht haben sollte diese anzupassen. Im Idealfall sollte der Einsatz dieser Werte dazu führen, dass klare Ziele für das gesamte Projektteam zur Verfügung stehen und dass jeder Mitarbeiter auch einen Gesamtüberblick über die Produktentwicklung erhält. Das Team, welches im Normalfall aus disziplinübergreifenden Spezialisten besteht, sollte im Idealfall auch räumlich und organisatorisch zusammengefasst sein um Silodenken zu vermeiden. Des Weiteren sollte jeder im Projektteam in regelmäßigen Kontakt zum Kunden stehen wodurch Feedbackschleifen verkürzt werden und der Person die Wertigkeit und Signifikanz der eigenen Arbeit bewusst wird. Das Projekt Setup wird durch absolute Transparenz, welche zu steigender Kommunikation und Koordination führt und Entscheidungsfreiheit und Selbstorganisation der Mitarbeiter und ihrer Teams abgerundet. Dies führt im Endeffekt dazu, dass nicht mehr die Personen gesteuert werden, sondern die eigentliche Arbeit wodurch einerseits die persönliche Freiheit erhöht und andererseits der Projektfortschritt sichtbar gemacht wird. Dieses stark abstrahierte Bild zeigt nun zwar keine praktische Implementierung, aber dies ist auch gar nicht möglich, da für jedes Produkt und jedes Team eine eigene, passende Lösung gefunden werden muss. Wichtig ist, dass die grundsätzlichen Werte erhalten bleiben, denn wie man leicht erkennen kann decken sich diese komplett mit den zuvor vorgestellten Motivationstheorien wodurch erklärt werden kann warum Mitarbeiter in Lean Organisationen tendenziell motivierter und engagierter sind und dadurch bessere Leistung erbringen [8]. Um die zuvor beschriebenen Theorien zu testen wurde im Rahmen einer Verbesserungsinitiative das Softwareentwicklungsteam eines Automotive Projekts herangezogen. Das Setup dieses Versuchs versuchte praktisch alle zuvor beschriebenen Werte einzubinden. Dies wurde zumindest in Ansätzen auch geschafft und führte zu folgender Struktur (siehe Abbildung 3: Projektstruktur): Abbildung 3: Projektstruktur

23 Das Projekt, welches an zwei verschiedenen Standorten umgesetzt wurde legte mit Hilfe der Aspekte Standardisierung, Transparenz und Selbststeuerung einen starken Fokus auf Frontloading. Das Team definierte zuerst den Inhalt der kommenden Release (Release Planning) welche im Durchschnitt zwei Monate dauert. Diese Release wurde dann, ähnlich zu Scrum [9], in kleinere Zyklen (ca. 2 Wochen) unterteilt. Vor jedem dieser Zyklen wurde noch eine Planungssession durchgeführt in welcher sowohl die Detailplanung erstellt, als auch ein gründliches Review der Requirements durchgeführt wurde. Des Weiteren gab es mehrmals pro Woche kurze Statusmeetings um den Vorschritt zu messen und mögliche Probleme zu diskutieren. Als grundsätzlicher Entwicklungsprozess wurde ein Standard Wasserfall / V-Modell verwendet, da sich dies für die Embedded Software Entwicklung sehr gut eignet und vor allem im Team bereits etabliert war. Der Vorteil dieser kurzen Zyklen besteht vor allem darin, dass die Feedback Zeit zwischen Implementierung und Testen stark reduziert und so auch die Kommunikation zwischen den verschiedenen Gruppen intensiviert wurde. Im ersten Schritt wurden die Prozessverbesserungssessions (Retrospective) noch in Begleitung eines Coaches durchgeführt um auch strukturelle Themen die außerhalb der Verantwortung des Teams liegen zu lösen. In weiterer Folge nahm sich dann das Team selbst dieser Aktivitäten an. Nach der ersten Release wurde ein Review des Projekts durchgeführt wobei auch das Feedback der involvierten Mitarbeiter eingeholt wurde: Dauer der Release: 11 anstatt der geplanten 21 Wochen Gefundene Fehler bei finaler Validierung: 25 anstatt 150 bei voriger Release Feedback: Obwohl der Pilot mit großer Skepsis und nur mittels großer Überzeugungsarbeit versuchshalber begonnen wurde waren die Mitarbeiter im Nachhinein so sehr davon überzeugt, dass sie sich für eine Verbreitung des Ansatzes einsetzten. Aus diesem Ergebnis lässt sich der Erfolg des Ansatzes erkennen. Mittlerweile wurden mehrere weitere Pilotprojekte ins Leben gerufen um sowohl die Effizienz und Qualität zu steigern aber besonders auch um die Mitarbeiterzufriedenheit zu erhöhen. Im Moment gibt es gerade verschiedene Bestrebungen die uns vertrauten Managementtheorien zu hinterfragen. Obwohl es in praktisch jedem Feld der Wissenschaft in den letzten Jahren bedeutende Veränderungen gegeben hat, halten wir bei der Mitarbeiterführung an Theorien fest, die schon mehrere Jahrzehnte alt sind obwohl sich unsere Umgebung in dieser Zeit drastisch verändert hat. Aus diesem Grund und aus Ergebnissen welche zeigen, dass es möglich ist bessere Ergebnisse zu erzielen und dabei auch einen größeren Fokus auf das Wohlbefinden der Mitarbeiter zu legen, bin ich überzeugt, dass ein Umdenken nicht nur förderlich sondern für zukünftigen Erfolg absolut notwendig ist. [1] Abraham Maslow: Hierarchy of Needs [2] Douglas McGregor: Theory X and Theory Y [3] Daniel H. Pink, Drive: The Surprising Truth About What Motivates Us [4] Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience [5] Jim Womack, Purpose, Process, People, LEI [6] Mary and Tom Poppendieck, Lean Thinking [7] Simon Sinek, Start with Why [8] Michael Gnam, Lean and Green Product Development [9] Dr. Roland Wolfig, MBA Roland Wolfig ist SW Qualitätsmanager bei Continental in Wien. Er beschäftigt sich seit mehreren Jahren mit Agilen und Lean Methoden im Embedded Systems und im Speziellen im Automotive Umfeld. Er versucht dabei sowohl theoretische Konzepte weiterzuentwickeln als auch diese direkt in Projekten auf ihre praktische Relevanz hin zu überprüfen.

24 Mobile App-Entwicklung und Testen steht vor neuen Herausforderungen, die neue aber auch altbewährte Ansätze erfordert, jedoch in einem anderem Kontext. Insbesondere in einem heiß umkämpften Markt ist es wichtig die Balance zu finden neue Features möglichst früh auszuliefern, auf der anderen Seite sollte dadurch die Qualität nicht leiden. Das Dilemma dabei ist, liefert man neue Features zu spät aus, ist die Konkurrenz schneller, ist die App für den Benutzer nicht brauchbar, sprich schlechte Qualität, wechselt der Anwender zur Konkurrenz. Die besonderen Herausforderungen und mögliche Maßnahmen werden im Folgenden erörtert. Die mobile App-Entwicklung hat mit vielen speziellen Herausforderungen zu kämpfen, die jedoch in der Desktop- oder Web-Softwareentwicklung kaum ein Problem darstellen. Neue Features ausliefern, bevor die Konkurrenz das macht: Die App-Entwicklung mitsamt Qualitätssicherung und Auslieferung ist ein schnelllebiger Markt. Es ist entscheidend einen pragmatischen Mittelweg zu finden, wann man mit neuen Features auf den Markt geht. Inkrementelle Erweiterungen: Apps müssen ständig weiterentwickelt werden um einerseits geänderte Anforderungen Rechnung zu tragen, aber auch um eine ständige Sichtbarkeit im App-Store zu gewährleisten. Das erfordert eine gute Regressionsteststrategie. Kunden reagieren sensibel auf geänderte Anforderungen: Oft werden Apps optisch aufgehübscht, aber auf Kosten funktionaler Eigenschaften, die vorerst gestrichen werden mussten und erst später nachgeliefert werden. Feedback und Bewertung in App-Stores sind für alle Interessenten unmittelbar sichtbar: Im positiven Sinn helfen gute Bewertung für das Bekanntwerden einer App im App-Store, andererseits können die Bewertungsnoten schnell fallen, wenn die Kunden mit der App nicht mehr zufrieden sind. Viele unterschiedliche Varianten, Hardware/Software als auch Fragmentierung der Betriebssysteme: Software-Emulatoren können echte Devices nicht gänzlich ersetzen. Immer wieder treten Fälle auf, wo bestimmte Geräte- und Betriebssystemkombination für böse Überraschungen sorgen. Nicht-funktionale Anforderungen z.b. nach ISO und nicht-funktionale Tests sind enorm wichtig für die Akzeptanz der Kunden: Die Apps sollen nicht nur attraktiv und einfach benutzbar sein, sondern auch performant und mit den knappen vorhandenen Ressourcen auskommen. Gleichzeitig ist eine äußerst hohe Robustheit und Zuverlässigkeit zu erfüllen. Tool-Unterstützung für die Testautomatisierung steckt noch in den Kinderschuhen: Mittlerweile sind einige Testautomatisierungswerkzeuge verfügbar, diese haben jedoch oft technische Einschränkungen oder können nur eingeschränkt auf das mobile Betriebssystem eingreifen. Trotz Testautomatisierung ist manuelles Testen nicht wegzudenken: Oft entscheidet das subjektive Empfinden, ob eine App benutzbar ist und den Kunden anspricht. Das kann die Testautomatisierung nicht bewerten. Häufige Betriebssystem-Updates: Mobile Betriebssystem werden häufig aktualisiert, damit verbunden sind Änderungen im API oder geänderte Design-Guidelines. Das kann zu ungewollten Seiteneffekte führen, die frühzeitig entdeckt werden wollen. Starke Schwankung der Umgebungsbedingungen: Die Anbindung von vielen Unterschiedlichen Hardware-Sensoren wie z.b. Neigungssensoren o- der Hardware-Geräten wie z.b. GSM oder GPS kann zu Situationen (z.b. schlechter GSM- Empfang, schwaches WLAN Signal) führen, die jedoch in der Testumgebung nicht berücksichtigt worden sind.

25 Um eine hohe Akzeptanz bei den Kunden zu erlangen ist es wichtig die Benutzer zu kennen, deren Verhalten, Interessen und Prioritäten einschätzen zu können. Beispielsweise wurde die Google Calendar App auf Android im neuen Material Design adaptiert. Dadurch waren einige gewohnte Features nicht mehr verfügbar, z.b. die Monatsansicht hat es in dieser Form nicht mehr gegeben. Der Unmut unter den Anwendern ist in den Bewertungen zu erkennen. Abbildung 2: Anforderungen auf Basis von Personas spezifizieren. App, die ständig weiterentwickelt wird, ist es erforderlich die neuen Anforderungen mit den bereits umgesetzten Anforderungen abzugleichen, sodass diese nicht verletzt werden. Benutzer reagieren sehr empfindlich auf Einbußen in der Funktionalität und tun ihren Unmut im App-Store gerne Kund, siehe Beispiel Umstellung des Google Calendar App auf das Material Design. Abbildung 1: Bewertungen der Google Calendar App nach Umstellung auf das Material Design. Um die Benutzer besser kennenzulernen und deren Interessen besser verstehen zu können, ist es wichtig sich vorab die Zeit zu nehmen und Zielgruppen und Stakeholder zu identifizieren. Zur Unterstützung können Personas definiert werden, d.h. eine Zielgruppe wird einer fiktiven aber konkreten Person repräsentiert, z.b. Angabe von Alter, Bildung, Interessen, Job. Auf Basis der Personas werden Features (z.b. User Story) abgeleitet und priorisiert. Als Ergänzung sollten Szenarien definiert werden (Specification by Example) um die Features anhand von konkreten Beispielen (Akzeptanzkriterien) klarer abzugrenzen. Die Akzeptranzkriterien werden vorab festgelegt und die Anforderungen sind somit von Beginn an testbar. Es ist nicht nur wichtig die Anforderungen auf Basis der Persona zu ermitteln und dokumentieren, sondern entscheidend für einen langfristigen Erfolg ist ebenso das Prüfen und Abstimmen von Anforderungen, sowie das Verwalten von Anforderungen. Im Falle einer Abbildung 3: Anforderungen dokumentieren, prüfen, verwalten und ermitteln. Es sollen möglichst alle Entwicklungsphasen automatisiert werden um die manuellen Tätigkeiten, die zu einer Verzögerung führen können, auf ein Minimum zu reduzieren. Eine Delivery Pipeline setzt sich

26 aus mehrere Stufen zusammen. Jede Stufe hat ein bestimmtes Ziel und mit jeder Stufe steigen die Qualitätsanforderungen an die mobile App. Abbildung 4: Mobile Delivery Pipeline. Erster Schritt in der Delivery Pipeline ist eine mobile App automatisiert zu bauen, d.h. den Letztstand aus dem Konfigurationsmanagementsystem auszuchecken und den Source Code zu übersetzen. Compilerwarnungen sollten idealerweise von Beginn an analysiert werden und zu einem Abbruch dieser ersten Stufe führen. Inkonsistenzen im Konfigurationsmanagementsystem, wie z.b. fehlende Source-Dateien, werden somit frühzeitig aufgedeckt, der Build schlägt in diesem Fall fehl. In dieser Stufe ist es wichtig, dass das Feedback schnell beim Entwickler landet und sofort nach jedem Commit ausgeführt wird. Je früher der Entwickler über Fehler benachrichtigt wird, desto kostengünstiger werden diese behoben. Beispielsweise haben Nightly Builds das Problem, dass der Entwickler erst am nächsten Tag Feedback über mögliche Fehler bekommt. Nachdem zwischen den Commits und Feedback eine lange Zeitspanne liegt, muss mit einer längeren Fehlersuche gerechnet werden, auch weil der Entwickler womöglich schon mit der nächsten Aufgabe begonnen hat und nun wieder zur ursprünglichen Aufgabe zurückspringen muss. Die nächsthöhere Qualitätsstufe sind die Unit-Tests. Auch hier ist es erforderlich, dass diese schnell durchlaufen und Feedback an den Entwickler liefern, ob sich durch eine Änderung eventuell Regressionsfehler eingeschlichen haben. Wichtig ist, dass in dieser Stufe nur Unit-Tests ausgeführt werden, die schnell sind. Gerne werden Unit- Tests mit Integrationstests vermischt. Das hat aber zur Folge, dass die Integrationstests oftmals länger laufen und ganz andere Fehlerursachen haben als klassische Unit-Tests, wie z.b. fehlende Konfiguration, Netzwerk nicht vorhanden oder die Testdatenbank enthält inkompatible Daten. Um Unit-Tests klar von Integrationstests abzugrenzen kann man folgende Richtlinien beachten. Unit- Tests benötigen keine Datenbank benötigen kein Netzwerk greifen nicht direkt auf das Dateisystem zu benötigen maximal 1/10 Sekunde benötigen keine spezielle Konfiguration. Wenn Unit-Tests fehlschlagen, dann kann es nur daran liegen, dass der soeben implementierte Algorithmus fehlerhaft ist, ein Regressionsfehler eingetreten ist oder es sich um einen Fehler im Test handelt. Somit ist der Fehler viel schneller eingrenzbar als im Integrationstest, wo der Test-Scope um einiges größer sein kann. Der Integrationstest sollte somit nach den Unit-Tests in einer separaten Teststufe ausgeführt werden, wo man auch schon von einer stabileren Basis ausgehen kann, wenn die Unit-Tests erfolgreich ausgeführt werden konnten. Eine weitere wichtige Qualitätssicherungsmaßnahme ist die statische Analyse des Quellcodes. Ziel ist es, z.b. die Einhaltung der Coding-Guidelines zu prüfen, potentielle Fehler aufzudecken oder übermäßig komplexe Code-Teile aufzudecken die überarbeitet werden sollten. Für die mobilen Plattformen gibt es mittlerweile eine gute Werkzeugunterstützung. Beispielsweise bietet Android mit Lint eine Werkzeugunterstützung, siehe (Android Lint, 2014). Apple bietet mit Xcode ein integriertes statisches Analysewerkzeug an. Eine sprachunabhängige Werkzeugunterstützung bietet beispielsweise SonarQube. SonarQube kann u.a. die Sprache C, C++, Java, C#, Objective C analysieren und diese in einem Web- Dashboard anzeigen. Es können damit potentielle Fehler erkannt werden, wie auch Verletzungen gegen die Coding-Konventionen. Metriken werden erfasst, wie z.b. Lines of Code, Anzahl an Funktionen, zyklomatische Komplexität (McCabe). Zusätzlich können Ergebnisse des dynamischen Testens, wie z.b. die Unit-Testergebnisse als auch die Testüberdeckung angezeigt werden.

27 Abbildung 5: SonarQube Dashboard. hohe Fragmentierung herrscht, sowohl was die Anzahl der unterschiedlichen Betriebssystemversionen betrifft als auch Herstelleranpassungen und zusätzlich die Anzahl der unterschiedlichen mobilen Endgeräte. Diese Variantenvielfalt zu testen ist in endlicher Zeit nicht zu bewerkstelligen. Deswegen macht es Sinn, z.b. die am häufigsten verwendeten Varianten (Geräte und Betriebssystemversion) für diesen Test auszuwählen. Wenn es jedoch nicht möglich ist, alle physischen Endgeräte für den Test zu berücksichtigen, weil diese einfach nicht vorhanden sind, ist es sinnvoller diese Tests in die Cloud auszulagern. Hier gibt es Anbieter, die sich darauf spezialisiert haben, Tests auf echten Geräten durchzuführen, wie z.b. (Sauce Labs, 2014). Diese Cloud-Dienste lassen sich auch nahtlos in das bestehende Continuous Integration System integrieren, z.b. mittels REST-API oder durch die Installation eines Plugins für das jeweilige Continuous Integration System. In dieser Stufe steht vor allem die Robustheit der mobile App im Vordergrund. Mobile Apps müssen besonders robust ausgelegt sein und die unmöglichsten Eingabemöglichkeiten berücksichtigen. Da das Testen aller möglichen Kombinationen schon gar nicht manuell und auch nicht automatisch in kurzer Zeit möglich ist, kann man einen Test-Monkey nutzen, der zufällige Benutzereingaben generiert. Damit werden zufällige Eingabedaten generiert, z.b. Tasteneingaben oder Touch-Events, an die ein Tester womöglich nie gedacht hätte. Der Test-Monkey beobachtet dabei das Verhalten der App auf die zufällig generierten Eingaben: Wird eine Exception ausgelöst wird diese protokolliert. Antwortet die App nach einer bestimmte Zeit nicht mehr, wird das Ereignis protokolliert und der Monkey beendet sich. Der Test-Monkey kann natürlich kontinuierlich im Hintergrund laufen um auch das Laufzeitverhalten der mobilen App über eine längere Zeit zu beobachten: Ist die Reaktionszeit der App auf Benutzereingaben konstant oder wird sie über die Zeit größer? Wächst der erforderliche RAM über die Zeit an? Für Android steht im SDK ein Monkeyrunner zur Verfügung, siehe (UI/Application Exerciser Monkey, 2014). Mit MonkeyTalk (MonkeyTalk, 2014) steht auch ein Open Source Testwerkzeug für ios (und auch Android) zur Verfügung. Mittels Behaviour Driven Development wird frühzeitig zur Zeit der Anforderungsspezifikation damit begonnen, Abnahmekriterien zu definieren. Die Abnahmekriterien sind dabei als Beispiel zu sehen, dass dazu beiträgt die Anwendung konkret zu beschreiben. Diese Abnahmekriterien werden in Folge der Implementierung automatisiert und zeigen somit dem Entwickler an, wann er mit der Implementierung fertig ist, nämlich genau dann, wenn diese Testfälle positiv durchgeführt werden konnten. Die Abnahmekriterien werden entsprechend von Behaviour Driven Development mittels der Satzschablone Gegeben sei, wenn und dann. Damit ist die Vorbedingung definiert, die durchzuführenden Aktionen und abschließend das erwartete Ergebnis. Schlussendlich soll die entwickelte und getestete App ausgeliefert werden und am Markt erscheinen. Um dabei möglichst keine Zeit zu verlieren, sollten hierzu keine manuellen Schritte erforderlich sein oder Magic-Skripte auf einem bestimmten Entwickler-PC ausgeführt werden. Sondern diese letzte Stufe sollte ein fixer Bestandteil der Delivery Pipeline sein und zentral in einem Continuous Integration System konfiguriert sein. Jeder sollte somit im Prinzip die Möglichkeit haben auf Knopfdruck die App zu testen und auf den Markt zu bringen. Dazu sollte kein Insider - Wissen erforderlich sein. Eine große Herausforderung mobiler Apps besteht darin, dass gerade im Android-Umfeld, eine sehr

28 Zusätzlich zu den automatisierten Tests sollten manuelle explorative Tests nicht außer Acht gelassen werden. Gerade mit manuellen Tests lassen sich schnell Situationen prüfen, die automatisiert nur mit viel Aufwand herstellbar sind. Folgende Testziele sollte mit dieser Testart geprüft werden: Test des Akkuverbrauch: Wieviel Akku verbraucht die App? Installationstests: Lässt sich die App installieren (z.b. interner Speicher, SD-Speicher)? Unterbrechungstests: Kommt die App mit Unterbrechungen (z.b. Standby, Anruf, SMS) zurecht? Update-Tests: Kann die App erfolgreich upgedatet werden, sodass auch die interne Datenbank aktualisiert werden? Datenverbindungstests: Wie kommt die App mit unterschiedlichen Verbindungen (z.b. 3G, Wifi) zurecht, was passiert wenn während einer Übertragung die Verbindung gewechselt wird? Ortungstests: Wie kommt die App mit der Ortung (z.b. Gps) zurecht, u.a. unter schlechten Bedingungen? Humble, J., & Farley, D. (2010). Continuous Delivery. Addison-Wesley. Knott, D. (2014). Hands-On Mobile App Testing. Leanpub. MonkeyTalk. (Dezember 2014). Von abgerufen Sauce Labs. (Dezember 2014). Von abgerufen sonarqube. (8. Oktober 2014). (SonarSource S.A) Abgerufen am von UI/Application Exerciser Monkey. (Dezember 2014). Von abgerufen Auch in der mobilen Welt stehen sowohl altbekannte als auch neue Methoden und Techniken zum Testen der App bereit. Wichtig ist eine ausgewogenen Mittelweg zu finden frühzeitig mit neuen Features auf den Markt zu gehen, auf der anderen Seite sollten diese Features den hohen Qualitätsansprüchen der Kunden entsprechen. Die Konkurrenz ist nur einen Touch im App-Store entfernt. Der Schlüssel zum Erfolg ist die Automatisierung, sowohl der Tests als auch von immer wiederkehrenden Schritten z.b. Deployment. Um zu schnellen Testergebnissen zu kommen und um spezielle Bedingungen rasch herzustellen sind explorative Tests eine ideale Ergänzung zu den automatisierten Tests. Dipl. Ing. Hermann Lacheiner Hermann Lacheiner hat schon während seines Informatik- Studiums an der JKU Linz Erfahrungen in der professionellen Softwareentwicklung gesammelt. Mittlerweile kann er auf eine langjährige Erfahrung in allen Projektphasen zurückgreifen: von Unit-Testen, Testautomatisierung und Testmanagement bis hin zu Requirements Engineering. Ein weiteres Betätigungsfeld ist die Einführung von ALM-Werkzeugen und die damit verbundene gesamtheitliche Betrachtung des Softwareentwicklungsprozesses. Thematische Schwerpunkte: Application Lifecycle Management Requirements Engineering Testmanagement Testautomatisierung Continuous Integration Open Source Android Lint. (Dezember 2014). Von abgerufen Darüber hinaus unterrichtet Herr Lacheiner an der FH Hagenberg und ist Autor von Fachartikeln und Vortragender bei diversen Konferenzen.

29 Project metrics are not sufficient to measure the performance and efficiency of a test team. Test management should introduce specific metrics for testing and monitor their output so as to assess test team's productivity and efficiency regardless of project's progress and outcome. These metrics should be project agnostic so as to have no correlation with the actual project status since a test team may well do a good job in a failed software development project or the opposite. The scope is to present an outlined methodology to create such metrics, using as an example an actual implementation, so as to be able to create project agnostic test metrics tailored to specific needs. Lately, the popularity of independent testing teams is increasing so rapidly that could be considered as a software industry trend. Either as a third party/ external contractor, as a crowd-source service coming from the cloud or as a different functional team within an -even projectized- software development house; independent test teams are considered the appropriate formation to take the most from testing services and quality assurance. Independent test teams are practically covering at least the system test activities that are, amongst others, the last step in software development life-cycle before releasing to the customer, following a customer-before-the-customer approach in a projectwithin-the-project formation. The profound added value out of these services has created an outburst of independent test teams or just test teams declared as independent. How can we identify a test team as being independent really? After all, from what a test team should be indepen-dent of? Since the formation and service of a test team is greatly affected by several attributes of the project working for (software development methodology, type of contract, scope of test work, technologies and tools used, overall organization structure, etc.) unfortunately there is no hard coded way, no golden rule to evaluate the actual independence of a test team. Just to create a common understanding of how an independent test team may looks like, bellow is a list of attributes and characteristics that are usually found in independent test teams. Again, this list is not exhaustive and it cannot be used as a check list for evaluation. You may easily come up with even more characteristics. The most obvious characteristic is the case where the test team is a third party working for a specific contract which governs the testing activities only and explicitly. If the independence arises from the very beginning, from the budget level then it is practically assured. Another obvious characteristic is whether the test team is actually a team having its own management. Testers reporting directly to a project manager have low level of independence and can hardly be considered as a separate team. Of course, if the test manager reports to the project manager then we are more or less on the same dependant situation. Other clear evidence of independence are well defined interfaces with the project team and entry exit criteria for the test activities that are actually followed in practice and are not just empty words in a test management plan of course! An independent test team has its own targets specific for its work; set and monitored by test team s management. So it should have specific to test metrics in order to measure work performed against these targets. Apparently, one of the main potential characteristics of an independent test team is the existence of specific to the team, targets and specific to the team, metrics. Before digging into more details in test metrics of specific purpose let s first explore the test team s specific goals and targets within a software development project. The generic, obvious and standard organizational goal for an undertaken project is to deliver with success. What success means though? How the rate of successfulness is measured? In order to define and identify success the main goal of the project is split further down to detailed objectives or targets.

30 The most common way to split a generic goal to project targets (followed in many project management principals) is depicted in the well known project management triangle or else known as the triple constraint which illustrates the, usually opposing targets to Deliver: 1. On Time, 2. On Budget, 3. On Scope and: 4. With Quality. These main targets can be further split into several sub-targets that usually have to do with the specific nature of the project, the teams that will be utilized, the technologies and methodologies used and various other factors of each and every project. Every member or sub-team of members of the project group undertakes activities their completion of which corresponds to one or more targets achieved. Piling up achieved targets we are getting closer to meet our goals and finish the project with success. This is in very rough terms what we call management by objectives or management by results in a project level. Out of the whole set of specific and detailed project targets we can isolate some that are specific to test and assigned to the test team only. The targets that are specific to test are the ones having minimum to zero dependency to other project activities or any other external -to test- dependencies. It is almost exclusively up to the test team whether these targets will be met or not and as such, their outcome characterizes the test team s work but not necessarily the overall project s result as this is dependent in several more targets. All targets serve the project goal and as such all targets are important for the project. However, If specific to test targets are achieved this is a good indicator whether test team has done a good job within the project or not. It takes more than that though so as to have a successful project. Metrics is a standard, a well defined way of measurement. Metrics in business provide the valuable and needed input to understand where we stand; what the current status is and how the trend looks like. Management on the other hand is the way to plan and follow the most suitable way/ path to meet our goals. There is no way to plan and follow a path towards our goals though if we do not know where we currently are; if we do not know where we stand. As such, metrics provide the principal input for most of the management activities - just like as the specifications are the input to design and development for a software application. In order to track, monitor and control project work status and project work progress, several metrics and KPIs have been developed and standardized as best practices in project management and even more are used in an ad hoc manner. The application of these metrics in testing activities may well serve the project goals but they cannot serve as valuable and effective way to measure performance and efficiency of a test team in general, regardless of the projects working for. Test management should introduce specific metrics for that purpose and should not rest assured that this need is covered through project management activities. Test management should define ways to monitor and control test team s output so as to assess test team's productivity and efficiency regardless of project's progress, status and outcome. These are the project agnostic test metrics that we are looking for. So, it is apparent that project success does not mean test team s success and project failure does not mean necessarily that test team has failed too. There may be cases where a project is not successful but the test team achieved its targets or the opposite. Consequently, project success or other generic project metrics are not a good indicator of how well test team performed and we cannot count on project metrics to evaluate a test team that worked for this specific project. For that, there need to be specific to test metrics so as to have a clear view of the test work accomplished. Before going into details of specific to test metrics, let s first see some basic attributes of metrics in general. Up to now we have seen why we need project agnostic test metrics. We will now proceed to see how we can build up such metrics, which are the principals to follow and what actually do we need to measure. The approach presented bellow is the one that I have already applied to my current test team and up to now has proved to serve my needs as a test manager in an excellent manner. This does not imply that it is presented as if it is the only way or even the better way to follow so as to introduce metrics to a test team. Personally I have spent considerable effort studying other metrics and I ended up that I should better create my own! My goal is not to provide you with specific metrics ready to be applied but mostly to demonstrate the pattern followed in order to create metrics so as to be able to create your own project agnostic test metrics which will serve your own specific needs according to your targets set by your management or your clients.

31 Our Target is to build up project agnostic test metrics so as to measure performance of a test team. How our test metrics can be project agnostic though? The metrics that we will create must be either uncorrelated to the project status, progress and conditions in general or must be somehow normalized so as to provide meaningful results across various different projects. Before seeing more details in regards to how to make our test metrics project agnostic let s see first how to create test metrics. Test work performed (and any work in general) has two main attributes (or parameters); Quality and Quantity. means not only the ones that are dictated by the project or have some project interest but all the actual activities that are taking place. This is also known in some cases as the service list. Once defined -all and in detail- then probably some of these can be bundled in groups of same attributes and characteristics where the same units could be adopted to measure productivity and efficiency. For example there may be various different test execution activities. However, most probably all of them can be measured using the same units. Having done this exercise for my team, I came up with 45 different test activities that can be bundled in 14 different in nature groups. Bellow in Fig. 1: Sample of List of Test Activities you can see some samples of this work: Quantity is the answer to the question How much is done (over a period of time) and in a corporate environment this is baptized Productivity. Quality is the answer to the question How well a work has been done (over a period of time) and in a corporate environment this is usually referred to as Efficiency. How much and how well; that is, productivity and efficiency are the two factors of work that we usually need to measure so as to define the success of the effort spent for an undertaken activity. The most simple and common way to measure them is the ratio of work done over the time taken to do it for productivity and the ratio of the added value of the work done per the time that is taken to do the work. In order to define these metrics of productivity and efficiency in detail we need to define a way to measure the numerator and the denominator of the aforementioned fractions. Denominator is the time. Time has very well defined units to be measured for some time now!! The numerator is actually depending on the specific activity for which we need to measure productivity and efficiency so there is no standard or common unit for this. So, In order to measure productivity and efficiency of a test team we need to define the appropriate units to measure how much and how well the work was done for each and every possible test activity. Fig. 1: Sample of List of Test Activities As you see I am using a two digit numbering format for the testing activities, separated by a comma. Also their title has a naming convention with a prefix and then the actual name. The first digit and the prefix correspond to the activity group and the second to the specific activity shown in the title within the activity group. This helps a lot, during reporting and data analysis, to identify easily the grouping and every activity within its group. Bellow in Fig. 2: Sample of Descriptions of Activity Groups you can see samples of test activity groups: But, which are the possible test activities? Is it only test execution? Of course not! So, the actual first step so as to define test metrics is to define the full list of possible testing activities that your team performs. To define in detail all the possible test activities. All Fig. 2: Sample of Descriptions of Activity Groups

32 Once the activities are defined, test team members can start reporting their work and time spent against them. How much time they have spent for a specific activity is the denominator for the productivity and efficiency factors that are still to be created. We need also to define a metric for the quantity and quality of the result of each and every test activity that has been defined and is reported. I ll use just use as an example the following three test activities groups. Test execution Composition of test specifications Document review For these groups the definition of productivity has been agreed to be the following: The number of test cases executed. The number of test cases composed. The number of pages reviewed. Similarly as efficiency for the same test activity groups can be defined the following: The number of reported issues. The inverse of (valid only) comments reported during review. The number of (valid only) comments created during review. Again, it should be pinpointed, that this is just an example and you could easily come up with different metrics for the same activities or you may group your activities in a different way. It is the logic that matters. The outcome is dependent on specificities. Having defined productivity and efficiency units for all test activities, we have come up with a full set of test metrics. Let s assume that we collect all necessary data and our metrics provide results, a significant bulk of data over a large period of time. Can we compare the results from different testers working for different projects? Is it safe to assume that Tester A is more productive than Tester B just by checking the result of the corresponding metrics? In other words are these results comparable? Time is absolute - at least out of the range of relativity theory! Time runs fast but runs at the same pace for all projects in the world and for all humans around the earth. However, can we compare the number of issues identified by a tester who works for a new complex development project which has loose, very loose quality processes with another one who works for a maintenance contract in applications that are already in production for over a decade? We all know that the first tester will of course come up with dozens of bugs every day while the second one may spend a day without finding a bug. Does this mean that the first tester is more efficient? Apparently productivity and efficiency have dependencies with several project characteristics or other external factors. So, how could we compare the results of productivity and efficiency from projects that are different in nature? In other words how can we make our test metrics be project agnostic? The answer to that in one word is normalization; normalization of results which could be applied with a couple of different ways. One way would be to normalize rankings. With this approach we first obtain and compare results per project separately. Then we create a ranking amongst testers for the metric that we are interested in. We do exactly the same for all projects and then we normalize the rankings for all projects. That would mean that the best (in terms of efficiency or productivity for a specific activity group) in every project takes the same score and the worst in every project again the same score. After normalization is applied, we can merge the different rankings creating a unified one for all testers working for different projects. Avoiding going into detail with the math behind that, bellow is a visualization of ranking normalization in the case where we have two projects. For the first one we have 6 testers working on it (A, B, C, D, F, G). The second one has 3 Testers (alpha, beta and gamma). We create the ranking of these testers per project and a for a specific measurement according the the calculated values out of our metrics as shown in Fig. 3: Visualization of Ranking Normalization. Then we normalize rankings so as the best and worst score in every project to be the same as shown in Fig.4: Visualization of Ranking Normalization. Then we merge all normalized project rankings to create the unified ranking for the whole team as shown in Fig.5: Visualization of Ranking Normalization.

33 other. This methodology is not dependent in any assumption for boundary values as it is based on mean values. The drawback is that it needs a relative large sample of values to create meaningful mean values. Two projects with a small number of test engineers per project may not be the best scenario to apply this methodology. Fig. 3: Visualization of Ranking Normalization Fig.4: Visualization of Ranking Normalization Fig.5: Visualization of Ranking Normalization This methodology assumes that the best tester and the worst tester of every project is equally best or equally worst which is a rather arbitrary assumption. Another way to apply normalization is to create and apply a normalization factor. In this approach we measure the mean value of a specific productivity or efficiency metric for the whole team and preferably for a large period of time. This is the team s mean value of the specific metric. Let s call it: MTM Again there is no golden rule to follow in metrics. There is no such thing as best set of metrics. It all depends on what we really want to measure and on specificities and peculiarities of our organization, technologies and methodologies used and business working for. What has been proposed here is an approach to follow so as to create your own metrics that will serve your needs. Even the approach itself may have variations. For sure though, there are some important activities and milestones that should be followed in the course of work to create appropriate metrics. These are: Create an activity list. Before starting to create metrics define what you need to measure Create units of measurement for every activity or activity group. There is no divine metric unfortunately that can be applied for every possible activity. Keep records of actual effort spent, not planned actual and as realistic and detailed as possible. Time spend on an activity is the denominator of every efficiency or productivity metric. Calculate mean values to use them as reference so as evaluate your results. There are industry standards, rule of thumbs but you should be able to compare yourself against yourself so to assess the trend. Are things getting better or worse? is a more important question to be answered than Are things ok or so and so?. The mirror after all, is always the toughest judge! Once we calculate this value we use it as a point of reference for any other project specific measurement. To do so we calculate the mean value of the same productivity or efficiency metric in a specific project. Let s call it: MPM. We define as normalization factor for specific project (P) and for metric (M) the fraction between the team s mean value per the project s mean value. Α(M,P)= MTM / MPM. Any result extracted for this metric (M) and for the specific project (P) is multiplied by the normalization factor A(M,P) so as to calculate the normalized value. Normalized values are then comparable with each Sakis Ladopoulos, MSc, TMMi professional Sakis Ladopoulos is a Test & Delivery Manager in INTRASOFT International ( and an independent test management and QA consultant. He is also a writer and speaker for quality assurance related topics. theodosios.ladopoulos@hotmail.com

34 With a great boom of agile way of leading a project, requirements are getting less and less detailed. Having just a broaden draft of documentation just in time for coding makes our testing work pretty mess. Tester has to be proactive and wise to ask the right question the right people in the right moment and that task is getting harder when people are on different locations. The real challenge is how to keep on track with requirements and changes? How to lead a testing team from remote location? The answer to that is really not easy and for sure is not one thing. In the last decade great investments were done to convert national project to global project. We are spreading our work across towns, countries and continents. There are many reasons for that. The most important are skill set availability, cost and complexity, resources constrains, government restrictions On the other hand we endorse agile way of working. We want to be efficient, quick and proactive. Researches show that more than 80% of agile teams are distributed across multiple locations. It is widely believed that distributed work impose many challenges that normally don t exist in collocated teams. Most common challenges would be delayed feedback, lack of communication, less shared project awareness, lack of trust between sites and maintaining good quality. All of that have an effect on quality. Test teams are responsible for maintaining good quality and distributed agile teams bring up the challenge whether we are able to persist under pressure. Test teams are in most of the cases distributed. It is very common to have test engineers as contractors from other side of the world. How does this affect overall progress? After all, the adage says, Out of sight out of mind, but the quality cannot be ignored. Hey, we are separated but for sure not divorced! Agile way of working have big influence on project organisation and all its artefacts. Its influence can be felt on documentation, planning meetings, team roles and responsibilities, project organisation Since testing is very important and since it has to be included from the project start up, all changes are reflecting on testing. Documentation itself suffers the most. We try to keep it simple but also we have to have enough for good work. This is what makes testing difficult. When test team is distributed on remote location many questions will appear bringing up challenges such as when to ask, how to ask, whom to ask? One could never know what is happening away from his eyes. Is the contact person free? Is he/she in the mood for conversation? Bottom line, do we interrupt any important work? In this kind of situations tester has to be wise, assertive but balanced, proactive. He/she must invest much more effort than located engineers to rectify gaps in the documentation. Testing cannot be performed without documentation, that is clear. We can t verify something that is not written and confirmed. And what happens in agile teams? In most of the cases on rapid agile projects documentation is getting less and less detailed and very often it happens that changes are not noted on time. Many things change and only few are documented. If you are working on some remote location it is very common that you won t be in a communication loop and you won t be notified about change. Creating detailed requirements and system specifications in advance may seem less risky, but this actually creates a false sense of security for the remote teams. The right way to do it is creating less specification up front and then, as project is evolving, through good cooperation get to the details. Problem with the documentation and the inability to follow development, changes and plans is just one of the problems with which remote test team struggles. There are other problems too. Different approaches in solving problems can be applied on differently organized distributed teams depending on which teams are distributed, on how many locations the product is developed and cultural differences. During my three years of work on a project developed in SCRUM framework 3 countries were involved together with 4 languages. 4 major risks that affect the quality of our the product were: Loss of communication richness Lack of coordination Geographic dispersion

35 Cultural differences Testing team was part of this big project as completely equal member and final say Go or No go was up to us so quality was the most important part. We had to be in every single pore, on all meetings, every plan or scheduler and we were distributed from the main team on other location, in other country. Quite a challenge! We had following organization: Main team Distributed developers Distributed testers The biggest team was on main location. All leads, SCRUM master, product owner and stakeholders were together on one location and developers and test team were distributed on 2 different locations. We had problems in different areas that reflected our work and made our work pretty a mess. Traveling onsite was one of the solutions but it cost us a lot of time, and time is money. Main problems and most appropriate solutions for us were: Stand up meetings: with small investments we managed to have daily stand ups over video calls and efficient tools, It was simple and easy to implement and it was of great help to us to feel like part of the team. Still we had problems - awareness of people to use this. They had to be persuaded to adhere to an agreement to schedule the meetings and use video calls. Not everyone accept changes so easily so it took a lot of time and effort to make everyone understand how this is important and yet easy to implement. Planning meetings: planning meetings were very slaw and not so efficient. We needed a lot of time to prepare, get into the plan, actually plan with others and make decisions. Since we were not efficient and didn t have expected progress we decided to split planning into two planning meetings. The purpose of the main meeting was to talk about milestones, general plan, dividing tasks. It was preferred to have it on-site. Second part of the meeting was held internally with teams, on their location. This way team could analyse problems in details, divide tasks and solve small problems. Missing roles: imagine a basketball team on one building and it s coach in another one. There is no video call that could help them coordinate and be successful. Every team has to be present on the main location in some way to keep track of what are the requirements, needs and how situation is developing. Since we weren t co-located our solution was to have deputies on each remote location. Lead (located) and its deputy (distributed) were in touch all the time discussing all topics. Their bond was the crucial for connecting people and teams. Building trust: Nothing is more important than have trust in your co-workers. Trust is the crucial element of a hyper-productive teams and it s not easy to gain it. Gaining trust is a challenge when team members are distributed across different time zones, cultures, and environments, and when they also face communication, language, technical alignment, and project management issues. When a team doesn t have a minimum level of trust, it s more difficult to deal with challenges when they appear. We all agree testing is important but we can agree also that testing is not as welcomed as we want it to be. If people know each other and if they have trust in each other than reporting ones mistakes can be accepted with more tolerance and patience. If people are not working closely together than they will not have enough trust and won t feel the need to bring team spirit and positive energy. Than it is often easy to blame and criticize distributed teams. From my perspective, building trust between distributed teams is the biggest challenge because when trust is strong, team members are able to work through the most difficult issues and they often create innovative solutions. Research done on our project showed that there aren t almost any relationship between geographic distance of remote testing team and quality and defect density. No matter in what kind of organization team you work on within distributed teams, the way we communicate and build trust is the crucial component required to achieve successful project with good quality. Communication will help us see each other as a team players who wants the same to reach schedule, maintain quality and lower cost. Even though The Agile Manifesto states that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation working in a distributed teams can be efficient and test team can feel like part of it. We for sure have to invest a lot of energy to keep us on track but others can also help. Milena Petrovic, software engineer working for Comtrade Solutions Engineering Her journey started with development and moved forward to QA in agile projects in After years of testing she became lead engineer on different projects for world s leading gaming companies. milena.petrovic@comtrade.com

36 Dieser Beitrag beleuchtet ein weitverbreitetes Phänomen: Sobald der Projektdruck steigt, werden wichtige qualitätssichernde Maßnahmen wie Test und Dokumentation vernachlässigt. Doch was steckt dahinter? Warum weichen dokumentierte und gelebte Prozesse oft so stark voneinander ab? Wie lassen sich diese Effekte vermindern oder vermeiden? Ich empfehle jedem Projektteam, es den Künstlern gleich zu tun, die immer wieder zurücktreten um Ihre Gemälde oder Ihre Skulptur mit etwas Abstand oder aus einer anderen Perspektive zu betrachten. Oft ist gerade die Nähe zum Objekt und der intensive Wunsch, das angefangene Werk zu vollenden, das größte Hemmnis klar zu erkennen, wo sich Verbesserungspotentiale eröffnen. Im Projektgeschäft kommt noch eine ordentliche Portion Zeitdruck dazu, die den Blick auf die Realität, sprich die tatsächliche Qualität, trübt. Was für den Künstler der Schritt zurück ist, sind für Projektteams beispielsweise Analyseworkshops, in denen die Projektbeteiligten ihr Handeln und die daraus entstehenden Ergebnisse in einer entspannten Atmosphäre unter die Lupe nehmen. Am besten tun sie das gemeinsam mit neutralen externen Fachleuten unter Leitung eines Moderators, der den Workshop professionell leitet. Abbildung 4: Test und Dokumentation Nicht selten stellt sich bei diesen Workshops heraus, dass sich im Laufe eines Projekts eine Lücke zwischen Anspruch und Wirklichkeit auftut. Der gelebte Prozess weicht vom dokumentierten Prozess ab. Genau genommen haben wir es sogar mit drei Prozessen in der Projektarbeit zu tun: Dem tatsächlich gelebten, dem dokumentierten und dem vermuteten Prozess, von dem wir glauben, dass er umgesetzt wird. Die dritte Variante ergibt sich aus der Tatsache, dass wir leider nicht in der Lage sind, die Realität objektiv zu beobachten. Wir unterliegen immer einer Realitätsverzerrung durch die Einflüsse psychologischer Phänomene. Sehr häufig klafft dies Lücke bei Dokumentation und Test. Dies äußert sich neben fehlender und unsinniger Dokumentation in so seltsamen Blüten wie die Programm-Kommentarzeile it s magic, die ausdrücken soll, dass ein Programmabschnitt scheinbar tut was er soll, aber der Kommentator nicht verstanden hat, wie, bzw. es nicht für nötig hält, andere über das Wunder aufzuklären. Ich habe auch schon Informatiker-Witze im Sourcecode gefunden, die wohl den verzweifelten Programmierer, der den ansonsten unkommentierten Code irgendwann überarbeiten soll, bei Laune halten sollen. Getestet wird häufig nur bis zum Abgabetermin und nicht bis alle Anforderungen (sofern bekannt und beim Test berücksichtigt) als erfüllt im Sinne der vereinbarten Qualitätsanforderungen nachgewiesen wurden. Interessant ist es auch zu beobachten, wie der Aufwand für Dokumentation am Ende eines Projekts massiv wächst, wenn Sicherheitsnormen und angestrebte Zertifikate die unsichtbare Peitsche schwingen. Code- und Architekturanalysen bei Software zeigen jedoch, dass zwischen nachträglicher Dokumentation und Realität nicht selten eine erhebliche Lücke klafft. Es handelt sich also weniger um eine Dokumentation der Realität, sondern mehr um eine nachträgliche Interpretation der Ergebnisse im Sinne der Erwartungen des Gesetzgebers oder der zertifizierenden Instanz. Die Folgen dieser Nachlässigkeit und freien Interpretation zeigen sich erst später und müssen dann oft durch diejenigen ausgebadet werden, die das Problem nicht verursacht haben: Endkunden, Service und künftige Entwicklungsteams. Sie trifft es dann aber umso härter. Grund genug den wahren Ursachen auf den Grund zu gehen. Häufig wird als Begründung für die Vernachlässigung von Pflichten der Faktor Zeit ins Feld geführt. Doch bei genauerer Betrachtung können wir das nicht

37 gelten lassen, da ja für andere Aufgaben (z.b. die Durchführung weiterer schlecht dokumentierter Projektaufgaben) Zeit zur Verfügung steht. Wenn wir für etwas keine Zeit haben, ist es uns nicht wichtig genug. Es geht also nicht um einen Mangel an Zeit, sondern an Wichtigkeit. Oder die Verpflichtung fühlt sich unangenehm an und wird deshalb erst einmal verschoben. Wir haben also einen sachlichen Grund (Priorität) und einen emotionalen Grund (Vermeidung von Unannehmlichkeiten). Warum ist etwas unwichtig? Die naheliegende Antwort lautet: Wenn etwas nicht zielführend ist! Das heißt, wenn Dokumentation und Test vernachlässigt werden, scheint sie nicht als zielführend betrachtet zu werden. Viele werden das abstreiten. Doch, wie heißt es so schön: Wir sollten die Menschen nicht an ihren Worten, sondern an ihren Taten messen. Was ist das tatsächliche Ziel, wenn Dokumentation und Test nicht wichtig sind? Vordergründig lautet es sehr wahrscheinlich: Hauptsache es läuft! Das wahre Ziel dahinter lautet jedoch: Wir lieben das Gefühl des Erfolgs. Und wenn etwas läuft, beweist es sichtbar unsere Fähigkeit etwas zu erschaffen. Wer schnell loswurstelt erhält leider oft auch die schnelleren Erfolgserlebnisse. Dummerweise verzögert Dokumentation nicht nur Erfolgserlebnisse. Ein weiteres wahres Ziel lautet: Vermeide unangenehme Gefühle. Dokumentation jedoch kostet die meisten Entwickler Überwindung ( wir sind ja schließlich keine Schriftsteller ) und sie macht angreifbar. Testen wird dank langjähriger Konditionierung in Schule und Studium als Prüfung oder Kontrolle empfunden wird. Damit verbunden ist die Angst zu versagen oder aus Misstrauen überwacht zu werden. Warum beeinflussen uns diese wahren Ziele so stark in unserem Handeln? Unser emotionales Zentrum (sog. limbisches System) im Zwischenhirn reagiert schneller auf Reize als unser Verstand. Die Erwartung von Lust oder Schmerz löst dort unmittelbare Reaktionen aus, die durch Ausschüttung von Proteinen (Hormone, Peptide) die Reaktion des Großhirns beeinflussen. Unsere Fähigkeit zur rationalen Entscheidung durch unser Großhirn wird durch eine sehr grundlegende Bewertung des Zwischenhirns beeinflusst BEVOR wir anfangen, bewusst über unser Handeln nachzudenken. Das Großhirn mit seinen sehr komplexen Strukturen, die beispielsweise unser soziales Verhalten und strategisches Denken steuern, kann allerdings diesem Lustgewinn- oder Schmerzvermeidungsreflex entgegenwirken. Diese Hemmung erfordert jedoch eine gewisse Anstrengung. Gehirnforscher haben herausgefunden, dass diese Fähigkeit zur Hemmung mit der Zeit wie ein Muskel ermüdet oder funktionsunfähig wird, wenn sie zu oft o- der zu stark beansprucht wird. Je müder das Großhirn wird, desto mehr verschiebt sich das Handeln von langfristig vernünftigen zu kurzfristig befreienden Reaktionsmustern. Tätigkeiten, die als langweilig, unangenehm, sinnlos oder nicht unmittelbar zielführend empfunden werden, erfordern Disziplin. Disziplin erfordert mentale Energie, die sich mit der Zeit erschöpft. Abbildung 2: Limbisches System und Stammhirn Hoher Stress oder Paniksituationen gehören dagegen zu den sehr starken Reizen, die dazu führen, dass über die Stresshormone die hemmende Funktion des Großhirns weitgehend blockiert wird. Aus den oben gemachten Überlegungen ergeben sich mehrere Lösungsansätze: Zielsetzung und Werte Prozessgestaltung Methodenwahl Einsatz von Tools Weiche Faktoren Lösungsansätze die funktionieren, müssen zwangsläufig dabei helfen, der Ermüdung oder Blockade der hemmenden Interventionen durch das Großhirn entgegen zu wirken. Bei der Zielsetzung gilt es, das unausgesprochene und doch so dominant wirkende Dogma Hauptsache es läuft zu durchbrechen. Das bedeutet, dass den Qualitätszielen von Anfang an eine hohe Bedeutung im Entwicklungsprozess zukommt und nicht erst am Projektende versucht wird, Qualität in die Produkte hinein zu testen oder hinein zu basteln. Das könnte grob skizziert so aussehen: Das Management beweist durch sein Führungsverhalten und die Priorisierung, dass es bereit ist, diese Qualitätsziele nach innen und nach außen (Kunden) aktiv zu fördern, zu verteidigen und ggf. durchzusetzen. Auch wenn dies kurzfristige Nachteile bringt. Falls sich eine Maßnahme als unrealistisch oder in der Praxis als schwer durchführbar erweist, lässt man sie nicht unter den Tisch fallen,

38 sondern analysiert die Ursachen und erarbeitet Alternativen. Jeder äußert seine Bedenken, Anregungen und Wünsche zu den Zielen, Werten und Maßnahmen. Aus dieser Haltung heraus gilt es den Prozess zu gestalten. Zum einen können die hemmenden Instanzen dem Projektteam quasi zur Seite gestellt werden. Denkbare Maßnahmen sind unabhängige Qualitätsbeauftragte, die nicht Teil des Projektteams sind. Verbindliche Quality-Gates und Qualitätsrichtlinien stellen sicher, dass alle Qualitätsanforderungen erfüllt werden, bevor die nächste Projektphase gestartet wird. Damit diese Maßnahmen nicht als Gängelei empfunden werden, erfolgt eine Aufklärung über die psychologischen Hintergründe und Motive. Die gemeinsame Erarbeitung von Qualitätszielen, -merkmalen und -maßnahmen sichert die Akzeptanz und Kooperationsbereitschaft der Beteiligten. In diesem Zusammenhang ist auch die Aufdeckung der Diskrepanz zwischen gelebtem, vermutetem und dokumentiertem Prozess von großer Bedeutung. Am besten bringt man auch noch einen vierten Prozess ins Spiel: Den individuell gewünschten Prozess. Die zugegebenermaßen nicht einfache Aufgabe ist es, diese vier Prozesse so gut wie möglich unter einen Hut zu bringen, das Ergebnis mit Sinn zu erfüllen und zumindest die aktive Zustimmung der Mehrheit zu erzielen. Dies erfordert auch, dass unnötige Einschränkungen des gestalterischen Freiraums und übertriebene Bürokratie vermieden wird. Innerhalb des Prozesses werden die Methoden und dafür eingesetzten Tools so gewählt, dass sie die Erfüllung der Qualitätsziele unterstützen. So lässt sich beispielsweise durch die Wahl der Programmiermethode wie Clean Code Dokumentationsaufwand vermindern, weil die Dokumentation (bei richtiger Anwendung) weitgehend implizit im Programm enthalten ist. Methoden wie Design for Test sorgen von Anfang an dafür, dass Testbarkeit im Fokus der Aufmerksamkeit steht. Die korrekte Anwendung der gewählten Methoden wird durch eine professionelle Schulung bzw. Einarbeitung gefördert und durch regelmäßige Qualitätssicherungsmaßnahmen wie Reviews abgesichert. Gerade bei der Qualitätssicherung können Werkzeuge zur Softwareanalyse und Testautomatisierung wertvolle Dienste leisten, weil sie von unangenehmen und monotonen Aufgaben entlasten. Es empfiehlt sich dabei den Einsatz dieser Werkzeuge bereits von Anfang an in den Prozess zu integrieren. Die weichen Faktoren sind in diesem Zusammenhang nicht zu unterschätzen. Eine herausragende Rolle spielt das Kommunikationsverhalten des Projektteams und der ansonsten beteiligten Stakeholder. Eine lösungs- und lernorientierte Haltung verbunden mit offener Kommunikation und der Bereitschaft zuzuhören fördern die oben angedeuteten Maßnahmen. Die Fähigkeit des Teams unnötige Stresssituationen zu vermeiden bzw. auftretende Stresssituationen zu erkennen und zu entschärfen sorgt dafür, dass der gesunde Menschenverstand Kurzschlussreaktionen und Verzweiflungstaten verhindern kann. Eine gesunde Teamentwicklung und eine professionelle Teamleitung, die neben den fachlichen auch die sozialen und emotionalen Bedürfnisse der Beteiligten berücksichtigen, stellt also eine bedeutende Basis für den Erfolg der skizzierten Maßnahmen dar. Die Tendenz, in Projekten gegen besseres Wissen zu handeln, wird durch das existenzielle Bedürfnis nach Lustgewinn oder Schmerzvermeidung begünstigt und durch wachsenden Projektdruck und informelle Ziele wie Hauptsache es läuft verstärkt. Die hemmenden Faktoren, die dieser Tendenz entgegenwirken, können durch Zielsetzung, Prozessgestaltung, Methodenwahl und Toolwahl gefördert werden. Die Basis für den Erfolg ist eine Unternehmens- und Teamkultur der offenen Kommunikation, sowie eine konsequente Lösungsorientierung und Lernbereitschaft nicht nur in fachlicher sondern vor allem auch in sozialer und emotionaler Hinsicht. Falls Sie noch weitere Informationen zum Thema Wahrnehmungsverzerrungen in der Projektarbeit wünschen oder Ideen und Anregungen zu meinem Beitrag haben, senden Sie bitte eine mit dem Stichwort rosarote Brille. Daniel Kahneman, Schnelles Denken, Langsames Denken, Siedler, 2011 Michael Paschen, Erich Dihsmaier, Psychologie der Menschenführung, Springer, 2011 Peter Siwon, Die menschliche Seite des Projekterfolgs, dpunkt, 2010 Mark Solms, Olver Turnbull, Das Gehrin und die innere Welt, Patmos, 2009 Dipl. Ing. (Univ.) Peter Siwon Peter Siwon ist selbständiger Trainer, Coach und Autor von Kolumnen und Fachbüchern mit dem Schwerpunkt Die menschliche Seite des Projekterfolgs. Seit 2008 ist er als Lehrbeauftragter an mehreren Hochschulen tätig.

39 Als Software Consultant stößt man in seinem Leben relativ häufig auf historisch gewachsene Systeme. In diesem Erfahrungsbericht beschreiben die beiden Software Consultants Jan Deiterding und Martin Förtsch die Implementierung und Einführung eines vollständig automatisierten Entwickler-Testsystems bei der Kabel Deutschland Vertrieb und Service GmbH. Neben der geschichtlichen Entwicklung gehen die Autoren auf Continuous Integration Ansätze ein und schildern eine erfolgreiche Implementierung eines Test Driven Development Ansatzes im Produktivbetrieb. Als größter deutscher Kabelnetzbetreiber bietet das Vodafone Unternehmen Kabel Deutschland seinen Kunden hochauflösendes (HD) und digitales (SD) sowie analoges Fernsehen, Video-on-Demand, Angebote rund um digitale Videorekorder, Pay-TV, Breitband-Internet (bis zu 200 Mbit/s), WLAN-Dienste und Telefon über das TV-Kabel an. Zudem vertreibt Kabel Deutschland Mobilfunkdienste. Das im MDAX notierte Unternehmen betreibt Kabelnetze in 13 Bundesländern in Deutschland und versorgt rund 8,3 Millionen angeschlossene Haushalte. Zum 31. März 2014 beschäftigte Kabel Deutschland rund Mitarbeiter. Das Unternehmen mit Sitz in Unterföhring bei München erzielte im Geschäftsjahr 2013/14 einen Umsatz von rund Mio. Euro, das bereinigte EBITDA lag bei rund 910 Mio. Euro. Neben Neukunden existiert auch eine große Zahl an Bestandskunden mit Bestandsprodukten. Im Zusammenhang mit Premium- und Rabattaktionen führt dies zu einer Vielzahl möglicher Produktkombinationen. Für die Abteilung Webapplikationen der Kabel Deutschland ist es von höchster Priorität, in allen Webanwendungen für Endkunden und Mitarbeiter Produktkombinationen korrekt abzubilden. In einer sehr komplexen Produktmatrix sind alle erlaubten und verbotenen Kombinationen abgebildet. Aktuell ist diese Produktmatrix so umfangreich, dass durch manuelle Tests nicht alle Kombinationen geprüft werden können. An dieser Stelle muss Kabel Deutschland die vollständige Korrektheit der Umsetzung der Produktlogik durch eine automatisierte Testsuite sicherstellen. Die Kunden können bei Kabel Deutschland Produkte über drei Wege bestellen: Ein Kunde kann sich direkt über die Webseite von Kabel Deutschland anmelden und Produkte bestellen, sowie seine Verträge ändern. Es existieren Call-Center, die direkt für einen Kunden Neuabschlüsse sowie Änderungen an bereits bestehenden Verträgen vornehmen können. Weiterhin existieren eigene Kabel Deutschland- Shops und Franchisenehmer, bei denen ein Kunde vor Ort sein Angebot auswählen kann. Die Beratung erfolgt dabei durch das Personal vor Ort. Alle Möglichkeiten der Kundenverwaltung nutzen spezielle auf den jeweiligen Einstiegspunkt zugeschnittene Webportale, da teilweise Rabatt- und Sonderangebote auf den jeweiligen Vertriebskanal zugeschnitten sind. Neben dem eigentlichen Bestellprozess werden hierfür eine Reihe weiterer Systeme bzw. Webservices benötigt. So existiert für bestimmte Adressen beispielsweise ein Service für Verfügbarkeitsanalysen, um den Kunden über die maximale Bandbreite seines Internetanschlusses zu informieren. Darüber hinaus ist es im Rahmen von Kombipaketen oder Rabattaktionen nicht immer möglich, jede beliebige Kombination von Produkten auswählen zu können. Die Verwaltung dieser Produktlogik ist aufwändig und muss bei jedem neuen Release auf allen Portalen von Kabel Deutschland korrekt umgesetzt werden. Erschwert wird dies dadurch, dass alle relevanten Services mit korrekten Versionsabhängigkeiten deployed werden müssen, um Kommunikationsfehler der Services untereinander zu vermeiden.

40 Um sicherzustellen, dass die Produktlogik bei jedem Release mit jeder Service- und Versions- Kombination nur vorgesehene Produkte anbietet, wurde ein vollautomatisiertes Testsystem aufgebaut. Fehler bei der Verarbeitung der Produktlogik können so bereits während der Entwicklung erkannt und behoben werden. Das Testsystem führt Akzeptanztests auf allen Bestellprozess-Applikationen und Vertriebsportalen und Schnittstellen durch. Dabei werden zum einen Neukunden-Bestellungen simuliert, bei denen potentielle Kunden typische Produktkombinationen bestellen. Ein weiterer Testtypus versucht dediziert veraltete Produkte (beispielsweise aus Rabattaktionen) zu bestellen, die vom System zwar als korrekt erkannt werden, aber vom aktuellen Vertrieb ausgeschlossen sind. Für Bestandskunden werden Änderungen simuliert, in denen geprüft wird, ob bestimmte weitere oder zusätzliche Produkte bestellbar oder von der Vermarktung ausgeschlossen sind. Hier liegt die Schwierigkeit darin, dass Bestandskunden unter Umständen sehr alte Produkte und Produktkombinationen im Vertrag haben. Im Unterschied zu Unit- und Integrationtests arbeitet das hier vorgestellte System auf einer zur Produktion identischen Testinstanz, bei der eine vollständige Installation aller Services überprüft wird. Abbildung1: Tests werden in einer grafischen Benutzeroberfläche über eine domänenspezifische Sprache erstellt. Die einzelnen Einträge werden durch Icons grafisch unterschieden, so dass ein Bearbeiter direkt erkennen kann, welche Art von Information in diesem Feld verlangt wird. Ein Test besteht dabei immer aus einer Reihe von Komponenten: Eine Beschreibung des Kunden Es können sowohl Neu- als auch Bestandskunden ausgewählt werden. Weiterhin können diese Kunden noch detaillierter definiert werden. So ist es z.b. möglich für einen Neukunden Adressen zu verwenden, an denen nur bestimmte Services verfügbar sind. Bei Bestandskunden kann das Vorhandensein oder das Fehlen gewisser Bestandsprodukte definiert werden (siehe Abbildung). Abbildung 2: Für jeden Test kann detailliert angegeben werden, welche Eigenschaften ein Testkunde besitzen muss. In einem Test wird ein Neu- oder Bestandskunde definiert und neue Produkte bestellt oder im Falle von Bestandskunden vorhandene Produkte abbestellt o- der geändert. Diese Tests werden in einer Domänenspezifischen Sprache verfasst (Domain-specific language, kurz DSL), so dass zusätzlich zu den Entwicklern auch Mitarbeiter der QA-Abteilung in der Lage sind, Anforderungen an Produktkombinationen schnell und direkt als Test zu formulieren. Es wird eine grafische Benutzeroberfläche verwendet, so dass die Anforderungen an den Benutzer möglichst minimal sind (siehe Abbildung 1). Eine Beschreibung der eigentlichen Bestellung bzw. deren Änderung Hier wird angegeben welche Produkte an- oder abgewählt werden sollen. Hierbei ist die Reihenfolge wichtig, da unter Umständen die Auswahl eines Produktes erst die Möglichkeit für andere, darauf aufbauender Produkte freischaltet (siehe Fehler! erweisquelle konnte nicht gefunden werden.). Definition zu testender Portale Eine Angabe, in welchen Portalen von Kabel Deutschland der Test ausgeführt werden soll. Metainformationen über den Tests

41 Abbildung 3: In einer Testbeschreibung wird auf einen Testkunden verwiesen und angegeben, in welchem Vertriebsportal welche Produkte an- bzw. abgewählt werden sollen. Dies sind u.a. eine eindeutige ID und Referenzen auf Anforderungs- bzw. Bug-Dokumente. Um die Erstellung der Tests weiter zu vereinfachen, wurde ein Template-System in Kombination mit einer Icon-basierten Beschreibung verwendet. Der Ersteller eines Tests kann sich ein entsprechendes Template herunterladen, in dem ein Dummy-Test definiert ist. Durch Icons wird unmittelbar dargestellt, welche Information an welcher Stelle notwendig oder optional ist (siehe Abbildung 4). Im Gegensatz zu klassischen Unit-Tests werden für die Tests keine fixen Bestandskunden oder Neukunden mit statischen Adressen verwendet. Stattdessen wird bei jeder Ausführung des Tests ein Kunde zufällig aus einer anonymisierten Testkundendatenbank ausgewählt, welcher die gewünschten Merkmale besitzt. Damit wird sichergestellt, dass ein Test für möglichst alle Kunden mit den ausgewählten Eigenschaften funktioniert, da der Merkmalsraum deutlich größer ist, als die Anzahl der einschränkenden Kriterien. Die Kunden in der Testkundendatenbank werden dabei so generiert, dass der vorhandene Kundenstamm bei Kabel Deutschland vollständig abgebildet ist. Dabei wird auch die prozentuale Verteilung der Kunden auf verschiedene Segmente beibehalten. Das bedeutet, dass für stark nachgefragte Produkte entsprechend viele Testkunden in der Datenbank vorhanden sind. Produkte mit geringer Verbreitung erhalten entsprechend weniger Testkunden. Da nach der Ausführung eines Tests der Testkunde verändert worden ist, wird dieser entsprechend markiert und bei weiteren Anfragen an die Datenbank nicht mehr als Ergebnis zurückgeliefert. Die Testkundendatenbank wird in regelmäßigen Abständen neu erstellt. Programmiersprache wird Java verwendet. Da der eigentliche Ablauf des Tests immer identisch ist, müssen nur die Testparameter (Kunden, Produkte usw.) angepasst werden. Aus diesem Grund wird als Testframework das Open Source Werkzeug Concordion (siehe verwendet. Es besitzt den Vorteil, dass die Testbeschreibung inkl. der benutzten Testdaten und die Ausgabe des ausgeführten Tests in HTML erfolgen. Damit können auch Fachbereiche Testergebnisse direkt analysieren. Erfolgreiche Testfälle werden in grün, fehlgeschlagene Testfälle in rot dargestellt. Sollten im Test unerwartete Fehler (z.b. Java-Exceptions) auftreten, stellt Concordion diese ebenfalls dar (siehe Abb. 4). Im Falle von Oberflächentests in der GUI wird zusätzlich das Tool Selenium (siehe verwendet, mit welchem Klickstrecken abgebildet werden können. Werden Tests gegen Schnittstellen durchgeführt entfällt der Selenium- Teil. In diesem Fall werden nur Requests z.b. per SOAP abgeschickt und die Rückgabewerte der Webservices geprüft. Mit den daraus resultierenden HTML-Berichten können sowohl Entwickler als auch beteiligte Fachbereiche schnell und einfach erkennen, welche Annahmen in der Produktverarbeitungslogik korrekt oder falsch umgesetzt werden. Gleichzeitig stellt der in HTML geschriebene Test einen zusätzlichen Teil der Dokumentation dar. Die Tests werden automatisch vom entwickelten System in Programmcode übersetzt und ausgeführt. Als Abbildung 4: Ausgabe eines ausgeführten Concordion-Tests. Das Testergebnis wird in eine Html-Datei gerendert. Die ausgeführten Überprüfungen werden grün bzw. rot hinterlegt.

42 Entwickler benötigen schnelles Feedback, um zu verifizieren, dass ihre Änderungen in der Software korrekt sind. Dafür ist es notwendig, dass Tests möglichst zeitnah und schnell aus- und durchgeführt werden. Wenn man gegen ein Interface testet, ist die Ausführungszeit eines einzelnen Tests ca. fünf Sekunden. Im Falle eines automatisierten Akzeptanztests im Browser ist die durchschnittliche Dauer ca. 45 Sekunden. Für einen einzelnen Test ist dies ein akzeptabler Zeitraum. Bei einer Anzahl von momentan ca. 600 Tests summiert sich die Dauer jedoch auf einen nicht zu unterschätzenden Zeitraum. Dies kann insbesondere dann zu einem Problem werden, wenn die Tests von jedem einzelnen Entwickler lokal gestartet und ausgeführt werden sollen. Aus diesem Grund werden alle Tests in einem zentralen GIT-Repository gehalten, welches an einem Continuous Integration (CI) Server angeschlossen ist. Der CI-Server hat eine Reihe von Jobs, die Gruppen von Tests gegen verschiedene Instanzen laufen lassen (siehe Abbildung 5). Alle zwölf Stunden werden alle vorhandenen Tests gegen den aktuellen Entwicklungsbranch laufen gelassen. Der All-Job, in dem alle Tests ausgeführt werden, hat eine durchschnittliche Laufzeit von 2 Stunden. Um diese Ausführungszeit weiter zu reduzieren, wurde die Ausführung der Tests parallelisiert. Da alle Tests voneinander unabhängig sind, kann die Ausführung auf mehrere Instanzen (Slaves) aufgeteilt werden. Damit kann auch der All-Job in kurzen Zeiträumen aussagekräftige Ergebnisse liefern. Die Anzahl der Slaves kann hierbei konfiguriert werden. Um noch schnellere Feedbackzyklen zu ermöglichen, gibt es einen zusätzlichen Job, in dem nur die Tests laufen, die die wichtigsten Produkte von Kabel Deutschland testen. Die Laufzeit dieses Jobs beträgt weniger als fünf Minuten. Durch die regelmäßige, automatische Ausführung können Entwickler trotz der langen Laufzeit immer noch ausreichend schnell Feedback zu Ihren Änderungen erhalten. Weiterhin können Entwickler und Mitarbeiter der QA-Abteilung auch einzelne Tests auswählen und gegen beliebige Instanzen und Releaseversionen laufen lassen. Für detaillierte Fehleranalysen können Entwickler zusätzlich derartige Tests auch lokal ausführen. Damit jederzeit der Status des Gesamtsystems sichtbar ist, wurden in allen Entwickler-Büros Build-Monitore aufgestellt, welche den Zustand der wichtigsten Jobs in Ampelfarben visualisiert. So kann jeder Entwickler auf einen Blick erkennen, ob das Gesamtsystem korrekt läuft (siehe Abbildung 5). Im Rahmen der abschließenden Qualitätskontrolle vor jedem Release werden zusätzlich Tests von der QA-Abteilung umfangreich ausgeführt und geprüft. Abbildung 5: Im Continuous Integration Server werden alle Tests in regelmässigen Abständen gegen unterschiedliche Instanzen der Entwicklung und der QA ausgeführt. Schlagen ein oder mehrere Tests fehl, wird der Job rot hinterlegt und direkt in Dashboards in den Entwicklerbüros angezeigt. Um die Übersicht über alle Tests zu behalten, wurde zusätzlich eine Webanwendung auf Grundlage des O- pen Source Suchmaschinen-Frameworks Solr (siehe erstellt. In der entwickelten Anwendung werden alle Tests kategorisiert (siehe Abbildung 7 und Abbildung 6). Über die zugrunde liegende Suchmaschine können Freitextsuchen durchgeführt werden. Weiterhin wird für jeden Test eine Historie gespeichert, aus der ersichtlich ist, wann ein Test fehlgeschlagen ist und welche Fehlermeldung vom System generiert wurde. Neben der Freitextsuche können Tests auch nach Kategorien gruppiert werden. So kann ein Entwickler beispielsweise alle Tests anzeigen lassen, die nur auf einem spezifischen Kundenportal mit einer fest definierten Fehlermeldung fehlschlagen. Diese Gruppierungen können gespeichert werden und als separates Dashboard angezeigt werden. Dadurch ist es z.b. möglich alle Tests in einer Übersicht anzeigen zu lassen, die den Tarifwechsel überprüfen, für die separate Dashboards generiert werden können. So kann der Zustand eines bestimmten Testkomplexes in Sekundenschnelle angezeigt werden. Die Testverwaltung vereint Informationen aus mehreren Systemen und führt diese in der Suchmaschine zusammen. So können Testdefinitionen geöffnet, heruntergeladen oder ausgeführt werden. Informationen über Teststabilität und Erfolgsrate runden das Bild ab und geben dem Entwickler stets alle zusammengeführten Informationen auf einem Blick.

43 Abbildung 7: Oberfläche der Testsuchmaschine. Test können anhand eines freien Texts gesucht werden. Auf der linken Seite werden unterschiedlichsten Kategorien angezeigt, anhand derer die Auswahl eingeschränkt werden soll. Mittig wird in einem Balkendiagram das Verhältnis erfolgreicher zu fehlgeschlagenen Tests angezeigt. Darunter werden alle Tests angezeigt, die die momentan ausgewählten Kategorien und Schlagwörter erfüllen. Abbildung 6: Detailansicht eines Tests. Unterhalb des Testnamens werden Details wie Schlagworte, Erfolgsrate des Tests, etc. aufgelistet. Auf der rechten Seite befinden sich Buttons um aus der Suchmaschine heraus direkt die Testbeschreibung und das Ergebnis betrachten zu können, sowie ein Knopf um den Test direkt ausführen zu können. Mit Einführung dieses Systems gibt es erstmals ein mehrere Instanzen übergreifendes Entwicklungs- Testsystem für Web-Bestellprozesse bei Kabel Deutschland. Diese Tests lösen keine Tests innerhalb der einzelnen Komponenten ab, sondern prüfen das Zusammenspiel aller beteiligten Applikationen und Webservices. Die Ergebnisse werden in einer Webanwendung gebündelt und sowohl für Entwickler als auch Mitarbeiter der QA komfortabel angezeigt. Durch die Einbindung in ein Continuous Integration- Systems werden die aktuellen Testergebnisse zeitnah bereitgestellt. Dieser Ansatz wurde gewählt, um in einem historisch gewachsenen System in der Lage zu sein, neben dem Refactoring neue Funktionen zu implementieren und dabei zu gewährleisten, dass die Funktionstüchtigkeit des Systems zu bewahrt wird. Nach der erfolgreichen Etablierung des Test Driven Development Ansatzes und des Continuous Integration Ansatzes konnte parallel damit begonnen werden, Tests auch auf Unitund Komponentenebene zu implementieren. Die Verbesserung der Softwarequalität zeigt sich insbesondere bei Betrachtung der Entwicklung der Wirkbetriebsfehler (siehe Abbildung 8). Zusätzlich wird in einem zweiten Diagramm die zeitliche Änderung der Lieferleistung angegeben (siehe Abbildung 9). Für beide Diagramme wurden Bezugswerte vom Monat Juni im Jahr 2009 definiert und deren relativen Veränderungen von diesem Wert ausgehend.

44 Abbildung 8: Anstieg der Lieferleistung (im Bezug zum Referenzmonat Juni 2009) im Bereich der Webentwicklung. Seit Einführung des Test Driven Developments konnte ein deutlicher Rückgang der Wirkbetriebsfehler festgestellt werden. Außerdem erfolgte seitdem eine stetige Steigerung der Lieferleistung. Verbesserte Requirements-Dokumente oder eine verbesserte abteilungsübergreifende Kommunikation in diesem zeitlichen Verlauf können sich jedoch ebenso positiv auf die Softwarequalität ausgewirkt haben. Die Softwarequalität hat sich nicht nur hinsichtlich der Produktionsfehler verbessert. Die Anzahl der in der QA-Phase gefundenen Fehler ist trotz teilweise zweifach gestiegener Lieferleistung auf einem stabilen Niveau geblieben. Abbildung 9: Reduzierung der gefundenen Fehler im Wirkbetrieb (im Bezug zum Referenzmonat Juni 2009) im Bereich der Webentwicklung Dr. Jan Deiterding und Dipl. Inf. (FH) Martin Förtsch Jan Deiterding und Martin Förtsch von der TNG Technology Consulting GmbH ( waren an der Automatisierung des Entwickler -Testframeworks bei der Kabel Deutschland Vertrieb und Service GmbH ( beteiligt.