Wissen & Lernen

Testing für SAP

Fundiertes Wissen rund um SAP-Testautomatisierung – von den Grundlagen bis zu vertiefenden Themen. Für Testmanager, IT-Verantwortliche und den Fachbereich.

SEE:RI – Die intelligente Lösung für Change Impact- und Testabdeckungsanalyse in SAP

In der Welt der SAP-Qualitätssicherung sind Testabdeckung und Change Impact Analyse entscheidende Faktoren, um Systemstabilität und Effizienz sicherzustellen. Ein effizientes Testmanagement erfordert eine gezielte und ausgewogene Testabdeckung. Doch häufig fehlt eine objektive Analyse, wodurch weniger relevante Bereiche übermäßig getestet werden, während die von Änderungen betroffenen Prozesse kaum oder gar nicht berücksichtigt werden. Mit der Entwicklung von SEE:RI setzen suxxesso und die Solutive AG neue Maßstäbe, um dieses Problem gezielt zu lösen und eine präzise, effiziente Testabdeckung sicherzustellen. SEE:RI ist der Gamechanger, der Unternehmen hilft, Systemänderungen gezielt zu überwachen, Testabdeckung zu optimieren und Risiken zu minimieren. SAP-Systeme unterliegen ständigen Veränderungen durch Updates, Transporte und Anpassungen. Doch welche Auswirkungen haben diese Änderungen auf bestehende Prozesse? Werden alle relevanten Testfälle berücksichtigt? Hier kommt SEE:RI ins Spiel: Die Solutive AG ist ein etablierter Experte für ALM- und Transportmanagement-Lösungen. Durch die Integration von SEE:RI in die Solutive ESM Suite schaffen wir eine nahtlose Verbindung zwischen Application Lifecycle Management (ALM), insbesondere dem Change Management, und der Testautomatisierung. SEE:RI lässt sich als Add-On zur suxxesso Tool Suite installieren und bietet Unternehmen die Möglichkeit, auf Basis echter Nutzungsdaten zu testen. Mit dieser innovativen Lösung erhalten Unternehmen eine leistungsstarke Kombination aus ALM, Change-Impact-Analyse und Testautomatisierung – für eine reibungslose und transparente Steuerung von SAP-Changes. Profitieren Sie von den Innovationen dieser einzigartigen Partnerschaft und optimieren Sie Ihre Testprozesse nachhaltig! Ein international tätiges Produktionsunternehmen stand vor der Herausforderung, seine SAP-Landschaft auf S/4HANA zu migrieren. Die größte Sorge des IT-Teams bestand darin, sicherzustellen, dass alle geschäftskritischen Prozesse nach der Migration weiterhin reibungslos funktionieren. Herausforderung: Die bestehende Teststrategie war manuell geprägt und nicht ausreichend skalierbar, um die vielen Änderungen, die mit der Migration einhergingen, effizient zu prüfen. Zudem fehlte Transparenz darüber, welche Geschäftsprozesse durch Änderungen am System betroffen waren und getestet werden mussten. Lösung mit SEE:RI: Durch den Einsatz von SEE:RI konnte das Unternehmen: Dank SEE:RI konnte das Unternehmen nicht nur Zeit und Ressourcen sparen, sondern auch die Qualität der Testprozesse erheblich verbessern. Die Migration verlief erfolgreich und ohne ungeplante Ausfälle. In diesem Video sehen Sie, wie SEE:RI das Change Management und die Testautomatisierung in SAP-Systemen optimal verbindet. Das Thema Change Impact Analyse mit SEE:RI war auch am suxxesso Solution Day im November 2024 ein wichtiger Bestandteil. Sie erhalten eine visuelle und anschauliche Erklärung der zentralen Inhalte aus unserem Blog. Durch den intelligenten Ansatz lassen sich Testaufwände reduzieren, Risiken minimieren und die Qualitätssicherung optimieren.

PDF-Verifikation für technologieübergreifendes End2End Testen von SAP-Prozessen

Die digitale Transformation vieler Organisationen führt dazu, dass diese ihre Geschäftsprozesse von Beginn bis zum Ende elektronisch abwickeln und ihre Geschäftspartner – ob Lieferanten, Behörden, Partner oder Kunden – digital an diese Prozesse anbinden. Dies können sowohl eingehende als auch ausgehende Schnittstellen sein, maschinenlesbare Dateien oder auch beliebte Ausgabeformate wie PDFs. Medien- oder Systembrüche stellen immer ein gewisses Risiko für Fehlzustände dar. Neben Schnittstellentests zwischen einzelnen Systemen ist somit vor allem auf Ausgabeformate wie PDF, auf das zusätzlich durch seine Komplexität (sowohl technologisch als auch in der automatischen Verifizierbarkeit), ein besonderes Augenmerk bei der Qualitätssicherung zu legen. Fehler an Schnittstellen zwischen ERP-Systemen und Dateiausgaben können weitreichende, bis hin zu rechtlichen Folgen für das Unternehmen haben. Verwenden Unternehmen also PDFs als Ausgabeformate, ist es essenziell, diese regelmäßig und genau auf Inhalt, Format und korrekte Darstellung zu prüfen. Szenarien wie Ausgangsrechnungen, Bestellbestätigungen und Verträge – um nur einige zu nennen – sind beliebte Anwendungsfälle, in welchen aus SAP-Systemen unveränderbare PDF-Dokumente ausgegeben werden. In diesem Zusammenhang reicht es nicht aus, sich auf die Prüfung der Inputquellen für diese PDFs vor der Generierung derselben zu verlassen. Der Formatbruch zwischen SAP und dem erzeugten Ausgabedokument birgt eine Risikoquelle, die in einer State-of-the-Art Qualitätssicherung nicht ignoriert werden darf. Erfreulicherweise ist das Bewusstsein für diese Fehlerquelle am Markt gegeben und viele Unternehmen legen ein gewisses Augenmerk auf das Prüfen der Input- und Output-Formate im Rahmen ihrer Qualitätssicherung. Die Kehrseite der Medaille ist allerdings, dass diese Qualitätssicherung meist manuell erfolgt. Für viele Unternehmen stellt die Komplexität und die Möglichkeiten der automatischen Verifikation eine zu große Einstiegshürde dar, um diese Teile der Prozesse automatisiert zu testen. Eine aktuelle Umfrage bei Unternehmen im Hinblick auf den Fokus der Qualitätssicherung von Schnittstellen sowie ein- und ausgehende Geschäftsdokumente zeigt, dass das Augenmerk der Tests auf folgende Aspekte gelegt wird: Unternehmen können es sich nicht leisten, nicht eindeutige oder noch schlimmer, fehlerhafte Dokumente an Kunden, Behörden, Partner oder Lieferanten zu übermitteln. Wie aus den angeführten Punkten ersichtlich, sind die Verifikationsanforderungen heterogen und steigern im Zusammenspiel die Komplexität der Qualitätssicherungs-Anforderungen. Der damit einhergehende Aufwand und die Anforderungen an das manuelle Testen steigen enorm und stellen ein Risiko für Unternehmen dar. Automatisiertes Testen muss den Anspruch haben, die Verifikationsmöglichkeiten zu maximieren und den Aufwand des Testens im Optimalfall gegen Null zu bringen. Marktübliche Automationsansätze scheitern an einem der zwei wesentlichen Anforderungspunkte: Die Herausforderung für Testautomation ist es also, einen breiten Funktionsumfang für das Erkennen von Einzelelementen in PDF-Dokumenten zu bieten – einhergehend mit einer hohen Usability und einem umfangreichen Werkzeugkoffer an Verifikationsmöglichkeiten. Usability ist meist sehr einfach zu beurteilen. Urteilen Sie selbst, ob die Oberfläche eingängig und verständlich ist, ob Sie nach wochenlanger Nicht-Nutzung des Tools sich auch wieder zurechtfinden würden. Ganz essenziell ist jedoch folgende Frage! Sind Testfälle einfach, ohne jegliche Programmierschritte abzubilden oder ohne sonstige technische Skills bewältigbar? Die technische Stabilität der erzeugten Testfälle, der angebotene Umfang an Verifikationsmöglichkeiten sowie das einfache Abbilden von ähnlichen, sich in wenigen Punkten unterscheidenden Varianten hilft – gepaart mit der Usability, die Verifikationsanforderungen Ihres Unternehmens an den kritischen Testaspekt „Ausgabeformat PDF“ zu bewältigen. Die meisten PDF-Testtools am Markt sind komplex zu bedienen und hauptsächlich bild- bzw. bildschirmpositionsbasiert. Das bedeutet, dass Inhalte anhand ihres Aussehens und/oder ihrer Position am Bildschirm erkannt werden. Ändert sich diese Position, so ist eine Erkennung nicht mehr eindeutig möglich. Die automatisierte Verifikation von bildbasierten Dokumenten wie es PDF-Formate sind, konnte durch geringe Funktionsumfänge, die komplexe Benutzung und die unverlässlichen Testergebnisse in der Vergangenheit kaum Fuß fassen, wodurch viele Unternehmen auf das manuelle Testen dieser Dokumente gesetzt haben. Unterstützen Automationstools wie die suxxesso Tool Suite zusätzlich die inhaltsstrukturbasierte Erkennung von Elementen, so eröffnen sich zahlreiche zusätzliche Möglichkeiten, um umfangreiche Verifikationen Ihrer Eingangs- und Ausgangdokumente durchzuführen. Als Beispiel sei hier die, der weiter oben zitierten Studie zufolge, essenzielle Verifikation erwähnt, Elemente zueinander in Beziehung zu setzen, basierend auf ihrer Position im Dokument. Plötzlich ist es sehr einfach möglich, Positionszeileninformationen einzeln und verlässlich zu verifizieren. Moderne Testautomationstools ermöglichen eine massive Steigerung Ihrer Testabdeckung, damit die Sicherstellung Ihrer System-Qualität sowie eine Maximierung der Effizienz Ihrer Testzyklen. Überzeugen Sie sich vom Umfang und der Benutzerfreundlichkeit modernster Testautomationsansätze wie dem der suxxesso Tool Suite!

