Sicherstellen, dass alles funktioniert: Regressionstests bei XING

Agile Entwicklungsprozesse wie SCRUM (siehe auch Einführung von Scrum bei XING) machen die Aufgabe der Qualitätssicherung schwieriger. Die größte Herausforderung ist dabei, sich auf Releasezyklen von zwei bis vier Wochen einzustellen.

Selbst in gut funktionierenden Teams bleibt oft nicht genügend Zeit, neben der regelmäßigen Qualitätssicherung für neue Features, manuelle Regressionstests durchzuführen. Jede neue Codezeile in einem Programm kann die exisitierenden Funktionalitäten beeinträchtigen. Deswegen reicht es nicht aus, allein die neuen Funktionen zu testen – die bestehenden Features müssen ebenso überprüft werden. Dies geschieht dadurch, dass Testfälle aus vorherigen Entwicklungszyklen wiederholt  werden. Dabei handelt es sich um die so genannten „Regressionstests“. Natürlich schreiben Entwickler selbst automatisierte Tests, so dass der existierende Code nicht beeinträchtigt werden sollte – diese finden aber auf der Unit- und Komponenten-Ebene statt. Systemtests, bei denen im Frontend Daten eingegeben werden und alle Ebenen überprüft werden, sind sehr zeitaufwändig und würden die Entwickler bei ihrer täglichen Arbeit eher behindern.

Die Lösung für dieses Problem sind automatisierte Regressionstests.

Die Tools für Regressionstests

Die QS-Abteilung bei XING hat ein Framework entwickelt, das von Test-Projektteams zur Erstellung von Regressionstests verwendet wird. Das Framework basiert auf TestNG und Selenium.
TestNG ist ein Test-Framework, ähnlich wie JUnit. Damit können nicht nur Unittests ausgeführt werden, sondern auch Testmethoden zu Gruppen zugeordnet werden. So wird eine Testmethode zur Überprüfung einer Suchfunktion an einer Schnittstelle im Backend zu „Suche“ und „Backend“ zugeordnet. Da die Methode auch bei kurzen Akzeptanztests durchgeführt werden soll, wird sie auch „Akzeptanz“ zugewiesen. Mit diesen Gruppen können unterschiedliche Suites erstellt werden, die alle Testmethoden nach bestimmten Gruppen filtern. So können wir anhand desselben Testcodes gleichzeitig kurze Akzeptanztests (Filter: „Akzeptanz“) und umfangreiche Systemtests (kein Gruppenfilter) durchführen. Außerdem können so Tests ausgeführt werden, die auf bestimmte Systemteile, wie z. B.  die Suche, beschränkt sind.

Selenium ist ein Testframework für die gängigen Browser. Viele Web-Testframeworks funktionieren auf HTTP-Ebene und prüfen den HTML-Code von Websites. Selenium agiert innerhalb des Browsers wie ein realer Nutzer. So wird es möglich, Websites wie XING zu testen, die eine hohen JavaScript- und AJAX-Anteil aufweisen.

Wir haben diese Tools, die an sich schon sehr leistungsstark sind, noch deutlich ausgebaut. Diese  Erweiterungen umfassen verbessertes Logging (Ergebnisse werden in einer Datenbank und unserem wiki erfasst) und gehen weit über die Default-Methoden für die Kernfunktionen der XING-Plattform hinaus (z. B.  Login und Logout).

Vorteile von automatisierten Testfällen

Gewöhnlich sieht ein automatisierter Testfall wie folgt aus:

@Description("TC-UC5-01-01\nsearch for string that is not available (neither company nor have)")
@Test(groups = { "frontend", "search" })
public void TC_UC5_01_01() {
String keyword = "abcdefghijklmnop";
login(TestUser.dont_care);
openCompanyPages();
searchCompanyByKeyword(keyword);
verifyCompanyCount(0);
verifyCompanySearchNoResult(keyword);
}

Dies hat mehrere Vorteile:

Zunächst fallen die sprechenden Namen der verwendeten Methoden auf. Diese sollen sicherstellen dass auch Menschen ohne tiefes technisches Wissen den Inhalt des Tests verstehen – was vor allem bei fehlgeschlagenen Tests hilfreich ist. Ein weiterer Vorteil ist die Trennung von Test-Workflow und tatsächlichem HTML-Frontend. Durch diese Trennung wird der Wartungsaufwand gesenkt – Änderungen im Frontend führen so zu Änderungen in einer einzigen Isolationsmethode statt zu Änderungen in vielen Testabläufen.

public void openCompanyPages() throws IOException {
	String locator = "//*[@href='/companies/']";
	waitForElementIsPresent(locator, Timeout);
	clickAndWait(locator, Timeout);
}

Der dritte Vorteil zeigt sich beim Schreiben von automatisierten Tests. Da die Isolationsmethoden verwendet werden, können die Tests ohne das Frontend der Applikation erstellt werden. Sobald das Frontend zur Verfügung steht, müssen die Isolationsmethoden umgesetzt werden, und es können Tests durchgeführt werden.

Bei einigen Sprints haben wir es geschafft, die automatisierten Tests fertigzustellen, noch bevor die  manuellen Tests abgeschlossen waren.

Die von den Projektteams erstellten automatisierten Regressionstests laufen täglich neben den Tests der Entwickler, um so eine maximale Resistenz gegen Regressionsdefekte zu erreichen.

Ein aktuelles Beispiel: Unternehmensprofile

Regressiontests nehmen erfahrungsgemäß im Verlauf eines Projekts zu. Im letzten halben Jahr haben wir im Rahmen des Projekts „Unternehmensprofile“ über 500 Testfälle automatisiert. Das entspricht ungefähr 60 % der manuellen Testfälle. Zur Durchführung werden etwa 2 Stunden benötigt. Zum Vergleich: Die von Entwicklern geschriebenen Tests enthalten 330 Testfälle und benötigen nur 83 Sekunden.

Anzahl der durchgeführten automatisierten Regressionstests.

Wie die Grafik zeigt, konnten anhand der Regressionstests einige Fehler vor dem Release gefunden und behoben werden. Die meisten Störungen im „Hintergrund“ sind auf einen instabilen Server zurückzuführen, auf dem die Tests durchgeführt wurden. Sie bleiben konstant, obwohl die Zahl der Testfälle zunimmt – damit bleibt auch die Ursachensuche auf konstantem Niveau.

Mit unseren leistungsstarken Logging-Mechanismen können wir sofort bestimmen, bei welchen Testmethoden der Wartungs- und Analyseaufwand zu hoch ist. Diese Tests werden verbessert oder ggf. deaktiviert.

Mit einer umfangreichen Suite automatisierter Regressionstests erlangt die Qualitätssicherung Freiraum und Sicherheit: Freiraum, um sich auf die neu entwickelten Features zu konzentrieren und die Sicherheit, dass die existierenden Features noch genauso gut funktionieren. Mit den beschrieben Techniken liegen die Wartungskosten unter den Kosten für manuelle Regressionstests und sogar deutlich unter den Kosten der späteren Fehlerbehebung.

Eine Woche nach dem Launch der zweiten Version von Unternehmensprofilen zeigt sich, dass unsere Bemühungen sich gelohnt haben. Insgesamt wurden drei Fehler gemeldet, die als unwesentlich einzustufen sind und innerhalb einer Woche behoben werden konnten. Im Vergleich zu 624 Personentagen in der Entwicklung sind drei Bugs eher zu vernachlässigen.