Addressing changes to your applications quickly is important. This is one of the reasons why organizations adopted the agile ideology. One of the important parts in this whole (agile) cycle is the use of many smaller feedback loops in favour of one major feedback loop. To create such a process, organisations are adopting what we now know as CI/CD – Continuous Integration and Continuous Delivery (or Deployment). This means that the testing processes must happen earlier and more frequently in the development cycles and so we call it Continuous Testing..

That’s how Continuous Testing has evolved, but what is Continuous Testing and how does test data play a part in the process?

What is Continuous Testing?

“Continuous Testing is defined as a software testing type that involves a process of testing early, testing often, test everywhere, and automate. It is a strategy of evaluating quality at every step of the Continuous Delivery Process. The goal of Continuous Testing is test early and test often. The process involves stakeholders like Developer, DevOps, QA and Operational system” Source: Guru99.

What do you need for continuous testing?

First of all Continuous Testing is not necessarily the same as test automation. Test automation is a prerequisite for Continuous Testing and is part of something bigger. In the same article the differences are noted:

Definition of Test Automation:

Test automation is a process where a tool or software is used for automating tasks.

Definition of Continuous Testing:

It is a software testing methodology which focuses on achieving continuous quality & improvement.

To achieve Continuous Testing the first thing you’ll need is test automation. According to the same article the way to go is:

1. Using tools to generate test automation suite from user stories/requirements

2. Create a test environment

3. Copy and anonymize production data to create test data set

4. Use service virtualization to test API

5. Parallel performance testing

What’s striking in this list is the statement that you need to copy and anonymize production data to create a test data set. Ask yourself: Is a full-size copy of production needed? It shouldn’t be necessary. If you’ve got one or multiple small updates of your application you want to test it continuously, preferably against a set of test data that is affected by the update(s). So do you really need that much test data? But what is the impact on Continuous Testing if you have an (anonymized) full sized copy of the production data? Let’s start with this last point.

The impact of a full copy

The impact of having a full copy of anonymized production data on Continuous Testing is no different whether tests are automated or performed manually. It’s a discussion about representativeness and speed. The key consideration is how can you anonymize your test data in a credible, usable manner and how quickly can you make it available? Masking a database will take time and therefore adds to the test data deployment cycle. Anyone who says otherwise has never had to do the job before or they’re making light of an important part of the process. Instead of copying it from production to test, you’ll have a process of copying, masking and then deploying it.

With the advent of data protection legislation across the globe, masking a database is now a mandatory aspect of deploying to the lower environments. The time taken to deploy the masked database is the foundation of the decision on the refresh frequency. Some organization may be able to refresh daily, others less frequently.

One consideration of masked database refreshes is that of the consistency of the masked results. You do not want different masked results on different days so you should ensure that your chosen masking processes will use a consistent masking technique. If you don’t do this you will thoroughly confuse the lower environment users who, one day, are looking at “Mary Jones” and on the following day she becomes  “Jane Doe”.

Once the first masked database is deployed it can act as a source for subsequent copies within the lower environments. It effectively becomes the “Test Data Master” of scale – full production size.

But why make multiple copies of the full scale database? Some would argue that full size is needed for volume testing, typically testing queries with a view to optimizing them – they’re usually the BI team. Others would say that the full database isn’t required because the current sprint is focused upon a particular aspect of the application or has a limited data content requirement.

Making additional full scale copies has a cost. First, it’s the time taken to copy and restore, second it’s the size and cost of the space required for each copy. On-prem databases are often closely controlled since it takes time to acquire and add disk resource. In the Cloud it’s magically there and the only person that knows is the person paying the bill at the end of the month. A person who may well not like surprises…

This is the core of the Continuous Testing discussion about using subsets of the database or database virtualization.

Also read: Test Data Management

Test data in Continuous Testing

Using a full-sized copy with anonymized production data, or only synthetic test data, may not fit the deployment timelines necessary for a Continuous Testing methodology. You’ll need something which results in having representative test data that’s easily available and repeatable.

Another impact of a large database is that it will take quite some time before you discover and find the right test data for your test case and you’ll probably not get it right the first time. As an alternative you could choose to generate specific test cases, but then you have the representativeness discussion. All databases have their anomalies and generating test cases tends to instrument these anomalies out of the test case. You’re effectively cleaning the data from the outset.

Typically each sprint will have its own focus and the inception of a sprint will also define the test data requirement. The answer to the question “What do we need?” is the foundation for the subset data selection criteria for that sprint. Given that each sprint will likely have different focuses, it follows that the subsets can and will be different. The benefit is that each sprint can be serviced uniquely and their test data selection is entirely appropriate for their needs.

The impact of a subset

Smaller databases reduce testing time by their very nature. Smaller databases lend themselves to fast refreshes. Smaller databases are easily adapted to evolving test data requirements.

Creating smaller databases from the consistently masked Test Data Master means you’re able to execute the same test with exactly the same test data repetitively or even incrementally. The added benefit of the full scale Test Data Master is that it can be used by those teams which need the volume experience without impacting others.

This approach lends itself to the immediate feedback loops inherent in the CI/CD stream. Test early and test often, by its nature, implies the need to periodically recover to a known start point. Both subsetting and virtualization achieve this objective.

Another key benefit of using subsets over virtualization is that the Test Data Master and the subsets are distinct entities. One can exist without the other. This is not the case with database virtualization since the virtualized images (effectively diff files) are directly and completely dependent upon the master image being available. They simply cannot exist without it. Should the master image become unavailable every user, or team, connected to it will experience a service interruption. It goes without saying that this has a direct cost to the business.

Separating the Test Data Master and subsets also means that refreshes from Production can be done in a more timely manner since the teams can work on the subsets while the master is in refresh mode. While that’s happening the BI teams can always use a subset, too.

Conclusion

Once established, Continuous Testing improves and accelerates the pace of your CI/CD pipeline. It means that Dev, Test and QA engineers can focus on executing the right tests on the right data in a timely manner.

Creating masked Test Data Masters and their associated subsets can be facilitated and automated using DATPROF’s Test Data Management suite.

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.

Of bekijk demo

Of bekijk demo