Abb. 1: Darstellung eines vernetzten Reisemobils Copyright: Truma Gerätetechnik
Als innovatives mittelständisches Unternehmen in einer schnell wachsenden und sich zunehmend digitalisierenden Branche stehen wir vor der Herausforderung, unsere Projekte schnell und effizient abschließen zu können. Bei unserem herkömmlichen Ansatz erarbeitet ein Requirements Engineer (RE) am Projektbeginn die Anforderungen mit den Stakeholdern, um die Eckpfeiler für das Produkt festzulegen. Die detaillierten technischen Anforderungen werden während der Projektlaufzeit von den Product Ownern mit dem Team ohne den RE erarbeitet und realisiert.
Wir haben festgestellt, dass diese Konstellation so lange gut funktioniert, bis die Anforderungen eine höhere Komplexität erreichen oder Abhängigkeiten zu anderen vernetzten Produkten oder Systemkomponenten bestehen.
Speziell bei der Entwicklung von smarten Systemen mit verteilten Funktionen wird das Team während der Entwicklungsphase immer wieder mit sich verändernden Anforderungen und technischen Herausforderungen konfrontiert. Dies führte zu einer schlechteren Performance des Teams bei der Realisierung von Features. Retrospektiv haben wir festgestellt, dass viele dieser Probleme durch ein kontinuierliches Einbinden eines RE hätten vermieden werden können. Da wir in jedem agilen Team die Rolle des Test Engineer (TE) von Projektbeginn bis -ende vorsehen, entstand die Überlegung, die Rolle des REs und TEs zu kombinieren. Hieraus entstand der neue Ansatz, den wir in einem ersten Projekt erfolgreich eingesetzt haben (siehe Abbildung 2).
Abb. 2: Schematische Darstellung der Doppelrolle aus RE und Tester im Vergleich zum herkömmlichen Ansatz
Pilotprojekt mit Doppelrolle RE/TE
Nach dem ersten Projekt, das wir mit der Doppelrolle durchgeführt haben, ist ein Erfahrungsbericht und eine Bewertung möglich. Als Pilotprojekt haben wir uns für eine Weiterentwicklung eines bestehenden Produkts entschieden, welches in unsere vernetzte Systemlandschaft integriert wird. Dabei handelt es sich um ein Diesel-Kombinationsheizgerät für Caravans und Reisemobile.
Der Anteil des Elektronikentwicklungsteams umfasste eine Applikations- und eine Steuerungssoftware, diese wurden am Ende durch 670 Requirements abgebildet und durch 800 Testfälle verifiziert. Sowohl die Anforderungen als auch die Testfälle wurden in dem Softwaremodellierungswerkzeug Enterprise Architect (EA) in tabellarischer Form erstellt und verwaltet. Die Verlinkung zwischen Anforderung und Testfall wurde durch Use-Case-Links hergestellt.
Das Team bestand aus drei Software- und einem Hardwareentwickler, der Doppelrolle RE und TE, einem weiteren Test Engineer und einem technischen Projektleiter.
Die Herausforderung aus Sicht des Requirements Engineering war es, die neuen Anforderungen homogen in die bestehende Spezifikation einzubinden. Da eine wesentliche Komponente des Produkts verändert wurde, entschieden wir uns, die Spezifikation anhand von Komponenten zu strukturieren und nur die geänderte Komponente zu ersetzen. Hierfür wurden in den ersten 2 Monaten des Projekts über 100 neue Anforderungen für die zu ersetzende Komponente abgestimmt und spezifiziert. Zudem waren noch weitere Anpassungen bei anderen Komponenten notwendig. Die Kernarbeit des Requirements Engineering war nach circa 3 Monaten abgeschlossen und unser Mitarbeiter konnte den Fokus ab diesem Zeitpunkt auf das Testing legen.
Im weiteren Verlauf des Projekts haben wir eine Verteilung von 70 Prozent für die Test Engineering- und 30 Prozent für die Requirements Engineering-Aufgaben geplant. Um eine gewisse Unabhängigkeit sicherzustellen, bekam unser Mitarbeiter noch Unterstützung von einem weiteren Kollegen, der mit 50 Prozent Kapazität bei der Erstellung und Durchführung der Testfälle unterstützte. Die bestehende Testspezifikation musste anhand der geänderten Anforderungen angepasst werden, zudem wurde eine leichtgewichtige Automatisierungslösung umgesetzt und das Produkt iterativ getestet. Nach einer kurzen Einarbeitungsphase konnte unser Mitarbeiter die Aufgaben im Testing problemlos selbstständig lösen. Dazu muss gesagt werden, dass unser Mitarbeiter zuvor schwerpunktmäßig Requirements Engineering betrieben und relativ wenig Erfahrung im Testing mitgebracht hat.
Nach einigen Monaten war die Testspezifikation auf aktuellem Stand und die Testautomatisierung war lauffähig sowie einige Dutzend wesentliche Testfälle automatisiert. Die beiden Mitarbeiter konnten die Aufgaben in der Testfallerstellung und der Testausführung gut bewältigen. Zudem gab es im Verlauf des agilen Projekts stetig Anpassungsbedarf an den Anforderungen. Diese zu konsolidieren und zu spezifizieren, war dem Mitarbeiter mit der verfügbaren Kapazität für das Requirements Engineering leicht möglich.
Erste Erkenntnisse
Die Qualität der Software wurde durch kontinuierliche Bug Fixes gesteigert und hatte bereits weit vor dem geplanten Release eine hohe Güte erreicht. In Summe wurden sowohl die Aufgaben im Requirements Engineering als auch im Testing zur vollen Zufriedenheit des Projekts bearbeitet. Einer der größten Vorteile der Doppelrolle aus RE und TE ist aus unserer Sicht, dass durch das massive Produktwissen aus der Requirements Engineering-Phase eine Einarbeitung in das Testing sehr schnell möglich ist. Das Verständnis über die Funktionen und die Inhalte der Requirements muss nicht erst durch Abstimmung zwischen RE und TE aufgebaut werden, sondern ist bereits vollumfänglich vorhanden.
Die große Sorge, durch die verloren gegangene Unabhängigkeit zwischen RE und TE Lücken in der Spezifikation und falsche Anforderungen zu übersehen, hat sich im Kontext dieses Projekts nicht bewahrheitet. Zudem hat ein zweiter Test Engineer zur Herstellung einer gewissen unabhängigen Sichtweise beigetragen, auch wenn diese sicher nicht auf den vollen Funktionsumfang hergestellt werden konnte.
Eine weitere wichtige Erkenntnis ist, dass diese Doppelrolle nur von Personen ausgefüllt werden kann, die Eigenschaften wie Flexibilität, effiziente Arbeitsweise sowie den Wunsch, Neues kennenlernen zu wollen, mitbringen. Zudem brauchen sie den ständigen Antrieb, sich weiterzuentwickeln, und sollten Spaß daran haben, viele verschiedene Aufgaben zu bewältigen. Der Typ Requirements Engineer, der gerne Dokumente wälzt und Formalismen einhält, wird in dieser Rolle nicht glücklich und kann sie auch nicht in der dafür notwendigen Weise ausfüllen.
Zusammenfassend lässt sich festhalten, dass sich die Doppelrolle aus RE und TE in diesem Projekt und in unserem Kontext erfolgreich bewährt hat. Unsere Metriken zeigten eine Effizienzsteigerung bei der Testfallerstellung von ca. 30 Prozent zum herkömmlichen Ansatz. Eine abschließende Quantifizierung der Performance in der Testfallerstellung lässt sich auf Basis dieses einen Projekts nicht vornehmen, da es auch rein auf die Performance des Mitarbeiters zurückzuführen sein könnte. Die Fehlerfindungsrate und die Qualität des Produkts selbst, sind mit bisherigen Entwicklungsprojekten vergleichbar und erfüllen somit die Sollanforderungen.
Da wir mit professionellem Pragmatismus an unsere Aufgaben herangehen, werden nur die wesentlichen Metriken erfasst. Zur Bewertung, ob sich ein Ansatz bewährt hat oder nicht, beziehen wir vor allem auch das Feedback unserer Mitarbeiter, des Projektleiters und der Stakeholder mit ein. Hier haben wir durchweg positive Rückmeldung bekommen. Aus Projektleitungssicht wurden die Aufgaben innerhalb des straffen Zeitplans termin- und fachgerecht erledigt. Der Mitarbeiter war vom breiten Aufgabenspektrum begeistert und möchte auch weiterhin in beiden Disziplinen tätig sein.
Ausblick
Unter der Voraussetzung, die geeigneten Mitarbeiter dafür zu haben, werden wir den neuen Ansatz auch in künftigen Projekten einsetzen. Durch Unterstützung von Mitarbeitern mit der Doppelrolle durch zusätzliche Kapazitäten im Testing wollen wir auch weiterhin eine gewisse Unabhängigkeit zwischen Requirements Engineering und Testing bewahren.
Vor allem bei sicherheitskritischen Anwendungsfällen ist eine striktere Trennung der beiden Rollen notwendig. Hier denken wir bereits darüber nach, die Rollenaufteilung über zwei Projekte zu splitten, das heißt, der RE des Projekts A wird der Tester des Projekts B und umgekehrt. Zudem werden wir die wichtigsten Metriken im Auge behalten, um den Nutzen hinsichtlich Entwicklungsdauer und Qualität abschließend bewerten zu können.
Fazit
Mit diesem Beitrag möchte ich Verantwortliche in anderen Unternehmen ermutigen, diesen Ansatz für sich auszuprobieren. Kleiner Projekte oder die Umsetzung von Änderungen während des Produktlebenszyklus eignen sich besonders, um die Doppelrolle aus RE und TE anzuwenden. Jedoch ist auch vorstellbar, Mitarbeiter in größeren Entwicklungsteams mit dieser Rolle zu betrauen. So wird das Verständnis für die Bedürfnisse des Testings bei den Requirements Engineers gestärkt und das starke Produktwissen der REs wird schnell und direkt in die Testteams getragen.
Requirements Engineering und Testing waren schon immer eng miteinander verbunden, durch agile Entwicklungsmethoden hat sich diese Verbindung noch verstärkt. Mitarbeiter beider Disziplinen bringen wichtige Grundvoraussetzungen mit, um die Aufgaben in der jeweils anderen erfüllen zu können. Somit könnte die Doppelrolle aus Requirement Engineer und Test Engineer die Zukunft für unsere Mitarbeiter sein.
