Sucht man im Internet nach Lösungsmöglichkeiten für das Testfallmanagement mit Atlassian JIRA, so findet man ein paar Vorschläge wie den im Artikel „Customise JIRA For Test Case Management“. Bei dieser Lösung werden die Testfälle als eigene Vorgänge erfasst und für jede Testausführung wird ein neuer Untervorgang angelegt
und der entsprechenden Release-Version zugeordnet. Die Vorgänge sind mit der Anforderung verknüpft, haben allerdings keinen direkten Einfluss auf diese (wie es bei Untervorgängen die Möglichkeit ist). Über angepasste Bildschirme für die Eingabe, Bearbeitung, Ansicht und den Statusübergang sowie eigene Workflows wird die Sache abgerundet. Im praktischen Einsatz bei Communardo hat sich diese Lösung allerdings nicht durchgesetzt, da sie sehr Aufwendig ist und ein paar wichtige Merkmale fehlen, wie z.B. die Testausführungsreihenfolge oder die direkte Statusabfrage der Testergebnisse aus der Anforderung heraus.
Nach weiteren Testphasen anderer Lösungsmöglichkeiten haben wir uns eine eigene Lösungsmöglichkeit überlegt. Es wird ein neuer Untervorgang „Testfall“ angelegt, welcher mit benutzerdefinierten Spalten (z.B. für Testschritte, erwartetes Ergebnis) versehen wird und über einen eigenen Workflow verfügt.
Nun werden unter der jeweiligen Anforderung die Testfälle erfasst und bei der Ausführung entsprechend die Ergebnisse darin vermerkt und der Status verändert. Damit kann der Projektleiter sehen, wie der Stand bezüglich der Anforderung ist und der Aufwand seitens Testfallerfassung ist sehr gering. Außerdem kann so die Ausführungsreihenfolge mit der Sortierung von Untervorgängen festgelegt werden. Es gibt natürlich auch hier Abstriche, wie z.B. die Sichtbarkeit der Testfälle für die Entwickler, aber mit etwas Anstrengung kann auch dieses Problem über die sogenannten Sicherheitsstufen gelöst werden.
Zusammenfassend kann man sagen, es gibt verschiedene Lösungsmöglichkeiten um mit Atlassian JIRA ein Testfallmanagement zu betreiben. Welches davon die richtige Lösung für das eigene Unternehmen ist, muss analysiert und auch probiert werden. Kleine Projekte eignen sich am Anfang sehr gut, um unter realen Bedingungen Erfahrungen zu sammeln.
Wie es aussieht ist Atlassian bestrebt die eigenen Produkte stärker mit einander zu verflechten. Neben einer Angleichung der Benutzeroberflächen (z.B. bei JIRA und Confluence) wird auch die Verknüpfung der Inhalte verbessert. So setzt man bei Atlassian auf den OpenSocial Standard, von dem man sich eine bessere Integration der eigenen Produkte untereinander (und mit anderer Software) verspricht. Die Implementation eines OpenSocial-Gadget-Containers in Form eines Dashboards existiert bereits für die aktuelle JIRA 4.0 Beta. Für Confluence ist bereits eine geplant. Um diese Dashboards in Zukunft mit Inhalten aus den anderen Atlassian Anwendungen zu ergänzen, wird es einen neuen Gadget-Plugin-Typ geben.
Aber auch auf technischer Ebene gibt es Bestrebungen die Interoperabilität der einzelnen Produkte zu verbessern. Die Grundlage dafür liefert das neue Plugin-Framework. So stellt es über einen neuen Plugin-Modul-Typ eine einheitliche REST-API bereit, die einzelne Dienste oder Ressourcen der jeweiligen Anwendung über eine URL zugänglich macht.
Außerdem wird es einfacher sein Plugins zu schreiben, die in mehreren Alassian Produkten einsetzbar sind: Mit SAL (Shared Access Layer) gibt es eine Service-Schicht, die eine einheitliche Schnittstelle für einige allgemeine Dienste unabhängig von der jeweiligen Anwendung bereitstellt. Des Weiteren können Plugins so konfiguriert werden, dass bestimmte Module nur für ein bestimmtes Produkt aktiviert sind. Auf diese Weise können Kompatibilitätsprobleme der Modultypen zwischen den einzelnen Anwendungen abgefangen werden.
Vorraussetzung für die meisten der vorgestellten Features, ist die Verwendung von Atlassian Produkten, die das Plugin Framework mit Version 2.2 oder größer verwenden (z.B. Confluence 3.0). Dies ist leider noch nicht bei allen aktuellen Releases der Fall, wie man der Versions-Matrix entnehmen kann.
Für die Integration von JIRA-Inhalten in Confluence stehen 3 Möglichkeiten zur Verfügung:
Die Anzeige bestimmter Filter ist allerdings nur für eingeloggte Benutzer möglich. Daher sollte entweder eine Trusted Connection zwischen Jira und Confluence etabliert werden oder im Aufruf des Macros der Benutzername und das Passwort enthalten sein.
Näheres zur Zusammenarbeit von Jira und Confluence findet sich unter http://confluence.atlassian.com/display/DOC/Confluence%20and%20JIRA.
Über das Macro “jiraissues” lassen sich beliebige in JIRA angelegte Views in Confluence integrieren. Auf diese Weise können z.B. Ansichten für offene Vorgänge oder zugewiesene Aufgaben eingefügt werden.
Standardmacro
{jiraissues:url=http://jira.xml.url}
Hierbei ist zu beachten, dass als URL der XML-Link aus dem Jira Issue Navigator verwendet werden sollte. Diesen Link findet man, wenn man in Jira auf “Find Issues” geht und dort die gewünschte View anlegt (eine ausführliche Anleitung findet sich in der Dokumentation des Macros).
Auswahl von Spalten
{jiraissues:url=http://jira.xml.url|columns=type;key;summary}
Benutzername und Passwort
{jiraissues:url=http://jira.xml.url?os_username=johnsmith&os_password=secret}
Aufruf ohne Trusted Connection
{jiraissues:url=http://jira.xml.url|anonymous=true}
Screenshot

Über das Macro “jiraportlet” lassen sich Portlets aus dem Jira-Dashboard in Confluence integrieren. Dafür muß die URL des entsprechenden Portlets angegeben werden. Diese findet man heraus, indem man auf dem Jira-Dashboard in den Configure-Modus wechselt und dann den Link hinter dem Namen des gewünschten Portlets kopiert.
Standardmacro
{jiraportlet:url=urlOfJIRAPortlet}
Benutzername und Passwort
{jiraportlet:url=urlOfJIRAPortlet?os_username=johnsmith&os_password=secret}
Screenshot

Eine recht simple Möglichkeit der Interaktion zwischen JIRA und Confluence besteht in der Verwendung von Trackbacks. Voraussetzung dafür ist, dass in beiden Systemen Trackbacks aktiviert sind. In JIRA findet sich die Option unter Administration – Global Settings – Trackback, in Confluence unter Administration – Allgemeine Konfiguration – Trackback. Verlinkt dann eine Confluence-Seite auf ein JIRA-Issue (oder anders herum), wird die verlinkte Seite informiert und blendet die Linkquelle ein. In JIRA führt das zu folgendem Ergebnis:

Mit Version 2.10 wurde die Integration von Jira-Issues in Confluence-Inhalte weiter verbessert. Das Macro “jiraissues” liefert nun eine Tabelle, die im Gegensatz zu früheren Versionen bequem angepasst werden kann. Spalten können nun – wie von Windows gewohnt – verschoben und sortiert werden. Die Sortierung erfolgt dann je nach Spalteninhalt entweder alphabetisch oder z.B. auf/absteigend nach Priorität. Einzelne Spalten können auch ganz ausgeblendet werden. Zu beachten ist allerdings, dass diese Änderungen nicht gespeichert werden – sobald man die Seite verlässt und neu aufruft, ist wieder die standardmäßige Anordnung und Sortierung eingestellt. Lange Listen werden nun seitenweise dargestellt und können bequem durchblättert werden.

Releaseparty at Atlassian? Confluence 3.2 BETA and 3.1.2 with soms bugfixes were released yesterday. [...]
Tino Schmidt's Vortrag zu Enterprise Mashups auf der webciety, 4.3 Remix the Web http://bit.ly/d26rtA [...]
neuer Blogpost: February Cumulative Update (2010) http://bit.ly/cwxZGE [...]
Webinar am 16.03.: „Communote Enterprise Microblogging - Funktionen und Einsatzbereiche im Unternehmen“ http://bit.ly/96eexF [...]