Nicht jeder kann es sich so wie Microsoft leisten, zwei Entwickler an identischem Code arbeiten zu lassen. “Unabhängiges Testen entwickelt sich offensichtlich zu einem Markttrend.” sagt Frank Ridder, Reasearch Director IT-Sourcing, Gartner. In besagter Studie von PAC, die zusammen mit Logica durchgeführt wurde, wird deshalb eine Verdopplung des Marktvolumens alleine in Deutschland bis 2010 auf 200 Millionen Euro vorausgesagt.

Erste Ansätze hierzu sind allerdings sehr technisch geprägt. So wurde der Begriff “Test as a Service” von Tieto mit geprägt, die damit IBM’s Software Business Partner des Jahres 2009 wurden. Hier handelt es sich um eine Reihe von Tools, die die Strukturierung und die Automatisierung von Tests fördern, und es Tieto ermöglichen, Tests als Outsourcing günstig anzubieten. Dies bedient vor allem dem Wunsch nach Kostensenkung, der aber neben der Automatisierung auch durch das Nearshore-Outsourcing bei deutschsprachigen Anwendungen oder durch Offshore-Outsourcing im Backend erfüllt werden kann. Steria Mummert berichtet über bis zu 50%ige Einsparungen.

Neben der reinen Kostensicht sind aber weitere Faktoren ausschlaggebend:

• Zum einen kann professionelles Testmanagement die Auswahl der notwendigen Tests (zum Beispiel anhand des Customers’ Testing Center) vornehmen. Dies ist ein komplexes Thema geworden, da kleine Änderungen der Software zu großen Änderungen für den Kunden führen können.
• Weiterhin sind gerade bei Produkt- oder Servieentwicklungen unabhängige Tester, optimalerweise sogar Kunden, von Vorteil. Heute ist es problemlos möglich Anwendungen weltweit zu testen.
• Drittens sind externe Tests auch eine Erleichterung für Softwareentwickler, die von dem Wunsch Neues zu gestalten getrieben werden. Testen kann sehr nervenaufreiben sein und erfordert in jedem Fall höchste Präzision und ist deshalb keine kreative Tätigkeit.

Wenige erlauben sich einen ganzheitlichen Blick, auch wenn dieser zu hilfreichen Erkenntnissen führt: mangelnder ganzheitlicher Blick, ungenaue Kenntniss von Prozesskosten, mangelhaftes Verständnis füreinander und schlechte “Usability” von  Nutzerschnittstellen sind wesentliche Fehlerquellen. Solche, teilweise grundsätzlichen Überlegungen, bergen das größere Optimierungspotential. Es wird befürchtet, dass diese Themen, einmal begonnen, zu viel Zeit in Anspruch nehmen.

Offensichtlicher und daher häufiger in Diskussion sind Themen wie fehlerhafte oder unfertige Programme oder Systeme, unzureichende Vernetzungen, oder uneinheitliche oder mehrdeutige Daten.

Ein Blick zurück offenbart die sieben häufigsten Fehlerquellen, die wir bei Analysen und Tests von Geschäftsprozessen festgestellt haben. Man sollte sich auf vier Themen konzentrieren, die möglicherweise grundsätzlicher Natur sind:

• Der ganzheitliche Blick geht verloren: zu schnelle Entwicklung von Prozessen führt zu Qualitätsproblemen; zu langsame Entwicklung derselben verschlechtern die Wettbewerbssituation. Ausnahmen werden betont anstatt minimal erforderliche Prozesse fehlerfrei zu implementieren.
• Die Kosten werden zu ungenau geschätzt: oft gibt es keine klare Aussagen zu den Kosten einzelner Prozessschritte. Deshalb werden Prioritäten grob geschätzt.
• Absprachen und das Verständnis füreinander sind mangelhaft: die wahren Bedürfnisse der Kunden werden vielfach falsch eingeschätzt. Auch durch unternehmensinterne Missverständnisse entstehen so fehlerhafte Schnittstellen, unnötig lange Prüfungen oder Risikofaktoren.
• Die Nutzbarkeit („Usability“) von Nutzerschnittstellen ist zu gering. Dazu zählen wir nicht nur Internetseiten oder andere graphischen Benutzeroberflächen, sondern auch Dokumente, Korrespondenz, Telefonate und Verträge.

In der Praxis stellt man drei häufige Probleme in den Mittelpunkt:

