Best-Practice: Testdatenbeschaffung im Rahmen kontinuierlicher Software-Entwicklung (Teil 2)

Maßgeschneiderte Testfalldaten

für Funktions-, Unit- und Regressionstests

 
In der Regel bedeutet die Weiterentwicklung einer Anwendung, dass unterschiedliche Features oder auch Bug Fixes zu implementieren sind. Meist sind mehrere Entwickler beteiligt. Im Optimalfall erhält jedes Feature eine eigene Umgebung (ABB 1).
 
Diese Umgebung enthält nur die relevanten Daten für den jeweiligen Fall. Es sind nur die Testdaten erforderlich, die für das neue Feature von Interesse sind. Dazu wird man spezifische Testfalldaten zum Beispiel bekannte Verträge, Kunden, Vorgänge o. ä. selektieren.
 
Auch hier gibt es Automation-Tools, die die jeweils abhängigen Daten komplett oder teilweise in die Test-Umgebung überführen. Durch eine Versioning-Option können diese sogar problemlos mehrfach genutzt werden, ohne die Testqualität zu beeinflussen. Dabei wird direkt nach der Bereitstellung der Daten und vor ihrer Nutzung
eine Sicherungskopie erstellt. Mithilfe dieser Sicherung kann die Testumgebung auf Knopfdruck immer wieder hergestellt werden, um einen Test von Neuem unter gleichen Bedingungen durchzuführen.
 
Der Vorteil solcher versionierten Daten: Diese können später auch für die Regressionstests genutzt werden. Für die Regression wird dann eine eigene Umgebung benötigt, in der für jedes Feature ein bis viele Tests regelmäßig laufen. Wir fassen die Testfalldaten hier unter Units zusammen. Die Regressionstests sollten automatisiert durchgeführt werden, beispielsweise über Continuous Integration oder durch Nightly Builts.
 
Die separate Regressionsumgebung für Unit- und Komponententests nimmt also die Daten der Testfälle der Features auf. Über die Anwendungs-Releases bzw. über die Zeit hinweg reichern sich dann Unit-Umgebungen mit einem wachsenden Fundus an wertvollen Tests an.
 
Das Integrieren vom fertigen Feature sollte regelmäßig zum Beispiel wöchentlich oder monatlich geschehen. Danach sollte auch hier wieder eine neue Baseline erstellt werden, zu der nach jeder Testdurchführung zurückgesprungen wird. Wenn das Feature fertiggestellt wurde, kann die Umgebung im Entwicklungsbereich freigegeben werden.

AKTUELLE BEITRÄGE

TDM Lösung – Make or Buy?

Die TOP5 ARGUMENTE – Warum sich die Eigenentwicklung einer Testdatenmanagement-Lösung heute nicht mehr lohnt. TDM ist zu einem komplexen Thema für Experten geworden, die ausgereifte Lösungen auf den Markt bringen

MEHR »

Testdatenbeschaffung – Drei grundlegende Optionen

Im Prozess der Software-Entwicklung müssen immer wieder Tests durchgeführt werden. Dazu werden je nach Entwicklungsphase verschiedene Testdaten – von einzelnen Testfalldaten bis hin zu Massendaten – benötigt. Welche Möglichkeiten gibt es, diese Testdaten zu beschaffen? Im Folgenden werden wir uns drei Optionen anschauen.

MEHR »

Massendaten für System- und Releasetests

Best-Practice: Testdatenbeschaffung im Rahmen kontinuierlicher Software-Entwicklung (TEIL 3/3). Bevor die neuen oder modifizierten Applikationen live gehen, kommen abschließend System-, Abnahme-, Last- oder Performancetests zur Anwendung. Hier braucht es keine feinkörnigen maßgeschneiderten Testfalldaten, sondern produktionsnahe Daten in größeren Mengen.

MEHR »

Maßgeschneiderte Testfalldaten für Funktions-, Komponenten- und Regressionstests

Best-Practice: Testdatenbeschaffung im Rahmen kontinuierlicher Software-Entwicklung (TEIL 2/3). In der Regel bedeutet die Weiterentwicklung einer Anwendung, dass unterschiedliche Features oder auch Bug Fixes zu implementieren sind. Im Optimalfall erhält jedes Feature eine eigene Umgebung. Diese Umgebung enthält nur die relevanten Daten für den jeweiligen Fall.

MEHR »

Grünes Licht für automatisiertes
Testdatenmanagement

Nutzen Sie unsere kostenlose Erstberatung, um schnell und unkompliziert Ihre optimalen und individuellen Optionen zu ermitteln!

Green traffic light