Ein Angebot von

Outsourcing in agilen Software-Entwicklungsprozessen

| Autor / Redakteur: Dr. Hartmut Lackner * / Sebastian Gerstl

Bild 1: Agile Softwareentwicklung.
Bild 1: Agile Softwareentwicklung. (Bild: Model Engineering Solutions GmbH)

Outsourcing von Testdienstleistungen liefert schnellere und bessere Ergebnisse als die Inanspruchnahme firmeninterner Ressourcen - so die Erwartung. In der Realität ist dies möglich, aber keinesfalls immer der Fall. Unter welchen Voraussetzungen ist Outsourcing von Test- und anderen qualitätssichernden Dienstleistungen im agilen Umfeld möglich?

Für Outsourcing der Qualitätssicherung gibt es viele (gute) Gründe: Die Entwickler sollen sich auf das Wesentliche – das Entwickeln nutzbringender Funktionen – konzentrieren, spezialisierte Anbieter können Testdienstleistungen günstiger anbieten als wenn diese im eigenen Haus erbracht werden und manchmal fehlen schlicht Zeit/Personal, um die Aufgaben zu bewältigen. Außerdem ist der Arbeitsaufwand für die Qualitätssicherung häufig vom Release-Zyklus der Produkte abhängig, denn zum Release-Termin hin wächst der Testaufwand erfahrungsgemäß. Nur, wohin mit den Testern nach dem Release-Termin?

Neben diesen ressourcen-orientierten Überlegungen gibt es auch durch Standards motivierte Aspekte: Auch die Entwicklung sicherheitskritischer Software profitiert vom Outsourcing. Bei solcher Software fordern Standards für einige Sicherheitsstufen den Nachweis über eine organisatorische Trennung der Entwicklungs-Teams von der Qualitätssicherung. In agilen Teams, in denen typischerweise ein hoher Grad an Arbeitsteilung herrscht, ist jedoch eine Trennung von Natur aus nicht gegeben. Wenn aber keine organisatorische Trennung besteht, stellt sich die Frage, wie bei einem derartig verzahnten Team überhaupt sinnvoll Outsourcing betrieben werden kann. Hierfür schauen wir uns zunächst einen agilen Softwareentwicklungsprozess genauer an und identifizieren, in welchen Stufen getestet wird. Haben wir diese identifiziert, können wir sehen, in welcher Form Outsourcing möglich wird. Hierzu zählen wir Onsite-Sourcing (Dienstleister beim Kunden) und die Varianten des Outsourcings: On-, Near- und Offshoring (Inland, Region, weltweit).

Teststufen

Agile Software-Entwicklungsprozesse zeichnen sich durch eine iterative und inkrementelle Vorgehensweise aus. Die Teams organisieren sich selbständig, kommen mit wenig bürokratischem Aufwand aus und reagieren kurzfristig auf Änderungswünsche der Kunden. Scrum, Kanban und Extreme Programming sind nur einige von vielen agilen Prozessen. Bild 1 zeigt das typische Muster für einen agilen Software-Entwicklungsprozess: Er beginnt mit einer Planungsphase, in der die Ziele für den kommen Zyklus – häufig als Sprint bezeichnet – gesetzt werden. Diese Ziele sind Funktionalitäten, die das Produkt mit Abschluss des kommenden Sprints besitzen soll. Es folgt eine Entwurfsphase (Design) in der die Ziele konkretisiert werden und an deren Anschluss (Develop) die Software implementiert und getestet werden kann. Die Ergebnisse und der Prozess werden anschließend begutachtet (Review). Gegebenenfalls findet eine Übergabe an den Kunden statt und es beginnt ein neuer Sprint unter Berücksichtigung der gemachten Erfahrungen. Jeder Sprint dauert ca. zwei bis vier Wochen, je nach konkretem Prozess, Projekt und Team.

Testaktivitäten sind in Abbildung 1 bewusst nicht ausgezeichnet, da diese je nach Ausprägung des agilen Entwicklungsprozesses an verschiedenen Stellen stehen können. Im Folgenden identifizieren wir vier solche Stellen und diskutieren ihr Potenzial zum Outsourcing.

Prinzipiell können wir feststellen, dass durch die kurzen Release-Zyklen die Testaufwände deutlich kontinuierlicher anfallen, als dies bei einem Prozess nach Wasserfall- oder V-Modell der Fall wäre. Auftraggeber und Dienstleister können somit ihre Ressourcen vorausschauender planen und eine andauernde Beziehung aufbauen.

Test und Testentwicklung im Sprint

Zunächst betrachten wir die Testentwicklung und -durchführung als Teil der Softwareentwicklung (Develop) während eines Sprints: Die Testentwicklung kann dabei vor, parallel oder nach der Implementierung der Software stattfinden. In einem agilen Musterprozess würden Projektmitarbeiter sowohl in der Rolle des Entwicklers als auch des Testers auftreten. Eine strikte Trennung, wie sie beim Outsourcen des Tests eintritt, ist nicht optimal, aber im Sinne der agilen Entwicklung – welche auch die besonderen Stärken der Teammitglieder berücksichtigen will – tolerabel. Auch tägliche Besprechungen von Angesicht zu Angesicht haben in der agilen Entwicklung einen hohen Stellenwert.

Wegen der notwendigerweise engen Zusammenarbeit mit den Mitarbeitern vor Ort ist die Präsenz des Test-Dienstleisters beim Kunden sehr zu empfehlen. On- und Nearshoring kommen auch in Frage, wenn die Mitarbeiter des Dienstleisters durch geeignete Kommunikationsmittel unterstützt werden. So behält auch der Auftraggeber den Überblick, ob das ausgelagerte Testteam die Geschwindigkeit des Sprints hält. Offshoring hingegen ist wegen Zeitverschiebungen und Sprachbarrieren eher ungeeignet.

