Am veröffentlicht

Microstrategy Upgrade 2020 im Kontext des Arbeitspakets Testing

Einleitung

Die Microstrategy Intelligence Plattform (MSTR) besteht aus diversen Komponenten, die in einem Unternehmen im Bereich Business Intelligence und Analytics eingesetzt werden können. Hauptkomponente der Plattform ist der MSTR Intelligence Server, welcher die Durchführung von Analysen jeglicher Art ermöglicht. Diese können mit Hilfe von verschiedenen Clients wie z. B. MSTR Web, MSTR Developer, MSTR Workstation, MSTR Mobile, MSTR Office etc. angestossen und auf unterschiedliche Art und Weise dargestellt werden. All diese Komponenten unterliegen einer ständigen Weiterentwicklung kosmetischer wie auch fundamentaler Natur durch den Hersteller. Darüber hinaus werden jährlich neue Features eingeführt. Gross angepriesen wurde für die Version 2020 unter anderem die neue Funktion MSTR Hyperintelligence Cards. Dieses Feature ermöglicht dem Kunden das Anzeigen einer Karte mit analytischen Daten, indem der Kunde mit dem Mauszeiger per Hoover Effekt über vorher definierte Entitäten in operativen Systemen gleitet.

Microstrategy Hyperintelligence Cards
Exemplarisch ist hier die Verwendung von Microstrategy Hyperintelligence Cards innerhalb von Excel zu sehen.

 

Ein MSTR Upgrade bringt, im Gegensatz zu App-Updates auf dem eigenen Smartphone, immer sehr viel Aufwand mit sich. Für ein erfolgreiches Upgrade ist ein Zusammenspiel von verschiedenen Rollen zwingend notwendig. Es werden sowohl Entwickler oder Administratoren, welche die Upgrades der Komponenten durchführen als auch Tester fachlicher Natur und Tester seitens der IT beansprucht. und Zudem sind koordinative Rollenbesetzungen wie etwa Projektleiter unverzichtbar.

Um ein MSTR Upgrade erfolgreich zu gestalten, sollte es unterschiedliche Phasen durchlaufen. Zunächst bedarf es einer Konzept- und Vorbereitungsphase, in der die Planung und erste Konzepte entstehen. Anschliessend folgt eine Realisierungsphase, welche die Umsetzung der Konzepte beinhaltet. Schwerpunkte der letzten Phase sind das Testen und das Protokollieren der Testergebnisse. Das Ziel, «Erfolgreiche Durchführung des Upgrades», ist dann erreicht, wenn die Bereiche Performance, Stabilität, Inhalt (generierte SQL’s) und Darstellung hinreichend getestet werden konnten und zufriedenstellende Resultate erzielt wurden. Um dieses Ziel zu erreichen werden beim Testen entweder Werte vor und nach dem Upgrade gegenübergestellt (A-B-Vergleich) oder aber Testergebnisse mit Referenzwerten verglichen.

In den nachfolgenden Kapiteln werden die einzelnen Phasen des Upgrades MSTR 2020 aus Sicht des Arbeitstaktes Testing detailliert betrachtet.

Konzept und Vorbereitung

HERMES 5 Modell
Dieses HERMES 5 Modell zeigt die drei verwendeten Dimensionen Zeit, Partner sowie Hierarchie auf und setzt sie in Verbindung zueinander indem es Szenarien, Module, Ergebnisse, Aufgaben sowie Rollen verwendet.

Ein Projekt wie das MSTR Upgrade 2020 kann mithilfe von Projektmanagementmethoden wie HERMES 5 in Teilpakete/Module (Projektführung, Testen, Einführungsorganisation etc.) aufgeteilt werden, für die jeweils ein Verantwortlicher definiert wird. Innerhalb dieser Module sind in der Konzeptphase diverse Dokumente zu erstellen. Beispielsweise ist im Modul Testen ein Testkonzept zu definieren, welches verschiedene Aspekte zum Testen enthält. Am Beispiel des Testkonzepts wird nachfolgend dargelegt, welche Aspekte bei der Erstellung von Dokumenten in der Phase Konzept und Vorbereitung zu beachten sind.

Im Testkonzept müssen zunächst die zu erreichenden Testziele aufgeführt werden. Anschliessend ist die Frage nach relevanten Testobjekten zu beantworten. Es müssen Testarten wie auch Testphasen, deren Verantwortlichkeiten sowie Testabschluss- und Testabbruchkriterien beschrieben werden. Darüber hinaus sind eine Testorganisation sowie deren Rollen zu definieren. Es muss ein Fehler-Management-Prozess vorliegen, damit sichergestellt ist, dass der Feedbackloop funktioniert, sollten die Testresultate nicht dem erwarteten Ergebnis entsprechen. Darüber hinaus sind Fehlerklassifizierungen und Priorisierungen zu definieren. Für jede Umgebung, die aktualisiert werden soll, muss definiert sein, welche Tests konkret prozessiert werden sollen und es muss eine Reihenfolge für die Umgebungen festgelegt werden. Zu guter Letzt sind Tools zu benennen, mithilfe derer die vorhin genannten Aufgaben durchgeführt werden können. MSTR liefert hier den hauseigenen Integrity-Manager, mit dessen Hilfe viele der definierten Tests, wie Vergleiche von SQL’s oder Darstellungen vor und nach dem Upgrade, durchgeführt werden können. Mit dem Integrity-Manager lassen sich zudem auch Resultate protokollieren und archivieren. Trotzdem kann bei der Protokollierung der Tests, vor allem in Anbetracht kollaborativer Arbeiten wie der Feedbackschleife dem Fehler-Management-Prozess oder der Bereitstellung von standardisierten Testschritten an die Fachtester, auf Tools wie das Application-Life-Cycle-Management (ALM) Quality Center (QC) nicht verzichtet werden.

Wie an diesem Beispiel gezeigt wurde, müssen viele Dinge berücksichtigt werden, bevor die Durchführung des eigentlichen Upgrades in Angriff genommen werden kann.

 

Durchführung des Upgrades

Im Rahmen der Phase Konzept und Vorbereitung wird u. a. definiert, in welcher Reihenfolge einzelne Umgebungen aktualisiert werden sollen, falls mehre vorhanden sind. In der Regel sollten einzelnen Umgebungen wie Integration, Entwicklung, Test, Produktion unabhängig voneinander aktualisiert werden. Bei einem derartigen Vorgehen entstehen Loops, in denen pro Umgebung die Upgrades und anschliessend alle Tests durchgeführt werden. Bei der Definition der Reihenfolge wird empfohlen mit den am wenigsten genutzten Umgebungen zu beginnen, zum Beispiel Integrationsumgebungen.

Eine weitere zentrale Anforderung, welche im Rahmen der Konzeptphase definiert wird, ist häufig, dass das Upgrade nicht – oder nur geringfügig – den Betrieb einschränken darf. Es stellt sich somit konsequenter Weise die folgende Frage: Wie lange dauert es, bis die Produktionsumgebung aktualisiert und hinreichend getestet wurde, sodass sie den Usern wieder zur Verfügung gestellt werden kann? Gelingt es nicht die anfallenden Prozesse (Upgrade und Testen) auf ein akzeptables Minimum zu beschränken, so muss für die Zeit, in der die Produktionsumgebung nicht zur Verfügung steht, eine Übergangslösung zur Verfügung stehen. Beispielsweise kann die Testumgebung mit produktiven Daten von den Usern genutzt werden. Dies bedingt allerdings eine umfangreiche Vorbereitung. Es muss sichergestellt werden, dass Produktionsumgebung und Testumgebung vor dem Upgrade synchronisiert werden und zwar in Bezug auf die Daten in der Datenbank als auch die Metadaten von MicroStrategy. Sobald dies der Fall ist kann zunächst die Testumgebung aktualisiert werden. Nach erfolgreichem Upgrade greifen die Benutzer übergangsweise auf die aktualisierte Testumgebung zu und die Produktionsumgebung kann auf den neusten Stand gebracht werden. Sobald auch dieses Upgrade erfolgreich war, werden beide Umgebungen erneut synchronisiert. Nach der Synchronisation dürfen die Benutzer wieder wie gewohnt auf die produktive Umgebung zugreifen.

Vor dem eigentlichen Upgrade müssen auf jedem Server Backups der Server-, der Projektkonfigurationen und der Metadaten erstellt werden. Um die Performance zwischen den beiden Versionen vergleichen und die Integrität der Daten sicherstellen zu können, werden vor dem Upgrade zusätzliche Integrity-Manager-Tests und Stabilitätstests durchgeführt. Für die neue MSTR-Version müssen ausserdem ggf. vorhandene Steuerungsskripte angepasst werden, wobei u. a. auch die neuen Funktionen integriert werden.

Die Komplexität der eigentlichen Installation hält sich in Grenzen, da diese mit Hilfe des von MSTR bereitgestellten GUIs funktioniert. Der komplexere Teil entfällt auf die anschliessende Konfiguration der installierten Komponenten. Neben der Aktualisierung der serverseitigen Steuerskripte und der in der odbc.ini gespeicherten Datenbankverbindungen müssen auch die Metadaten aktualisiert und neue Funktionen angebunden werden.

Testen und Protokollieren

Microstrategy Integrity-Manager SQL Vergleich
Praktisches Beispiel aus dem Microstrategy Integrity-Manager, in dem das SQL eines Reports vor und nach dem Veränderungen verglichen wird. Es wird zuerst eine Baseline erstellt. Danach werden die Resultate, in diesem Fall SQL’s gegen diese zuvor erstellte Baseline verglichen.

Da keine Objekte entwickelt werden, fallen in solchen Lifecycle-Projekten die Entwicklertests weg. Somit bleiben noch die Integrations-, die Fach- und die (Vor-) Abnahmetests. Sofern die Bewirtschaftung der angebundenen Datenbanken nicht auch aktualisiert werden, also nur die MicroStrategy Platform erneuert wird, kann auf das Testen der Daten ebenfalls verzichtet werden. Im Kontrast dazu ist es aber unabdingbar die generierten SQLs der MSTR-SQL-Engine zu vergleichen. Hier können beispielsweise Unterschiede in der Reihenfolge von Attributen entstehen, die aber keinen Einfluss auf die präsentierte Reihenfolge der Attribute im Report hat und daher als Abweichungen dokumentiert sind, diese jedoch nicht angegangen werden. Solche Tests können mithilfe des Integrity-Managers durchgeführt werden und gehören zu den Integrationstests. Auch bei der Darstellung kann der Integrity-Manager einen Vorher-Nachher-Vergleich durchführen. Der Punkt kann aber auch im Rahmen der Fachtests durch das Business getestet werden indem immer zwei Umgebungen nebeneinander verglichen und Abweichungen protokolliert werden. Die Performance- und Stabilitätstests können leider nicht mithilfe des Integrity-Managers durchgeführt werden, da dieser für solche Aufgaben nicht konzipiert wurde. Hierfür stellt aber MSTR Java-Tools zur Verfügung. Diese Performance- und Stabilitätstests sind darauf ausgerichtet die Web- und Intelligence-Server von MSTR auf Herz und Nieren zu prüfen. Dabei kann man zum Beispiel Parameter wie Anzahl an Cube-based-Reports oder Anzahl gleichzeitig konkurrierender Benutzer einstellen.

Zusammenfassung

Wenn auch nur ein Bruchteil der Arbeiten, die bei einem MSTR Upgrade notwendig sind, in diesem Blog beschrieben wurden, konnte trotzdem aufgezeigt werden, dass ein solches Upgrade in Punkto Aufwand wie auch Komplexität nicht zu unterschätzen ist und genügend Ressourcen eingeplant werden müssen.