• Programme oder Systeme sind nicht rechtzeitig fertig oder fehlerhaft. Dies ist ein andauerndes Streitthema, da Anforderungen genauso wie Technik die Ursache bilden können.
• Vernetzungen sind fehlerhaft:  verdeckte Abhängigkeiten, implizite Annahmen, unklare Statusmeldungen, nicht eingehaltene oder uneinheitliche Definitionen führen zu Schnittstellenfehlern.
• Daten sind uneinheitlich oder mehrdeutig:  Migrationssünden, Dubletten,  Fehler in der Konfiguration, mehrdeutige Bezugsgrößen, fehlende Definitionen, unsaubere Messungen oder subjektive Interpretationen sind die Quelle für Fehlinterpretationen oder fehlende Reproduzierbarkeit.

Das mangelhafte Training  von Mitarbeitern zur Einstellung auf neue Prozesse ist ebenfalls ein häufig anzutreffendes Problem. Wir sehen dies nicht als wesentliche Fehlerquelle, weil vielfach obige Probleme zugrunde liegen.

Cridon bietet eine Vielzahl solcher Tests an und stellt diese im Cridon CTC Customers’ Testing Center  basierend auf unserer über 15 jährigen Erfahrung und unseren Recherchen vor. Wir bieten so die Möglichkeit, die Risiken der Einführung neuer Produkte und Services zu minimieren und für eine höhere  Innovationsbereitschaft einzustehen.

Das Cridon CTC Customers‘ Testing Center umfasst 15 erprobte Tests. Cridon hat Tests durch echte Kunden analysiert und kommt zu dem Schluss, dass diese überlegene Dienste leisten, wenn die wesentlichen Erfolgsfaktoren beachtet werden. Das Customers‘ Testing Center bietet

• die Möglichkeit mit echten Kunden im Sinne der „Open Innovation“ zu testen
• die leichte Auswahl des passenden Tests zu den Themen Produkte und Service, Geschäftsprozesse und Marketingansatz
• professionelle Planung. Um Trugschlüsse zu vermeiden ist dies ebenso wichtig, wie die eigentliche Durchführung der Tests
• zielgerichtete Auswertung. Mit unserem Beratungshintergrund können wir optimierende Quick Wins oder zukunftsweisende und disruptive Alternativen in den Mittelpunkt der Betrachtung rücken

Das Cridon Test Center umfasst

• Marketingtests: Diese Tests prüfen, ob, wo und in welcher Ausprägung ein Produkt oder eine Dienstleistung am besten verkauft werden kann:
  • A/B Test (Variantentest, Shelf Test)
  • Marketing Message Test
  • Markttest
  • Friendly User Test (Customer Trial)
  • Feldtest
• Prozesstests: Ob Prozesse funktionieren, und wie schnell bzw. wie gut diese funktionieren lässt sich mit Prozesstests prüfen (siehe White-Paper zu Prozesstests). Diese umfassen meist die gesamte Organisation:
  • Kundenservicetest
  • Prozesstest und Prozess-Integrationstest
  • Operational Readiness Test
  • Model Office Test
  • Systemtest und System-Integrationstest
• Produkttests: Diese Tests prüfen, ob ein Produkt oder eine Dienstleistung funktioniert, und wie Kunden darauf reagieren;
  • Usability Test (User Interface Test)
  • Produkttest
  • Servicetest
  • Operational Readiness Test
  • Prototypentest

Einige dieser Tests betrachten die gesamte Wertschöpfungskette und lassen sich als End-to-End Tests bezeichnen (in obiger Graphik durch “*” markiert).

Wir haben seit über zehn Jahren Erfahrung mit der Organisation von Tests, die gesamte Unternehmen umfassen. Gerne beraten wir bei der Konzeption und der Durchführung dieser Tests.

• schnelle Entwicklung einen Marktvorteil bedeutet,
• viele Einflüsse auf ein Entwicklungsprojekt zu geänderten Anforderungen führen, und
• die Zufriedenheit der Kunden und Mitarbeiter oberstes Kriterium ist.

Der Einsatz agiler Methoden sollte überdacht werden, wenn

• komplexe Sachverhalte zu bewältigen sind oder sehr hohe Qualität erforderlich ist,
• die andauernde Pflege der Systeme bedacht werden muss, und wenn
• fachliche Kreativität und disruptive Innovation gewünscht sind

Was sind agile Entwicklungsmethoden?

Im Jahr 2001 wurde von einigen Entwicklern, das “Agile Manifesto” veröffentlicht und unterzeichnet. Das Manifest legt Prinzipien fest, die bei kunden- und ergebnisorientierten Arbeiten beachtet werden sollten. Das Manifest charakterisiert die Ziele vieler agiler Methoden und fasst diese zusammen mit

• “Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan”

Agile Methoden stellen deswegen das eigentliche Programmieren in den Vordergrund und nicht häufig diskutierte klassische Themen wie Dokumentation, umfangreiche Abstimmungen und Struktur. Gelegentlich kann es bei agilen Methoden deshalb auch dazu kommen, dass Programme neu erstellt werden müssen.

Stellt man die Dimensionen „Anzahl der Iterationen“ und „Komplexität pro Zyklus“ gegenüber, so lässt sich argumentieren, dass agile Methoden dort gut angesiedelt sind, wo Geschwindigkeit vor Komplexität geht. „Wassferfall“ Methoden sind eher auf ausführliche Abstimmungsprozesse ausgelegt um die bestmögliche Lösung in wenigen Iterationen zu erreichen.

Was ist Scrum?

Scrum wurde in den 90er Jahren von zwei Unterzeichnern des Agilen Manifests Ken Schwaber und Jeff Sutherland entwickelt. Letzterer hat 2003 mit zwei Partnern die “Scrum Alliance” ins Leben gerufen. Diese ermöglicht eine Zertifizierung und trägt zu der Popularität von Scrum bei.

Teammitglieder organisieren ihre Arbeit hier weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -methoden. Mittels eines Product-Backlog werden kleinere Entwicklungspakete abgegrenzt, die von einer überschaubaren Mannschaft (z.B. 5 Entwickler in einem Monat) in so kurzer Zeit umgesetzt werden können, dass das System getestet und einsatzbereit ist. Mit vielen, klar strukturierten Meetings zum Teil auf täglicher Basis wird ein intensiver Kontakt zwischen der fachlichen und der technischen Seite des Projekts hergestellt. Diese Gespräche werden nur grob und oft handschriftlich dokumentiert und ersetzten so oft die Dokumentation.

Jeff Sutherland erklärt Scrum auch so: „Scrum is …

• an agile process to manage and control development work …
• a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
• a process that controls the chaos of conflicting interests and needs
• a way to improve communications and maximize co-operation …
• a way to maximize productivity.
• Scrum is scalable from single projects to … projects with over a thousand developers and implementers.

Pro und Contra

Schnelle Entwicklung

Agile Methoden sind im Vorteil, wenn die Geschwindigkeit der Entwicklung wesentlich ist. Die Abstimmung zwischen Entwicklern und den anfordernden Parteien erfolgt schnell und wird nur dokumentiert, wo dies nötig erscheint.

Unabhängigkeit von externe Einflüssen

Projekte werden in kleine Einheiten unterteilt. Gerade bei Scrum sind diese Einheiten auch so gestaltet, dass nach kurzer Zeit bereits Produkte entstehen, die getestet und lauffähig sind.  So ist auch bei grundlegenden Änderungen ein Produkt vorhanden, das funktioniert.

Zufriedene Kunden und Mitarbeiter

Kunden können in Abstimmungen stark einbezogen werden. Damit haben sie viel Einfluss auf die Entwicklung und sind gut informiert. Mitarbeiter werden bei agilen Methoden gefordert. Gerade bei Scrum wählt das Team Entwicklungstechniken und Arbeitspakete gemeinsam aus.

Komplexe Sachverhalte

Vorgelagerte Schritte zur Abstimmung von komplexen Sachverhalten erfordern häufig hohe Konzentration. Funktionale Gesichtspunkte zu durchdenken und abzustimmen, User Experience Tests oder Markttests können lange dauern.
In diesen Fällen ist es oft empfehlenswert, die fachliche und die technische Entwicklung zu entkoppeln und ausgearbeitete Konzeptionen über Testbedingungen abzusichern.

Pflege der Systeme

Je weniger Dokumentation vorhanden ist, desto schwieriger ist die Pflege bestehender Systeme. Bei der Pflege von Systemen sind ursprünglichen Experten selten dann verfügbar, wenn man sie braucht. Dann wird vor allem fachliche Dokumentation benötigt.

Kreativität und disruptive Innovation

