Ein Strukturansatz

Use-Case-Coverage durch Testautomatisierung

Thomas Garus

(c) Shutterstock / Kalakruthi

In einem Softwareentwicklungsprojekt stellen sich früher oder später mindestens zwei Fragen: „Was soll in einem Softwaretestprojekt alles getestet werden?“ und „Welche Anwendungsfälle wurden bereits durch (automatisierte) GUI-Regressionstests abgedeckt?“ Das Testen von Software umfasst zwar viele weitere Aspekte, etwa das manuelle, explorative Testen und die Entwicklertests. Dennoch wollen wir uns in diesem Artikel auf die fachlichen, automatisierten Regressionstests beschränken, da sich diese mit den entsprechenden Werkzeugen besonders gut mit dem Anforderungsmanagement verbinden lassen. Wie eine solche Verbindung aussehen kann, wird im Folgenden aufgezeigt.

Im Laufe des Artikels wird zudem deutlich, wie sich die Regressionstests strukturieren lassen und wie die Rückkopplung toolgestützt von den Tests bis hin zum Anforderungsmanagement aussehen kann. Zunächst klären wir die Begrifflichkeiten und stellen eine Testprojektstruktur vor. Danach soll auf ein Vorgehen verwiesen werden, das wir bereits erfolgreich eingesetzt haben, um damit die beiden Eingangsfragen zu beantworten.

Der „Happy Path“ der Testautomatisierung

Zu einem Softwareentwicklungsprojekt sollte auch ein Softwaretestprojekt gehören, das sich auf die Automatisierung von Testfällen spezialisiert. Dies sorgt im Rahmen der Systemrealisierung für eine erweiterte Qualitätssicherung. Mit einem Tool der Wahl werden Testfälle erstellt und anschließend in eine Continuous-Integration-Umgebung eingebunden.

Eine häufige Form der Automatisierung auf System- beziehungsweise Akzeptanzebene dürften die GUI-Tests sein. Dabei wird die Anwendung von dem Automatisierungstool so durchlaufen, als säße ein Anwender davor, wobei die Testfälle einen charakteristischen Durchlauf für einen Bereich der Anwendung widerspiegeln. Durch die Automatisierung dieser Testfälle können Regressionstests für das Softwareentwicklungsprojekt erstellt werden, die in regelmäßigen Abständen ausgeführt werden. Dadurch ergibt sich der Vorteil, jeden Tag den Status über die Funktionsfähigkeit der Anwendung zu erhalten.

Zu Anfang eines Testprojektes dürften die „Happy Path“-Testfälle abgebildet werden. Diese durchlaufen die Kernfunktionalitäten einer Anwendung mit exemplarischen Daten und dienen der Sicherstellung der Funktion eines Kernbereichs der Anwendung. Es werden zunächst also keine „Randbedingungen“ oder besonders kritische Pfade beschritten, sondern der optimale beziehungsweise Standardablauf abgebildet.

Damit die Tests nachvollziehbar und nachhaltig bleiben, müssen sie gut strukturiert werden. Auf Basis dieser Struktur kann die Testautomatisierung erfolgen. Dazu soll kurz eine Klassifizierung vorgestellt werden.

Klassifizierung von Testbereichen

Zur Strukturierung von Regressionstests verwenden wir verschiedene Testbereiche. Testbereiche können so verstanden werden, dass jeder Bereich eine fachliche Einheit in der Anwendung darstellt. Ein solcher Testbereich für eine Softwareanwendung kann beispielsweise der Bereich „Benutzer“ einer Benutzerverwaltung sein.

In jedem so definierten Bereich sind bestimmte Aktionen möglich. Für die meisten Anwendungsbereiche lassen sich die Aktionen aus dem CRUD-Pattern (Create, Read, Update, Delete) als Anhaltspunkt ableiten. Anhand dieser Muster können das Anforderungsmanagement und die Tester die Anwendungsfälle für jeden Bereich identifizieren. Das Testteam wird im Anschluss an die Anwendungsfalldefinition die konkreten Testfälle definieren. (Abb. 1).

