Wir stellen Ihnen in diesem Artikel die aktuellen Neuerungen von Micro Focus ALM vor und klären auf, weshalb der „Sprung“ von 12.60 direkt auf 15.00 erfolgte.
Ziemlich genau ein Jahr nach der Veröffentlichung von ALM12.60 stand mit ALM15 der nächste, große Versionssprung an, welcher durch einige sinnvolle Erweiterungen und Detailverbesserungen aufwarten kann.
Die erste Frage unserer Kunden lautet meist „Warum 15? Was hat es damit auf sich?“ Die Hintergründe hierfür sind relativ schnell und einfach erklärt. Der eigentlich logische und für viele nachvollziehbare, nächste Schritt wäre wahrscheinlich ALM13 gewesen, wobei die Zahl „13“ aus Aberglaube oftmals ausgelassen wird, da sie in vielen Kulturen als Unglückszahl angesehen wird.
Die Verwendung der Versionsnummer 14 kommt ebenfalls nicht in Frage, da diese bereits der SaaS-Variante von ALM.NET zugeordnet ist – die Bezeichnung „ALM15“ hat somit eine durchaus plausible Berechtigung.
SSO-Authentifizierung
Single Sign-on ist im Zusammenhang mit ALM bereits seit längerem ein Thema, bisher fehlte jedoch eine ausreichende Implementierung, wodurch sich für den sinnvollen, produktiven Einsatz zu viele Einschränkungen ergaben. Auf Grund der Komplexität, speziell im Hinblick auf die notwendigen Konfigurationsschritte, sowie dem großen Interesse an dieser Authentifizierungsmethode bei unseren Kunden, haben wir uns gezielt dafür entschieden diesem Bereich deutlich mehr Aufmerksamkeit zu schenken, als es an dieser Stelle innerhalb einer kurzen Feature-Vorstellung möglich wäre. Ein separater, technischer Artikel, welcher sich sorgfältig mit den benötigten Voraussetzungen und der vollständigen Einrichtung von SSO beschäftigt ist bereits in Arbeit.
Web Runner
Mit Hilfe des neu hinzugekommenen Web Runners können manuelle Tests ausgeführt und direkt zur Laufzeit mit zugehörigen Defects auf Step- und Run-Ebene versehen werden. Eine Verlinkung zu bereits erfassten Fehlern ist ebenfalls möglich, darüber hinaus gibt es jedoch (noch) keine weiteren Funktionen.
Abbildung 1: Test Sets Modul
Abbildung 2: Defects Modul
Vielen ALM-Nutzern, die bereits ALM12.0x oder ALM12.2x kennen, werden sicher Parallelen zum mittlerweile eingestellten „ALM Web Client“ auffallen, auch wenn die Herangehensweise aus funktionaler Sicht diesmal eine Andere ist. Beide Ansätze haben gemein, dass Sie ohne eine clientseitige Installation genutzt werden können.
Mit dem Web Client legte man den Fokus noch auf die Verwaltung von Requirements und Defects, ein Modul für das Test Management wurde später ebenfalls integriert, musste aber noch über einen zusätzlichen SiteAdmin-Parameter freigeschaltet werden und kam nie über den Status einer „Technical Preview“ hinaus. Der Web Runner hingegen ist ausschließlich auf die Durchführung von manuellen Testfällen ausgerichtet – eine Verwaltungsmöglichkeit für Requirements und Defects existiert nicht.
Abbildung 3: Ausführung von manuellen Tests
Site Administration REST API Reference
Die REST API wurde um einen Bestandteil für den SiteAdmin-Bereich von ALM erweitert, welcher ebenfalls über eine eigenständige Dokumentation innerhalb des „ALM Help Centers“ verfügt:
https://admhelp.microfocus.com/alm/en/15.00/online_help/Content/APIs/API_ALM_REST_Site_Admin.htm
Die Implementierung von SiteAdmin-Funktionalitäten birgt deutliche Vorteile in Form von Arbeitserleichterungen bis hin zu Zeitersparnissen für ALM-Administratoren, da sich hiermit vielerlei Prozesse mit Hilfe von Skripten automatisieren und dadurch effizienter gestalten lassen können.
Um nur einige Beispiele zu nennen:
- Verwaltung von Domains
- Erstellen & Löschen von Domains
- Verwaltung von Projekten
- Erstellen von neuen, leeren Projekten sowie Projektkopien
- Löschen von Projekten
- Aktivierung / Deaktivierung von Projekten
- Wiederherstellung, Import und Export von Projekten
- Durchführung von Wartungsarbeiten – Verify, Repair, Upgrade
- Verwaltung von Benutzern innerhalb der Projekte
- Hinzufügen & Entfernen von Projektnutzern
- Vergabe & Entzug von Administrator-Berechtigungen
Langjährigen ALM-Nutzern werden die aufgeführten Möglichkeiten sicher bekannt vorkommen, da diese bereits in der „Site Administration COM API“ (ehemals „ALM Site Administration API“) enthalten sind. Somit handelt es sich hierbei nicht um eine Erweiterung hinsichtlich grundlegend neuer Funktionalitäten, sondern vielmehr um eine sinnvolle Ergänzung der Haupt-API, welche gegenüber Ihrem Vorgänger zudem signifikante Vorteile aufweist:
- Vollständige 64-bit-Kompatibilität
- ALM-Clientinstallation zur Ausführung nicht benötigt
- Verbesserte Performance im direkten Vergleich mit OTA-API-Pendant
ALM AutoPass License Server (technical preview)
Zwar noch als „technical preview“ hervorgehoben, erhält man mit ALM15 ab sofort die Möglichkeit, erste Einblicke und Erfahrungen mit einer ausgelagerten Lizenzverwaltung zu sammeln. Die Verknüpfung von ALM und AutoPass kann hierbei direkt während der Installation, oder auch im Nachhinein, via Anpassung einer Konfigurationsdatei, vorgenommen werden.
Um die Verbindungsdaten händisch zu hinterlegen, muss die Datei „clusterSettings.properties“ im ALM-Deployment-Unterverzeichnis „conf“ zunächst mit einem Editor geöffnet und anschließend um Werte für die nachfolgenden Parameter ergänzt werden:
- „AUTOPASS_SERVER_PORT“ – z.B. der Standard-Port: „5814“
- „AUTOPASS_SERVER_NAME“ – Servername oder IP-Adresse, z.B. „127.0.0.1“
- „AUTOPASS_SERVER_PROTOCOL“ – z.B. “HTTPS”
Abbildung 4: clusterSettings properties im conf-Verzeichnis von ALM
Als Vorteile, welche sich durch die Anbindung eines eigenständigen Lizenzservers ergeben, sind verbesserte Möglichkeiten hinsichtlich der Lizenzorganisierung und -verwaltung zu nennen. Die ALM-internen Funktionen zur Berichtserstellung beschränken sich innerhalb der Site Administration auf ein Minimum und sind nicht mit einem dedizierten Lizenzserver vergleichbar.
Abbildung 5: Übersicht der eingespielten QC-/ALM-Lizenzen
Abbildung 6: Lizenznutzungshistorie über den Zeitraum eines Monats
Abbildung 7: Abruf von Detailinformationen zum System, welchem die Lizenz zugeordnet wurde
Vorteile:
- Erweiterte Auswertungsmöglichkeiten, Lizenznutzungsstatistiken & Lizenztracking
- Aufteilung von Lizenzen auf mehrere ALM-/QC-Instanzen
Einschränkungen:
- Nach wie vor keine Differenzierung zwischen Site-, Area-, und Global-Lizenzen
- Keine Möglichkeit, die Lizenznutzung auf einzelne Benutzer einzuschränken
- Lizenzdateien sind aktuell noch schwer erhältlich (tech preview)
Weitere Neuerungen kurz und knapp
Das Dashboard Modul wurde um einen sogenannten „Health Report“ ergänzt, welcher es erlaubt, schnell und mit geringem Erstellungsaufwand Rückschlüsse über die Integrität und den Fortschritt eines Projektes zu erhalten. Der Bericht kann über das „Dashboard View“ angelegt werden und besteht aus den folgenden 4 Graphen:
- Defect Aging
- Requirement Coverage
- Blocked Tests
- Project Progress
Abbildung 8: Erstellung des Reports über den Button „New Health Report“
Abbildung 9: Der vollständige „Health Report“ bestehend aus vier Graphen
Weiterhin können im Analysis View angelegte Graphen nun direkt per E-Mail versendet werden.
Abbildung 10: Analysis View – „Send By E-mail“-Funktionalität
Für API Keys, die mit ALM12.60 eingeführt wurden und eine sichere Authentifizierungsmethode für externe Anwendungen darstellen, die sich mit ALM verbinden, wurde die Option ergänzt, ein Ablaufdatum hinterlegen zu können. Bisher konnten einmal erzeugte API Keys lediglich widerrufen bzw. gelöscht werden, was wiederum eine zusätzliche Nacharbeit zur Folge hatte. Wichtig zu erwähnen ist jedoch, dass nur ein genereller Gültigkeitszeitraum (via SiteAdmin-Parameter) definiert werden kann, welcher anschließend für alle API Keys gilt. Eine Möglichkeit, spezifische Zeiträume für einzelne Keys zu hinterlegen gibt es bis dato jedoch noch nicht.
