Continuous test data

Het is belangrijk om snel wijzigingen in je applicaties aan te pakken. Dit is een van de redenen waarom organisaties de agile ideologie hebben aangenomen. Een van de belangrijke onderdelen in deze hele (agile) cyclus is het gebruik van veel kleinere feedbackloops ten gunste van één grote feedbacklus. Om een dergelijk proces te creëren, gebruiken organisaties wat we nu kennen als CI/CD: continuous integration en continuous delivery (of deployment). Dit betekent dat de testprocessen eerder en vaker in de ontwikkelcycli moeten plaatsvinden en daarom noemen we het Continuous Testing.

Zo is Continuous Testing ontstaan, maar wat is Continuous Testing en hoe spelen test data een rol in het proces?

Wat is Continuous Testing?

“Continu testen wordt gedefinieerd als een type softwaretest dat een proces omvat van vroeg testen, vaak testen, overal testen en automatiseren. Het is een strategie om kwaliteit te evalueren bij elke stap van het continue leveringsproces. Het doel van Continuous Testing is vroeg testen en vaak testen. Bij het proces zijn belanghebbenden betrokken zoals Developer, DevOps, QA en Operationeel systeem” Bron: Guru99.

Wat heb je nodig voor continuous testing?

Allereerst is continu testen niet noodzakelijk hetzelfde als testautomatisering. Test automatisering is een voorwaarde voor Continuous Testing en maakt deel uit van iets groters. In hetzelfde artikel worden de verschillen vermeld:

Definitie van Test Automation: Test automatisering is een proces waarbij een tool of software wordt gebruikt voor het automatiseren van taken.

Definitie van Continuous Testing: Het is een softwaretestmethodologie die zich richt op het bereiken van continue kwaliteit en verbetering.

Om continuous testing te bereiken, is testautomatisering het eerste wat je nodig hebt. Volgens hetzelfde artikel is beste manier:

1. Tools gebruiken om testautomatiseringssuite te genereren op basis van gebruikersverhalen / vereisten;
2. Maak een testomgeving;
3. Kopieer en anonimiseer productiegegevens om een test data set te maken;
4. Gebruik servicevirtualisatie om API te testen;
5. Parallelle performance tests.

Opvallend in deze lijst is de stelling dat je productiedata moet kopiëren en anonimiseren om een test data set te maken. Stel jezelf de vraag: is een volledige kopie van productie nodig? Het zou niet nodig moeten zijn. Als je een of meerdere kleine updates van je applicatie hebt ontvangen, wil je deze continu testen, bij voorkeur aan de hand van een set testgegevens die door de update(s) worden beïnvloed. Dus heb je echt zoveel test data nodig? Maar wat is de impact op Continuous Testing als je een (geanonimiseerde) volledige kopie van de productiegegevens hebt? Laten we beginnen met dit laatste punt.

The impact van een volledige kopie

De impact van het hebben van een volledige kopie van geanonimiseerde productiegegevens op Continuous Testing is niet anders, of tests nu geautomatiseerd of handmatig worden uitgevoerd. Het is een discussie over representativiteit en snelheid. De belangrijkste overweging is: hoe kun je je test data anonimiseren op een geloofwaardige, bruikbare manier en hoe snel kun je deze beschikbaar stellen?Het maskeren van een database kost tijd en draagt daarom bij aan de implementatiecyclus van testgegevens. Iedereen die iets anders zegt, heeft de klus nooit eerder hoeven te doen of ze maken een belangrijk onderdeel van het proces onbelangrijk. In plaats van het van productie naar test te kopiëren, heb je een proces van kopiëren, maskeren en vervolgens implementeren.

Met de komst van gegevensbeschermingswetgeving over de hele wereld, is het maskeren van een database nu een verplicht aspect van implementatie in de lagere omgevingen. De tijd die nodig is om de gemaskeerde database te implementeren, vormt de basis van de beslissing over de vernieuwingsfrequentie. Sommige organisaties kunnen mogelijk dagelijks vernieuwen, andere minder vaak.

Een overweging bij het vernieuwen van de gemaskeerde database is die van de consistentie van de gemaskeerde resultaten. Je wilt geen verschillende gemaskeerde resultaten op verschillende dagen, dus je moet ervoor zorgen dat de door jou gekozen maskeerprocessen een consistente maskeringstechniek gebruiken. Als je dit niet doet, zul je de gebruikers uit de lagere omgeving in verwarring brengen als ze de ene dag “Mary Jones” zien en de volgende dag “Jane Doe”.

Zodra de eerste gemaskeerde database is geïmplementeerd, kan deze fungeren als bron voor volgende kopieën binnen de lagere omgevingen. Het wordt in feite de “Test Data Master” van schaal – volledige productiegrootte.

Maar waarom zou je meerdere kopieën maken van de volledige database? Sommigen beweren dat volledige grootte nodig is voor volumetests, meestal het testen van queries om ze te optimaliseren – meestal zijn ze het BI-team. Anderen zouden zeggen dat de volledige database niet vereist is omdat de huidige sprint gericht is op een bepaald aspect van de applicatie of een beperkte vereiste voor gegevensinhoud heeft.

