No doubt, it is an unfortunate situation when at the beginning of the working day you realize that some tests either failed or are running improperly. To make matters worse, you try to explain to your management that the test failed because of some programmer who has changed test data.

The major problem of test data is a constant source of additional tasks for QA engineers. So it doesn’t matter if you perform manual or automated testing – when your tests fail, you will definitely spend some time figuring out what’s wrong with the final test results.

Further, in the article, we will look at the most common problems that can arise while interacting with random test data.

1. Users Can Copy Each Other’s Information

Let’s look at an example. Imagine that we have API 1. It was developed for user automated tests based on test (virtual) user.

API 1 went to another testing team. We started working on API 2 and created autotests for it as well. Unfortunately, API 2 had the same user and email as API 1. In other words, whenever tests for API 1 are running, the test user’s email will change and all the tests for API 2 will fail.

2. Another Team Has Changed Configurations

If two or more QA teams edit the same test environment, the changes of one group can affect the activities of another one. It is common during interaction with feature flags. One group of testers works with functionality for enabled feature flag, while another one waits for it to be disabled.

3. Damage to Information

Sometimes it happens that in a moment valid information may become completely inadequate for further processing. A bright example of it is a date in a simple calendar. If your autotest needs a future date, you can choose the one that will come in a few years. But someday this date, that you have chosen will become a past and, unfortunately, the test will fail.

What Strategy Will Help to Prevent This?

Use Docker

Only the use of a certain virtual environment gives users control over a particular test environment which includes software and database configuration. To start the tests, you just have to launch a virtual machine and run tests. And when all the necessary checks are completed, stop the machine.

Create a New Version of a Database for Tests

If there is a need, you can create original versions of DB for running automated tests. For example, in Windows, this can be accomplished by creating SQL DACPAC. A user can independently configure a scheme of a personal DB, adding only the actual test data, create a base with all his/her tests, delete the DB when all the tests have been performed.

Each Project Team Should Have Its Test Environment

Even if several test groups have to use the same test environment or account in a test program, they should have different user test suites. In this case, they definitely won’t be able to copy each other’s data by accident. Just use such names that are easy to remember and hard to miss.

Create Original Data With Every Step of a Test Run

A good way to manage your entire test environment is to develop test information just before starting the test run. For example, a test requires a customer. A developer creates the customer, uses it to conduct tests, and then deletes it. With this approach, all information will be in the form that you need, and unnecessary data will not overfill your database.

Try Using “+1” for All Dates in the Future

Instead of putting an X date in the future, it is better to take today’s date and use the DateAdd function to be able to add a range from a month to a day. In such a situation, the date will always be in future time.

In the end, it’s worth noting that working with test data can be extremely difficult and tedious. But if you enlist effective planning and strategic approaches, then everything can be organized so that the information is always correct throughout the execution of all tests.