SAP Cloud ALM in der Qualitätssicherung

Die SAP gab vor einiger Zeit bekannt, den SAP Solution Manager per 2027 aus der Wartung laufen zu lassen, und kündigte damit indirekt SAP Cloud ALM als dessen Nachfolger an. Handelt es sich hier nur um einen verschönerten Solution Manager oder steckt mehr dahinter? Wo liegen die Unterschiede im Hinblick auf ALM-Funktionalitäten, was bedeutet dies für die Qualitätssicherung und damit die Testautomation, die in S/4HANA Projekten und agilen Cloud-Systemlandschaften unabdingbar ist? Werfen wir gemeinsam im folgenden Blogbeitrag einen Blick auf diese Fragestellungen! Bei SAP Cloud ALM handelt es sich um ein Application Lifecycle Management Tool, welches Mitte 2020 als SaaS von SAP auf den Markt gebracht wurde, die Lizenzen für SAP Cloud ALM sind im Enterprise Support – Cloud Edition – enthalten. Grundgedanke ist und war, mit diesem Produkt die ALM-Schiene von SAP, die bisher vom SAP Solution Manager besetzt war, für Cloud-Applikationen zu erweitern. Application Lifecycle Management Tools helfen Unternehmen dabei, den kompletten Lebenszyklus einer Applikation von der Entwicklung bis zum Betrieb effizient zu steuern und zu gestalten. Darunter fallen Tasks wie Requirement-Management, Projektmanagement, die Entwicklung der Software, die Qualitätssicherung sowie das Ausrollen von Änderungen (Deployment) und die Wartung im Rahmen des Betriebs. Modernes, agiles Projektvorgehen sowie Continuous Delivery erfordern effiziente Prozesse, darunter engmaschige Qualitätssicherung, um dem Tempo der Entwicklungen standhalten zu können. ALM soll dabei helfen, Deployments zu beschleunigen und Releasezyklen massiv zu verkürzen. Durch seine Saas-Architektur ist SAP imstande, laufend Updates und neue Funktionalitäten für SAP Cloud ALM zur Verfügung zu stellen, was – nebenbei gesagt – vor allem bei aktuellem Stand (07/2023) dringend nötig ist, fehlen doch wichtige Features, um einen kompletten Lebenszyklus von Applikationen managen und steuern zu können. Im Grundgedanken wurde der SAP Solution Manager für On-Premise-Produkte entworfen und SAP Cloud ALM als das ALM-Tool für Cloud-Applikationen. Schnell holte SAP-Kunden die Zukunftsaussicht ein, als, wie bereits erwähnt, SAP das Wartungsende des SAP Solution Managers mit 2027 ankündigte. Natürlich kann auch der Solution Manager für hybride Systemlandschaften verwendet werden und vor allem Cloud ALM, da ab 2027 die Unternehmen in Richtung Ablöse des SAP Solution Managers getrieben werden. Den spannendsten Aspekt für Testautomationstool-Hersteller wie suxxesso stellt natürlich die Qualitätssicherung dar. Als eines von nur zwei aktuell gültig SAP zertifizierten, in den SAP Solution Manager integrierten Testautomationstools, erlangte suxxesso umfangreiches Know-how beim Zusammenspiel des Solution Managers mit unserer suxxesso Tool Suite. Dieses Wissen umfasst unter anderem den Aufwand, der betrieben werden muss, um effiziente Qualitätssicherung im Solution Manager durchzuführen, sowie die Kenntnis über die zusätzlichen benötigten Vorarbeiten – in Mitbetrachtung der (fehlenden) Usability des Solution Managers. Gleichzeitig trieb und treibt suxxesso die Integration in Cloud ALM voran, um jenen Kunden, die bei den Early Adopters dabei sind, gewohnt umfangreiche und stabile Integrationen in SAP Tools zu bieten. Das erste Fazit fällt, rein auf die Integration und den Testablauf gesehen, durchwegs positiv aus. Wichtige Kernelemente der Testautomation, beispielsweise das Verwalten der „Systems under Test“, die Möglichkeit, Testketten zu orchestrieren, rollenbasierte Tests durchzuführen und auch Drittapplikationen in die Qualitätssicherung zu integrieren, wurden in die Hände der Testautomationstools gelegt. Eingebundene Tools wie unsere suxxesso Tool Suite sind nicht nur auf die reine Automation und das Abspielen von Testfällen begrenzt, sondern können ihre volle Stärke – wie in den Punkten oben angeführt – zur Geltung bringen. Vor allem bei der Unterstützung aller suxxesso Data Manager Funktionalitäten, Rollenschritten und systemübergreifenden Testfällen hat SAP die suxxesso gmbh massiv unterstützt, die Schnittstelle auch unseren Anforderungen hin geöffnet. Somit können auch Cloud ALM-Kunden die volle Bandbreite DER hochspezialisiertesten SAP-Testautomationslösung am Markt nutzen, im Gegensatz zu der eingeschränkten Integrationsmöglichkeit in den SAP Solution Manager. Dies bringt nochmals massive Vorteile gegenüber herkömmlichen, generalistischen Testautomationstools mit sich. Überzeugen Sie sich von den Möglichkeiten und der Integration der suxxesso Tool Suite in SAP Cloud ALM im Rahmen des DSAG-Jahreskongresses in Bremen, wo wir in unserem Partnervortrag „Live-Testautomation für Cloud-ALM: Gamechanger in SAP-Projekten“ einen Live-Einblick in unsere Integration und hochspezialisierte SAP-Testautomation bieten! Besuchen Sie uns in der Messeausstellung auf unserem Standplatz A4 und verpassen Sie nicht unseren Vortrag passend zum Thema Cloud ALM: suxxesso Vortrag am 19.09.2023, 17:45 – 18:30 Uhr: „Live-Testautomation für SAP Cloud ALM: Gamechanger in SAP-Projekten“, SAP-Testautomation in S/4 HANA mit Reporting & Management in SAP Cloud ALM Wir freuen uns auf Ihren Besuch!

Die Rolle der Testautomation im Change- und Transportmanagement bei SAP S/4HANA Implementierungen

SAP S/4HANA Implementierungen, egal ob nach Greenfield- oder Brownfieldansatz vorgegangen wird, sind mehr als herkömmliche Projekte, vielmehr handelt es sich dabei um tiefgreifende Änderungen bei Prozessen als auch bei Funktionalitäten im Rahmen der digitalen Transformation der Systemlandschaften. Nicht vergessen werden darf hierbei die direkte Auswirkung auf die Mitarbeiter, welche diese Änderungen oft im täglichen Tun in Form von angepassten Prozessen, ungewohnten Benutzeroberflächen oder gänzlich neuen Systemen spüren. Um hier einen strukturierten, geordneten Übergang bei der Einführung von SAP S/4HANA zu gewährleisten, ist ein sauberes Change- sowie Transportmanagement unerlässlich. Für solch große Änderungen im Unternehmen ist es wesentlich, den kompletten Prozess, von der Idee einer Änderung oder neuen Funktionalität bis zum Transport der Changes in produktive Systeme, strukturiert und sorgfältig geprüft zu dokumentieren und zu begleiten. Für diese Aufgaben werden Change Management Prozesse inklusive Transportmanagement aufgesetzt, die nach neuesten Standards softwareunterstützt betrieben und gewartet werden. Diese sollten unbedingt schon vor dem eigentlichen Implementierungsprojekt beginnen. Nachhaltig aufgesetztes Change- und Transportmanagement unterstützt Unternehmen nicht nur bei der Implementierung von S/4HANA Systemen, sondern auch über die Lebenszeit der Systeme im täglichen Betrieb. Der Umfang, die Anzahl sowie der weitreichende Scope dieser Changes in solchen Transformationsprojekten macht eine gewissenhafte Qualitätssicherung aller Änderungen unerlässlich. Nicht nur die punktuell betroffene Änderung eines bestimmten Objekts, auch seine möglichen Seitenwirkungen auf andere Objekte und Funktionalitäten müssen entsprechend geprüft und sorgfältig qualitätsgesichert werden. Gerade in Transformationsprojekten ist es für Unternehmen wichtig, neben der rein objektiv messbaren Funktionalität auch das Vertrauen der betroffenen Mitarbeiter und die Akzeptanz des (teilweise) neuen Systems zu gewinnen. Instabile Systeme mit immer wiederkehrenden Fehlern führen bereits in Implementierungsphasen dazu, die Akzeptanz des Projekts und dessen Unterstützung durch die Mitarbeiter zu gefährden. Deshalb muss das Ziel sein, die Qualität von Beginn des Projekts an hochzuhalten. Die Anzahl der Changes, welche auf Unternehmen zukommen, macht eine durch Testautomation unterstützte Qualitätssicherung unerlässlich. Die Anzahl an Changes sowie Transporten und das damit einhergehende Testaufkommen, stellen Unternehmen vor große Herausforderungen und verursachen einen großen Teil der Projektkosten. Testautomation kann hier, intelligent implementiert und ins Change- sowie Transportmanagement integriert, zu massiven Aufwandsersparnissen innerhalb des Implementierungsprojekts von SAP S/4HANA Systemen, als auch weiterführend in der Sicherstellung der Qualität während des laufenden Betriebs führen. Vor dem Transport gestartete automatisierte Testruns, dynamisch zusammengestellt und genau jene Testfälle enthaltend, welche die geänderten Funktionalitäten abtesten, stellen sicher, dass durch Transporte keine unerwünschten Fehlwirkungen und Seiteneffekte auf den Systemen auftreten. Vollautomatisierte Rückmeldungen dieser Testruns fungieren als Quality-Gate vor dem tatsächlichen Transport, welcher nur durchgeführt wird, wenn die Qualitätskriterien der Quality-Gates erreicht werden. Ein rein manuelles Testen aller Changes, aller Transporte und deren möglicher Seitenwirkungen stellt Unternehmen oft vor Aufgaben, die in einer teils stark eingeschränkten Qualitätssicherung somit zu Lasten der Kernsysteme des Unternehmens gehen. Neben dem reinen Aspekt der durch unzureichende Qualitätssicherung entstehenden Probleme wirkt sich ein Testkonzept, welches auf rein manuellem Testen beruht, auch massiv negativ auf das Tagesgeschäft aus, da Ressourcen stark in der Qualitätssicherung der Systeme gebunden sind. Testautomation nimmt im Rahmen der digitalen Transformation eine zentrale Rolle in der Umsetzung und dem Betrieb eines modernen Change- und Transportmanagements ein, da diese ohne eine objektive Qualitätssicherung mit umfangreicher Testabdeckung für SAP S/4HANA Projekte nicht mit vertretbarem Aufwand durchführbar sind.

Entscheidungsbäume in der SAP-Testautomation

Testautomation, als Teil der Qualitätssicherungsmaßnahmen eines Unternehmens, muss wie alle anderen Teile dieses hochsensiblen Fachgebiets den Richtlinien, Methoden und Maßnahmen aus anerkannter Testmethodik und-praxis folgen, um eine objektive und verlässliche Bewertung der Qualität von SAP-Systemen liefern zu können. Inhalt unseres heutigen Blog-Artikels bildet die Verwendung von Entscheidungsbäumen in der SAP-Testautomation, welche in der Fachwelt oft diskutiert und teilweise kontrovers gesehen wird. Entscheidungsbäume, im Programmierkontext beispielsweise If-ElseIf-Else-Klauseln oder Wenn-Dann-Bedingungen, werden eingesetzt, wenn sich Prozesse ab einem bestimmten Punkt, je nach Ausprägung eines Kriteriums (beispielsweise: Materialart), unterschiedlich verhalten. Die Verwendung von Entscheidungsbäumen in einem Testfall resultiert also darin, dass nicht nur der Prozess, den der Testfall durchläuft, sondern auch das Ergebnis je Ausführung unterschiedlich sein können. In einer ersten Reaktion werden viele unter Ihnen nun sagen: Das darf nicht sein, ein Testfall muss in seinem Verhalten, Ablauf und Ergebnis eindeutig sein. Bevor wir auf unsere Sichtweise bei Entscheidungsbäumen und deren Verwendung in der SAP-Testautomation eingehen, betrachten wir noch kurz ein Praxisbeispiel sowie einige anerkannte Richtlinien des Testens, welche uns als wichtig erscheinen. Wir testen die Variantenkonfiguration unseres SAP-Systems und möchten diese mit einer möglichst hohen Testabdeckung versehen. Nun sind unsere Varianten dahingehend unterschiedlich, dass sie sich in gewissen Teilen anhand der benötigten Daten und Eingabefelder unterscheiden. Es entstehen also an gewissen Punkten für jede Variante eigene Prozessabläufe, welche sich durchaus voneinander unterscheiden können. Umgelegt auf die Qualitätssicherung bedeutet dies: für jeden eindeutigen Prozessablauf muss ein Testfall erstellt werden. Die Grundlage für die Betrachtung unserer Problemstellung bieten zwei Richtlinien international anerkannter Testmethodik: Basierend auf diesen beiden Annahmen wollen wir nun erläutern, warum aus unserer Sicht Entscheidungsbäume in der Testautomation durchaus ihre Daseinsberechtigung haben und dies auch mit anerkannter Testpraxis konform geht. Wichtig hierbei ist jedoch, beide oben angeführten Richtlinien einzuhalten. Wie bereits weiter oben dargelegt, müsste ohne Verwendung von Entscheidungsbäumen für jede unserer Varianten aus dem Praxisbeispiel ein eigener Testfall angelegt werden. Diese eindeutigen Testfälle würden allen Kriterien der anerkannten Testpraxis genügen: Umgelegt auf Testautomation ist damit ein gewisser Aufwand verbunden, da alle unterschiedlichen Varianten des Prozessdurchlaufs als einzelne Testfälle abgebildet werden müssen. Entscheidungsbäume liefern uns eine Möglichkeit, Prozesse, die sich in Teilen voneinander unterscheiden, als einen Testfall abzubilden. So weit so gut, doch ist dies im Hinblick auf saubere Testmethodik auch zulässig? Für jeden Durchlauf unseres Entscheidungsbaum-Testfalls müssen VOR der Ausführung folgende Aspekte klar und eindeutig festgelegt sein: Für jede muss klar sein, welcher durchlaufen wird und welches um den Durchlauf des Testfalls als erfolgreich zu kennzeichnen. Werden alle dieser drei Aspekte berücksichtigt, so erfüllen Entscheidungsbaum-Testfälle alle angeführten Richtlinien der Testpraxis: Als Fazit dieses Blogartikels sind wir der Meinung, dass unter Einhaltung festgelegter Regeln, Entscheidungsbäume alle Kriterien der Testmethodik auch in der Anwendung der Testautomation erfüllen. Richtig eingesetzt helfen Entscheidungsbäume, den Aufwand sowohl bei Erstellung als auch Wartung von Testfällen zu optimieren und somit komplexe und umfangreiche Testszenarien, wie jenes der Variantenkonfiguration, einfacher zu bewältigen. Wollen Sie mehr über den Einsatz von Entscheidungsbäumen in der Testautomation mit der suxxesso Tool Suite erfahren?

Die wichtigsten Erfolgsfaktoren für nachhaltige und effiziente SAP-Testautomation

Wenn Unternehmen darüber nachdenken, ihre SAP-Qualitätssicherung effizienter und gleichzeitig besser zu machen, so kommen sie am Thema Testautomation nicht mehr vorbei. Um die Vorteile, die man sich vom automationsunterstützten Testen erwartet, auch wirklich vollumfänglich nutzen zu können, gibt es aber einige wichtige Erfolgsfaktoren, die es zu berücksichtigen gilt. Der folgende Blogbeitrag basiert auf zahlreichen Kundengesprächen, deren Retrospektiven sowie unserer jahrzehntelangen Erfahrung mit Testautomation. Jeder Veränderung liegt eine unbefriedigende Ausgangssituation zugrunde. Im Hinblick auf die Qualitätssicherung Ihrer SAP-Systeme können dies unterschiedlichste Gesichtspunkte sein, welche den Wunsch nach einer Veränderung und Effizienzsteigerung aufkommen lassen. Diese oder ähnliche Sorgen sind es, welche Unternehmen dazu bewegen, über eine Adaptierung ihrer Teststrategie in Richtung Testautomation bzw. das radikale Ändern ihrer Testautomationslösungen nachzudenken, da diese nicht effizient oder nachhaltig umgesetzt sind. Die Entscheidung für das automationsunterstützte Testen hat große Auswirkungen auf die Qualitätssicherung und den Testprozess. Der Gewinn, welchen Sie durch Testautomation erreichen, hängt von strategisch wichtigen Überlegungen ab, denen Sie sich unbedingt VOR einer Entscheidung stellen müssen. Widmen wir uns nun den essentiellen Fragestellungen, die über Erfolg oder Nichterfolg von Testautomation entscheiden. Hohe Usability oder nur durch Fachexperten zu installieren? Ein zentraler Gesichtspunkt bei der Auswahl Ihrer Automationsstrategie muss, neben der selbstverständlichen Qualität und dem Funktionsumfang der Lösung, sein, ob die eingesetzten Lösungen von Ihrem eigenen Team umgesetzt werden können oder ob Sie massiv externe Unterstützung benötigen. Betroffene Parameter sind massiv erhöhte Einführungskosten (Projektkosten), hohe Kosten für Wissenstransfer zwischen Fachexperten und Automatisierern sowie eine planerische Abhängigkeit von externen Ressourcen. Schlüssel zum Erfolg einer Testautomation sind höchste Benutzerfreundlichkeit und der intuitive Aufbau der Automationslösung. Dadurch sind interne Fachexperten in der Lage, die SAP-Testautomation komplett selbständig aufzusetzen und zu warten, und zwar ohne weiteres Eingreifen durch externe Ressourcen. Oft werden Testsets automatisiert und funktionieren, praktisch fabriksneu, nach Wunsch. Doch mit der Zeit schwindet die Anzahl an funktionierenden Testfällen, hoher Wartungsaufwand ist nötig, um instabile Ansteuerungen zu korrigieren und die Automationsmaschine am Laufen zu halten. Betroffene Parameter sind massiv steigende Wartungskosten der Testautomationslösung, welche den Nutzen der Automation gegenüber dem manuellen Testen wegknabbern sowie die Bindung von internen oder externen Ressourcen, welche sich um die unnötig hohe Instandhaltung der Lösung kümmern müssen. Schlüssel zum Erfolg ist es, geschäftskritische Systeme wie Ihre SAP-Landschaften mit hochspezialisierten Automationstools zu testen, welche im Hinblick auf die verwendeten Technologien schon von Definition her weit stabiler sind als generalisierte Lösungen, welche eine breite Technologieunterstützung anbieten. Die Automation Ihrer SAP-Prozesse stellt eine große Erleichterung für ihr Testteam dar. Doch das ist erst der halbe Weg! Weiterhin muss Ihr Testteam sich darum kümmern, vor jedem Testlauf für jeden Testfall die Korrektheit, Aktualität und Unverbrauchtheit der Testdaten sicherzustellen. Betroffene Parameter sind ungenützte Einsparungspotentiale im Testprozess, Fehlwirkungen, die auf inkorrekte Testdaten zurückzuführen sind, und verlorene Ressourcen für das Tagesgeschäft aufgrund von unnötig hoher Ressourcenbindung im Testprozess. Schlüssel zum Erfolg ist die Vollautomation! Setzen Sie auf Lösungen, welche neben der Prozessautomation auch eine vollautomatische Testdatenbereitstellung liefern! Ungeliebte Testdatensuche gehört somit der Vergangenheit an und Ihre Fachexperten können sich dem wichtigen Tagesgeschäft widmen, anstatt repetitiv monoton Testdaten zu suchen. Reine Prozessautomationslösungen werden, durchaus verständlich, mit Bedacht eingesetzt, da jeder Durchlauf die vorhin besprochenen Testdatenbereitstellungsaufwände hervorvorruft. Dadurch erhöht sich die Anzahl der Testzyklen gegenüber dem manuellen Testen kaum und die mögliche Steigerung der Qualität wird nicht genutzt. Betroffene Parameter sind verzögerter Return on Investment, Automationslösungen, welche schlecht gewartet (da selten genutzt) werden und das volle Potential der Testautomation nicht nutzen. Schlüssel zum Erfolg ist, wie oben besprochen, die Vollautomation! Sie können eine massive Erhöhung der Testzyklen erreichen, da für zusätzliche Testläufe kein manueller Mehraufwand entsteht! Setzen Sie Ihre strategisch aufgesetzte Automationslösung so oft ein, wie Sie wollen, und maximieren Sie damit den Nutzen Ihrer Investition! Sie investieren in Testautomation, erstellen ein Testautomationsset, und es ist zu komplex, dieses auf unterschiedlichen Systemen zu verwenden? Sie setzen es nur auf Ihrer Q-Umgebung ein? Betroffene Parameter sind ungenütztes Potential durch die reine Verwendung in einer Stage (meist Q) als auch unnötiger Aufwand für die Adaptierung Ihres Testsets für andere Mandanten, Buchungskreise, … Schlüssel zum Erfolg, einmal mehr, die Vollautomation als auch die Parametrierbarkeit von Testfällen. Durch die Vollautomation haben Ihre Fachexperten selbst Ihre Prozesse automatisiert als auch dabei geholfen, die vollautomatische Testdatenbereitstellung zu konfigurieren. Was Ihnen dies nutzt? Plötzlich sind Ihre Entwickler im Stande, auf der DEV-Stage komplett automatisierte, fachliche Tests, ohne jeglichen manuellen Aufwand, durchzuführen. Das System sucht sich die Testdaten selbst, egal auf welcher Stage, und führt die automatisierten Testfälle aus. Somit profitieren Sie von massivem Qualitätsgewinn auf der DEV-Stage, also bevor die Entwicklungen auf die Q-Umgebung kommen. Sind die Testfälle auch parametrierbar, so können Sie ein und dasselbe Testset auf unterschiedlichsten Mandanten, Buchungskreisen, … durchführen, ohne unnötigen Konfigurationsaufwand oder gar Duplikate von Testfällen zu haben. All diese und noch einige andere Überlegungen helfen Ihnen, den Nutzen Ihrer SAP-Testautomation zu maximieren und nicht in Fallen zu laufen, welche potentiell Ihre Investitionen zunichte machen oder den Nutzen minimieren. Sehr gerne präsentieren wir Ihnen die suxxesso Vollautomation im Rahmen einer unverbindlichen Websession, eines PoC oder einer virtuellen Teststellung und gehen dabei auch gerne auf Ihre individuellen Fragen ein.

