27 MAY, 2015 – MARCO DEN HAAN
Fortunately, we no longer have to discuss the need for testing. Almost every organization is convinced you first have to test any new product to find out if they live up to their expectations instead of ruining the name of the company as a result of weird errors popping up. And hiring test professionals helps. For that reason, test drivers do an endless amount of laps driving around new concept cars. And in the same way software testers are trying out the latest versions of new applications. All well and good but, that does not mean we are there yet.
An application is, just as a car is, an object which requires help in order to function. First of all you need an infrastructure. In case of a car that would be a piece of road. But since you are still in the process of testing the car is not allowed on the public roads just yet. And you will need a piece of road on which you are able to test and compare corner stability, acceleration, braking, speed and so on. In other words you are in need of a test track. One on which you can do an endless amount of laps. The test track of a software tester is the test environment. An environment in which you can conduct experiments and assess whether the application is reacting on the input given as expected up front. This environment needs to be adequate for the test to be executed. A drag strip is explicitly well suited for testing acceleration, but you will not be able to use it for assessing the cornering stability. As such, an unit test requires a different kind of environment when compared to the needs for an user acceptance test.
Yet, in order for an application to work it is in need of fuel, just as a car is. An application is built for processing information, data. No data, no processing. Which means there is a need for test data management, the fuel of an application in a test environment.
The attention for test data is however surprisingly low, as the tester will gather the data as needed for suiting the test cases to be executed. The application is in a test environment, and in that particular environment data is present, which means the tests can be executed. If only it would be as simple as that.
To make a final comparison with a car; if you pour diesel into a petrol powered car, you probably end up not as far as you would have thought upfront. If on top of that you do not know you made that particular mistake you probably end up taking the engine apart in an effort to find out why it is not function properly, only to end up finding out it was due to the wrong fuel. Test data can be just like that. To be able to assess the result of any given test for correctness, you need to be absolutely sure the input the application is given is valid.
With that being the case, one can say testing is made out of three variables: Test object, environment and data. If you wish the testing process runs smooth, with which is intended that only defects are found regarding the software under test, you will need to control and manage both other variables. Complicating factors during test execution will arise when you are not in control of test data.
To be in control of data in any given environment you want to set up test data management. Test data is not limited to one object, environment or testing type, but influences the whole of applications and processes in your IT-landscape. It is therefore a necessity to properly think about test data management and lay down a policy.
Image by Flickr
Subscribe to our newsletter
Recieve free updates on new blogs, webinars and tutorials
Let us know how to reach you. We keep you updated on the latest developments concerning test data, test data management, subsetting and masking. You can unsubscribe at any time.