Depends on your definition of testing, anonymized data is widely used by Microsoft and others for monitoring and testing in production, it's the basis for A/B testing or monitoring for example.
In Europe the GDPR does not allow usage of private data, but the GDPR does not apply to anonymised information and anonymised data can be used without consent. ...
I wouldn't say it is common to use real data in testing, although the customer might provide a subset of "real" data in order to facilitate the process.
Apart from the privacy and business issues, there are also the legal ones, e.g. General Data Protection Regulation (GDPR) has been enforced since 25 May 2018 in Europe (but I think every company dealing ...
In some industries it's not feasible to test without customer data. Sometimes it's not possible to properly anonymize said data - I test software that uses the US social security number for a large number of lookups. That means that any method of anonymization must ensure that the social security number of a given person must produce the same ...
There are a few variables here:
Will the tests modify the data? - If they will, you'll need to reload the data as a precondition for each test.
How long does it take to load the data? - If it takes a long time to load the data (and what constitutes a "long time" depends on your situation) you will likely want to reuse the data
Does the data impact other ...
Ideally I would like tests to be independently executable, so that you can repeat a failing testcase without running the whole test-suite. So it should be a precondition for each test to load the dataset, now you could add a unless it was previously loaded clause.
If it is an automated test you could do the same. Check if the data is available, if not load ...
Principles related to the processing of personal data
Personal data shall be obtained only for one or more specified and
lawful purposes, and shall not be further processed in any manner
incompatible with that purpose or those purposes.
So as per data protection law applied, production data can’t be processed for ulterior purposes from when it was ...
There are situations that are almost impossible to fully test without live data of some kind. However, we may not need to use customer data. I have tested with my live credit and debit cards when I needed to do an "End to End" test of a system. There are bugs that show up only in such a test. A small amount used in a test can be written off based on how much ...
Others have mentioned the GDPR, but there are also industry specific rules and constraints.
If you’re dealing with payment data, such as credit cards and cardholder data, the PCI DSS has an explicit prohibition on using actual customer data for testing.
Also, the US government has developed draft guidelines on this exact topic:
DPIAC Privacy ...
I would not recommend using real customer data for testing. On argument was already mentioned: unlawful use of customer data.
Another problem which can arise: leaking confidential business information. Imagine this scenario: due to a bug or misconfiguration, your test system suddenly sends out real email. Real persons now get a newsletter for a new product ...
Reading your question it seems you have a messed up DevOps pipeline. The fix should not be for the testing strategy but the DevOps implementation itself. Few things that needs to be restructured are:
Why are you automatically syncing staging data to Production?
The purpose of staging is to mimic the production environment and make sure things work in ...
As others have highlighted its definitely a very grey area!
Most companies I've worked for do use real customer data (with or without the customers knowledge!). Mainly because sometimes with complex systems, certain issues are unable to be reproduced with test data. On numerous occasions i have found issues we are unable to reproduce without using real ...
You are not done testing unless you have covered the following boundary conditions for every text entry field in your application.
Null (if you are testing an API)
One less than the maximum allowed number of characters
The maximum allowed number of characters
One more than ...
I would suggest:
Create all the users and books you need in-suite setup.
Drive your test through data-driven through CSV or JSON
Delete the configuration in suite-tear down
in CSV put in all the details like:
user,privilege, action, resource, expected output
a sample CSV would be:
user,privileg, action, resource, expected output
test1,admin, delete, v1/...
Am in favor of using the application itself to create any data needed for the (regression) test whether testing the UI or the API. Whenever possible I also like to clean up after the test by removing data created for it. Prefer also to do this through the application if possible but directly in the (test!) database if necessary.
This isn't as scalable ...
What if the datastore changes and the API stays the same? Tests should help developers to refactor safely. This includes changing data storage types, maybe even to flat files or another API for storage. I prefer to use the least implementation details as possible for this reason.
The API the test-fixtures use do not have to be an web-service, but could also ...
If multiple tests can use the same datasets (from your question it seems they can), then I think Case 3 is more efficient, because you will spend less time overall creating the test datasets (not loading, but creating (ie, writing the SQL scripts)). You will create it once and use it for many tests.
It will be a "Pro" (not a "Con") to manage it at project ...
Is it common to use real data of the customer to perform testing?
Yes, in smaller engineering teams this is very common. They just blindly copy production data into a testing environment. In larger corporates hopefully they have pragmatic internal policies to guide this. Certainly if the data is of sensitive personal nature.
What policies companies apply ...
In my opinion ,create separate worksheet for each search fields with all possible values in it and provide hyperlink of those worksheet to all dog categories and even you can reuse those search field worksheet in case of common search fields.