Eine gute Vorbereitung ist alles

Usability, intuitive Bedienung, Affordance, Aufgabenangemessenheit – alles wichtige Konzepte für eine menschenzentrierte, benutzerfreundliche Software. Wir heften uns auf unsere Fahnen, in unserer suxxesso Tool Suite eine mächtige, auf SAP spezialisierte Testautomations-Software unter Berücksichtigung der gängigen UX-Designkonzepte umgesetzt zu haben. Unser erklärtes Ziel ist es, dass ab sofort auch „Testautomationslaien“ ihre Prozesse ohne großes Vorwissen aufzeichnen können. Aber reicht dies für die erfolgreiche Einführung von Testautomation? Im Zuge der Workshops mit unseren Kund*innen treten bei den vorbereitenden Schritten die ersten Fragen auf: „Wie kann ich einen Arbeitsbereich anlegen? Ich habe keinen Zugriff auf das gemeinsame Laufwerk! Das Skripting ist nicht aktiviert!“ Spätestens wenn der erste Testfall gespeichert werden soll, poppen die nächsten Fragen auf: „Wie soll ich meinen Testfall benennen? Durchnummerieren oder Langtext?“ Um Testautomation nicht als notwendiges Übel oder zusätzlichen Ressourcenfresser zu empfinden, empfehlen wir eine gründliche Vorbereitung: Sind diese Grundvoraussetzungen geschaffen, kann das fröhliche Automatisieren beginnen! „Hier muss ich eine Entscheidung treffen, wie mein Prozess weitergeht. Je nachdem, welche Testdaten ich habe, …“ Kennen Sie diese Situation beim Testen? Beim manuellen Testen kein Problem – die Testdaten geben die Richtung vor, in welche Ihre getesteten Prozesse sich bewegen. Die Ausprägung der aktuellen Testdaten bestimmt somit die Aussagekraft Ihrer Tests und Ihre Testabdeckung – wollen Sie das wirklich? Beim automatisierten Testen ist diese „flexible“, von Testdaten bestimmte Vorgehensweise methodisch nicht State-of-the-Art. Aufgezeichnet und dokumentiert wird ein ganz konkreter Prozess, der einem genau vorspezifizierten Pfad folgt. Abzweigungen oder Entscheidungsbäume innerhalb des Testfalls und der Testausführung sind nicht erwünscht. Damit werden ganz bestimmte Testdatenkonstellationen voraussetzt, die definierte Ergebnisse liefern sollen, um eine erfolgreiche Verifikation zu ermöglichen. Nur so ist eine objektive und immer stabile Bewertung der Testergebnisse möglich. Testautomation erfordert häufig ein Umdenken beim Definieren der Testfälle, beim Abgrenzen der Testfälle, beim Beschreiben der Testfälle. Diese und viele andere Themen tauchen im Zuge der Workshops bei unseren Kund*innen auf. Diese Workshops dienen nicht nur der reinen Wissensvermittlung zu unseren Tools, sie sollen nicht nur mit dem Handling vertraut machen, sondern bieten auch viel Raum für organisatorische, methodische und sonstige Fragen rund um das Thema Testautomation. Sie als Teilnehmer*innen profitieren davon, dass Sie Testfälle auf den eigenen, vertrauten Systemen aufzeichnen und wir Ihre dabei auftretenden Fragen und Unklarheiten durch Best Practice-Beispiele und unsere langjährige Erfahrung beantworten. So unterstützen wir Sie bestmöglich bei der Einführung von Testautomation in Ihrem Unternehmen und Sie sparen wichtige Ressourcen durch Vermeidung von unnötigen „Anfängerfehlern“. Möchten auch Sie begleitet von Expert*innen in Ihr Projekt Testautomation starten, so kontaktieren Sie uns für einen Workshop! Wir unterstützen Sie gerne.

Die Evolution der Testautomation bis hin zu völlig neuen Einsatzgebieten

Testautomation ist vielschichtig. Von codebasierten Unittests über Lasttests bis hin zu vollautomatisierten User Acceptance- und Funktionstests deckt sie ein breites Spektrum ab, welches die Qualitätssicherung von Softwareprodukten nachhaltig revolutioniert hat. Testautomation war nicht von heute auf morgen da – sie hat sich, nach heutigen IT-Maßstäben gerechnet, kontinuierlich und gesund entwickelt zu dem, was sie heute ist: eine mächtige Unterstützung zum manuellen Testen. Doch die Entwicklung der Testautomation ist noch lange nicht abgeschlossen. Viele derzeit noch unausgereifte Ansätze wie KI-basiertes Testen, werden in den kommenden Jahren in der Qualitätssicherung Einzug halten. Doch immer mit der Ruhe – die kontinuierliche, nicht überhastete Entwicklung der Testautomation hat sie zu dem gemacht, was sie heute ist. In der Qualitätssicherung unserer wichtigsten IT-Systeme und Landschaften dürfen wir keine Kompromisse eingehen und keine Versuchskaninchen sein – automatisiertes Testen bzw. automatisierte Tätigkeiten müssen objektiv und vor allem 100% verlässlich sein. Roboter oder Automaten, welche uns die tägliche Arbeit abnehmen, sind rapide am Markt erschienen. Sie sollen vor allem folgende Tätigkeiten übernehmen, um unsere Mitarbeiter von „Basistätigkeiten“ zu befreien und sie für komplexe Tätigkeiten freihalten: Und vor allem: sie sollen dies auf unseren Produktivumgebungen machen. Wenn man sich die angeführten Aufgaben ansieht, für welche RPA Tools gedacht sind, wird man eines schnell erkennen: sie sind identisch mit jenen, die auch von Testautomationstools abgedeckt werden. Nun stellt sich die Frage: wenn Testautomation und RPA so viele Gemeinsamkeiten haben, wo sind die Unterschiede? Denken wir weiter in der Evolution, so gibt es einen logischen Schritt für die Entwicklung des Einsatzes Ihrer Testautomationstools, so diese modernen Ansprüchen im Hinblick auf Usability als auch Vollautomation entsprechen: Die Erweiterung des Einsatzgebietes von Testautomation in Richtung Prozessautomation. Warum ist dies die optimale Lösung? Testautomationstools wie unsere suxxesso Tool Suite mögen sich vielleicht am heutigen Tag noch nicht das Label „RPA Tool“ anhaften, jedoch ist der Weg nicht mehr weit. wir folgen weiter der bewährten, kontinuierlichen Evolution der Software, um am Ende eine ausgereifte Lösung darzustellen, welche Sie bedenkenlos auf Ihren Produktivumgebungen einsetzen und damit mehrere Fliegen mit einer Klappe erschlagen können: hochfrequent getestete Automatien auf Ihren bewährten Qualitätssicherungssystemen, welche für Sie weiterhin den Testaufwand Ihrer Prozesse um bis zu 80% verringern. Und zusätzlich nehmen Ihnen ein und dieselben Automaten Teile Ihrer Aufgaben auf den Produktivsystemen ab. Jedoch nicht mit einem mulmigen Bauchgefühl, denn dieses beseitigen sie auch, da sie laufend getestet und auf den weniger kritischen Umgebungen im Einsatz sind.

