Es gibt beim Testen grundsätzlich drei verschiedene infrastrukturelle Ansätze beim Testen:

1. Keine Testinfrastruktur, sog. Ad Hoc Testing
2. Nutzung einer speziellen Testumgebung, die optimiert wird für das Testen einer spezifischer Domäne
3. Nutzung einer allgemeinen Testumgebung (Kaufsoftware oder Eigenentwicklung)

Die RapidRep Test Suite kann in allen drei Testansätzen eingesetzt werden!

Bei dieser Form des Testens steht die spontane Ausführung und Auswertung von wenigen Testfällen im Vordergrund. Auf die Testplanung und Teststeuerung wird bei dieser Form weniger Wert gelegt.

RapidRep unterstützt diese Vorgehensweise sehr effizient, da mit dem RapidRep Test Runner eine komfortable Testoberfläche angeboten wird, mit der Testfälle schnell und einfach angelegt und wiederholt durchgeführt werden können. Die benutzerdefinierten Sichten garantieren eine übersichtliche Darstellung aller Testaktivitäten.

Spezielle und allgemeine Testumgebungen werden genutzt um Testfälle mit Anforderungen zu verknüpfen und anschließend in Testplänen zu organisieren. Auftretende Abweichungen von den Sollergebnissen werden als Defekte gesondert abgelegt.

Bei dieser Form des Testens liegt der Schwerpunkt auf der effizienten Organisation des gesamten Testprozesses.  Spezielle Reports stellen den Testfortschritt dar und geben Aufschluss über den aktuellen Abdeckungsgrad bzw. Erfüllungsgrad der zu testenden Objekte.

Die RapidRep Test Suite bietet spezielle Konnektoren zu den gängigen Testmanagement - und Defektmanagementsystemen. Selbst eigens Systeme für die Verwaltung von Testfällen und Defekten werden von RapidRep unterstützt, sofern diese bestimmte Mindestanforderungen erfüllen.

Im linken Teil der Abbildung werden die insbesondere in Großprojekten häufig eingesetzten Komponenten für das Testmanagement dargestellt. Als erstes werden die zu testenden Anforderungen erfasst und einem Testplan zugeordnet.

In einem Testplan wird festgelegt, welche Testfälle zum vollständigen Testen einer Anforderung benötigt werden. Die Testfälle werden dann über das Anstossen eines Skriptes zur Ausführung gebracht. Das Testfallergebnis (erfolgreich / nicht erfolgreich) wird als Status an den Testplan übermittelt. Für den Fall, dass berechnetes und erwartetes Ergebnis nicht übereinstimmen, wird der Defektmanager mit zusätzlichen Details versorgt, damit Business Analysten und Entwickler die Fehlerursache ermitteln und beheben können.

Der rechte Teil der Abbildung illustriert den wichtigsten und gleichzeitig schwierigsten Schritt im Testzyklus, die eigentliche Testdurchführung. Hier wird verglichen, ob beispielweise die berechneten Ergebnisse mit den erwarteten Ergebnissen übereinstimmen oder ob eine Migration verlustfrei durchgeführt wurde oder nicht.

mehr