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

Massendaten für System- und Releasetests

 
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. Diese Tests werden in der Regel von einer separaten Testgruppe oder der QS Abteilung in eigenen Umgebungen durchgeführt.
 
Diese Umgebungen müssen in regelmäßigen Abständen mit aktuellen Produktionsdaten versorgt werden. Entweder monatlich oder sogar wöchentlich, je nachdem, in welchem Stadium sich der Entwicklungszyklus befindet. Generell werden gegen Ende einer Entwicklung öfter frische Daten benötigt als zu Beginn. Aus Performance- und Kostengründen werden diese Datenerneuerungen – mittels Tabellenkopie – auf Tabellenebene durchgeführt.
 
Die kopierten Tabellen haben jedoch die Datenstruktur der aktuell produktiven Version. Also müssen sie an die teils geänderten Strukturen der neunen – im Test befindlichen – Tabellen angepasst werden, z. B. durch zusätzliche Spalten oder
geänderte Datentypen.
 
Diese Strukturänderungen sollten zentral dokumentiert sein und am besten durch ein Umstellungsskript erledigt werden. Dieses Skript ist in zweifacher Hinsicht nützlich. Erstens automatisiert es die Testdatenbereitstellung, d. h. bei jeder weiteren Datenerneuerung bringt es die Daten automatisch in die richtige Form. Und zweitens wird es bei der Indienststellung – Go-Live – der neuen Version ohnehin gebraucht. Umso besser, wenn es schon benutzt und damit getestet wurde.
 
Um nun eine noch breitere Abdeckung der Massentests zu erhalten, können die Daten der spezifischen Unit- bzw. Komponententests mit den Daten aus der Produktion gemischt werden. Nun sollte – wie auch in anderen Umgebungen zuvor – eine Baseline erstellt werden. Diese dient wieder als Referenzbestand, um nach der Durchführung unserer Regressionstest den Ausgangsbestand wiederherzustellen.
 
Fazit:
Die bisher gezeigten Ansätze erlauben umfangreiche Tests während des kompletten Entwicklungszyklus. Dabei spielt das verwendete Entwicklungsmodell nur eine zweitrangige Rolle. Ob nach dem klassischen Wasserfallmodell, dem V-Modell oder auch mit agilen Methoden wie Scrum oder Prototyping gearbeitet wird…
 
Es stehen in jeder Entwicklungsphase geeignete Testdaten zur Verfügung. Testumgebungen sind sachlich getrennt Funktionstest und Regression sind verzahnt. Eine häufig genug erneuerte Vor-Produktion ermöglicht nicht nur das Testen der Versions-Änderung – des Upgrades also –, sondern entkoppelt auch Produktion und Entwicklung bzw. Test.
 
Mit der UBS Hainer TDM Suite können alle hier angesprochenen Prozesse an die aktuellen Bedürfnisse angepasst und automatisiert werden. Wir beraten Sie gern anhand Ihrer konkreten Anforderungen.

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