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.

CURRENT POSTS

TDM Solution – Make or Buy?

The TOP5 ARGUMENTS why developing your own test data management solution is no longer profitable today. TDM has become a complex issue. For this reason, there are experts today who offer mature TDM solutions to the market

Read more »

Test data procurement – Three basic options

In the process of software development, tests need to be performed repeatedly. Depending on the stage of development, various test data, from individual test case data to bulk data, is required. There are three basic options for obtaining this test data: The manual creation of test data, the creation of synthetic test data and the conversion of productive data into test data

Read more »

Bulk data for system and release tests

Best-Practice: Test data procurement in the context of continuous software development (PART 3/3). Before the new or modified applications go live, system, release, load or performance tests are applied. For this purpose, no fine-grained customized test case data is needed, but production-related data in larger quantities is required. These tests are

Read more »

Customized test case data for functional, component and regression testing

Best-Practice: Test data procurement in the context of continuous software development (PART 2/3). The further development of an application usually means that different features or even bug fixes need to be implemented. Ideally, each feature gets its own environment. This environment contains only the relevant data for that particular case.

Read more »

Green light for automated
Test Data Management

Take advantage of our free initial consultation to quickly and easily determine your optimal and individual options!

Green traffic light