Verschiedene Onsite-Offshore-Modelle aus Sicht der Kunden

von Dr. Martin Grether

Der Kunde ist König. Dieser Satz gilt auch, wenn Softwaretests beauftragt werden. Manche Kunden wissen ganz genau, was zu testen ist, und geben exakt vor, welche Tests durchzuführen sind, damit sie die Software als „fehlerfrei“ akzeptieren. Für andere Kunden findet Testen einfach am Ende der Entwicklung statt und ist integraler Bestandteil des IT-Projektes.

Seit Tests nicht mehr zwangläufig vor Ort beim Kunden stattfinden müssen (wegen der guten Anbindung über das Internet), mischt sich der Kunde auch mal stärker oder weniger stark in das Onsite-Offshore-Liefermodell seines Dienstleisters ein – und spricht damit vor allem das Preis-Leistungs-Verhältnis an.

In diesem Artikel werden einige Kundensituationen beschrieben, die das Liefermodell der Testdienstleistungen (im Projekt oder Standalone) bestimmen. Die Spanne reicht vom extremen Fabrikmodell bis hin zur Anpassung im agilen Vorgehen. Vollständig ist die Aufzählung sicher nicht, zeigt aber doch, welche Varianten in der Lieferfähigkeit heutzutage möglich sind bzw. auch gefordert werden. Auf Lieferansätze zur Testautomatisierung, die Nutzung von Mobile-Cloud-Plattformen oder Crowdtesting wird nicht eingegangen, da es sich nicht um klassische Onsite-Offshore-Modelle handelt.

Lasst uns vier echte Anforderungen von TSystems-Kunden anschauen, damit wir die gewünschten Lösungen vergleichen können.

Offshore Testing

Modelle „mit Restriktionen“:

Die Situation beim ersten Kundenbeispiel ist, dass sein komplexes Softwaresystem jeweils zwei- bis dreimal pro Jahr, über mehrere Jahre hinweg getestet werden muss. Die funktionalen Änderungen variieren in geringerem Umfang, dafür sind aber die technischen Anforderungen an Verfügbarkeit, Stabilität und Datenverlust sehr groß. Weiter gibt es neben der zentralseitigen komplexen Software (teilweise Echtzeitverarbeitung) permanent verbundene, dezentrale Komponenten, die embedded Software enthalten. Zu prüfen sind:

  • alle Softwareprodukte, funktional und betrieblich
  • zentrale und dezentrale Softwareprodukte
  • Deployment der dezentralen Komponenten
  • Integration in das Zentralsystem

Hinzu kommt, dass aufgrund des Datenschutzes die Daten nicht außerhalb der EU verarbeitet werden dürfen. Das Unternehmen ist deutschsprachig, so dass die Projektkommunikation auf Deutsch erfolgt.

Aufgrund der schon erwähnten langen Laufzeit des Projekts sind vom Kunden nach der erfolgreichen Einführung im Wartungsbetrieb Kosteneinsparungen – bei gleichbleibend hoher Qualität der Tests – erwünscht.

Die Restriktionen für den Offshore-Ansatz stellen sich hier als eine lange Liste von Anforderungen dar, die in der Summe für das Auslagern von Tests nicht viele Optionen lässt. Da die technischen Tests bereits stark automatisiert sind (= wenig personalintensiv) und die End-to-End-Geschäftsprozesstests gemeinsam mit dem Kunden durchgeführt werden, bleiben für den Offshore-Ansatz die Tests der dezentralen Komponenten.

Unter Berücksichtigung der Datenschutzrichtlinie wurde so die dezentrale Hardware physisch in ein Nearshore-EU-Land verlagert und wird nun von dort aus getestet.

Die Extremvariante:

In diesem Fall hat der Kunde ein größeres Softwaresystem: ein Bankensystem, bei dem pro Release alle Funktionen und eine enorme Anzahl an Varianten des Systems im Detail überprüft werden. Dafür sind in einem Testtool durch den Kunden inzwischen über 50.000 Testfälle hinterlegt!

