Grundlegendes Konzept

Warum sollte ich automatisch testen?

Testen ist ein wichtiger Bestandteil zur Qualitätssicherung in der Softwareentwicklung. Besonderer "Bedarf" für Qualitätssicherung entsteht dabei immer nach Anpassungen an einem System, z.B.

• Funktionieren alle Prozesse nach einem großen Versionsupdate noch?

• Habe ich durch meine individuellen Anpassungen (C2-Customizing) vielleicht andere Bereiche im CRM "beschädigt"?

• Funktionieren nach einem Versions- oder Modul-Update meine systemspezifischen Anpassungen (C2-Customizing) noch?

• Regelmäßiges Testen, um frühzeitig Probleme zu erkennen – alles, was nicht durch den Endanwender gemeldet wird, ist ein Gewinn!

Selbst bei einfachen Systemen ist es ermüdend, alles manuell zu testen. Umfangreiche und kritische Systeme (und dazu zählen insbesondere CRM-Systeme) sollten umfassend getestet werden. Automatisierung ermöglicht es, den Aufwand in Grenzen zu halten ("Der Test muss nur einmal geschrieben werden (zeitaufwendig) und kann beliebig oft ausgeführt werden (kaum manueller Zeitaufwand)".

Aber auch Tests unterliegen gewissen Einschränkungen. Sicher ist es nicht erstrebenswert oder möglich, alles zu automatisieren: Integration und Schnittstellen mit Drittsystemen können nicht mit vertretbarem Aufwand automatisch getestet werden. Dafür bieten sich "halb-automatische Tests" an: Alle CRM-Aktionen sind automatisiert, die Aktionen im anderen System werden vom Testausführenden selbst abgearbeitet.

Nicht zuletzt ist ein Testfall mit dem Test-Studio eine "ausführbare Dokumentation": Er ist automatisch ausführbar, aber dennoch leicht zu verstehen. So haben Sie immer eine aktuelle Dokumentation, auf der Sie aufbauen können!

Wo teste ich?

Tests können prinzipiell auf jedem CRM-System ausgeführt werden, sinnvoll ist dies jedoch nur bei zwei:

Welche Anforderungen an Testfälle gibt es?

• Testfälle sollten autark funktionieren und sich nicht darauf verlassen, dass andere Testfälle vor ihnen korrekt ausgeführt wurden.

Die Ausführungsreihenfolge der Tests kann nicht festgelegt werden.

• Sie raten nicht über den Zustand der Anwendung. Im Test weiß man immer genau, welche Aktionen man bereits ausgeführt hat und was das erwartete Verhalten der Anwendung ist.

• Sie können mehrmals hintereinander ausgeführt werden, ohne dadurch auf Fehler zu laufen.

• Test verhalten sich deterministisch und müssen im Fehlerfall auch einen Fehler ausgeben.

• Sie werden nicht solange wiederholt, bis sie erfolgreich gelaufen sind. "Wackel-Tests" müssen entweder im Customizing des CRMs oder im Test repariert werden.

• Testfälle sind möglichst kurz zu halten. Der Test sollte wirklich nur die Aktionen ausführen, die auch für den Test notwendig sind und genau eine fachliche Nachbedingung testen.

Wie sind Tests aufgebaut?

Wir unterscheiden zwischen fünf Stufen:

Workspace: Das Projekt (Verzeichnis), das alle Testfälle und Testschrittbibliotheken enthält.

Testsammlung: Mehrere Testfälle, die einen engen Bezug haben, z.B. "Alle Testfälle für den Angebotsprozess". Siehe "Wie organisiere ich Testfälle?".

Testfall: Ein zusammenhängender Testfall, z.B. "Angebotsprozess für Bestandskunden". Dieser besteht aus Testschritten. Eine detaillierte Einführung finden Sie in der Anwenderdokumentation.

Testschrittbibliothek: Bietet die Möglichkeit Testmethoden anzulegen, die testfallübergreifend verwendet werden können.

Testschritt: Sequenz aus Keywords, die einen einzelnen fachlich abgeschlossenenen Schritt darstellen. Bspw. "Wähle den Geschäftspartner aus". Im BPM Umfeld ergibt ein Testschritt pro BPM-Benutzer-Aktion meist Sinn.

Wie organisiere ich Testfälle?

Jeder Testfall ist eine eigene Datei. Mehrere Testfälle, die fachlich eng verbunden sind (z.B. alle Testfälle für den Angebotsprozess) können in einer gemeinsamen Testsammlung abgelegt werden. Mehrere Hierarchieebenen sind möglich.

Alle Testsammlungen werden innerhalb eines Workspaces zusammengefasst und können mittels Testschrittbibliotheken erweitert werden. Bestenfalls gibt es einen Workspace pro System.

Beispielhafter Workspace

CRM_Tests (WorkSpace)
|- lib 
|  |- MeineTestBibliothek (Testschrittbibliothek)
|  |- ...
|- tests
|  |- Bestandskunden (Testsammlung)
|  |   |- Tarifänderung (Testsammlung)
|  |   |   |- Tariferhoehung.webtest (Testfall)
|  |   |   |- ...
|  |   |- Umzug
|  |   |   |- Umzug_mit_Netzbetreiberwechsel.webtest
|  |   |   |- Umzug_ohne_Sonderkuendigungsrecht.webtest
|  |   |   |- ...
|  |   |- ...
|  |- Neukunden
|  |   |- Neukunde.webtest
|  |- ...

Die Struktur der Testsammlungen bestimmt nicht die Reihenfolge in welcher die Tests ausgeführt werden.

Keyword-Driven-Testing

Das CURSOR Test-Studio verwendet das Prinzip des Keyword-Driven-Testens. Ein Keyword stellt eine (komplexere) Aktion dar, die im CRM durchgeführt werden kann ("Speichere den Datensatz", "Fülle dieses Nachschlagefeld durch Suchen mit den Kriterien X und Y"). Diese Abstraktion ermöglicht ein schnelles Schreiben der Tests, da auf einer fachlichen Ebene gearbeitet wird, die der Arbeitsweise eines Menschen ähnelt.

Keywords sorgen außerdem für robuste Tests, denn das Keyword zum Speichern des Datensatzes wird immer funktionieren: Sollte der Schalter Speichern aus der Symbolleiste ein anderes Icon erhalten oder sich die Oberfläche des CRMs ändern, funktioniert das Keyword weiterhin und der Test muss nicht angepasst werden.

Vorgehensweise des Test-Studios

Testausführung

Während der Testausführung verhält sich das Test-Studio wie ein Anwender. Dies bedeutet, dass das Test-Studio bedient den Web Client "wie ein Mensch" und befolgt dabei strikte Anweisungen.

Variable Eingaben wie “Wenn Ereignis A eintritt, dann führe als nächstes Anweisung A aus, ansonsten Anweisung B” sind nicht möglich. Das Test-Studio ist immer an einen zuvor definierten Weg ohne mögliche Weichen gebunden. Dies dient der Übersichtlichkeit der Testergebnisse und sichert eine langfristig wartbare Test-Suite. Um mehrere Wege abzubilden sollten auch mehrere Testfälle erstellt werden.

Testfallerstellung

Die Testfallerstellung erfolgt analog der Ausführung in der Anwenderperspektive und kann grundsätzlich ohne Einblicke in die Umsetzung des Customizings erfolgen (Beispiele: technisches Modell von BPM-Prozessen, Implementierung von Skriptbibliotheken und Maskenskript). Für die sogenannten Black-Box-Tests kann bspw. die Anwenderdokumentation eines Prozesses als Grundlage für die Testfallerstellung verwendet werden. Somit können Test-Studio-Tests auch durch Nicht-Entwickler wie bspw. fachlich verantwortliche Personen erstellt werden.

Soll tiefergehende Logik getestet werden, empfiehlt es sich, einen Blick in die Umsetzung des Customizings zu werfen und die dort implementierte Logik bei der Erstellung des Testfalls zu berückichtigen (Beispiele: Standardwerte, berechnete Felder). Diese White-Box-Tests setzen somit eine Zusammenarbeit mit einem Ansprechpartner voraus, welcher das Customizing einsehen und verstehen kann.

Je nach Testverfahren gibt es zahlreiche Punkte, die getestet werden können, bspw.:

• Randfälle prüfen (Leere Eingaben, "kreative" Eingaben)

• Sowohl negative als auch positive Fälle testen (letztere werden beim manuellen Testen meist bevorzugt)

• Verzweigungen und Entscheidungen prüfen.

Dabei ist zu beachten, dass der Test mit dem ersten Fehlerzustand beendet wird. Der nachfolgende Code wird nicht ausgeführt. Zu viele Bedingungen innerhalb des selbsten Testfalls abzudecken kann somit dazu führen, dass einige davon nicht getestet werden.

Testdaten

Der Test ist selbst dafür verantwortlich, seine benötigten Testdaten anzulegen oder zu identifizieren, damit mit diesen Daten gearbeitet werden kann und sie auch hinterher ggf. wieder zu löschen.

Testdaten können auf verschiedene Arten für das Test-Studio bereit gestellt werden. Für Funktionalitäten, die Datensätze nicht verändern, sondern lediglich verwenden, können dedizierte Testdatensätze im zu testenden System angelegt werden. Hierbei ist zu beachten, dass die Tests dann auch nur in Kombination mit den vorhandenen Testdatensätzen fehlerfrei durchlaufen können. Hierbei besteht die Gefahr, dass die Testdatensätze von anderen Anwendern oder Testfällen verändert werden und die Tests dann nicht mehr mit den erwarteten Daten arbeiten und somit irrtümliche Fehlerzustände aufgezeigt werden können. Diese irrtümlichen Fehlerzustände werden durch fehlerhafte Testdaten und nicht durch fehlerhaftes Customizing verursacht.

Eine weitere Möglichkeit bietet die Anlage der Testdatensätze über einen BPM-Prozess. Dieser kann durch das Test-Studio gestartet werden. Datensätze können somit deutlich schneller angelegt werden. Außerdem wird der Testfall dadurch enorm verkleinert, so dass nur noch die Punkte durchlaufen werden, die testrelevant sind. BPM-Prozesse können außerdem verwendet werden um Testdaten zu entfernen oder um sie auf einen definierten Zustand zurück zu setzen.

Selbstverständlich kann auch das Test-Studio zur Anlage von Testdaten verwendet werden. Hierbei ist zu beachten, dass die Testfälle dadurch ggf. stark vergrößert werden und dadurch auch Stellen in den Tests enthalten sind, die nicht das eigentlich zu testenden Custmizing sind. Außerdem wird es hierbei mit großer Wahrscheinlichkeit einige Redundanzen geben. Dies ist die langsamste Variante um Testdaten anzulegen.

Grenzen von Oberflächentests

Von CURSOR bereitgestellte Features werden sehr ausführlich und kontinuierlich getestet. Wird das Test-Studio in einem kundenindividuellen System genutzt, so können diese Standardfunktionalitäten vernachlässigt werden. Die Oberflächentest sollten sich ausschließlich auf die individuellen Umsetzungen (C2) konzentrieren.

Es ist nicht immer sinnvoll, alles über die Oberfläche zu testen. Der Test eines Features kann durch eine andere Testart sinnvoller und schneller sein.

Exkurs Unit-Tests (Skript-Bibliothek)

In der Skript-Bibliothek gibt es die Möglichkeit, Unit-Tests zu einzelnen Methoden zu schreiben. In Ergänzung zu Oberflächentests sind diese eine sehr gute Wahl um Hintergrundaktionen oder Berechnungen zu testen. Sie haben eine sehr geringe Laufzeit (häufig im Millisekundenbereich) und hinterlassen keine Testdaten, da sie mit Transaction Rollback arbeiten. Anwendungsfälle für Unit-Tests sind bspw. komplexere Berechnungen oder Logiken, die gegen ein erwartetes Ergebnis geprüft werden. Mittels Unit-Tests lassen sich keine Oberflächen bedienen. Weitere Informationen können im Artikel Skriptbibliothek nachgelesen werden.