Business-Gamechanger SAP-Testautomation

Produktivitätssteigerung, Ressourcenoptimierung, kürzere Time To Market. Zu selten werden diese Begriffe mit Testautomation in Verbindung gebracht. In unserem heutigen Blogbeitrag wollen wir Testautomation aus dem Blickwinkel von Entscheidungsträgern betrachten: Hilft uns das automationsunterstütze Testen unserer Systeme im Hinblick auf unsere Prozesse? Können wir businessrelevante Faktoren damit positiv beeinflussen? Qualitätssteigerung, objektive Testergebnisse, hohe Testabdeckung – all dies sind mittlerweile Begriffe, die mit Testautomation assoziiert werden. Doch neben diesen zugegebenermaßen sehr wichtigen Aspekten, hat eine strategisch gut geplante und implementierte Automationslösung massiv positive Auswirkungen auf Ihre Geschäftsprozesse. Testautomation hilft nicht nur dabei, Ihre Testabdeckung zu erhöhen, sondern reduziert die Durchlaufzeiten der Testzyklen drastisch, wodurch Releases und Hotfixes viel schneller ausgerollt werden können. Mithilfe von Testautomation sparen Sie bis zu 80% Ihres Ressourcenaufwands bei der Testvorbereitung und Testdurchführung. Neben höherer Auslieferungsqualität können Ressourcen für Ihre eigentlichen Tätigkeiten, das Tagesgeschäft, eingesetzt werden – Sie erreichen eine merkbare Produktivitätssteigerung durch Minimierung Ihres manuellen Testaufwands. Die mit höchster Usability ausgezeichnete suxxesso Tool Suite spart zusätzlich noch den Einsatz externer Ressourcen, da Ihre Mitarbeiter, die täglich mit den Prozessen arbeiten, selbst zu Testautomatisierern werden – innerhalb weniger Minuten! Eine nachhaltig durchdacht entwickelte Teststrategie, welche Testautomation als zentralen Bestandteil der Qualitätssicherung beinhaltet, hilft nicht nur Ressourcen für das Tagesgeschäft freizuspielen, sondern auch Kosten zu sparen. Kostenersparnisse bei Personaleinsatz in Testzyklen, einfache Wartung der Testbasis, als auch Einsparungen bei Support und Wartung der Systeme durch höhere Testabdeckung, häufigere Testzyklen und somit gesteigerte Qualität helfen bei der Senkung Ihrer Projekt- und Betriebskosten. Die gleichzeitige Steigerung der Benutzerzufriedenheit durch stabilere Systeme und das weitgehende Eliminieren der ungeliebten manuellen Testaufgaben, sind weitere positive Aspekte, welche für den Einsatz automatisierter Testwerkzeuge sprechen. suxxesso bietet Ihnen sehr gerne eine Teststellung unserer mit höchster Usability ausgezeichneten suxxesso Tool Suite an. Sehen Sie auf Ihren eigenen Systemen, wie einfach, schnell und intuitiv SAP-Testautomation in Ihre Qualitätssicherung integriert werden kann und wie rasch sich die vorhin besprochenen Business-Wins für Sie und Ihr Unternehmen umsetzen lassen!

Vollautomatisierte Berechtigungs- und Workflowtests für Ihre SAP-Systeme

Einer unserer Kunden bat um Unterstützung beim Testen seiner Workflows sowie der SAP-Berechtigungseinstellungen. Ziel war es eine umfangreiche Testabdeckung der Berechtigungseinstellungen abzubilden, welche zusätzlich an unterschiedlichen Standorten getestet werden sollen. Testautomation wird berechtigterweise zumeist mit funktionalen Tests in Verbindung gebracht. Baut man sein Testset geschickt auf, so können mit Hilfe der Testautomation auch nicht-funktionale Tests durchgeführt werden. Viele Testautomationen sind so aufgesetzt, dass funktionale Tests mit eigens konfigurierten Usern durchgeführt werden, welche auf der jeweiligen Testlandschaft umfangreiche Berechtigungen besitzen, um hier möglichst einfach und ohne Abbildungen von Workflows und Berechtigungskonzepten, die rein funktionalen Aspekte der SAP-Systeme zu testen. Oft ist es aber gewünscht und nötig, auch das Zusammenspiel der unterschiedlichen Rollen in End-to-End Testszenarien abzubilden. Unterschiedliche Konzepte der Toolanbieter führen hier teils zu Einschränkungen, welche diese Art der Test nur unzureichend abbildbar machen. Die suxxesso Tool Suite setzt für den Test von Workflows auf die Funktionalität der Role-Steps. Ein Role-Step besteht aus einem oder mehreren Testschritten, welche mit dem suxxesso Test Pilot automatisiert wurden. Der Role-Step fasst also Testschritte zusammen, welche mit einer bestimmten Rolle und damit deren spezifischen Berechtigungen ausgeführt werden sollen. Die Eleganz der Lösung besteht im vollautomatisierten Credential-Management der Testengine, welche zu jedem Zeitpunkt das Sessionmanagement sauber steuert und Sie so beliebig verschachtelbare Workflows abbilden lässt – ganz egal ob wir im selben System bleiben, unterschiedliche SAP-Systeme ansteuern oder auch Drittsoftware in unsere Workflowtests einbinden. Sobald die Testengine bei der Ausführung auf einen Role-Step trifft, greift das Sessionmanagement. Wird eine neue Anmeldung benötigt, so wird vollautomatisch eine neue Session eröffnet, welche bis zum letzten Schritt des Role-Steps aktiv bleibt. Danach entscheidet das Credential-Management der suxxesso Tool Suite, ob die Session im weiteren Verlauf noch benötigt wird oder geschlossen werden kann – ganz von selbst, ohne Ihr Zutun. Sie müssen sich weder um Anmeldemaske, Orchestrierung oder den korrekten Wechsel zwischen den Sessions kümmern. Entscheidend für einfach zu erstellende und gleichzeitig stabile Workflows ist ein hochentwickeltes Sessionmanagement, welches zu jeder Zeit sicherstellt, dass der rote Faden des Workflows nicht verloren geht und Sessions sauber wiederverwendet oder beendet werden. Dieselbe Engine, welche uns für die oben besprochenen Workflowtests behilflich ist, unterstützt uns beim Abbilden von lückenlosen Berechtigungstests. Oftmals alleinig in der Verantwortung von SAP-Systemadministratoren werden Berechtigungstests, vor allem wenn sie gewissenhaft und umfangreich durchgeführt werden sollen, gerne auf die lange Bank geschoben oder nur unzureichend durchgeführt. Testautomation bietet uns die Möglichkeit unser Berechtigungskonzept mit Hilfe von Automationsbausteinen abzubilden und diese mit unterschiedlichen Rollen auszuführen. Basis hierfür ist ein sauberes Bausteinmanagement, welches dem Benutzer die Möglichkeit gibt, sowohl Negativ- als auch Positivtestfälle mit ein und demselben Baustein durchzuführen. Alles andere würde in einem unüberschaubaren Chaos von Testfällen und Bausteinen enden, welche nur schwer wartbar und verwaltbar sind. Das Zusammenspiel der suxxesso Role-Steps und Bausteine ermöglicht einen lückenlosen, sauber dokumentierten Berechtigungstest, der sowohl für Process-Owner als auch Administratoren klar strukturiert und objektiv einen Überblick über die korrekte Konfiguration der SAP-Berechtigungseinstellungen liefert.

Effiziente Wartung Ihrer Testautomationslösung

Nachdem sich Unternehmen für Testautomation entschieden haben, steht der Aufbau des Testautomationssets im Fokus der Aufmerksamkeit.

Testing 1×1 – Regressionstest, Re-Test und Testautomation

