How does your organization customize test data?

I am working as a tester for an organization that has a web service as its essential application. We are currently loading a huge amount of test data through the web interface as it will be done in the real world.

This gives the data an amount of legitimacy and prevents errors in the data format. However, it is very difficult to load data in this way, and I often wonder if loading data directly into the database would be more productive.

Do other people have this solution, which option did you choose? Is there another solution that will give both speed and data legitimacy.

+1


a source to share


4 answers


This comes from a developer perspective, not a tester, so it may or may not apply.

I can't speak for the organization as a whole, but in our project we spent some time creating "real" data that we load into a test database using SQL scripts. This data is a combination of real data from the production environment and data that are designed to represent specific “problem situations” in our product.

The scripts run automatically as part of our software build and are used by automated integration tests based on a unit testing framework. These tests will validate finding, creating, editing, and deleting data through the various interfaces available.



During this build and test, the test database is reset and reloaded with data in some cases. This is done in order to remove dependencies between tests; one test should not rely on data created or modified by another test, or because the data for some tests may differ from the data for other tests. Most tests are performed based on the same test data.

Setting up this test data (and maintaining it) was (and sometimes) a bit of a headache, but it ultimately worked well in our case.

+4


a source


In most cases, the tester prefers to load test data using scripts, so it is not possible to load data [time] using part of the user interface. And for the key point of the tester, each test should be done with only one row data or whole db data. So for better testing, follow how to force scripts to load data. and another pont here, Make script is once an investment to load data for an entire project.



+1


a source


In the end, we decided to move from a system where data is installed through the user interface to a data insertion system. But watch the data to make sure it's the real world. This works well and the tests run much faster.

0


a source


I had the same problem with test data. Our organization has a batch job that populates a database with production like data. I am coordinating with functional testers to get testdata for my loadrunner scripts.

0


a source







All Articles