Het maken van extra kopieën op ware grootte brengt kosten met zich mee. Ten eerste is het de tijd die nodig is om te kopiëren en te herstellen, ten tweede is het de omvang en de kosten van de benodigde ruimte voor elk exemplaar. On-prem databases worden vaak nauw gecontroleerd, aangezien het tijd kost om schijfresources te verkrijgen en toe te voegen. In de cloud is het zomaar ineens daar en de enige persoon die het weet, is de persoon die de rekening aan het einde van de maand betaalt. Een persoon die misschien niet van verrassingen houdt…

Dit is de kern van de Continuous Testing-discussie over het gebruik van subsets van de database of databasevirtualisatie.

Lees ook: Test Data Management

Test data in Continuous Testing

Het gebruik van een volledige kopie met geanonimiseerde productiegegevens, of alleen synthetische test data, past mogelijk niet in de implementatietijdlijnen die nodig zijn voor een continue testmethode. Je hebt iets nodig dat resulteert in representatieve test data die gemakkelijk beschikbaar en herhaalbaar zijn.

Een andere impact van een grote database is dat het geruime tijd zal duren voordat je de juiste test data voor je testcase ontdekt en vindt en dat je het waarschijnlijk de eerste keer niet direct goed zult krijgen. Als alternatief zou je ervoor kunnen kiezen om specifieke testgevallen te genereren, maar dan heb je de representativiteitsdiscussie. Alle databases hebben hun anomalieën en het genereren van testcases heeft de neiging om deze anomalieën uit de testcase te halen. Je schoont de gegevens vanaf het begin effectief op.

Doorgaans heeft elke sprint zijn eigen focus en het begin van een sprint bepaalt ook de vereiste test data. Het antwoord op de vraag “Wat hebben we nodig?” is de basis voor de selectiecriteria voor subsetgegevens voor die sprint. Aangezien elke sprint waarschijnlijk verschillende focussen zal hebben, volgt hieruit dat de subsets anders kunnen en zullen zijn. Het voordeel is dat elke sprint uniek kan worden onderhouden en dat de selectie van testgegevens volledig geschikt is voor hun behoeften.

De impact van een subset

Kleinere databases verminderen de testtijd door hun aard. Kleinere databases lenen zich voor snelle vernieuwingen. Kleinere databases kunnen gemakkelijk worden aangepast aan veranderende vereisten voor testgegevens.

Door kleinere databases te maken op basis van de consistent gemaskeerde Test Data Master, kun je dezelfde test herhaaldelijk of zelfs incrementeel uitvoeren met exact dezelfde testgegevens. Het extra voordeel van de volledige Test Data Master is dat deze kan worden gebruikt door die teams die de volume-ervaring nodig hebben zonder anderen te beïnvloeden.

Deze benadering leent zich voor de onmiddellijke feedbackloops die inherent zijn aan de CI / CD-stroom. Vroeg testen en vaak testen, impliceert van nature de noodzaak om periodiek te herstellen naar een bekend beginpunt. Zowel subsetting als virtualisatie bereiken dit doel.

Er is een extra overweging bij het vergelijken van subsetting met virtualisatie. Elk proces dat wordt bijgewerkt, ingevoegd of verwijderd in een gevirtualiseerde omgeving, zal onmiddellijk de benodigde ruimte voor het virtuele “diff” -bestand vergroten. Met een subset blijven de ruimtegrenzen (met de voor de hand liggende uitzondering van inserts) constant. Het is waar dat subsets in het begin een iets grotere voetafdruk kunnen hebben, maar het verschil met virtualisatie wordt in de loop van de tijd kleiner.

Een ander belangrijk voordeel van het gebruik van subsets ten opzichte van virtualisatie is dat de Test Data Master en de subsets verschillende entiteiten zijn. Het een kan bestaan zonder het ander. Dit is niet het geval bij databasevirtualisatie, aangezien de gevirtualiseerde images (in feite diff-bestanden) direct en volledig afhankelijk zijn van de beschikbare masterimage. Ze kunnen eenvoudigweg niet bestaan zonder. Als de masterimage niet beschikbaar is, zal elke gebruiker of elk team dat ermee verbonden is een serviceonderbreking ervaren. Het behoeft geen betoog dat dit directe kosten voor het bedrijf heeft.

Het scheiden van de test data master en subsets betekent ook dat verversingen vanuit productie sneller kunnen worden uitgevoerd, aangezien de teams aan de subsets kunnen werken terwijl de master zich in de verversingsmodus bevindt. Terwijl dat gebeurt, kunnen de BI-teams ook altijd een subset gebruiken.

Test data automation & Continuous Testing – Een samenvatting

Eenmaal vastgesteld, verbetert en versnelt Continuous Testing het tempo van uw CI/CD-pijplijn. Het betekent dat Dev-, Test- en QA-engineers zich kunnen concentreren op het tijdig uitvoeren van de juiste tests op de juiste data.

Het maken van gemaskeerde test data masters en de bijbehorende subsets kan worden vergemakkelijkt en geautomatiseerd met behulp van DATPROF’s Test Data Management suite.