Führung im Test: Unternehmensweite Geschäftsprozess-Absicherung
Anmerkung der Redaktion: Willkommen zur Reihe „Führung im Test“ vom Softwaretest-Guru und Berater Paul Gerrard. Die Serie soll Testern mit mehrjähriger Erfahrung – insbesondere jenen in agilen Teams – dabei helfen, in ihren Rollen als Testleiter und Manager zu glänzen.
Im vorherigen Artikel haben wir uns die Tools angeschaut, die für effektives Testen und Zusammenarbeit benötigt werden. In diesem Artikel geht es um die letzte Testphase und darum, wie Sie sicherstellen, dass Ihre Systeme wie geplant liefern.
Melden Sie sich für den Newsletter The QA Lead an, um benachrichtigt zu werden, wenn neue Teile der Serie erscheinen. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir für einen tieferen Einblick in dieses und andere Themen sehr empfehlen. Nutzen Sie dafür unseren exklusiven Gutscheincode QALEADOFFER und sparen Sie $60 auf den vollständigen Kurspreis!
Wir sind bei den letzten Artikeln der Leadership In Test Serie angekommen. Bisher haben wir behandelt, wie man ein Testprojekt von Anfang bis Ende plant und steuert sowie viele der eingesetzten Tools und Prozesse.
In diesem Artikel möchte ich auf das Konzept der Enterprise Business Process Assurance (EBPA) eingehen – was es bedeutet und wie man es angeht. Wir werden folgendes behandeln:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Was ist Enterprise Business Process Assurance?
- Grundlagen von Systemintegration und -tests
- Horizontales Testen: Der End-to-End-Testansatz
- Integrationsrisiken und End-to-End-Testing
Es gibt viel zu besprechen, also legen wir los.
Was ist Enterprise Business Process Assurance?
Jedes Unternehmen, das neue Systeme einführt, hat beim erstmaligen Einsatz damit schon Probleme erlebt. Systeme, die selbst nur geringfügig nicht zur bestehenden Infrastruktur und den Geschäftsprozessen passen, können Chaos verursachen und sind oft schwer wieder zu beheben.
Iterative, agile und kollaborative Vorgehensweisen helfen zwar, aber die Herausforderungen einer unternehmensweiten Integration können nur durch eine finale Testphase gemeistert werden.
Wir nennen diese finale Phase Enterprise Business Process Assurance (EBPA). Der Erfolg hängt von einer oder mehreren Testphasen ab, die nachweisen, dass die Systeme, Geschäftsprozesse und Daten integriert sind und die zugesagten Leistungen erbringen.
Es gibt kaum wissenschaftliche Artikel zu diesem Thema, obwohl die späteren Phasen jedes Großprojekts davon geprägt sind. Um unsere EBPA-Strategie zu untermauern, werfen wir zunächst einen genaueren Blick auf die Arten von Systemintegration und -tests, mit denen Sie es zu tun haben werden.
Bei Projekten auf Unternehmensebene steigt die Komplexität exponentiell an. Deshalb kann die Wahl einer unternehmensgerechten Datenbankmanagement-Software einen großen Unterschied für Ihre Quality-Engineering-Bemühungen machen.
Grundlagen von Systemintegration und -tests
Vertikale Integration
Aus technischer Sicht bedeutet Integration die Verbindung zwischen den verschiedenen Schichten der technischen Architektur. Das Integrationstesten von Entwicklern besteht meistens aus der Überprüfung, ob über die Benutzeroberfläche in einer Update-Transaktion eingegebene Daten erfolgreich in der Datenbank gespeichert werden.
In die andere Richtung wird geprüft, ob die gespeicherten Daten korrekt in der Benutzeroberfläche angezeigt werden können, wenn sie angefordert werden. Die Verbindungen und Pfade durch die technische Architektur können als vertikale Pfade oder vertikale Integrationstests betrachtet werden.
Horizontale Integration
Endnutzer sehen die technische Architektur und ihre Komplexität nicht. Sie verstehen das System als eine Reihe von Funktionen, die von verschiedenen Nutzern im Rahmen sogenannter Nutzerreisen ausgeführt werden.
Diese „Journeys“ verfolgen Pfade innerhalb der Geschäftsprozesse der Anwender und greifen dabei bei jedem Schritt über die Benutzeroberfläche auf verschiedene Systeme und Funktionen zu.
Agile Teams arbeiten an kleineren Stories und sehen das größere „Epic“ nicht. Entwickler können längere Nutzerreisen meist ohnehin nicht nachverfolgen und testen, weil ihnen die Umgebungen oder die entsprechenden Daten fehlen. Daher verlassen sich Unternehmen in der Regel auf größere Tests und unabhängige Testteams, um diese zu validieren.
Nutzerreisen decken naturgemäß sowohl den Geschäftsprozess als auch die Systemfunktionen in Kombination ab. Auf diese Weise testen horizontale Tests die Integration zwischen den Systemen und dem Geschäftsprozess.
Vertikale Integrationstests verfolgen eine eher technische Sichtweise; horizontale Tests eine nutzer- oder geschäftsprozessbezogene Perspektive.
Nutzen wir nun diese Konzepte, um ein Modell zu erstellen, das uns hilft, EBPA zu verstehen und zu planen. Wir werden die horizontalen und vertikalen Integrationsansätze im Modell verorten.
Ein Modell für Integration und Tests
Integration ist ein oft missverstandenes Konzept. Der Integrationsprozess beginnt tatsächlich fast schon mit dem Start der Programmierung. Man könnte sagen, dass die Integration beginnt, sobald wir zwei Codezeilen haben – denn die zweite Zeile muss mit der ersten integriert werden. Integration endet, wenn alle funktionalen Tests mit der Benutzerabnahme abgeschlossen sind.
Konzentrieren wir uns auf ein Beispiel mit Standard-Software (COTS) und Modulen für Enterprise Resource Planning (ERP).
Das Softwareunternehmen, das COTS- oder ERP-Module entwickelt, hat bereits Unit- und Funktionstests durchgeführt. Wenn diese Komponenten geliefert werden, kann man in der Regel davon ausgehen, dass sie funktionieren und technisch integrierbar sind. Dennoch besteht immer das Risiko, dass integrierte Komponenten verschiedener Anbieter auf unerwartete Weise miteinander interagieren.
Werden Komponenten außerdem individuell angepasst, ändert sich ihr Verhalten und dies führt wiederum häufig zu subtilen (und auch weniger subtilen) Nebenwirkungen an anderer Stelle. Es bleibt weiterhin notwendig, eine vertikale Integration durchzuführen, um den Austausch von Steuerinformationen und Daten im Technologiestack zu überprüfen, sowie eine horizontale Integration von Komponenten und Geschäftsprozess.
Wir stellen die vier Integrationsaktivitäten in einem Vier-Quadranten-Modell mit zwei Achsen dar. Auf der X-Achse befindet sich der Umfang des zu testenden Systems – entweder eine einzelne Komponente oder ein isoliertes Teilsystem oder die integrierten Systeme im Kontext des Geschäftsprozesses.
Die rechte Seite des Modells ist blau schattiert und stellt EBPA dar. Die Prüfung unseres Systems im Zusammenhang mit anderen Systemen (SIT) und dem Geschäftsprozess (BIT) nennen wir Enterprise Business Process Assurance.
Schauen wir uns nun die vier Quadranten einzeln an.
Modul-, Feature- oder Komponententest
Das Modul muss funktional getestet werden, unabhängig davon, ob es individuell entwickelt wurde oder es sich um eine COTS-Komponente handelt. Das Nutzererlebnis ist dabei immer wichtig und muss mit einem Schritt oder einer Aktivität im Geschäftsprozess integriert sein.
Sub-System-Integrationstest
Integration erfolgt schrittweise. Sobald Komponenten und Funktionen auf niedriger Ebene verfügbar sind, werden sie in das zunehmend größere System integriert und getestet, bis das vollständige und kohärente System bereitsteht. Dies nennen wir Sub-System-Integrationstest.
Systemintegrationstest (SIT)
Kein System existiert für sich allein, daher müssen wir, sobald unser System fertig ist, dieses mit anderen Systemen integrieren. Wir installieren unser System in einer Umgebung mit den Schnittstellensystemen und testen das Zusammenspiel als ein „System von Systemen“ über diese Schnittstellen hinweg. Ziel in dieser Phase ist es, technische Integrationsrisiken zu adressieren – wir nennen dies Systemintegrationstest.
Business Integration Test (BIT)
Es gibt eine abschließende Stufe der Integration, die sicherstellen soll, dass die realisierten Systeme mit den Geschäftsprozessen und (oft manuellen) Verfahren der Nutzer dieser Systeme integriert sind. Unter Einbeziehung der externen Schnittstellen des Systems (sofern noch nicht überprüft) validieren wir, dass die Systeme und Geschäftsprozesse im Zusammenspiel konsistente und effiziente Nutzerwege ermöglichen und Daten korrekt sowie widerspruchsfrei verwalten und übertragen. Dies nennen wir im Allgemeinen Business Integration Test.
Im verbleibenden Artikel konzentrieren wir uns hauptsächlich auf die horizontale, EBPA-bezogene Seite des Modells.
Verwandter Beitrag: 10 BESTE TESTDATEN-MANAGEMENT-TOOLS
Horizontales Testen: Der E2E-Testansatz
Die horizontale Integration stützt sich am stärksten auf das sogenannte End-to-End- (E2E-) Testen.
E2E-Testing ist eine Testentwurfstechnik, bei der eine Abfolge verknüpfter Transaktionen durchgeführt wird, die typischerweise mehrere Systeme einschließlich unseres/unsrer zu testenden Systeme umfassen. Diese Tests folgen meist den Nutzerwegen durch die jeweiligen Geschäftsprozesse.
Auf Grundlage eines Modells des Geschäftsprozesses werden Wege durch diesen Prozess verfolgt, um eine sinnvolle Folge von Transaktionen zu erstellen, die die tatsächliche Nutzung des Systems durch Nutzer in der Praxis simulieren.
Solche Modelle können bekannte Schaubilder wie Flussdiagramme oder Swimlane-Diagramme sein oder technischere Varianten wie UML-Sequenz- oder Kollaborationsdiagramme. (UML ist die Unified Modelling Language, die von vielen IT-Organisationen verwendet wird).
E2E-Tests adressieren spezifische Risiken, die durch frühere Tests auf Sub-Systemen oder in Umgebungen, die stark von simulierten Schnittstellen und rein synthetischen Daten abhängen, nicht angemessen abgedeckt werden können.
Im Bereich des horizontalen Testens wird der E2E-Testansatz häufig von spezieller Software ergänzt. Für eine sorgfältig ausgewählte Liste von Softwarelösungen, die diesen Prozess optimieren, sehen Sie sich diese Top-Testmanagement-Lösungen an.
Abnahme
Das Konzept der „Passgenauigkeit“ ist relevant für die Integration von Komponenten, die Integration ganzer Systeme und die Integration von Systemen in Geschäftsprozesse.
Die Abnahme basiert in der Regel auf den Ergebnissen horizontaler End-to-End-Tests (E2E), da die Geschäftsinteressenten darauf vertrauen können, dass diese Tests zeigen, wie das neue System zu ihren Arbeitsweisen passt und diese unterstützt. Horizontale E2E-Tests geben ihnen Vertrauen, dass der gelieferte Service funktionieren wird.
Der Abnahmeprozess für Systeme hängt üblicherweise zumindest teilweise vom erfolgreichen horizontalen E2E-Testen ab. Das liegt daran, dass nur E2E-Tests das System in einer realistischen Umgebung prüfen und realistische Benutzeraktivitäten simulieren.
In vielen Organisationen ist es erst in den letzten Testphasen möglich, das Funktionieren von Systemen zu demonstrieren. Dies gibt den Stakeholdern die Sicherheit, dass das System wie gefordert arbeiten wird.
Wenn Sie gebeten werden, einen Abnahmetest zu planen, erwarten wir, dass die E2E-Testtechnik eine große Rolle in Ihrer Planung spielt.
Integrationsrisiken und E2E-Tests
Wie besprochen, beziehen sich Integrationsrisiken auf die Integration von System zu System oder von Systemen in Geschäftsprozesse.
Einige Organisationen entscheiden sich dafür, die Tests, die diese beiden Risikoarten adressieren, in Systemintegrationstests (SIT) und Geschäftsprozesse-Integrationstests (BIT) zu unterteilen. Oftmals werden die Risiken und Tests jedoch zu einer einzigen Testphase zusammengeführt, die E2E, Abnahme oder Geschäftsprozesse-Test genannt wird.
Unabhängig davon, wie die Tests strukturiert sind, wird die oben erläuterte E2E-Testmethode umfangreich genutzt. In Ihrer Umgebung können die Risiken Varianten dieser Themen sein, und es kann notwendig sein, das Testziel und Ihren Testansatz entsprechend anzupassen.
Die hier aufgeführte Risikoliste sollte lediglich als Ausgangspunkt betrachtet werden und Sie daran erinnern, worauf Sie Ihr Testen fokussieren sollten. Es ist wahrscheinlich, dass für Ihre Organisation, Ihre Branche oder Ihre Technologie spezifische Risiken hinzukommen, die Sie zu dieser Startliste hinzufügen müssen.
In der folgenden Tabelle bezieht sich „Systeme“ auf die Gesamtheit der integrierten Systeme einschließlich des neuen Systems oder der sich in Entwicklung befindlichen Systeme, weiterer Altsysteme oder Infrastruktur und externer Systeme wie z. B. Banken oder Partnerorganisationen.
| Risiko | Testziel | Testvorgehen |
| Systeme sind nicht integriert (Datenübertragung). | Nachweisen, dass Systeme integriert sind und den Datentransfer korrekt durchführen. | Systemintegrationstest (SIT) |
| Systeme sind nicht integriert (Steuerungsübergabe). | Nachweisen, dass Systeme integriert sind (die Steuerungsübergabe mit den erforderlichen Parametern erfolgt korrekt). | SIT |
| Schnittstellen versagen bei längerer Nutzung. | Nachweisen, dass Schnittstellen kontinuierlich über einen längeren Zeitraum genutzt werden können. | SIT (Diese Überprüfungen können auch im Rahmen von Zuverlässigkeits- und/oder Failover-Tests erfolgen) |
| Systeme sind nicht integriert (Daten stimmen über Schnittstellen nicht überein). | Nachweisen, dass Systeme integriert sind (über Schnittstellen übertragene Daten werden konsistent verwendet, z. B. Währung, Sprache, Maßeinheiten, Zeitpunkte, Genauigkeit, Toleranzen). | SIT |
| Systeme sind nicht synchronisiert (Datenübertragungen werden nicht ausgelöst, zu falschen Zeiten oder mehrfach ausgelöst). | Nachweisen, dass Datenübertragungen korrekt ausgelöst werden. | SIT |
| Objekte oder Entitäten, die in mehreren Systemen existieren, stimmen zwischen den Systemen nicht überein. | Nachweisen, dass Zustände von Geschäftsobjekten in allen Systemen, die Daten darüber speichern, korrekt abgebildet werden. | Geschäftsprozesse-Integrationstest (BIT) |
| Systeme sind nicht mit den Geschäfts- (Lieferketten-) Prozessen integriert. | Nachweisen, dass die Systeme mit den Geschäftsprozessen integriert sind und die Lieferkette unterstützen. | BIT |
| Backend-Geschäftsprozesse unterstützen die Web- oder mobilen Frontends nicht. | Nachweisen, dass die Lieferkettenprozesse praktikabel sind und das Geschäftsziel unterstützen. | BIT |
| Integrierte Systeme, die von denselben Mitarbeitenden genutzt werden, haben für ähnliche oder verwandte Aufgaben uneinheitliche Benutzeroberflächen oder Verhaltensweisen. | Nachweisen, dass Benutzer ein konsistentes Verhalten über Systeme hinweg erfahren, während sie ähnliche oder verwandte Aufgaben ausführen. | BIT (Diese Überprüfungen können auch während der UX-Prüfung durchgeführt werden) |
Anmerkungen zur Risikotabelle
Einige der oben genannten Risiken benötigen eine nähere Erläuterung.
Probleme bei der Datenübertragung
Oft werden Daten über Netzwerke zwischen Systemen übertragen. Falls diese Übertragungen als Batch-Prozesse laufen und fehlschlagen oder eine als Echtzeitprozess ausgelöste Übertragung durch einen Benutzer, ein Geschäft oder ein anderes System fehlschlägt, fehlen die Daten im Zielsystem.
Fehlerhafte Steuerungsübergabe
Eine Steuerungsübergabe ist ein Vorgang, bei dem eine Benutzeraktivität oder ein Systemprozess den Benutzer oder Prozess zu einer anderen Funktionalität des Systems weiterleitet.
Typischerweise gibt es verschiedene Zieloptionen, und je nach Benutzeraktion oder Dateninhalt einer Transaktion wird ein anderer Weg durch die Anwendung gewählt.
Aus Sicht des Benutzers gelangt er an die falsche Stelle der Anwendung, oder ein Systemprozess erwartet, dass ein falscher Prozess ausgeführt wird, und die Synchronisation geht verloren.
Daten stimmen nicht überein
Ein System kann z. B. Daten zu Geld, Standort von Vermögenswerten oder physischen Größen verteilen, die über alle Systeme hinweg „aufsummiert“ werden müssen.
Beispielsweise muss, wenn 100 Lagereinheiten eingekauft und bewegt, verkauft, in Fertigungsprozessen verwendet, als fehlerhaft eingestuft und zurückgegeben oder verschrottet werden, die Anzahl der in jedem Teilsystem gehaltenen Einheiten mit der ursprünglichen Bestandsmenge von 100 übereinstimmen.
Eine Variante dieses Problems ist zum Beispiel die Verwendung der Mengeneinheiten in den Systemen, die Daten speichern. Die Losgrößen oder Zusammenfassungen der gezählten Mengen müssen berücksichtigt werden, oder Systeme müssen metrische und imperiale Maße angleichen, und so weiter.
Systeme nicht synchronisiert
Im Zusammenhang mit dem oben genannten Datentransferproblem müssen die Systemprozesse, die Übertragungen durchführen, in der richtigen Reihenfolge geplant werden, durch ordnungsgemäß autorisierte Prozesse oder Personen ausgelöst werden und rechtzeitig sowie durch das passende Ereignis oder eine Kombination von Ereignissen ausgelöst werden.
Einige Batch-Prozesse müssen stündlich, täglich, wöchentlich, am Monats-, Quartals- oder Jahresende usw. ausgeführt werden und bedürfen einer Überprüfung. Vieles im Funktionsverhalten hängt von den relativen Zeitpunkten der Transaktionen oder dem Alter der Daten in den Systemen ab und muss ebenfalls überwacht werden.
Objekte stimmen nicht überein
Nicht die Anzahl an Objekten, Geld oder physischen Messwerten, sondern der Status von Objekten, die in verteilten Systemen gehalten werden, ist hierbei risikobehaftet. Beispielsweise sollte der Beschäftigungsstatus eines Personaldatensatzes in allen Systemen, die Kopien dieses Datenobjekts speichern, konsistent sein. Die Prozesse, die Statusänderungen über die Systeme hinweg verbreiten, müssen ausgelöst und ihre Aktionen überprüft werden.
Systeme nicht mit dem Geschäft integriert
Das Verhalten der Systeme muss mit den Absichten der Nutzer/innen übereinstimmen. Typische Probleme treten auf, wenn das System unvollständige, veraltete oder falsche Informationen anzeigt. Die eigentliche Ursache liegt meist darin, dass Datentransfers oder Synchronisationen nicht korrekt funktionieren, aber diese Probleme machen sich in der Benutzeroberfläche bemerkbar.
Back-End-Prozesse unterstützen Front-End nicht
Diese Art von Problem zeigt sich als Inkonsistenz zwischen führenden Systemen (Systeme of Record) und interaktiven Systemen (Systeme of Engagement). Back-End-Batchprozesse, die nicht oft genug oder gar nicht ausgeführt werden, stellen Daten nicht für Front-End-Systeme bereit. Umgekehrt werden Benutzervorgänge über die Front-End-Systeme nicht in den führenden Systemen reflektiert.
Inkonsistente Benutzeroberflächen
Wenn ein Unternehmen oder Service über mobile, Web- und Kiosk-Oberflächen angeboten wird, kann es zu unterschiedlich oder inkonsistent agierenden Bedienoberflächen kommen. Sie wurden möglicherweise unabhängig voneinander getestet, verhalten sich jedoch unterschiedlich. Beispielsweise werden unterschiedliche Eingabevalidierungen angewandt, verschiedene Datenfelder erfasst/angezeigt oder die Reihenfolge der Eingaben variiert.
Abschließende Gedanken
Wir haben hier ein Modell für Integration und Test vorgestellt, das die unternehmensweite Integration und den Geschäftsprozess in den Vordergrund stellt. Der E2E-Ansatz ist der einzige, der eine vollständige Systemintegration erfordert und Tests auf vollständigen Nutzerreisen basiert. Auf diese Weise können Stakeholder einen Nachweis systemischer Korrektheit im realistischen Kontext sehen.
Viele Organisationen verlassen sich darauf, dass Anwender eine Art E2E-Tests als Abnahmetests manuell durchführen. Aus Erfahrung plädiere ich für einen systematischeren, risikobasierten Ansatz, der die Automatisierung der arbeitsintensiven Testdurchführung erleichtert.
Wenn Organisationen agile und dynamischere Continuous-Delivery-Entwicklungsansätze übernehmen und agilen Teams mehr Verantwortung für das Testen ihrer Subsysteme übertragen, ist es leicht, die späte unternehmensweite Integration und Abnahmetests zu vernachlässigen.
Der EBPA-Ansatz, insbesondere wenn automatisiert, erweitert das Continuous-Integration-Regime von Teilsystemen auf die unternehmensweite Absicherung von Geschäftsprozessen.
COTS- und ERP-Pakete ermöglichen die Implementierung äußerst leistungsfähiger, aber komplexer Systeme mit geringerem Entwicklungsaufwand – aber die Integrationsrisiken sind genauso präsent wie bei individueller Softwareentwicklung.
In größeren Umgebungen werden agile und Continuous-Delivery-Ansätze immer populärer. Damit wachsen mit der Komplexität und dem Umfang auch die Lieferfrequenz und das einhergehende Risiko.
Die Lösung ist eindeutig: Organisationen müssen EBPA ernst nehmen. Sie müssen Integrationsrisiken verstehen und wissen, wie sie das Testing strukturieren müssen, um diese Risiken anzugehen. Tester müssen sich dem modernen, modellbasierten Ansatz zuwenden, ihre Geschäftsprozesse, Systeme und Tests abstrahieren und Testautomatisierung systematisch umsetzen.
Melde dich für den Newsletter von The QA Lead an, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir sehr empfehlen, um noch tiefer in dieses und andere Themen einzutauchen. Wenn du ihn buchst, nutze unbedingt unseren exklusiven Gutscheincode QALEADOFFER und spare $60 auf den vollen Kurspreis!
Empfohlene Lektüre: 10 BESTE OPEN-SOURCE TEST MANAGEMENT TOOLS