garus_testautomatisierung_1

Abb. 1: Teststrukturierung

Mit diesem Ansatz ist ein Team in der Lage zu entscheiden, welche Testfälle automatisiert werden sollen. Die zweite Frage –„Welche Fälle wurden bereits abgedeckt?“ – lässt sich anhand einer Verknüpfung mit den Anforderungen im Requirements-Managementsystem beantworten. Dazu stellen wir unser Vorgehen für eine Transformation vor.

Zustandsüberführung vom Testfall ins Requirements-Managementsystem

Als Requirements-Managementsystem verwenden wir im Projekt HP-ALM. Für die Rückverfolgbarkeit der Anforderungen über die GUI-Tests (und insbesondere deren Status) wird ein Transformator verwendet. Bei der Automatisierung der Testfälle im Test-Tool versehen wir sie mit einer sogenannten „Task-ID“, die immer einem Use Case in HP-ALM zugeordnet ist, sodass die zu automatisierenden Anwendungsfälle schnell gefunden werden können. Damit nicht nur eine Verbindung, sondern auch der aktuelle Teststatus für die Anwendungsfälle in das Requirements-Managementsystem übermittelt wird, wird nach jedem nächtlichen Durchlauf der Tests eine XML-Datei erzeugt. Diese beinhaltet die Testfall-ID, die Task-ID und den Teststatus für jeden Testfall. Sie bildet die Grundlage für die Übergabe des aktuellen Teststatus an das HP-ALM. Dazu wird das Task-Repository aus dem HP-ALM über einen Mylyn-Connector eingebunden. Die zur Verfügung stehenden Anwendungsfälle werden aus dem Repository ausgelesen und die Informationen der XML-Datei eingelesen. Im Anschluss findet die Übertragung der eingelesenen Informationen an das HP-ALM statt. Durch vorherige Definition wurde festgelegt, welche Informationen aus dem XML-File in welche Felder im HP-ALM geschrieben werden. Als wichtige Information in Verbindung mit den Testfällen dient der Coverage-Status der Anwendungsfälle. Er wird entsprechend der Ergebnisse aus den Testfällen täglich aktualisiert. Somit sind die Use Cases im Requirements-Managementsystem immer auf dem neuesten Stand. In Abbildung 2 ist die Transformation beispielhaft dargestellt.

garus_testautomatisierung_2

Abb. 2: Mylyn Reporting

Änderungen von Anwendungsfällen – Auswirkungen auf die Tests

Ein geschriebener Testfall bleibt allerdings nicht ewig in Stein gemeißelt. Anforderungen ändern sich, werden ergänzt oder entfallen komplett. Daher müssen automatisierte Testfälle regelmäßig angepasst werden. Auch hier kann die Verbindung mit einem gepflegten Requirements-Managementsystem eine Hilfe darstellen.

Dafür ist es notwendig zu analysieren, welche Use Cases durch die Entwicklung betroffen sind, um später die richtigen Testfälle anpassen zu können. Dies wird mit einer Delta-Betrachtung durchgeführt. Der Gedanke dabei ist, herauszufinden, welche Teile der Anwendung sich zu einem definierten Stand geändert haben, welcher Teil der Use Cases betroffen ist und welche daraus abgeleiteten Testfälle involviert sind. Im ersten Schritt, der Konzeption, wurden bereits die Anwendungsfälle zu dem Requirement zugeordnet, auch in HP-ALM. Durch eine gewisse Gratwanderung kann der Umfang der Änderungen ermittelt werden. Dabei lässt sich ein Bewertungsschema anwenden, dessen Aussagen sich neben weiteren in Abbildung 3 zeigen. Das Delta stellt dabei nur die Änderungen im Vergleich zum vorherigen Stand dar.

garus_testautomatisierung_3