Oft wird erwähnt, dass Scrum gerade für Situationen geeignet ist, in denen Kreativität gewünscht ist. Dabei bezieht man sich auf Ikujiro Nonaka und Hirotaka Takeuchi, die Ihren Artikel “The New New Product Development Game” 1986 im Harvard Business Review eben solche Situationen untersucht haben. Sie haben zwar ein sinnvolles Vorgehen mit dem Rugby-Spiel verglichen woraus sich der Name Scrum ableitet. Aber ansonsten bestehen wenige Parallelen. Die auffälligste ist, dass Nonaka und Takeuchi interdisziplinäre Teams fordern. Dies ist bei Scrum nur eingeschränkt der Fall.
Kreativität und disruptive Innovation bedingen, dass sich ein Team Zeit dafür nimmt, Fehlschläge einkalkuliert und unter Hochdruck arbeitet.

D3 Define: Analysis and Strategy

D3 Define: Analysis and Strategy aims on identifying innovation principles which are aligned with the corporate strategy and also with customer and market requirements.

We recommend analyzing the current situation pragmaticlly but thoroughly before developing principles to lead the innovation process or even an innovation strategy. For doing so we look on four areas at minimum: the customers and their touch points to you, the business models and the innovation strategy.

D3 Discover: Product Management

D3 Discover: Product Management is central to product management and has to consider innovation principles, customer characteristics as well as technological insight.

In 1986 Peter Drucker has shown in his book „Innovation and Entrepreneurship”, that most new products are identified by creative thinking. He also showed that this is very risky since most of this initiatives fail. For this reason we also employ systematic methodologies to identify innovation based on your business experience.

We think that right from the start of a product a very clear understanding of expectations on the revenue and its generators should exist. Also, the risks of the introduction of new product should be assessed since this could impact most business matters.

Also the usage of prototypes to rapidly test user experience  and the market are important elements of this part of the framework.

D3 Develop: Business Processes and Implementation

D3 Develop: Business Processes and Implementation: The implementation of new products and services can be already complex without considering existing systems. When there is a need to migrate existing systems or to interconnect with legacy systems complexity can increase tremendously.

We support mainly four areas with our business process and implementation method: the defintion and implementation of business processes is a major ingredient of most of the products and services we have worked on. Today, without substantial automation most services cannot be provided.

We select vendors to support new products and services based on requirements which have been derived from business processes. We offer project management if required.  We focus on understanding what the value for the customer is and which financial performance can be expected.

You can download a PDF-Document with our D3 Framework for Innovation Management here.

See also the press release 1 and the press release 2 .

Vor allem High-Tech Service Industrien (wie die Telekommunikation, oder die Finanzbranche) sind gekennzeichnet durch starken Wettbewerb, viele unterschiedliche Produkte, Schnelllebigkeit und hohen Preisdruck. In solchen Umgebungen ist es oft nicht möglich, eingeführte fehlerhafte Produkte ohne Imageschaden während des Betriebs zu optimieren. In solchen Fällen sollte man sich die Zeit nehmen, Prozesse von Anfang bis zum Ende, von end-to-end, zu testen.

Die meisten Unternehmen haben den Wunsch Dienstleistungen mit hoher Qualität möglichst schnell anzubieten, weshalb komplexe Geschäftsprozesse mit einem hohen Automatisierungsgrad schnell entwickelt werden müssen. Verantwortungsvolle Manager wissen, dass sie komplexen Unternehmen vorstehen, die nur in Grenzen gestaltbar sind, und die einer Lernkurve unterliegen. Deshalb fordern sie End-to-End Tests bereits während eines Entwicklungsprojekts.

Betrachtet man die Faktoren Markt, Produkt, Prozesse und Systeme so wird deutlich, dass sich nicht alle Elemente der Wertschöpfungskette ausführlich testen lassen, weil dies zu lange dauern würde. Eine vertretbare Zeit bis zur Marktreife kann allerdings erreicht werden, wenn man die Eigenheiten professionell durchgeführter Tests kennt und beurteilen kann, wann Tests verlustfrei aufeinander aufbauen können.

Siehe auch die Artikel zu den Erfolgsfaktoren und der Arten dieser Tests, die wir bereits erfolgreich organisieren konnten.

Das Dokument Definition von End-to-end Tests beschreibt die möglichen Testarten und zeigt deren Abhängigkeiten auf.

Wir haben bereits eine Reihe von End-to-End Tests in komplexen Umgebungen aus Organisation, Prozessen und Systemen durchgeführt und unterstützen Sie gerne bei der Konzeption und der Durchführung eines End-to-End Tests.