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.

Am 02.12.2009 fand das 3. ASQF Fachgruppentreffen Software-Test Sachsen in Dresden statt. Jan Overbeck von der ANECON Software Design & Beratung GmbH hielt einen Vortrag zum Thema Widerstand gegen Testen (…und wie Tester ihm begegnen).

Dabei ging es zum einen darum, dass bei den meisten Projekten leider immer noch die Testphase im Projekt recht knapp gehalten wird und auch die Phase ist, welche am ehesten gekürzt wird, wenn z.B. in der Entwicklung mehr Zeit verbraucht wird. Das dies aber nicht zielführend ist, waren sich alle einig.

Anschließend wurden die Widerstände, die Projektbeteiligte gegenüber dem Testen haben, genannt und die eigentlichen Nutzen für die Projektbeteiligten aufgezeigt. Damit war klar, dass es eigentlich jeden Projektbeteiligten etwas bringt, wenn getestet wird und die Beteiligten gefundene Fehler nicht als etwas Schlimmes verstehen, sondern als etwas, was noch vor der Produktivnahme korrigiert werden kann.

In der anschließenden Diskussion ging es dann unter anderem um das Thema der Rollenbesetzung und der Integration ins Team oder der Auslagerung als extra Team. Es zeigte sich, dass beide Varianten etwas für sich haben und anhand der Entwicklungsmethode entschieden werden muss, welche die bessere ist. Auch kam als Thema auf, dass Entwickler nicht die Testfälle vorgeben können, da sonst die Testfälle keine Fehler zu Tage führen können und letztlich die Entwickler selbst dies auch nicht wollen. Am Ende wurde noch genannt, dass immer definiert sein muss, welche Qualität man mit einem Projekt erreichen will und sich dadurch letztlich der Testaufwand festlegt.

Beim anschließenden Imbiss kam noch das ein oder andere Gespräch mit den Teilnehmern zustande.