Oftmals können ähnliche Begrifflichkeiten im Test zu Verwirrungen und Missverständnissen führen. In unserem heutigen Testing 1×1 wollen wir uns dem Regressionstest und dem Re-Test widmen und deren Rolle in der SAP-Testautomatisierung beleuchten. Beide klingen ähnlich, haben jedoch eine komplett unterschiedliche Aufgabe in der Software-Qualitätssicherung. Sehen wir uns zuerst den Regressionstest an. Der Regressionstest kümmert sich in der Qualitätssicherung darum, dass Systemfunktionalitäten nach einer Systemänderung noch gleich funktionieren wie vor der Änderung. Er prüft also für uns die unveränderte Funktionalität des Systems. Nehmen wir also am System ein Update vor, so soll dieses in den allermeisten Fällen ja nicht jegliche Funktionalitäten im System verändern, sondern maximal gewisse Prozessabläufe ändern bzw. neue Funktionalitäten hinzufügen. Der große Rest unseres Systems, der unverändert bleiben soll, ist im Fokus der sogenannten Regressionstests. Sie sollen sicherstellen, dass die vorgenommenen Änderungen am System nicht zu unerwünschten Verhaltensänderungen am Rest des Systems geführt haben. Beispiel: Unser Webshop wird durch einen Produktkonfigurator erweitert. Mit Hilfe dieses Konfigurators soll es für den Kunden möglich sein, Varianten eines Produkts nach seinen Vorstellungen zu gestalten. Das Einloggen, der Bezahlvorgang, die Eingabe der Kundenstammdaten, das Kontaktformular, … bleiben von der Änderung unbeeinflusst (bzw. sollen unbeeinflusst bleiben). Wir prüfen hier mittels Regressionstest, oder einfach gesprochen: in einem Vorher-Nachher Test, ob sich unser System in den nicht zu ändernden Bereichen weiterhin gleich verhält und keine unerwünschten Verhaltensänderungen am System auftreten. Der Re-Test, oftmals mit dem Regressionstest verwechselt, hat eine komplett andere Rolle in unserer Qualitätssicherung. Er kommt erst dann ins Spiel, wenn wir schon Fehlzustände gefunden haben. Seine Aufgabe ist es nämlich zu prüfen, ob ein im Zuge eines Testzyklus aufgetretener Fehler nach der Korrektur durch die Entwickler in einem weiteren Testdurchlauf nun behoben ist. Beispiel: Finden wir also in unserem System einen Fehlzustand, so melden wir diesen in Form eines Fehlerreports ein. Danach wird dieser von Entwicklern behoben und ein Update auf das System gespielt, um uns einen neuerlichen Test der Funktionalität zu ermöglichen – den Re-Test. Im Zuge dieses neuerlichen Testens prüfen wir, ob unser gefundener Fehlzustand durch die Fehlerbehebung der Entwickler korrigiert werden konnte – das ist die Aufgabe des Re-Tests. Oftmals diskutiert wird beim Re-Test, welche Testfälle nun nach dem Auffinden eines Fehlzustandes nochmals durchgeführt werden sollen: Diese Frage lässt sich in Zeiten der Testautomation sicher einfacher beantworten. Hier gehen wir gerne ein wenig von der klassischen Testschule ab und sagen: wenn kein Zusatzaufwand für den Tester auftritt, so ist es durchaus legitim die umgebenden Bereiche meiner gefundenen Fehlwirkung intensiv und großzügig zu testen, um damit potentielle Seitenwirkungen einer Fehlerbehebung zu prüfen. Oftmals ist es so, dass Fehlwirkungen andere Fehler maskieren: der maskierte oder bis dahin verdeckte Fehler tritt erst auf, wenn der maskierende Fehler behoben ist. Es kann uns aber auch passieren, dass die Behebung eines Fehlers bzw. das Coding, welches unseren Fehler behebt, an anderer Stelle ungewollt zu einem Folgeproblem, einer sogenannten Seitenwirkung, führt. Beide dieser Fälle befinden sich oft im Umkreis der ursprünglichen Fehlfunktion, können aber durchaus auch in einem weiter gefassten Gebiet auftreten. Die klassischen Einsatzgebiete der Testautomation umfassen genau den vorhin besprochenen Regressionstest. Hier können unsere wichtigsten Prozesse mittels Testautomation mit einer Testabdeckung belegt werden und beliebig oft, zu beliebigen Zeitpunkten, das gewünschte Systemverhalten sichergestellt werden. Fügen wir unserem System weitere Funktionalität hinzu, so werden diese neuen Funktionalitäten durch Erstellen von neuen Testfällen in unser Regressionstestfallset übernommen.

Externe Abhängigkeiten vermeiden und Qualität steigern

Für unseren Kunden, ein Unternehmen aus der Pharmaindustrie, ist es wichtig, in der Qualitätssicherung nicht auf andere angewiesen zu sein und die Qualität bei möglichst hoher Effizienz zu steigern. Nachdem jahrelang manuell getestet wurde, entschied man sich vor zwei Jahren für die Einführung von Testautomation. Mit externer Unterstützung wurden Testsets aufgebaut, welche im Hinblick auf Stabilität der Ansteuerung und Aufwand der Testdatenbereitstellung sehr wartungsintensiv waren. Durch die laufend nötige externe Unterstützung sowie die teilweise instabile Ansteuerung der Prozesse wurde nach und nach der Fokus wieder zum manuellen Test hin verschoben. Dadurch ergaben sich oftmals die leider bekannten Probleme wie: Gemeinsam mit dem Kunden wurden die Ziele definiert, welche mit der automationsunterstützten Qualitätssicherung erreicht werden sollten: In gemeinsamen Gesprächen und nach einer zweistündigen Websession konnte die endgültige Entscheidung zugunsten der suxxesso Tool Suite getroffen werden. Nach dem erfolgten Kickoff-Termin und einem dreitägigen, gemeinsamen Workshop zur Einschulung der involvierten Mitarbeiter auf Kundenseite konnten die Process-Owner bereits komplett selbstständig ihre Prozesse automatisieren und somit die manuelle Testlast verringern. „Wir konnten unseren Testaufwand um rund 80% verringern, ohne externe Ressourcen aufbauen zu müssen. Die Anpassung der Testfälle kann zu 100% von unseren eigenen Fachexperten durchgeführt werden“, so der Projektleiter unseres Kunden. Als Basis wurden die in der suxxesso Tool Suite bereits vorgefertigten Testfälle verwendet und in Details an die eigenen Prozesse angepasst. Bereits durch diesen ersten Schritt wurden massive Zeiteinsparungen bei gleichzeitigem Qualitätsgewinn erzielt. Schlüssel zum Erfolg des Projekts sind die hohe Benutzerfreundlichkeit und der intuitive Aufbau der suxxesso Tool Suite. Dadurch ist unser Kunde in der Lage, die SAP-Testautomation komplett selbständig und ohne weiteres Eingreifen durch das suxxesso Team durchzuführen. Die stabile Ansteuerung der SAP-Technologien durch die Spezialisierung unserer Tools auf SAP-Testautomation hat im Team schnell zu Erfolgserlebnissen und dem merkbaren Nutzen der Testentlastung jedes Einzelnen im Testteam geführt. Durch die bereits nach wenigen Tagen eigenständige Testautomation konnten die Zweifel, welche nach der ersten, missglückten Einführung von Testautomation durchaus vorhanden waren, rasch beseitigt werden. Die Akzeptanz der Testautomation innerhalb der Fachbereiche sowie deren Mitwirken sind für einen dauerhaften Einsatz und eine Erweiterung der Testabdeckung unabdingbar. Mittlerweile, rund ein Jahr nach Projektstart, testet unser Kunde mehrmals wöchentlich mittels unterschiedlicher Testsets die Funktionalität seiner Systeme. Die quantitativ häufigeren Tests führen zu einer Entlastung des Supports, da Fehler schon vor Auftreten im Produktivbetrieb von der Testengine gefunden und somit einer Behebung zugeführt werden können. Entwickler nutzen fachliche Tests, um bereits auf DEV-Umgebungen die Qualität möglichst hoch zu halten. Dies ist durch die automatisierte Testdatenbelieferung des suxxesso Data Managers und die vollautomatisierten Tests möglich. Entwickler ohne detailliertes Fachwissen können so bis ins Detail fachliche Funktionalitäten bereits in frühen Entwicklungsstadien testen und erhöhen somit die Qualität der gelieferten Lösungen weit vorne im Qualitätssicherungszyklus. Die massive Effizienzsteigerung beim Testen, das damit verbundene Freispielen der Fachexperten für ihre eigentlichen Kernaufgaben sowie die deutliche Verschiebung des Qualitätslevels bereits in frühen Phasen der Qualitätssicherung machen dieses Projekt zu einer Erfolgsgeschichte, die wir als suxxesso gmbh gerne weitererzählen. Suchen auch Sie nach einer effizienten Testautomationslösung, welche hochspezialisiert auf Ihre Kernsysteme ist? Hakt Ihre aktuelle Lösung?

Aufbauende Testketten vs Einzeltestfall – oder warum Testautomation anders tickt

