ESE Fachwissen
Qualität auf Abruf
Autor: Dr. Hartmut Lackner, Model Engineering Solutions GmbH
Beitrag - Embedded Software Engineering Kongress 2017
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. In diesem Vortrag erfahren die Teilnehmer unter welchen Voraussetzungen Outsourcing von Test- und anderen qualitätssichernden Dienstleistungen im agilen Umfeld möglich und erfolgreich ist.
Die eigenen Ziele nicht aus den Augen verlieren
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. Abbildung 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 (s. PDF) 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
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.
(s. PDF Abbildung 2)
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.
Autor
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.
Test, Qualität & Debug - unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualität & Debug.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Test, Qualität & Debug - Fachwissen
Wertvolles Fachwissen zum Thema Test, Qualität & Debug steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.