|"Testing complex business rules may require knowing the exact state of several variables spread over multiple databases, tables, and/or files, and finding that precise combination may be like looking for a needle in a haystack. "|
The goal of using a test data generation product, of course, is data--tons of it. Thousands or even millions, some claim billions, of records containing variations of the described data can be generated and placed in the database or file format of choice. Most major databases--Informix, Microsoft Access, Oracle, SQL Server, and Sybase--are supported, as well as flat fixed and limited files.
These days, it's not always quite that easy. Databases can contain more than just data, such as stored procedures or derived foreign keys that link other tables or databases. In these cases, it is not feasible to generate data directly into the tables.
"Ironically," notes NAI's Pearson, "it was Datatect's stubborn refusal [warnings, error dialogs, etc.] to violate database integrity that actually gave us in QA [quality assurance] a much better understanding of the table dependencies and business logic of our application."
But Pearson employed a creative workaround. "For tables like the help desk table that fire stored procedures and triggers to ancillary tables, we use Datatect to create flat files. These flat files are supplied as input to our automated test scripts, which in turn simulate user input to create the data in the database through the browser." This approach takes advantage of the software being tested to create the actual database entries from the generated data.
The synergy between test-data generation and test-automation tools is natural, and in some cases, the test data generation capability is being embedded in test execution products.
Putting data to work
Generated test data can obviously be used to create databases with enough information to approximate real-world conditions for testing capacity and performance. If you need to ensure that your database design can support millions of customers or billions of transactions and still deliver acceptable response times, you need some practical means of creating these volumes.
Functional testing is a different animal, however. If you are testing business rules, such as whether an overdue account balance may permit additional credit purchases to be posted, then you must know precisely which account number contains the condition and which transactions may be entered against it. It may be easy to generate huge volumes of accounts with balances that are all over the map in terms of their amounts and due dates, but it is not as simple to know exactly which accounts satisfy which business rules.
The same issues exist for sampling production data. Even if you are comfortable that your data sample represents the types of conditions to be tested, it's another matter altogether to know which accounts meet which requirements. Testing complex business rules may require knowing the exact state of several variables spread over multiple databases, tables, and/or files, and finding that precise combination may be like looking for a needle in a haystack.
Can you benefit from a test-data generation tool? Probably. If you can, how do you select the best one for your needs? "The most important step is to carefully research the data population needs required by your testing efforts," says Pearson. Not only will this help you evaluate the various products, but it will also add to your education about how your software and its data are designed. And that information is useful whether you generate data or not! //
Linda Hayes is CEO of WorkSoft Inc. She was one of the founders of AutoTester. She can be reached at firstname.lastname@example.org.