Die Testabdeckung, ein heiliges Gut in der Qualitätssicherung, soll möglichst hoch ausfallen, um die Qualität der zu betestenden Systeme bestmöglich sicherzustellen. Warum in Zeiten von Testautomation Ansätze aus dem manuellen Testen nicht mehr das optimale Mittel sind, wollen wir in unserem heutigen Blogbeitrag erläutern. Im manuellen Test sind Tester bestrebt, und dies absolut berechtigt, möglichst effizient eine hohe Testabdeckung im Testzyklus zu erreichen. Meist geschieht dies durch die Aneinanderreihung von Einzeltests zu aufbauenden Testketten bis hin zu vollständigen End to End Testszenarien. Im Zuge des manuellen Tests baut sich der Tester, ausgehend von den Initialtestdaten, ein komplettes Szenario auf und testet mit diesem Testdatenset seine kompletten, sich meist über viele Transaktionen und Module erstreckenden, Testketten. Findet sich im Zuge der Durchführung dieses Tests ein Fehler, kann der Tester entsprechend reagieren und einen Fehlzustand melden. Der Problematik, dass im Zuge dieser Testkette nun vielleicht die Folgeschritte nicht mehr mit den Testdaten des bisherigen Testdurchlaufs durchgeführt werden können (z.B.: weil ein Auftrag aufgrund eines Fehlers nicht angelegt werden konnte und man nun mit diesem Auftrag in der Kette nicht weiterarbeiten kann), wirkt der Tester durch Adaption der Testdaten (durch Auswahl eines bereits vorhandenen Auftrags oder durch Umgehung des Problems bei der Auftragsanlage) entgegen. Diese lineare Durchführung von zusammenhängenden Tests hat sich beim manuellen Testen, durchaus berechtigt, zu einer beliebten Art des Testvorgehens entwickelt. Der Aufwand für Testdatensuche kann so optimiert werden Verwendet man dieselbe Vorgehensweise der aufbauenden Testketten in der Testautomation, stößt man auf das Problem, dass im Fehlerfall der Automat nicht einfach wie ein manueller Tester eine Alternative sucht, um mit den restlichen Schritten der Testkette fortzufahren, sondern es wird ein Fehler für den Testfall ausgegeben. Passiert dieser Fehler früh im Prozess, bekommen wir eine Aussage zur Qualität und Funktionalität unseres Systems nur bis zum entdeckten Fehlzustand. Der Testfall endet an diesem Punkt und wir bekommen keinerlei Aussage zum Rest der Testkette. Dies ist ineffizient und nicht zeitgemäß. Wir wollen der Bedeutung von aufbauenden Testketten als auch End to End Tests nichts von ihrer Wichtigkeit nehmen. Es ist essentiell, auch das Zusammenspiel der einzelnen Systemmodule, den durchgängigen Prozessdurchlauf, zu testen. Für die Testautomation, um möglichst effizient und mit hoher Testabdeckung zu testen, empfehlen wir, möglichst granulare Tests einzeln auszuführen, und zu den einzelnen Verifikationsobjekten Einzelaussagen zu bekommen. Natürlich dürfen auch Einzeltestfälle nicht aufeinander aufbauend sein (erst wenn man sie z.B.: dem Bausteinsystem des suxxesso Test Pilots zu Ketten zusammenfügt), sondern sollen völlig autonom ausführbar sein. Um dies sicherzustellen, muss jeder Einzeltestfall seine eigenen Testdaten bekommen. Dies kann den Aufwand der Testdatenbereitstellung massiv erhöhen, ist aber aufgrund der Überlegungen von zuvor, unumgänglich. Ein Lösungsweg hier ist der innovative Testdatenbereitstellungsansatz des suxxesso Data Managers: wir lehren dem Data Manager einmalig die Voraussetzungen der Testdaten für den jeweiligen Testfall. Ab diesem Zeitpunkt kann der suxxesso Data Manager bei jedem Aufruf des Testfalls live akkurate, den Testdatenanforderungen entsprechende, unverbrauchte Testdaten zur Verfügung stellen und somit dem Tester den kompletten Testdatenbereitstellungsaufwand abnehmen. Somit können wir sowohl Einzeltests als auch komplexe, aufeinander aufbauende, Testketten testen, ohne jeglichen Aufwand für die Testdatensuche betreiben zu müssen. Diese Möglichkeit ist für die Qualitätssicherung, vor allem im agilen Umfeld, extrem wertvoll, da sowohl granulare Funktionalitäten als auch End to End Prozesse gleichermaßen abgedeckt sind und somit die Testabdeckung maximiert werden kann. Versuchen Sie also schon bei der Konzeption Ihrer Testautomationsstrategie auf die durchaus unterschiedliche Art der Verifikationsmöglichkeiten, die Ihnen im Gegensatz zum manuellen Test zur Verfügung stehen, zu reagieren. Optimieren Sie Ihr Testvorgehen und maximieren Sie somit den Nutzen Ihrer Investition in die Testautomation – die Qualität Ihrer Systeme wird es Ihnen danken!

Rechnet sich Testautomatisierung?

Der Hauptgrund, warum in Projekten über Testautomation nachgedacht wird, schwankt zwischen den beiden klassischen Beweggründen: Qualitätssteigerung und Durchlaufzeit der Testzyklen. Je umfangreicher unsere Testabdeckung in einem Testzyklus ist, je schneller wir die Testphase einer Release durchlaufen, desto besser. Nicht falsch verstehen, das sind sehr wichtige, wenn nicht die wichtigsten Aspekte welche für Testautomation sprechen. Wenn es jedoch um Managemententscheidungen geht tritt auch noch ein wichtiger dritter Aspekt ins Rampenlicht, der oft in der Entscheidung über den Einsatz von Testautomation der letzte ausschlaggebende Faktor ist: der Return on Investment (ROI). Oft beschäftigen wir uns in unserem Blog als auch in Kundengesprächen mit den wichtigen Aspekten der Testabdeckung sowie der Zeitersparnis, welche wir mit Testautomatisierung erzielen können. Diese beiden Aspekte müssen im Testen von z.B.: SAP-Systemen in der heutigen Zeit eine Selbstverständlichkeit sein. Mit dem Einsatz der suxxesso Tool Suite steigern Sie Ihre erzielbare Testabdeckung enorm, gewinnen wertvolle Zeit in Testzyklen durch die Minimierung der Durchlaufzeit Ihrer Testläufe und maximieren die Objektivität Ihrer Qualitätssicherung. Heute möchten wir den Fokus auf den Return on Investment legen. Welche für das Management wichtigen Drehschrauben ändern sich mit dem Einsatz von Testautomation entscheidend? In welchem Maße ändern sie sich? Wie können wir den Einsatz der suxxesso Tool Suite in unserer SAP-Qualitätssicherung, neben den Qualitäts- und Geschwindigkeitsmetriken, messbar und bewertbar machen? Um eine Messbarkeit des ROI zu erreichen, gilt es die richtigen Parameter zu identifizieren, welche eine Bewertung möglich machen. Betrachtet man diese Parameter, so kann man einen objektiven ROI für den Einsatz von Testautomation auch in Ihrer SAP-Qualitätssicherung errechnen. Im Folgenden möchten wir gemeinsam mit Ihnen einen Blick auf die einzelnen Parameter legen, um deren Bedeutung für den ROI nochmals zu beleuchten. Die Anzahl jener Testfälle welche Sie mit einer Testautomationslösung wie der suxxesso Tool Suite automatisieren können, trägt entscheidend zur Berechnung des ROI bei. Sie hilft uns zu ermitteln wie hoch der Anteil der Testfälle ist, den Ihr Testteam nicht mehr manuell, sondern vollautomatisiert durchführen kann. Die Anzahl der Ausführungen jedes Testfalls innerhalb einer Testphase (z.B.: eines 14-tägigen Funktionstests) wirkt sich auf den Aufwand aus, den sich Ihr Testteam pro Testzyklus erspart. Je öfter wir nun einen automatisierten Testfall durchführen, desto massiver wirkt sich die Ersparnis gegenüber einer manuellen Testfalldurchführung aus. Analog zu den Testläufen pro Zyklus erhöht sich die Ersparnis durch Testautomation auch mit der Anzahl der Testzyklen pro Jahr. Wie viel Aufwand entsteht für das Testteam durch die Ausführung eines manuellen Testfalls? Die Antwort auf diese Frage beeinflusst den Faktor Zeit, den wir uns durch die Automation eines einzelnen Testfalls ersparen. Automatisiert man einen Testfall, so entfällt in zukünftigen Testzyklen der Aufwand für die manuelle Durchführung. Die Testdatenbereitstellung ist oft für mehr als 50% des Gesamtaufwands des Testaufwands verantwortlich. Das Suchen von aktuellen, unverbrauchten, nicht veralteten Testdaten für jeden einzelnen Testfall ist ein massiver Aufwandstreiber und noch dazu eine Aufgabe, welche kein Tester gerne macht. Für jede einzelne Durchführung eines Testfalls müssen die Testdaten vor der Ausführung geprüft und gegebenenfalls überarbeitet werden – dies gilt im Übrigen sowohl für manuelle Tests als auch für viele Testautomationslösungen am Markt, welche mit statischen, manuell gepflegten Testdaten arbeiten. Mit Hilfe des suxxesso Data Manager setzen wir, einmalig konfiguriert, diesen Aufwand für alle automatisierten Testdurchführungen auf Null. (Mehr Informationen zu unserem suxxesso Data Manager finden Sie hier). Der interne Stundensatz mit welchem Sie Ihre Mitarbeiter bewerten, ist entscheidend für die Kalkulation, ob und wann sich eine Testautomation für Sie rechnet. Gemeinsam mit dem ersparten Aufwand ergibt er einen wichtigen Faktor in der ROI Rechnung. Zugegeben der wohl am Schwierigsten zu bewertende Faktor ist der Aufwand der Testautomation. Hier spielen viele Faktoren eine Rolle, welche Sie berücksichtigen müssen: Entscheidend hier ist, wie einfach ist die Testautomation einzuführen? Können die eigenen Mitarbeiter Tests automatisieren und vor allem die nicht zu vernachlässigbare Wartung der Testfälle in Zukunft durchführen? Oder kommen hier laufend Kosten für externe Berater auf mich zu? Um hier eine objektive Betrachtung zu erreichen kommen Sie meist nicht umhin, vor der Anschaffung Teststellungen der Automationslösungen durchzuführen und gemeinsam mit jenen Personen, die später mit den Tools arbeiten, eine objektive Bewertung der angeführten Parameter durchzuführen. Überzeugen Sie sich von der Bedienbarkeit, der Stabilität und der erzielbaren Ersparnis durch die angedachte Testautomationslösung! suxxesso bietet Ihnen sehr gerne eine Teststellung unserer, mit höchster Usability ausgezeichneten, suxxesso Tool Suite an. Profitieren Sie davon, den Aufwand der Testdatenbereitstellung auf 0 zu setzen. Durch die nur mit Spezialisierung auf SAP-Testautomation erreichbare Usability, welche Ihren Fachbereich ermächtigst selbstständig seine Tests zu automatisieren, minimieren Sie die Kosten für externe Beratung.

suxxesso Q&A – intuitive und gleichzeitig mächtige Tabellenansteuerung im suxxesso Test Pilot

