Das im folgenden vorgestellte Testverfahren wird mit den kommerziellen Entwicklungstools JIRA und Bonfire von Atlassian durchgeführt. Diese werden mittlerweile in vielen Unternehmen weltweit eingesetzt, da die Lizenzen günstig und die Tools sehr gut für agile Softwareentwicklung geeignet sind.
Atlassian ist eine australische Softwarefirma die im Jahr 2002 von Mike Cannon-Brookes und Scott Farquhar in Sydney gegründet wurde, die sich aus Studienzeiten an der Universität von New South Wales kannten. Das Unternehmen machte 2009 einen Umsatz von AUD $58 Millionen und hat 20.000 Kunden weltweit. Atlassian ist Anbieter von Enterprise 2.0-Software.
JIRA ist das erste Softwareprodukt von Atlassian und seit 2002 auf dem Markt.
Bonfire als ergänzendes Webseiten-Test-Plugin gibt es seit 2011. JIRA ist eine webbasierte Anwendung zur Fehlerverwaltung, Problembehandlung und operativem Projektmanagement. Primär wird JIRA für die Softwareentwicklung eingesetzt. Dort unterstützt es das Anforderungsmanagement, die Statusverfolgung und später den Fehlerbehebungsprozess. Der Name stammt vom ursprünglichen japanischen Namen für Godzilla, „Gojira“. Die Entwickler von JIRA wollten etwas mit Bezug zu
Bugzilla und kamen so auf Gojira. Ausgesprochen wird es, der japanischen Lesart entsprechend, „Dschiera“ und nicht, wie vielfach fälschlich angenommen, „Dscheira“.
Eigentlich ist JIRA also für das Aufgabenmanagement gedacht. Vor allem wird in der Softwareentwicklung darüber das Bug-Management abgewickelt. Da Bugs häufig beim Testen gefunden werden, kann es Sinn machen, die Tests ebenfalls in JIRA abzubilden.
Hierbei handelt es sich mein eigenes Verfahren, das ich in folgendem Beitrag vorstellen will. Dabei werde ich erklären wie das Testen in JIRA funktioniert, wie es eingerichtet wird und was es für Vorteile hat.
1. Von UserStories zu Testcases
Zunächst werden aus vorhandenen UserStories Testcases für das Testen in JIRA erstellt.
Wie sollte ein Testcase aussehen?
Ein Testcase ist die kleinstmögliche Einheit in einer UserStory, wenn möglich nur eine Aktion des Nutzers. Er besteht aus einer Vorbedingung, einer durchzuführenden Aktion und einem erwarteten Ergebnis.
Beispiel:
Testcase: A reason is given why the login is in this particular context necessary
Pre-Condition:
User is not logged in
Action:
Check if next to login form a reason is given why the login is in this particular context necessary, incl. links to help articles.
Expected Result:
The reason is given and understandable, links to help are available.
