Archiv für den Autor: tinatigertech

Workflow zum Testen mit JIRA und Bonfire

von tinatigertech | 1 Kommentar

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.

Weiterlesen →

Automatisiertes Testen von Webseiten mit dem Selenium WebDriver

von tinatigertech | 2 Kommentare

Das Open Source Projekt „Selenium“ zum Durchführen automatisierter Browser Tests gibt es bereits seit 2004. Ins Leben gerufen wurde es von Jason Huggins, während seiner Zeit bei ThoughtWorks, die zu diesem Zeitpunkt hauptsächlich mit Javascript arbeiteten. Obwohl  der InternetExplorer der beherrschende Browser war, wurden bei ThoughtWorks bereits einige alternative Browser benutzt (vor allem Mozilla Varianten). Open Source Testing Tools gab es nur für einzelne Browser (typischerweise für den InternetExplorer) oder es waren Simulationen von Browsern (z.B. HttpUnit) und die Kosten für kommerzielle Tools waren vor allem für kleine Projekte noch nicht bezahlbar .

Glücklicherweise unterstützten alle zu testenden Browser Javascript. Deshalb machten sich Jason und sein Team daran ein Testing Tool in der Sprache zu schreiben die das Verhalten ihrer Applikation am Besten verifizieren konnte. Inspiriert von dem FIT-Projekt wurde eine tabellenbasierte Syntax über das Javascript gelegt und es damit auch Nutzern mit begrenzten Programmierkenntnissen ermöglicht Tests zu schreiben. Dieses Tool wurde 2004 unter dem Namen „Selenium“ (oder auch „Selenium Core“) und unter einer Apache 2 Lizenz veröffentlicht.

Da Selenium in purem Javascript geschrieben ist, musste es auf dem gleichen Server wie die Applikation laufen, um die Browser Sicherheitsbestimmungen zu umgehen. Das war aber nicht immer möglich. Um dieses und andere Probleme zu lösen wurde ein HTTP Proxy geschrieben. Damit ließen sich viele Einschränkungen der  „Same Host Policy“ der Browser umgehen. Dieses Design ermöglichte es, Selenium-Anbindungen für viele Programmiersprachen zu schreiben. Sie mussten nur in der Lage sein eine HTTP-Anfrage an eine bestimmte URL zu schicken. Diese Version wurde bekannt als „Selenese“ oder auch „Selenium Remote Control“ (Selenium RC).

Währenddessen wurde bei ThoughtWorks an einer weiteren Browser Automatisierung gearbeitet: dem WebDriver. 2007 wurde der erste Code hierzu veröffentlicht. Er wurde für Nutzer von Projekten entwickelt, die ihre Ende-zu-Ende-Tests von dem darunterliegenden Test-Tool isolieren wollten. Typischerweise wird dies mit dem Entwurfsmuster Adapter gemacht. WebDriver entwickelte sich aus diesem Bedürfnis heraus und war ursprünglich für HTML Unit gedacht. Die Unterstützung für den InternetExplorer und Firefox folgten aber kurz nach dem Release.

Es gab erhebliche Unterschiede zwischen Selenium RC und WebDriver. Der größte Unterschied war, daß Selenium RC eine Wörterbuch-basierte API hatte, die alle Methoden für eine Klasse beanspruchte, während der WebDriver eine objektorientiertere API hatte. Außerdem unterstützte der WebDriver zunächst nur Java, während Selenium RC Unterstützung für viele Sprachen anbot. Technisch war Selenium Core hauptsächlich eine Javascript-Applikation, die in der Security-Sandbox des Browsers lief. WebDriver versuchte sich in den Browser zu integrieren, und das Browser Sicherheitsmodell zu umgehen, was einen weitaus höheren Entwicklungsaufwand zur Folge hatte.

Im August 2009 wurden beide Projekte miteinander verschmolzen. und der Selenium WebDriver ist das Resultat beider Projekte. Er unterstützt Sprachanbindungen für Java, C#, Python und Ruby. Außerdem bietet er Unterstützung für Chrome, Firefox, Internet Explorer, Opera und die Android und iPhone Browser. Es gibt Nebenprojekte die Anbindungen für Perl und eine Implementierung für den BlackBerry Browser anbieten.

Einrichten der Testumgebung 

Beispiel für Eclipse und Java

Die WebDriver API ist nicht an ein spezielles Testframework gebunden und kann sowohl in Unit Tests als auch in der guten alten Main-Methode verwendet werden.

Weiterlesen →