Tests als Spezifikation

Im Rahmen der Tests-First-Methode werden Tests bereits vor der Sprintplanung als Teil der Software-Unit-Spezifikation entwickelt. Erst wenn diese fertig ist, darf die zu entwickelnde Funktionalität für einen Sprint eingeplant werden.

Hierbei kommt es vor, dass die textuelle Unit-Spezifikation zu Gunsten der Testentwicklung knapper ausfällt. Für ständig präsente Teammitglieder stellt dies kein Problem dar, weil sie eng in die Entwicklung einbezogen sind und durch ihre Präsenz Fragen kurzfristig klären können. Die Nähe zum Team ist hier ebenso wichtig, wie in der Testentwicklung im Sprint.

Vollständigkeit der Tests

Die Testentwicklung lässt sich teilweise auch in spätere Phasen verlagern. So kann während eines Sprints vorrangig das funktionale Verhalten der Unit Under Test abgesichert werden. Weitere Tests zur Erfüllung von definierten Code-Abdeckungskriterien können in einer nachgelagerten Phase folgen. Da der Großteil der Funktionalität bereits abgetestet ist, besteht erfahrungsgemäß nur wenig inhaltlicher Diskussionsbedarf. Die Tester können deshalb selbständig weitere Testfälle entwickeln und sich an den bereits existierenden orientieren.

Die Vollständigkeit und Richtigkeit des vom Dienstleister gelieferten Ergebnisses ist leicht mit Code-Abdeckungswerkzeugen nachzuvollziehen. Auch besteht kein unmittelbarer Zeitdruck für den Test, sodass ein Dienstleister freier in der Planung seiner Ressourcen ist. Diese Trennung der Testaktivitäten eignet sich deshalb besonders zum Offshoren.

Integrations- und Systemtest

Die Pflege der Integrations- und Systemtests in einem agilen Softwareentwicklungsprozess ist aufwändig: Regelmäßig wächst und ändert sich der Funktionsumfang des Produktes, sodass die Tests kontinuierlich gepflegt werden müssen. Ein umfassendes Systemverständnis ist an dieser Stelle Voraussetzung zur Entwicklung wirksamer Tests.

Der Aufwand zur Pflege ist auf dieser Ebene nicht mehr so kontinuierlich wie zuvor: Bereits kleine Änderungen ziehen gelegentlich umfangreiche Änderungen der Tests nach sich. Zur Gewährleistung der Testqualität ist es sinnvoll hier mit einem Dienstleister zusammenzuarbeiten, damit dieser Spitzenlasten abfedert. Schwieriger ist jedoch die Integration seiner Mitarbeiter, da diese nur abschnittsweise am Projekt teilhaben.

Hilfreich ist ein verlässlicher Partner mit geringer Fluktuation, der für das laufende Projekt immer wieder projekterfahrene Mitarbeiter heranziehen kann. Die Verlässlichkeit des Partners wiegt in diesem Fall schwerer als seine geografische Nähe. Deshalb kommen auch hier On- und Nearshoring-Partner in Frage. Bei ausreichend Vertrauen kommt auch Offshoring in Betracht.

Den Umfang definieren

Bild 2: Ursachen für das Scheitern von Outsourcing (Mehrfachnennung möglich).
Bild 2: Ursachen für das Scheitern von Outsourcing (Mehrfachnennung möglich). (Bild: Model Engineering Solutions GmbH)

Aus Erfahrung wissen wir, dass die klare und genaue Definition der auszugliedernden Aufgaben von entscheidender Bedeutung für deren erfolgreiche Erledigung ist. Unabhängige Studien belegen dies, wie z.B. EquaTerras Outsourcing-Studie. Die größten Probleme in ausgelagerten Testprojekten sind das Verständnis über den Umfang des Testprojektes und deren Steuerung. Unangemessene Planung und unzureichende Fähigkeiten/Werkzeuge auf beiden Seiten folgen.

Deshalb ist es in agilen Softwareentwicklungsprojekten mit Outsourcing der Qualitätssicherung umso wichtiger, sich der Teststufe und den damit verbundenen Aufgaben bewusst zu sein. Dies betrifft nicht nur den Auftraggeber, sondern auch den Dienstleister.

In diesem Beitrag wurden die wesentlichen Testphasen und Schnittstellen identifiziert. Diese reichen von Unit-Tests während eines Sprints über die Teilung der Testaktivitäten über mehrere Sprints bis hin zum kontinuierlichen Systemtest. Nicht alle eignen sich gleichermaßen zum Outsourcen. Insbesondere innerhalb der Sprintphasen ist Nähe zum Auftraggeber gefragt. Moderne Kommunikationsmittel unterstützen den Dienstleister dabei, diese Nähe herzustellen. In späteren Phasen ist diese nicht mehr so essenziell, sodass auch entfernte Dienstleister zur Optimierung der Kosten in Frage kommen.

Der Autor

Dr. Hartmut Lackner, Model Engineering Solutions GmbH
Dr. Hartmut Lackner, Model Engineering Solutions GmbH (Bild: Model Engineering Solutions)

* Dr. Hartmut Lackner ist seit 2016 Leiter des MES Test Centers. Mit seinem Motto: „Das Leben ist zu kurz für manuelles Testen“, hat er sich dem automatisierten Testen verschrieben. Dieses Thema hat ihn auch während seiner Promotion an der Humboldt-Universität zu Berlin sowie als Leiter industrieller Forschungsprojekte am Fraunhofer Institut FOKUS begleitet. Als Leiter des MES Test Centers bringt er das Testen komplexer Softwaremodelle weiter voran.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45661108 / Agilität)