Abb. 3: Einordnung Testumfang

Benefit durch die beschriebene Verknüpfung

Der eigentliche Nutzen entsteht nicht durch die bloße Datenübertragung, sondern durch die bereits vorhandene Zuordnung der Use Cases zu den Requirements. Wie eingangs erwähnt, wird verlinkt, welche Anwendungsfälle von welchen Requirements geändert werden. Dadurch und durch die stetige Aktualisierung entsteht die Möglichkeit, eine Use-Case-Coverage abzubilden und auf diese Weise die Testfallabdeckung zu beurteilen. Dies kann als Zusatz zur Code-Coverage durch Testfälle angesehen werden. Da diese Informationen sowohl vom Anforderungsmanager, vom Entwickler wie auch vom Tester interpretiert werden können, haben wir nebenbei eine Kommunikationsschnittstelle geschaffen. Jede dieser Rollen kann auf die Testbereiche Bezug nehmen und so seine Informationen klarer kommunizieren. Dies kommt dem Projekt in allen Teilen der Projektphase zu Gute, sei es in der Anforderungsanalyse, der Umsetzung, der Testautomatisierung oder dem Releasetest.

Aus diesem Vorgehen leiten sich zusätzlich einige interessante Hilfestellungen für das Projekt und das Anforderungsmanagement ab. Durch das zentrale Einbinden der Tester bei der Verwaltung der Testbereiche, und durch die aktive Rückkopplung aus den Tests in das Anforderungsmanagement, entsteht ein stetiger Mehrwert für die Anforderungskonzeption und für die Qualität des Projektes in frühen Phasen. Zudem wird der Testmanager entlastet, da durch das teilautomatische Reporting die manuelle Zuordnung entfällt und er nur noch die Deltas der Änderungen zu den Anwendungsfällen zu betrachten braucht.

Zusammenfassende Gedanken

In diesem Artikel wurde beschrieben, wie ein Vorgehen im Anforderungsmanagement mit dem Vorgehen für den Softwaretest verbunden werden kann. Als Bindeglied der Zusammenarbeit dient unser Modell der Testbereiche. An diesen kann der Anforderungsmanager dem Entwicklungs- und Testteam die sich ändernden Bereiche der Anwendung aufzeigen. Mittels der Betrachtung der Änderungen durch die Anforderungen als Delta wird die Arbeit im Testteam effizienter. Sie können mithilfe der Struktur und der ausgearbeiteten Anforderungen nachvollziehen, was genau sich ändert, sodass festgehalten wird, ob es sich um neue Testfälle, große oder kleine Änderungen handelt.

Als Prämisse lässt sich formulieren, dass es eine Abwägungsangelegenheit ist, wie ausführlich einzelne Funktionen der Anwendung getestet werden. Im Sinne des Projektes sollte daher der Nutzen durch den Test im Fokus stehen. Sobald die Automatisierung einer Spezialfunktion eines Testbereiches keinen Nutzen für das Projekt bringt, sollte kein großer Aufwand für die Automatisierung betrieben werden. Es lässt sich durch dieses Vorgehen ableiten, was genau getestet werden muss, da bekannt ist, was bereits getestet vorliegt. Durch das Reporting in Richtung HP-ALM ergibt sich darüber hinaus ein tagesaktueller Stand einer Use-Case-Coverage für das Projekt.

Verwandte Themen:

Geschrieben von
Thomas Garus
Thomas Garus
Thomas Garus ist Test Consultant bei der BREDEX GmbH in Braunschweig. Er hat in diversen traditionellen und agilen Projekten gearbeitet, in denen er für die Testkoordination, die Testautomatisierung für Desktop- / Webanwendungen und das Etablieren von Teststrategien zuständig ist. Darüber hinaus setzt er sich für einen einheitlichen Testgedanken und Prozessverbesserungen im Projektteam ein. Thomas ist zudem Mentor und Coach für neue Test Consultants in der Firma.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: