Managing test data voor SAAS en Cloud

Veel organisaties onderzoeken de eindeloze mogelijkheden van cloud computing. Voor bijna elke letter van het alfabet lijkt er een “as a Service” variant beschikbaar te zijn! Van opslag, hardware, databases, netwerken tot software, bijna alles kan worden gekocht van platforms zoals Microsoft Azure en Amazon AWS. Binnen enkele minuten kun je nieuwe snelle en grote virtuele machines laten draaien en nog sneller vernietigen, maar hoe maak je dit betaalbaar? Voordat we daarop ingaan, laten we eerst de terminologie doornemen.

Werken in de cloud is soms wat anders dan on-premise oplossingen. Bij testdatabeheer is de reden voor deze verschillen dat je altijd verbinding kunt maken met on-premise databases, maar met ‘de cloud’ is dat niet altijd het geval.

In het algemeen onderscheiden we twee verschillende soorten ‘cloud’:

 

  1. Een database in de cloud
  2. SAAS, cloud of gehoste applicaties

Databases in de cloud

Als het alleen een database is die in de cloud is geïmplementeerd, kunnen de testgegevens worden beheerd door DATPROF. We ondersteunen momenteel MySQL, SQL, Oracle, Postgress, MariaDB, EDB, DB2 navitely en we ondersteunen AzureSQL en Aurora. Deze databases kunnen worden beheerd door de DATPROF toolset. Het belangrijkste verschil tussen cloud- en lokale databases is dat de verbindingsreeks anders is.

DATPROF Supported cloud databases

SAAS, Cloud of gehoste applicaties

Interessanter wordt het als je denkt aan applicaties in de cloud of een SAAS applicatie. Vanuit het perspectief van testdatabeheer zien we twee verschillende strategieën van gehoste/SAAS-applicaties:

  • Sommige applicaties zijn beschikbaar in de cloud en je kunt nog steeds verbinding maken met de database onder de applicatie

of

  • De applicatie is beschikbaar in de cloud, maar u kunt geen verbinding maken met de database (bijvoorbeeld Salesforce)

 

Beide voorbeelden van toepassingen worden door softwareleveranciers als SAAS-toepassingen genoemd. We maken onderscheid tussen deze twee voorbeelden. Want als u verbinding kunt maken met de database, kan DATPROF uw testgegevens beheren. In dit geval is er vanuit ons perspectief niet veel verschil tussen een database in de cloud of een applicatie in de cloud.

Het tweede voorbeeld over Cloud- of SAAS-applicaties is uitdagender. De reden is dat onze voorkeursaanpak is om rechtstreeks verbinding te maken met databases om de testgegevens te beheren. Bij deze leveranciers mag dit niet. Maar er zijn enkele alternatieve routes. Wat we kunnen doen is de gegevens extraheren naar een andere database, testgegevensprocessen uitvoeren (subsetting en/of maskering) en de gegevens terug in de database injecteren. Met dit proces is het ook mogelijk om uw testgegevens ook in deze omgevingen te beheren.

Het migreren van grote organisaties met on-premise systemen naar de cloud kan best lastig zijn. Zelfs het onderzoeken van de verschillende prijsopties van de verschillende instantietypes is niet eenvoudig. Heeft u een D2sV3 of E2sV3 nodig en hoe verhoudt deze zich tot een r5d.large? Alleen al in Azure zijn meer dan 200 verschillende instantieconfiguraties beschikbaar. In het algemeen is de prijs afhankelijk van het aantal CPU-cores, het geheugen en de maximale schijfcapaciteit. Opslagkosten zijn meestal afhankelijk van de grootte, het type (SSD of HDD) en de replicatie-opties die u selecteert.

Wanneer u overstapt naar AWS of Azure, gaan niet alleen uw productiegegevens naar de cloud, maar ook uw test- en ontwikkelomgevingen. De meeste organisaties die naar de cloud migreren, gebruiken al Agile/DevOps-methodologieën. Deze ‘nieuwe’ manier van werken vraagt ​​om een ​​andere manier van omgaan met testdata. Elk team moet zijn eigen testgegevens hebben en mag niet afhankelijk zijn van andere teams die dezelfde testgegevens gebruiken. De cloud kan zoveel omgevingen beschikbaar maken als u nodig heeft, maar zelfs in de cloud zijn deze kopieën van productie-instances extreem kostbaar. Misschien hebt u geen dure rampen- of replicatiefuncties nodig, maar de algehele configuratie moet waarschijnlijk zo goed mogelijk overeenkomen met de productiespecificatie.

De juiste hoeveelheid test data

Gelukkig behoort het werken met testgegevens op ware grootte tot het verleden. Tegenwoordig kunnen we specifieke subsets, zelfs geanonimiseerd, extraheren uit grote complexe productiedatabases voor testen, ontwikkeling en training.

Het echte voordeel van het werken met compacte, kwalitatief goede en veilige testdata is dat je echt het volledige potentieel van de cloud kunt ontsluiten. Door met de juiste hoeveelheid testgegevens te werken, kunt u gemakkelijk duizenden dollars besparen, omdat uw ontwikkel- en testinstanties minder CPU-kracht, minder geheugen en minder opslagruimte nodig hebben. Uw Dev- en QA-teams worden efficiënter door hun eigen testgegevens te beheren en kunnen meer testen in minder tijd. Dit leidt tot software van betere kwaliteit die sneller kan worden vrijgegeven voor het uiteindelijke voordeel van het bedrijf.

Data subsetting

Test data subsetting is extracting a smaller sized – referential integer set of data from a ‘production’ database to a non-production environment.

Meer weten?

Neem gerust contact op!

  • Hidden
  • Dit veld is bedoeld voor validatiedoeleinden en moet niet worden gewijzigd.

Data Masking

DATPROF Privacy

Data Automation

DATPROF Runtime

Data Discovery

DATPROF Analyze