In vielen Entwicklungsteams zeigt sich ein bekanntes Muster: Ein Pull Request ist sauber reviewed, die automatisierten Tests laufen durch und kurz nach dem Release treten in der Produktion dennoch Probleme auf. Besonders häufig passiert das in Systemen, deren Datenmodelle über Jahre
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.
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.
Best-Practice: Testdatenbeschaffung im Rahmen kontinuierlicher Software-Entwicklung (TEIL 1/3). Durch die massive Zunahme datengestützter (Data-Enhanced Business Model) oder auch datengetriebener (Pure Data-Driven Business Model) Geschäftsmodelle
Mithilfe des Testdaten-Finders in der UBS Hainer TDM Suite wird es jetzt für Tester und Entwickler noch einfacher, schnell und individuell spezifische Testfalldaten zusammenstellen.
Viele Unternehmen – darunter die großen Versicherungen und Banken – arbeiten seit Jahrzehnten mit Mainframe-Lösungen. Immer häufiger stellt sich die Frage, wie sich
Im Rahmen eines Proof of Concept (PoC) werden Softwarelösungen vor dem Kauf praxisrelevant und kostengünstig in einem Testlauf ausprobiert. Für diesen PoC