Die Testaufgaben hat der Kunde aufgeteilt in einen Fachbereichsanteil und einen Testausführungsanteil. Die Testfälle werden von Business-/Testanalysten im Detail spezifiziert und in einem Testtool hinterlegt (Voraussetzungen, Abhängigkeiten, Testschritte, erwartete Ergebnisse). Die Ausführung aller Tests wird ausgeschrieben, unabhängig davon, ob sich die Funktionalität geändert hat.

Die Anforderung des Kunden an das „OnsiteOffshore“-Testcenter sind also relativ einfach: Die funktionalen Tests sollen ab einem bestimmten Zeitpunkt und ohne Unterbrechung durchgeführt werden (Ausnahme sind natürlich technische Probleme). Das „Follow the Sun“-Prinzip wird als geeignet angesehen. Die Erwartung ist, dass der Dienstleister mehrere Testcenter in verschiedenen Zeitzonen mit einer genügend hohen Anzahl an Testern hat. In welchem Land, ist für den Kunden nicht entscheidend. Wichtig sind noch Anforderungen bezüglich verschiedener Sprachen und ein Onsite-Ansprechpartner. Den Offshore-Testcentern werden für die Testzeit Remote-Zugänge gewährt, inklusive Zugriff auf das Testtool. Fehlersituationen sind genau zu dokumentieren, so dass die „Issues“ durch das lokale Fachteam des Kunden nachgeprüft werden können.
(Alternativen wie Crowdtesting wünscht der Kunde an dieser Stelle aufgrund der Sensitivität der Tests im Bankenumfeld nicht.)

Viel zu entscheiden am Liefermodell ist in diesem Fall nicht. Es bleibt der echte, manuelle Factory-Ansatz als Lösung, mit Testcentern in zwei (oder drei) verschiedenen Zeitzonen rund um den Globus.

Bitte agil:

Im realen Leben kennt der Kunde oft nicht alle Anforderungen zu Beginn des Projekts. Oder das Projekt hat einen derart großen Umfang, dass sich über die Projektlaufzeit die Anforderungen ändern werden. Solche Projekte werden typischerweise unter Verwendung von agilen Methoden entwickelt – und getestet.

Wie wir wissen, ist ein Merkmal der agilen Methode, dass die Kommunikation (Interaktion) zwischen allen Projektbeteiligten an erster Stelle steht. Das bedeutet, dass am besten alle Projektmitarbeiter am Ort des Kunden zusammengezogen werden. Denn auch die Zusammenarbeit mit dem Kunden als Endnutzer ist essenziell für das Gelingen der Endproduktes, eben weil der Kunde oft während der Fertigstellung von seinem ursprünglichen Plan abweicht und neue Anforderungen an die Software stellt.

Ein Outsourcing, wie es in sequenziellen Softwareentwicklungsmodellen aufgrund der klar getrennten, seriellen Aktivitäten von Anforderung, Entwicklung und Test gut möglich ist, ist im agilen Umfeld deutlich schwieriger umzusetzen. Um die Anforderungen nach Offshore des Kunden zu erfüllen, muss das agile Vorgehen so angepasst werden, dass es auch über zwei getrennte Standorte hinweg möglich ist.

In Abstimmung mit dem Kunden haben wir den Ansatz derart geändert, dass wir die User Stories noch gemeinsam mit ihm und bei ihm entwickeln und diese zu Sprints verpacken. Zu diesem Zeitpunkt werden auch die Test Cases der User Stories entwickelt sowie die notwendigen Integrationstests. Die User Stories und Testfälle werden dem Offshore-Entwicklungsund-Testteam übergeben und dort im SprintVerfahren umgesetzt. Nach der Lieferung des Sprints werden die Integrationstests und die Verifikation der Anforderungen (User Stories) zusammen mit dem Kunden durchgeführt.

Aufgrund dieses Vorgehens ergeben sich für das Onsite-Offshore-Liefermodell spezielle Anforderungen. Onsite, beim Kunden, werden Testspezialisten mit Fachwissen zur Analyse und Dokumentation der neuen Anforderungen benötigt sowie Experten für die Testdurchführung (Integrationstest, Abnahme). Offshore ist es notwendig, dass die Tester agile Testmethoden beherrschen und direkt im Projekt arbeiten.

Der Klassiker:

Der Kunde hat typischerweise schon jede seiner IT-Disziplinen auf den „Outsourcing-Prüfstein“ gestellt und die Effizienz im Bereich IT-Prozesse, -Entwicklung, -Betrieb etc. optimiert. Durch Prozessverbesserung hat der Kunde seine Schnittstellen so verbessert, dass
Outsourcing ermöglicht wird. Wie sieht das klassische Outsourcing im Bereich Test für den Kunden aus?

Dazu muss der Kunde sich entschieden, was er selbst tun will und welche Aktivitäten durch seine Lieferanten, eventuell Offshore, erledigt werden sollen. Hier gibt es im Wesentlichen zwei unterschiedliche Ansätze:

1. Testmanagement-Ansatz

2. Demand-Supply-Ansatz

Beim Testmanagement-Ansatz findet der Organisationsübergang auf Ebene des Testmanagers statt. Der Kunde stellt den Testmanager, da er sich verantwortlich für die Abnahme der Software sieht und daher die Tests selbst managen will. Die Tätigkeit des Testmanagers erweitert sich, wenn die neue oder geänderte Software auch noch integriert wird und Endto-End-Geschäftsprozesstests erfolgen.

Der Testmanager auf Kundenseite erstellt auch meist das Testkonzept und steuert die Testdurchführung. In diesem Fall kann ein erfahrener Testmanager die Testaufgaben direkt mit einem Offshore-Testcenter abstimmen und die Durchführung steuern und überwachen.
Beim Demand-Supply-Ansatz hält der Kunde selbst kein spezielles Test-Know-how mehr vor. Er steuert die Tests im Demand-SupplyAnsatz mit Kennzahlen.

Ganz einfach hat es unser Kunde gesagt: „Über die Zeit (Release) erwarten wir, dass die Qualität steigt und die Kosten sinken.“ Um die Testaufträge zu erhalten und einzuplanen, nimmt das Testteam an der Bewertung aller Change Requests in Bezug auf neue oder geänderte Software teil und wird damit sehr früh in den Release-Prozess eingebunden. Bis auf einen Test Service Manager und einige Testanalysten benötigt man in diesem Fall kaum Onsite-Testspezialisten und kann so den Großteil der Arbeiten in einem Offshore-Testcenter erledigen.

Fazit:

Was vor 15 Jahren in Deutschland noch kaum denkbar war, ist inzwischen jedoch fast alltäglich: Für den Kunden ist vor allem interessant, dass der Dienstleister seine Aufgabe zufriedenstellend löst, aber nicht, wie er es macht. Waren damals noch alle Tester direkt beim Kunden, so ist das heute oft keine Forderung mehr. Noch besteht der Kunde häufig darauf, dass Test Manager und Analysten, die ihn und seine Geschäfte verstehen, gut erreichbar vor Ort sind. Die Durchführung der Tests kann aber in anderen Ländern erfolgen. Die direkte Kontrolle benötigen die meisten Kunden inzwischen nicht mehr. Der Kunde vertraut den etablierten Firmen und ihren Prozessen, die die Dienstleistungen im Onsite-Offshore-Ansatz anbieten.

Für die Liefermodelle sind damit die Anforderungen in Bezug auf das Testobjekt und die verwendeten Methoden das bestimmende Element für die unterschiedlichen Liefermodelle.

Dienstleister, die diese Anforderungen bewältigen wollen, müssen in ihrem Onsite-Offshore-Mix das richtige Fach-und-Test-Knowhow, die passende Methodenkompetenz, die richtige Anzahl an Testspezialisten und Sprachen bereitstellen – kein einfaches Unterfangen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts