Die Migration in die Cloud ist in aller Munde. Dabei geht es meist um die technischen Aspekte des Umzugs und darum, Bestandsdaten zu entschlacken und bisherige Prozesse 1:1 oder in verbesserter Form in der Cloud abzubilden. Das ungeliebte Stiefkind dieser Projekte jedoch ist der Test. Wie aber testet man die Atlassian Cloud?
Es gibt vier Eckpunkte, die man vor der Migration zu testen hat:
- User Experience – Reicht die Default-Ansicht oder muss ich das UI anpassen?
- Kernprozesse – Lassen sich Kernprozesse identisch oder mit geringen Modifikationen in der Cloud umsetzen?
- Nutzerverwaltung – Wie funktioniert die mandantenfähige Nutzeradministration der Cloud im Vergleich zur Server bzw. Data Center Edition?
- Drittsystemintegration – Funktionieren meine an Jira und Confluence angebundenen Drittsysteme weiterhin?
Für unseren Blog-Beitrag haben wir uns einen Kernprozess herausgegriffen, an dem wir den Testvorgang exemplarisch durchgehen. Der Prozess basiert auf der bisherigen Server-Version von Jira Software.
Beispielprozess – Ausschreibungsverwaltung
Ein Auftrag wurde ausgeschrieben und nun soll intern geprüft werden, ob das eigene Unternehmen daran teilnimmt. Dazu erstellt ein Mitarbeiter (der Ersteller) in Jira ein Issue inklusive der wichtigsten Kenndaten wie Titel, URL und eindeutige ID der Ausschreibung. Jira prüft sofort anhand der eindeutigen Ausschreibungs-ID, ob es sich hier um ein Duplikat handelt und unterbindet ggf. die Erstellung des Issues.
Der Bearbeiter prüft die Ausschreibungsunterlagen auf Machbarkeit. Einzelne Kenndaten passt er womöglich noch an und entschiedet dann, ob das Unternehmen an der Ausschreibung teilnimmt oder nicht. Ist die Entscheidung für eine Teilnahme gefallen, wird die Ausschreibung bearbeitet und der Status auf „Abgabe erfolgt“ verändert. Hat die ausschreibende Stelle ihre Entscheidung gefällt, wechselt der Status auf „Zuschlag erhalten“ oder „Zuschlag nicht erhalten“.
Hier gibt es also zwei Personen, die den Prozess durchlaufen. Für den Test kommt noch eine dritte hinzu und zwar der Jira-Administrator. Dieser nimmt etwaige Anpassungen an der Atlassian-Software vor.
Personen
- Ersteller
- Bearbeiter
- Jira-Administrator
Der Test verläuft in zwei Schritten; hier der erste.
Testdurchgang #1 (im nicht-produktiven Cloud-System)
Als Voraussetzung müssen folgende Migrationsschritte bereits erfolgt sein:
- Cloud-Site mit Free-Plan ist erstellt und die Domain verifiziert
- Datenexport vom Altsystem in die Cloud Site wurde durchgeführt
Wir befinden uns jetzt im Schritt 3: Migration im Altsystem per Meldung bekannt geben und die migrierten Prozesse und Daten testen. Dabei gilt es festzustellen, ob die Prozesse einwandfrei und im Optimalfall genau wie in der Server-Version funktionieren. Übrigens, die vollständige Schrittliste finden Sie in unserem White Paper Migration in die Cloud.
Testprozess in der Cloud:
- Der Ersteller trägt in der Issue-Erstellungsmaske die wichtigsten Kenndaten wie Titel, URL und eindeutige ID der Ausschreibung ein und drückt „Erstellen“.
Dabei achtet er darauf, dass die eindeutige Ausschreibungs-ID noch nicht von einem anderen Issue verwendet wurde. - Der Ersteller ruft das Issue auf und füllt wie gewohnt die weiteren Daten mittels des Workflowschritts „Daten ergänzen“ aus.
- Der Bearbeiter validiert im Schnelldurchgang (ohne die Unterlagen zu prüfen, da nur ein Test) und versucht, das Issue auf „keine Teilnahme“ zu schieben -> funktioniert ✅
- Der Bearbeiter löscht das erstellte Issue.
- Der Ersteller wiederholt die Schritte 1-3.
- Der Bearbeiter schiebt das Issue nun auf „Teilnahme“ -> funktioniert ✅
- Der Bearbeiter schiebt das Issue anschließend auf „Abgabe erfolgt“ -> funktioniert ✅
- Der Bearbeiter schiebt das Issue abschließend auf „Zuschlag erfolgt“ -> funktioniert ✅
- Der Ersteller wiederholt das Ganze nochmal, um für weitere Testzwecke bewusst ein Duplikat zu erstellen.
- Der Bearbeiter schiebt das Issue zu „Teilnahme“ -> „Abgabe erfolgt“ -> „Zuschlag nicht erhalten“ -> funktioniert ✅
Damit ist der reguläre Prozessablauf mit allen Eventualitäten (keine Teilnahme, Zuschlag erhalten, Zuschlag nicht erhalten) getestet. Im Folgenden soll nun das Verhalten bei Duplikaten getestet werden.
- Der Ersteller trägt in der Issue-Erstellungsmaske die wichtigsten Kenndaten wie Titel, URL und eindeutige ID der Ausschreibung ein und drückt „Erstellen“.
Dabei achtet der Ersteller darauf, dass die eindeutige Ausschreibungs-ID MINDESTENS VON EINEM ANDEREN Issue verwendet wurde (am besten die ID aus dem vorherigen/ersten Durchlauf in der Cloud nutzen). - Der Ersteller erhält keine Fehlermeldung und das Issue lässt sich ohne Duplikatswarnung erstellen.
- Der Ersteller informiert den Jira-Administrator.
- Der Jira-Administrator prüft, wie die Duplikatserkennung vorher mit der Server-Variante von Jira umgesetzt wurde. Er stellt fest, dass die dafür nötige App nicht mit der Cloud kompatibel ist.
- Der Jira-Administrator evaluiert zwei Alternativen, wie die Duplikatsprüfung ohne die App umgesetzt werden kann:
- Jira-Automation-Regel
- Webhook
- Der Jira-Administrator entscheidet sich für den Webhook, da so eine größtmögliche Flexibilität und Anpassungsmöglichkeiten gewährt bleiben – beispielsweise um auch noch Informationen aus Drittsystemen abzufragen oder einzufügen.
- Der Jira-Administrator entwickelt einen Webhook, der für das Event „Issue erstellt“ ausgelöst wird. Im Code des Webhooks wird anschließend eine JQL-Suche in Jira mit dem Parameter „AusschreibungsID = <ID des aktuellen Issues>“ ausgeführt.
Werden Ergebnisse gefunden, wird ein Issue Link angelegt, der auf das ursprüngliche Issue verweist. Der aktuelle Issue wird vom Webhook auf „keine Teilnahme“ gestellt und damit geschlossen. Nutzer erkennen auf diese Weise sofort, dass das Issue ein Duplikat ist und keine weiteren Daten eingetragen werden müssen. - Der Ersteller wiederholt den Vorgang.
Dabei achtet der Ersteller darauf, dass die eindeutige Ausschreibungs-ID mindestens von einem anderen Issue verwendet wird. - Der Ersteller ruft den Issue auf und sieht, dass das Issue automatisch geschlossen wurde -> funktioniert ✅
Dieser Prozess ist natürlich nur ein Beispiel für die verschiedenen Tests, die Sie im Laufe einer Migration durchführen. Wenn Sie mehr darüber wissen möchten oder Fragen haben, sprechen Sie mich gern dazu an.
