How do you get the data you use for testing? Do you find it? Create it? Request it? What if you only had to find it/create it/request it once? How easy would your life be? MUCH EASIER is the answer. So, finding it or having to create it isn’t easy. What if you switched over to requesting your data? That would be simpler right? Right. Data can be THIS easy. I know, I know, it seems impossible, but the steps are simple. Here’s how quick and easy data can be.
- Create and use a template for your data requests. Include all the pertinent questions that will get you to the desired end result. This can vary per company, project, and team.
- Use a tool that enables you to create the data you need.
- Schedule the delivery of your data for the time-frame that suits your needs best.
That’s the high level of what needs to happen. And simply speaking, that’s all most people need to know. So let’s break it down by roles.
Tester:
- You need to know what your data requirements are. Don’t know what they are? Figure them out.
- Once you know your requirements, submit your test data request (TDR). The data you receive is only as good as the requirements you give. Help others help you. Be clear, concise, and accurate. This might sound hard at first, but after you get into the swing of things, it will be easy.
Test Data Engineer:
- Use a tool to develop requested data to specification. My recommendation for this is CA Test Data Manager. Production data will typically only get you 10-20% of the data you need for testing, so development of data is the only way forward.
- Provide a copy of the data created. This enables the tester to use the intended data for that request. It also dramatically reduces the amount of time the tester spends trying to find data.
Now that you have the test data, how do you get it over and over again—and up to date like you asked for in the first request? Very simple. When the data pool is created with the code to create the data, the code can be written to handle innumerable executions at future times. Work with your test data engineer to ensure this is written as such. Then, work with the test data engineer to set up automatic creation.
Picture the circle of life, TDR style. You start with your test case, you submit a TDR, the data is created and delivered. Then, you can go back as often as you want, skipping the TDR and data creation, because the code to create it already exists. All you have to do is execute the code, as many times as needed. Simple, fast, and accurate.
There are four options for automated data creation with varying levels of automation.
1. Set up a batch job
The tester lets the test data engineer create the schedule he/she needs the data for and the engineer can set up the batch job to create the data as such. Often times, clients will want fresh data available multiple times a week when their testers arrive to work for the day. This is accomplished by setting the batch job to start in the middle of the night on the desired days. Then, the testers are ready to go when they arrive with fresh fuel for their testing.
2. Soap UI call
This applies to automated testing. When using Soap UI to execute automated tests, a call can be added to execute a data pool, which will run and create the needed code for the executed test. This enables data exactly when it’s needed.
3. Test data on demand (TDOD)
TDOD is a GUI form of CA Test Data Manager. This GUI application enables a tester to select an existing data pool to execute, change variable values as needed, and either execute the code immediately or schedule it for when he/she would like it. This is different than a batch job, but the end result is the same. Data when the tester wants it.
4. Data creation from test case optimizer (TCO)
If using TCO to optimize test cases, a tester can also call an existing data pool to be executed to create data. Within the application, the tester would select which data pool to be used, then the data is created at the desired time using the selected code.
As you can see, there are a variety of options for hypercharging your testing by:
- Eliminating the waiting time for data by delivering it day one of the test cycle
- Shortening test cycles as the testers are no longer looking for data, because their data is delivered
- Increasing the ability to find errors faster
- Enabling repeatability with synthetic data generation