„Erste Hilfe – Selbsthilfe.“ So oder so ähnlich lauten typische Werbeslogans von Hilfsorganisationen, wie Brot für die Welt. Der Slogan bezieht sich auf das Leben von Menschen in Ländern des Globalen Südens, die irgendwie befähigt werden sollen, ihr Leben unter schwierigen Bedingungen zu gestalten. Äthiopien befindet sich beispielsweise auf Platz 173 des Human Development Indices, einem Wohlstandsindikator der Vereinten Nationen.
Entsprechend hart ist das Leben in Ländern des Globalen Südens: Es gibt beinahe täglich Stromausfälle, die Internetverbindungen sind schlecht und in vielen abgelegenen Ecken dieser Länder gar nicht vorhanden, die Wasserversorgung ist schlecht und nicht regelmäßig gewährleistet und die Straßen haben tiefe Schlaglöcher. Außerdem ist die politische Lage in sogenannten Least Developed Countries unsicher und unbeständig. Kurz bevor ich am 25. Juli 2019 aus der Hauptstadt Äthiopiens, Addis Abeba, zurückkehrte, gab es auf Grund eines lange schwelenden ethnischen Konflikts einen blutigen Putschversuch in dem Land am Horn von Afrika. Die Lage hat sich noch immer nicht beruhigt. Für die Menschen in diesen Ländern führen diese Umstände zu einem Leben in ständiger Bedrohung und Gefahr: Gefahr vor gewalttätigen Auseinandersetzungen, aber auch ein Abgeschnittensein von der Außenwelt, denn im Falle des Putschversuchs in Äthiopien wurden sofort von offizieller Seite sämtliche Telekommunikationswege gekappt.
Sustainable Development Goals
Trotz dieser traurigen und ernüchternden Situation befindet sich die Welt, wie wir sie kennen, an einem Scheideweg. Es gibt stetige Bemühungen, die Lebensbedingungen der Menschen zu verbessern. Die Regierungen der Vereinten Nationen haben 2012 beschlossen, sogenannte Sustainable Development Goals zu entwerfen. Damit wollen sie die Entwicklung der Weltökonomie, der Gesellschaft und des Ökosystems auf der Erde nachhaltig verbessern.
Zusammenhang von entwicklungspolitischen Projekten und dem Software Test Management
Was aber haben ein erfolgreiches, nachthaltiges, entwicklungspolitisches Projekt in Madagaskar, Äthiopien oder Tansania und das Software Test Management für ein Unternehmen gemeinsam? Die Antwort ist einfach: Die Konzepte aus der nachhaltigen Entwicklungszusammenarbeit und der dafür notwendigen Steuerung können auf Softwareentwicklung und Softwaretest übertragen werden. Innerhalb der Human-Centered Informatics wird dies schon seit einer Weile gemacht. So werden Konzepte wie die Wirkungskettenanalyse, die ursprünglich verwendet wurde, um z.B. Probleme von Wasserknappheit in den ländlichen Regionen Kenias zu lösen, erfolgreich auf Fragen des Designs von Softwaresystemen angewendet. Eine Wirkungskette ist ein Tool, das unter anderem in der Entwicklungspolitik eingesetzt wird und bei dem man – von einem ursächlichen Ereignis ausgehend – eine Kette nachfolgender Ereignisse nachvollzieht. So lässt sich analysieren, wie diese Ereignisse miteinander kausal in Verbindung stehen.
Im Softwaretest in großen Softwareprojekten können verschiedene Evaluations- oder sogenannte Governance-Methoden zum Einsatz kommen. Eine Evaluationsmethode ist die so genannte Politikfeldanalyse. Sie fragt nach, was die Akteure in einem gewissen Kontext tun, warum sie es tun und was sie letztlich bewirken. Aber auch Governance-Methoden wie der Inkrementalismus werden genutzt. Inkrementalismus beschreibt einen Politikstil zurückhaltenden Reformierens, der durch Versuch und Irrtum gekennzeichnet ist. All diese Methoden stammen eigentlich aus den Sozialwissenschaften. Die Ansätze fließen heute in die sogenannte agile Softwareentwicklung ein.
Die Teststrategie
Der Test eines großen Softwaresystems ist eine sehr spezielle und schwierige Aufgabe. Sie braucht einen speziellen Testansatz: Releases von neuen Features und Hotfixes können unerwünschte Fehler in anderen Teilen der Software nach sich ziehen. Hotfixes sind Softwareaktualisierungen, die der Softwarehersteller seinen Kund*innen kurzfristig zur Verfügung stellt. Das Ziel einer robusten und nachhaltigen Teststrategie besteht deshalb darin, die Risiken von Fehlern zu reduzieren und Fehler in der Software zu finden, bevor sie an den Kunden ausgeliefert wird. Das erhöht die Kundenzufriedenheit und senkt die Entwicklungskosten, denn früh gefundene Fehler sind wesentlich einfacher zu beheben als Fehler, die erst nach ihrer Auslieferung entdeckt werden.
Testmethode ATDD
Daher erweitert DATEV im Kassenarchiv online, einer Onlineanwendung für das gesetzeskonforme Speichern von Daten aus elektronischen Kassen, das Acceptance Test-driven Development (ATDD) mit Hilfe entwicklungspolitischer Methoden. ATDD ist eine Testmethode, in der Testfälle in einer speziellen Programmiersprache namens Gherkin oder mit einem Softwarepaket namens Spock in Form von Akzeptanzkriterien geschrieben werden, um so die automatisierten Testfälle direkt gegen diese Kriterien schreiben zu können.
Diese erweiterte Testmethode nennt sich Ownership-inspired risk-based Acceptance Testdriven Development (OIRATDD). OIRATDD nutzt Methoden aus der Politikwissenschaft und der Verwaltungswissenschaft, die die innere Haltung verändern und so zu einem veränderten Handlungsmuster führen. Sie nutzt also Methoden, die in entwicklungspolitischen Projekten verwendet werden und bringt sie in den Kontext des Softwaretests. In Gottschalk und Winther-Nielsen (2018a; 2018b; 2018c) wurde OIRATDD bereits als eine entwicklungspolitische Methode eingeführt und in einem Projekt in Madagaskar verwendet. Dabei zeigte sich, wie wichtig Ownership ist.
Ownership für ein Projekt zu übernehmen bedeutet, Verantwortung für das jeweilige Produkt zu übernehmen. Dies soll jedoch nicht nur Projektleiter*in oder Product Owner*in tun, sondern das gesamte Team – das nennt man Whole Team Quality. Ownership setzt sich aus folgenden Merkmalen zusammen:
– Partizipation
– Leadership
– Monitoring
– Feedback
Partizipation bedeutet, dass jedes Teammitglied im Rahmen des agilen Prozesses an der Entstehung des Produktes teilnimmt und sich auch über Hierarchiegrenzen und Rollendefinitionen hinweg beteiligen darf. Unter Leadership wird verstanden, dass im Falle des Testmangements die Mitarbeiter*in mit der Verantwortung für die Qualitätssicherung Führung übernehmen darf und soll, d.h. die Teststrategie und die Ausformungen der unterschiedlichen Teststufen festlegen darf. Dies geschieht unabhängig von der Verantwortungsebene oder der Führungsverantwortung. Monitoring heißt, dass die Testergebnisse für alle Mitarbeiter*innen überprüfbar sind. Beispiele hierfür sind Bug Lanes, also einer Spalte, in der alle Fehler am Kanban Board festgehalten werden, und Dashboards, also einer digitalen Darstellung z.B. der Fehlersituation eines Projekts in grafischer Form. Und was ist Feedback? Da gibt es auf der einen Seite das direkte Feedback durch Testfälle, die im besten Fall grün, d.h. erfolgreich, im schlechtesten Fall rot, d.h fehlgeschlagen sind. Aber es bedeutet auch, dass es auf sozialer Ebene sachbezogenes und respektvolles Feedback innerhalb des Teams z.B. in Retrospektiven gibt, natürlich aber auch auf dem kurzen Dienstweg, in Dailies oder im Daily Doing.
Der Begriff des risiko-basierten Testens in OIRATDD bezieht sich darauf, dass das Team in sogenannten kleinen und großen Refinements ein gemeinsames Verständnis darüber entwickelt, dass die Hauptrisiken bei der Implementierung neuer Features identifiziert und diese deshalb zuerst getestet werden müssen. Refinements sind Team Meetings, in denen die konkreten Aufgaben eines jeden Teams im Detail diskutiert werden.
Softwaremethode OIRATDD
OIRATDD ist eine Erweiterung agiler Softwaremethoden, die auf sogenanntem Test-driven Development basieren. Dabei schreiben Entwickler erst Testfälle für ein Problem, um anschließend eine Lösung zu implementieren. Eine Erweiterung von Test-driven Development stellt Acceptance Test-driven Development dar. Dabei spezifiziert der Product Owner innerhalb eines Scrum Teams Acceptance Testfälleanhand von Akzeptanzkriterien, die das zu entwickelnde Feature erfüllen muss. Daraus können Entwickler ihren Code entwickeln. Im Vergleich zum Test-driven Development wird die Dimension des Accenptance Test-driven Developments, welches Entwickler auf Basis von Unit Tests verwenden, um Akzeptanztests erweitert, die vom Product Owner in der Programmiersprache Gherkin entwickelt worden sind. Es werden neben sehr abstrakten, kleinteiligen Tests, die bestimmte Zeilen Code der/des Entwickler*in testen, auch Testfälle geschrieben, die größere Szenarien anhand der Akzeptanzkriterien der Software entwickelt.
Die wichtigsten Methoden, die man im Rahmen des OIRATDD aus der Entwicklungszusammenarbeit nutzen kann, gehören zum PRA/PLA gehören. Bei PRA/PLA handelt es sich um das sogenannte Particpatory Rural Appraisal, bzw. um Participatory Learning and Action. Das ist ein Toolkit von Methoden z.B. für Retrospektiven, um effizienteres Arbeiten zu ermöglichen. In einem klassischen entwicklungspolitischen Projekt handelt es sich um Methoden zur Identifizierung von z.B. der Frage, warum bestimmte Ziele in einem Projekt nicht erreicht werden konnten. Demnach ist PRA/PLA auch eine Technik zur Evaluation von Projekten. Beispiele hierfür sind unter anderem Interviews mit Projektteilnehmer*innen, Wirkungsketten, Retrospektiven, also Teammeetings. Hier diskutieren Teilnehmer zum Beispiel über die Verbesserung der Arbeitseffizienz und Lösungen sozialer Konflikte. So können sie Teams bei einer agilen Transformation begleiten und sie empowern, so dass sie, basierend auf ihren Bedürfnissen, eine teameigene Strategie entwickeln können, die genau ihren Bedürfnissen entspricht.
OIRATDD ist ein agiler Werkzeugkasten, der agile Teams dazu befähigt, effizienter zu arbeiten, um ein stärkeres Ownership für ihre Codequalität zu entwickeln und die Teamkultur zu verbessern. Mit OIRATDD kann frühzeitiges Softwaretesting eingesetzt werden und so der Scrummerfall, als eines von vielen Antipattern, also ein Verhalten, dass ungünstig oder schädlich für den jeweiligen Entwicklungsprozess ist, in der agilen Softwareentwicklung, der Vergangenheit angehören. Im Scrummerfall fallen agile Teams in ein Muster zurück, in dem sie das bekannte Entwicklungsmodell des Wasserfalls in einen Sprint einbauen und so das Wasserfallmodell, das eine lineare Abfolge von Projektphasen beschreibt, ohne kurzfristige Änderungen durchführen zu können, statt über viele Monate alle zwei Wochen durchlaufen.
Dieser Blogeintrag ist eine Zusammenfassung des Vortrags, den ich bei der DWX 2019 in Nürnberg hielt (https://www.developer-week.de/programm-2019/#/talk/was-wir-von-entwicklungspolitischen-projekten-in-madagaskar-kenia-und-tansania-fur-das-testmanagment-lernen-konnen-ein-interaktiver-vortrag).
Hier schreibt für euch:
Ein Kommentar
Software Management ist ein wirklich sehr, sehr spannendes und auch interessantes Thema muss ich sagen. Bitte mehr davon.