Die Ansteuerung von Tabellen oder tabellenähnlichen Konstrukten, sowohl in SAP-GUI als auch SAP-Webtechnologien, ist eine der schwierigsten Herausforderungen, welche Testautomations-Tools bewältigen müssen. Am heutigen Beispiel einer Kundenanfrage wollen wir die Usability, mit welcher der suxxesso Test Pilot diese Ansteuerungen meistert, aber auch die umfangreichen Möglichkeiten des Tabellendurchsuchens darstellen. Die Unterstützung unserer Tabellen-Engine umfasst neben der klassischen Table Control in der SAP-GUI auch Texttabellen, welche im GUI nicht als Tabellen dargestellt, sondern in Form von Textelementen angeordnet sind. Nachfolgend einige Beispiele: Nicht nur für die unterschiedlichen Tabellenarten, auch für unterschiedliche Technologien läuft die Bearbeitung von Tabellen im suxxesso Test Pilot immer gleich ab. Ganz egal, ob Sie SAP-GUI oder eine andere der unterstützten SAP-Frontendtechnologie ansteuern möchten. Für den User ändert sich nichts! Gleicher Funktionsumfang, gleiche Handhabung – somit höchste Usability! Diese Anfrage erreichte vor Kurzem unser Supportteam und wir wollen es zum Anlass nehmen, einen Einblick in die umfangreichen Automations- und Verifikationsmöglichkeiten unserer Tabellen-Engine zu geben. Die Prozessautomation mit dem suxxesso Test Pilot setzt auf höchste Usability, sodass auch Nicht-Automationsexperten damit ihre Prozesse automatisieren können. Gleichzeitig, durch die Spezialisierung unserer Tools auf SAP-Technologien, steht ein riesiger Funktionsumfang zur Verfügung, der nur durch diese Spezialisierung und die mit der Automation von SAP-Prozessen einhergehenden Herausforderungen möglich ist. Am Beispiel eines Flugplans der SAP-Transaktion dwdm wollen wie Ihnen die Möglichkeiten unserer Tabellen-Engine vorstellen. Wir selektieren in der Spalte Abflugstadt San Francisco als Eintrag (natürlich wären auch die Kombination mehrerer Spalten als Erkennungsmerkmal zulässig). Dieser Automationsschritt wird automatisch als Tabellen-Schritt erkannt und im suxxesso Test Pilot stehen uns dadurch die umfangreichen Möglichkeiten der Tabellenansteuerung zur Verfügung. Ziel dieses Beispiels ist es nun, Zeilen in dieser Tabelle zu identifizieren. Auf diese gefundenen Zeilen können wir dann beliebige Aktionen wie zum Beispiel das Ändern der Abflugzeiten oder eine Verifikation vornehmen. Folgende Möglichkeiten stehen uns zur Verfügung: Dieser kurze Einblick in unsere Tabellen-Engine zeigt die Spezialisierung auf SAP und den hohen Funktionsumfang an Möglichkeiten, den Sie von der suxxesso Tool Suite erwarten dürfen. Gleichzeitig sind diese hochspezialisierten Ansteuerungsoptionen für Tabellen für jedermann innerhalb kürzester Zeit erlernbar und intuitiv anwendbar. Dadurch bleibt das Automationswissen in Ihren Fachbereichen, Testfälle können einfach vom Process-Owner automatisiert und auch angepasst werden, ohne externe Hilfe einkaufen zu müssen!

Testing 1×1: Die Rolle von Testdaten im Softwaretest und der damit verbundene Aufwand in Testzyklen

In unserer Rubrik Testing 1×1 wollen wir heute auf die Rolle der Testdaten im Softwaretest und im Speziellen beim Testen von SAP-Systemen eingehen. Testdaten kommt, neben dem reinen Durchlauf des Testfalles, eine enorm wichtige Rolle zu, welche vor allem im Zusammenhang mit Testautomation oft unterschätzt wird. Nach einem kurzen Beispiel sollen unterschiedliche Aspekte aufgezeigt werden, die im Zusammenhang mit Testdaten zu berücksichtigen sind. Unter Testdaten versteht man im Softwaretest jene Eingaben, welche im Prozess- bzw. Testfalldurchlauf eingegeben werden, um einerseits den Prozess und andererseits die Korrektheit des Durchlaufs sicherstellen zu können. Dies klingt erstmal einfach, ist bei genauerer Betrachtung aber auch mit weiteren Überlegungen verbunden, auf welche wir gerne im Folgenden an Hand eines Beispiels eingehen möchten. Beispiel: Sie erfassen einen Kundenauftrag für ein Material. Die Testbedingung (legt fest, was getestet werden soll) in unserem Beispiel ist, dass ein Auftrag nur dann erfolgreich durchgeführt werden kann, wenn genügend Material auf Lager und verfügbar ist und die Mindestmenge des Materials bestellt wird. Wir müssen für unseren Testfall vor der Ausführung also ein Material suchen, welches aktuell auf Lager und verfügbar ist, und zwar in der (Mindest)Menge, die wir für unseren Testfall benötigen. In der Sprache des Softwaretests gesprochen: die Anforderungen an die Testdaten für unseren Testfall sind: Diese Überlegungen zu den jeweiligen Testdatenbedingungen müssen wir für alle Testfälle, welche wir in unserem Testplan durchführen, tätigen. Tipp: Schreiben Sie diese Anforderungen an die Testdaten möglichst präzise und eindeutig fest. Dies ist für die Dokumentation und Wiederausführung von Testfällen mindestens genauso wichtig wie die Dokumentation des Prozessdurchlaufs, der getestet werden soll. Die Dokumentation der Testdatenvoraussetzungen hilft Ihnen, Tests möglichst objektiv und vor allem in der Aussagekraft gleichwertig durchzuführen. Kollegen, welche den Testfall zukünftig durchführen, haben damit die Möglichkeit, die Testbedingungen so zu testen wie sie auch bei der Konzeption des Testfalls angedacht waren. Zurück zu unserem Beispiel: Wir legen unseren Kundenauftrag im System an, als Material verwenden wir Kopierpapier, welches mit einer Mindestmenge von 30 Kartons im System hinterlegt ist. Unser Testfall lässt sich erfolgreich durchführen, da im Lager noch 50 Kartons des Kopierpapiers vorhanden waren. Begleiten Sie uns auf eine kleine Zeitreise, die uns drei Monate in die Zukunft führt. Sie befinden sich in einem Testzyklus, der dazu dienen soll, nach der Einspielung eines Updates Ihr SAP-System auf die weiterhin korrekte Funktionalität zu prüfen. Seit Ihrem letzten Test blieb das Testsystem unverändert, Sie spielen unseren Beispieltestfall mit dem selben Material nochmals durch und erhalten eine Fehlermeldung, da nicht mehr genügend Kopierpapier auf Lager liegt. Sie müssen sich ein neues Material suchen, mit welchem Sie Ihren Testfall durchführen können und welches allen Ihren Testdatenvoraussetzungen entspricht. Unsere Testdaten sind, beim aktuellen Lagerstand, verbraucht, und führen zu einer Fehlermeldung bei der Durchführung des Testfalls, welche auf die Testdaten(qualität) und nicht auf mangelnde Qualität des Testobjekts (Auftrag anlegen) zurückzuführen sind. Dies führt zu zusätzlichem Aufwand, da wir neue Testdaten suchen und den Testfall wiederholen müssen. – Testdaten verbrauchen sich Denken Sie an andere Beispiele: Nehmen wir an, Mitarbeiter, welche länger als 20 Jahre in unserem Unternehmen arbeiten, bekommen eine Mitarbeiterprämie ausbezahlt. Die gute Testpraxis empfiehlt, Testdaten möglichst am Rande des Intervalls auszusuchen, welches als Testdatenvoraussetzung vorgeschrieben ist. Wir wollen sowohl den Negativ- als auch den Positivfall des Testfalls verifizieren. Sie suchen sich also einen Mitarbeiter, der möglichst knapp vor seinem 21. Dienstjahr steht, und einen Mitarbeiter, der erst möglichst wenig Dienstzeit in seinem 21. Dienstjahr absolviert hat. Ihr Testfall wird, so unser Testobjekt (Regelprüfung der Prämienauszahlung für 20+ Dienstjahre) korrekt funktioniert, einmal die Prämie nicht auszahlen und einmal schon. Eine weitere Zeitreise, wieder 3 Monate in die Zukunft, könnte bei den selben Testdaten ein komplett anderes Bild zeichnen. Nämlich jenes, dass auch der für die Prämie vermeintlich zu kurz im Unternehmen befindliche Mitarbeiter die Prämie ausbezahlt bekommt. Das liegt daran, dass der Mitarbeiter nur 3 Monate später, schon sein 21. Dienstjahr begonnen hat und somit korrekterweise die Prämie erhält. – Testdaten altern Dem nicht genug, beeinflussen sich Testdaten unterschiedlicher Testfälle natürlich gegenseitig. Verbraucht oder verändert einer der Testfälle, für welche Sie sich mühsam Testdaten zurechtgelegt haben, im Zuge seiner Durchführung jene Daten eines darauf folgenden Testfalls, kann im schlimmsten Fall die Sucharbeit für Folgetestfälle nochmals nötig werden. – Testdaten beeinflussen sich gegenseitig Wie Sie an unseren Beispielen gesehen haben, fließen viele Aspekte in die Korrektheit und Aktualität von Testdaten ein. Die 5 wichtigsten Überlegungen, welche Sie im Zusammenhang mit der Testdatenbereitstellung treffen sollten: Berücksichtigen Sie all diese Aspekte und nehmen Sie einige strukturierende Überlegungen vor, wie zum Beispiel die Testdatenkriterien allgemein für jeden Testfall niederzuschreiben, so können Sie allein mit diesen Schritten im aktuellen als auch in allen folgenden Testzyklen viel manuellen Aufwand sparen, der Ihnen das Testen und die Qualitätssicherung erschwert.