Automatisierte Software-Tests

Feature | 23. Februar 2009 von Carsten Langenhan, Principal Consultant bei der SQS Software Quality Systems AG 0

Tests und Testautomatisierung stehen immer im Dienst einer übergreifenden Qualitätssicherung: Sie sollen Unternehmen dabei unterstützen, Kosten und Risiken zu senken sowie Personal- und Zeitaufwand erheblich zu verringern, während die Komplexität der getesteten Systeme in der Regel steigt.

Wegen der regelmäßigen Release-Zyklen zählen Regressionstests zu den wichtigsten Testformen im SAP-Umfeld. Mit ihrer Hilfe lässt sich nachweisen, dass eine in der vorigen Version reibungslos arbeitende Funktionalität auch im neuen Release ohne Probleme weiter läuft. Darüber hinaus lassen sich Durchführung und Auswertung von Tests durch Automation insgesamt beschleunigen, da Regressionstest-Zyklen von der Verfügbarkeit der Fachabteilungen entkoppelt sind. Diese werden von immer wiederkehrenden und zeitraubenden Routine-Tests entlastet.

Sind die Testfälle für diese Prüfungen erst einmal etabliert und automatisiert, entwickelt sich der Vorgang im wahrsten Sinne des Wortes zu einem Selbstläufer. Der Return on Investment (ROI) stellt sich typischerweise nach vier bis sechs Regressionen ein. Testautomation ist demnach kein Mittel zur Realisierung von „Quick Wins“, sondern ein langfristig angelegtes Investment. Die erreichbaren Einsparungspotenziale liegen zwischen 30 und 50 Prozent.

Vor der Automatisierung

Häufig besteht der Irrglaube, dass durch Testautomation das Unmögliche möglich wird. Große Schwierigkeiten tauchen jedoch erfahrungsgemäß im Vorfeld der Automatisierung auf, wenn es gilt, die richtigen Testfälle und Testdaten zu bestimmen. Diese Testfälle müssen manuell ausführbar sein und ein abgegrenztes Ziel haben.

Um herauszufinden, welche Teile einer Software wiederholt getestet werden müssen, stehen dem Testmanagement verschiedene Ansätze zur Verfügung:

  • Risikoanalysen ermitteln geschäftskritische Szenarien, die unabdingbar dann überprüft werden müssen, wenn ein Update, Patch oder SAP-Transport anstehen.
  • Fachliche Impact-Analysen wiederum unterstützen die Tester dabei, den beim nächsten Release der Software zu erwartenden Änderungsbedarf zu lokalisieren und zu quantifizieren.

Eine grundlegende Herausforderung bei der eigentlichen Automation besteht darin, Software-Objekte über bestimmte interne Attribute zu identifizieren, um sie in der Automation sicher wiederzufinden. SAP-Systeme lassen sich Tests relativ gut automatisieren, denn SAP-Objekte können üblicherweise über ihren Typ und bestimmte Attribute wie etwa interne Namen identifiziert werden.

Alternative Testtools

Wichtig! Testautomatisierung

•benötigt einen gewissen Reifegrad der Testprozesse.
•ist ein Long-Term-Investment und erwirtschaftet kurzfristig keinen ROI.
•ist Software-Entwicklung und muss entsprechend behandelt werden.
•sollte evolutionär ausgebaut werden.
•basiert in erster Linie auf passenden Verfahren und erst dann auf den eingesetzten Werkzeugen.

Mit externen Werkzeugen wie HP QuickTest Professional oder Compuware TestPartner erhalten die Automatisierer einen guten Zugriff auf diese internen Objektattribute, die jedoch über die grafische Benutzeroberfläche (GUI) nicht sichtbar sind. Davon abgesehen bietet sich natürlich der Einsatz des SAP-eigenen Tools eCATT an. Ferner können verschiedene Tools die so genannten SAP-Blueprints auslesen, um festzustellen, in welchem DynPro oder welcher Transaktion Änderungen durchgeführt wurden.

Zu den Grundsätzen, die bei jeder Art von Software-Test zu beachten sind, gehört die strikte Trennung von Testdaten und ausführbaren Testskripten. Letztere erstellen die Tester. Zudem sollten die Testfälle von Geschäftsprozessen getrieben und entsprechend modularisiert aufgebaut sein.

Um die Zusammenarbeit zwischen professionellen Test-Technikern und Fachexperten des Business einfacher zu gestalten, empfiehlt sich zudem eine Keyword-getriebene Automatisierungsstrategie. Dabei bleiben die Automationsaktionen auf der GUI auf einige wenige und allgemeinverständliche Schlüsselworte reduziert.

Wahl der Automatisierungsstrategie

Ein Beispiel für eine Verbindung von modularem Geschäftsprozess- und Keyword-getriebenen Ansatz liefert das Werkzeug HP Quality Center (QC). Mithilfe des QC-Moduls BPT (Business Process Testing) lassen sich bausteinartig Geschäftsprozesse für die Testautomatisierung in Form einer „Kette“ zusammenstellen, an deren einzelne „Glieder“ (Business Components) die Testdaten anzuhängen sind.

Jede zusammenhängende „Kette“ bildet einen Geschäftsvorfall, wobei die jeweils zuständige Fachseite den Input für jede einzelne Business Component liefert. Die Fachleute sorgen für die verbale Beschreibungen der Kettenglieder, während die Techniker sie in Testskripte übersetzen.

Die Tester, die neue Ketten – sprich Testfälle – zusammenbauen, haben so auch den Vorteil, dass sie auf bereits bestehende „Kettengliedern“ aufbauen können. Testfälle müssen sich nicht notwendigerweise in allen Punkten fundamental voneinander unterscheiden. Besteht eine Kette für einen Geschäftsprozess beispielsweise aus 100 Test-Gliedern, ist es sehr wahrscheinlich, dass eine ganze Reihe von Einzelgliedern aus anderen Ketten übernommen werden kann.

Ein Beispiel dafür ist der Anmeldeprozess an SAP-Systemen, der nicht jedes Mal neu beschrieben und definiert werden muss, nachdem das SAP-Login einmal vorgegeben ist. Dieses „Kettenglied“ würde auch einen Release-Wechsel überstehen. Ein angenehmer Nebeneffekt geht mit einer solchen Beschreibung und Testautomation für das testende Unternehmen einher: Es erhält eine Gesamtsicht auf die „Brainware“ seiner Fachabteilungen, wenn diese strukturiert in Test-Skripten vorliegt.

Externe oder SAP-Tools?

SAP-unabhängige Testwerkzeuge zeigen bei der Testautomatisierung besonders dann ihre Vorzüge, wenn integrierte Geschäftsprozesse zu testen sind, an denen neben SAP noch Systeme von Drittanbietern beteiligt sind, etwa für das Customer Relationship Management (CRM) oder das Content Management (CM).

Zwar erkennt das SAP-interne Werkzeug eCATT sofort, wenn ein bestimmtes Testskript wegen Änderungen nicht mehr auf einer bestimmten Software-Transaktion läuft. eCATT liefert in solchen Fällen entsprechende Analysen und Auswertungen. Es ist allerdings gut möglich, dass diese in SAP geänderte Funktionalität für den Testfall eines Geschäftsprozesses völlig unerheblich ist, der über integrierte Systeme mehrerer Anbieter läuft.

Methodisch vorgehen

Ein externes Tool wie HP QuickTest Professional hat hier den Vorteil, an dieser Stelle nur diejenigen Teile der Systeme gezielt unter die Lupe zu nehmen, die auch tatsächlich in den zu testenden Geschäftsprozess involviert sind. Der Testfall ist also trotz einer Änderung in SAP noch lauffähig.

Tools alleine garantieren jedoch noch keinen Erfolg. Unabhängig von den Werkzeugen ist ein methodisches Vorgehensmodell Grundlage jeder Testautomation. Dazu gehören:

  • Die Vorstudie, die Anforderungs-, Machbarkeits- und Prozessanalysen nebst einer ROI-Kalkulation beinhaltet
  • Die Konzeption, in der die Automatisierungs- und Umsetzungsstrategie festgelegt wird.
  • Die Pilotierung, während der die Tester die Technologie implementieren und die gewählte Automatisierungsstrategie anhand eines Durchstichs mit zwei bis drei ausgewählten Testfällen umsetzen.
  • Die Feinplanung mit Termin-, Aktivitäten- und Ressourcenplanung.
  • Die Implementierung, das heißt: die vollständige Realisierung inklusive Coaching, Training und Dokumentation.

Tags:

Leave a Reply