Tag Info

Hot answers tagged

9

In my company, we use a separate test environment where we copy production data daily. This environment is periodically used to detect issues like the ones you have encountered. The vast majority of our testing is carried out with synthesized, non-production data. Some of this is produced by hand, but most is produced by scripts we build. We periodically ...


7

Ideally I would like to write the test based on a file that approximates what my script would be actually processing, rather a much much smaller sample size. If it were me, I would test functional correctness and scale independently. Fault isolation is easier that way. Your code/test/debug cycle can go more quickly too. The thinking here is that ...


7

We consider email and phone numbers as sensitive data. These fall into the category of "Personally Identifiable Information" (PII). We scrub all PII. Check out the Wikipedia definition of PII.


7

Is there a general best practice for this? We already scrub sensitive information when using data in our test environments, but what about scrubbing less sensitive information such as email address or phone number? Most shops have practices for using test data. The specifics differ, but in general you don't want to use Production data which would ...


6

You should absolutely be scrubbing email addresses and phone numbers. They are, as others have said, personally identifiable information, and failure to scrub them is a breach of data security standards. That said, the scrubbing method doesn't have to be terribly difficult - if there has to be something in those fields, set all the email addresses to a ...


4

Here's how I'd approach this situation (the tl;dr version): Analyze your options and give an indication of the risks involved. Your risk analysis should show your preferred option as having the lowest risk (expressed as a relative number, e.g. 1 being the highest risk and 25 the lowest) and state a few of the biggest risk factors for each potential ...


4

The first two issues that come to mind are scalability and tolerance of faulty data. Data Science frequently implies large data sets. As a tester, you need a sense for expectations about data set sizes and the corresponding performance. Those metrics need to be put in the context of the computing environment of course; what you can do on a laptop running ...


4

Welcome to SQA, Rumi P. It sounds like you have a bootstrap problem rather than a chicken-and-egg problem. There is nothing intrinsically wrong with using software under test to create your test data, especially if it lets you write and maintain tests more easily. Of course if you don't implicitly trust your Linq classes, you should test them. One way ...


3

Based on your response to my comment, you're not actually looking to test database operations but an application that employs the operations. That makes things a little simpler. If you have access to the data store - the simplest method you can use is to perform an operation with your application and treat the data store as an oracle for verification ...


3

I found this site that offers a sample of user agents in csv format: http://user-agent-string.info/download Actual download link: http://user-agent-string.info/rpc/get_data.php?uaslist=csv The format is: "Type","Name","useragentstring"


3

I searched Google for "User-Agent strings" and found this and this and this. If you work for a company with a website, you might try asking them for a list.


3

Welcome to SQA. As @user246 says, there's nothing intrinsically wrong with using your application under test to generate your test data - although you probably do want to have tests that validate the data you generate that way. While you technically don't need to have test data reflecting real usage conditions there are times and cases where this is a ...


3

I've done this in many places myself, where we copied over production data because it was so very useful in troubleshooting issues that were only apparent in Customer data and it also provided additional test scenarios and data structures that we did not then need to always recreate. It's extremely useful, and if your Development Team is balking at this you ...


3

I haven't heard of a standardized term for this technique, but it is commonly used. We do this pretty regularly at my current company, but avoided it almost completely when I worked at Microsoft, even though there were a number of cases where it could have greatly improved our ability to troubleshoot issues. At Microsoft, they considered the risk of ...


3

One more online Data Generator: TeDaGen. It supports on-the-fly generated output conversion to many different formats (XML, CSV, SQL, etc.), as well as many fields as options to generate.


3

Some tools for test data generation - online and standalone: Datagenerator - free tool, DB data / tables generation. GenerateData.com - free online script-based data gen, different output formats, including CSV, Excel and SQL. Spawner Data Generator - sample/test data for databases. More links may be found here, but the above 3 I use more often and ...


3

Test data generators are especially useful when the data format is likely to change. Here is a common problem I've encountered with test data: it isn't always clear which parts of the data are intentional and which are optional. For example, suppose you want to test a CSV file of names and addresses, where each record contains a first name, last name, ...


2

At my current company, we are a small team. We have designated a shared folder on the file system where we place these types of test assets. And we each maintain them on an as-needed basis. This approach works well enough for us. At other companies where I have worked, I had a larger team. In some of those cases, one of the roles was that of a "Test Lab ...


2

It really depends on the type of company you are, or the products you are testing. It also goes to your testing approach. Are you basing your tests on the data available, or are you creating data required by your tests. IMHO, the most effective way is to get a copy of production data, and perform analysis on it. De-duplicate the data. Perform "equivalence ...


2

Honestly, the only limit is your imagination. You'll find out pretty quickly if the programmers took the permissive approach (allow everything except...) or the repressive approach (prevent everything except...) Some examples you can use: Copy/Paste the entire text of Hamlet (thanks to QA Hates You for this one (you'll have to google for it - I don't have ...


2

One alternative I have seen is to have the company set up a "test" environment within their domain, then give specific personnel within your company access to it. That setup provides two benefits: it provides a pre-deployment test environment to evaluate new versions directly against production data in a protected environment and also provides a platform to ...


2

Data security and privacy standards vary from country to country around what can and cannot be stored, and are generally only guidelines not legislation. That said, if your management are saying that data needs to be scrubbed, then it needs to be scrubbed regardless what the technical team thinks. There are other ways to look after data that do not require ...


2

Best Practice I always find as a loaded term. While there are industry-wide practices some of those may be lenient in any particular space or be far more strict, especially in places where there is a lot of Personally Identifiable Information (PII) or financial information. Much of that PII has to be very well protected, or you can encounter situations ...


2

I searched google and found another which is pretty GOOD. You can find them here and here.


2

It's hard to provide input on your specific processes, but here's how I generally deal with Selenium automation. Maybe it can help you out. One separate database which contains all the data for the tests: data-driven testing. This means you'll likely have to compose Views (combining tables as necessary) which serve as the datasource for test methods. ...


2

This is a really interesting question. I don't think we're entirely happy with our approach, and we discuss it regularly, but these are our constraints and what we've done so far (framework has been in use for about 3 years). 1) We reload a skeleton database at the start of each test run. This has a minimal set of data, as little as possible - a user, ...


1

In Technical Perspective Working code is better than anything. You can have a working solution and re-factor it going forward Do you have any solution options ? What Challenges do you have implementing it? Solution perspective Options Operations would be CRUD (Create, Read, Update Delete). For each one you need to have the previous state setup and ...


1

People have already covered the privacy side of this issue. Couldn't have said it better than Kate. What concerns me is the risk of another embarrassing round of notifications greatly outweighs... whatever benefit there is to not scrubbing (which is unclear). What is the reason some team members want to leave the data as-is? You clearly have email ...


1

Some tests are better run via a test API as they can then test sections of code that may be unreachable or very hard to reach but a test API does not test the database interface so you also need to test with SQL. The most important thing to remember is Never, Ever, run untested code on a live database - you could potentially do an immense amount of damage ...


1

There are many, many approaches, each having its pros and cons when it comes to simplicity of reading, easiness of modifying data, easiness of modifying data schema (refactoring), easiness of parsing data, type of data you want to model. If you were I would experiment. I would pickup the simplest approach (properties) to see if fits your problem. Here's the ...



Only top voted, non community-wiki answers of a minimum length are eligible