Beim letzten Mal habe ich Euch erzählt wie meine Tätigkeit begann. (Teil1)
Diesmal möchte ich darauf eingehen, wie meine Tätigkeit bei der VW FS AG konkret aussieht.
Die Unterabteilung „Webservices & Banking Solutions“ ist für die Weiterentwicklung und Verantwortung der Internet- und Intranet-Präsenzen der VW FS AG und ihrer Tochtergesellschaften zuständig. Insgesamt werden über hundert verschiedene Webseiten auf drei Infrastrukturen gehostet. Diese Infrastrukturen sind:
- FS.NET: Das Intranet der VW FS AG
- FS.WWW: Die Internetumgebung für Webauftritte wie bspw. VWCorporate, Porsche, Skoda…
- FS.Direktbank: Das Bankingumfeld für Audi- und VW-Bank
Jeder Webauftritt besitzt eine Vielzahl von diversen Funktionen und Komponenten, die zu jeder Zeit fehlerfrei den Kunden und Mitarbeitern zur Verfügung stehen müssen. Meine Aufgabe besteht grob ausgedrückt darin, diese Komponenten und Funktionen auf ihre Richtigkeit zu testen. Da es sich bei den drei Infrastrukturen inklusive der Webauftritte jedoch um eine gewaltige Menge an verschiedenen Funktionen und Elementen handelt, war für ein effizientes Vorgehen, insbesondere bei komplexen Abläufen, eine Spezialisierung auf bestimmte Bereiche erforderlich. Zu meinen Spezialgebieten gehört bspw. das Berechtigungskonzept für die Infrastrukturen (Testen der verschiedenen Berechtigungen), das Online-Banking, die Bilderdatenbank und die Postfachmaßnahmen. Zur Unterstützung meiner Testaktivitäten stehen mir unterschiedliche Softwaretools zur Verfügung. Beispiele dafür sind das SAP CIC (Manipulation von Kundendaten), das SAP CRM (Testen von Marketing-Kampagnen), der IBA-Administrator (Verwalten von Bankingkunden) und der DirX-Manager (Manipulation von Mitarbeiterdaten). Die beiden wichtigsten Softwaretools sind jedoch das HP ALM und der AEM 5.6. Der Adobe Experience Manager (AEM) ist der Ort, wo alle Webseiten verwaltet werden. Wenn ich eine Webseite erstellen, verändern oder löschen möchte, so tue ich das alles über den AEM. Das Application Lifecycle Management (ALM) wird hauptsächlich zur Dokumentation von Testfällen und Defects (Fehler) verwendet. Fehler, die während der Testausführung auftreten, werden hier dokumentiert und an die Entwicklung weitergeleitet.
Da ich jetzt einiges über Softwaretools und meine Spezialgebiete erzählt habe, möchte ich Euch zum Schluss ein vereinfachtes Beispiel für den Ablauf meiner Testaktivität anhand des Berechtigungskonzepts für FS.NET (Intranet) aufzeigen.
Die Berechtigungen für FS.NET sind hierarchisch aufgebaut. Developer und Chiefeditoren bilden die höchste Ebene, Standarduser und Gäste die niedrigste. Read-Only ist ein Modus, der es allen Nutzern, die nicht Chiefeditor oder Developer sind, verbietet, bestimmte Änderungen an Seiten vorzunehmen. Um dies zu testen, wird meinerseits die Berechtigung eines Users verändert oder ein neuer User angelegt. Anschließend wird der Read-Only Modus über eine Siteconfig im AEM aktiviert. Sollte dann bspw. ein Standarduser in der Lage sein, eine Komponente z. B. Richtext permanent auf einer Seite zu speichern, dokumentiere ich das als Fehler im ALM und leite es an die Entwicklung weiter. Wenn der Fehler behoben ist, überprüfe ich es nochmal und schließe den Fehler ggf. endgültig.
Das wars fürs Erste von mir. Ich hoffe, dass ich Euch einen mehr oder weniger interessanten Einblick in meinen Werkstudentenalltag bieten konnte.
Beim nächsten Mal erzähle ich Euch, welchen konkreten Nutzen ich aus meiner Beschäftigung ziehen konnte.
Viele Grüße
Siegfried Gaertner