Reloadable test data takes more time up front (as compared to on-the-fly data creation), but saves blood, sweat, and tears in the long term. It also virtually eliminates "works on my machine" bugs, creates a more intricate and realistic environment, and is the first step on the road to test automation.
Act now to take 50 percent off test execution time, virtually eliminate “works on my machine” arguments, and we’ll throw in load testing absolutely free!
Ladies and gentlemen, right now, you’re probably wondering if I’m crazy. “How can she make this incredible offer?”
Well, I’m here to tell you that with pre-created reloadable test data, it’s easy.
“What is this magical ‘reloadable test data?’” you ask.
Reloadable test data is test data that you reuse every time you test. Right now, many testers—and yes, even developers—tend to create test data on the fly each time they run a test.
Test Case ID 1 is an example test case based on an application that manages nurse/patient records in a health care system.
This requires a tester to create the following data (which would take at least ten minutes):
- Agency administrator
- Patient
- Two branches
- Two branch administrators with email addresses
- Nurses from patient’s old branch
- Multiple patient appointments with above nurses
- Variousvital statistics for the patient
Chances are, this test would be run at least four times: a first pass, two regression or sanity tests, and one bug retest. Ten minutes times four test runs equals FORTY minutes.
But WAIT! With reloadable test data, creating that same data will take only TWENTY minutes. “How is that possible?” you ask.
By taking an extra ten minutes up front to set up and create this data in a reloadable format, you can reuse the test data four times—or even more.
Where does this extra time savings come from? I’m glad you asked …
Take 50 Percent Off Test Execution Time
You, too, can create and use reloadable test data in five easy steps!
Step 1: As you write your test cases, simply keep a spreadsheet that records the entities you will need for each case and what special characteristics each entity must have. IMPORTANT! To maintain data freshness, do this as you write each test case—or else you will have to spend extra time trying to remember the needed data and you will end up with dry, cracked entities.
Table 1 shows part of a spreadsheet we’ve created for our application that maintains nurse/patient records for a clinic.
But what does the “Is Changed” column mean? Can I just ignore it?
NO! That column is VERY IMPORTANT. Sometimes, in the course of running a test, the data for an entity is changed BY THE TEST. Perhaps Administrator 1 is deleted or Patient 3 is transferred to the care of Nurse 5. In a case where this happens, you will not be able to share this test data between different test cases.
Step 2: When all of your test cases are complete, it’s time to create the actual data in a format that is loadable for your application. For example, it could be another spreadsheet with sheets and columns that map directly to the tables in your application’s database. As you create this data, keep track of its necessary identifiers by filling in the specifics in the “Need To Know” column from the original spreadsheet in table 1. BUT WAIT! Before you start, there’s one more way to save time!
Look at each entity that you need to create—you could even re-sort your spreadsheet to help you do this—and compare them. Are any two exactly the same, right down to the “Is Changed” column (which must say “no”)?
If so, you can create a single data entity for MORE THAN ONE TEST CASE. Imagine the savings! Instead of using ten minutes to save twenty, you can save sixty OR EVEN MORE!
Step 3. Go back
| Attachment | Size |
|---|---|
 XDD14765filelistfilename1_0.pdf | 911.21 KB |
About the author
Tanya Dumaresq is the QA Manager at Macadamian. She has spoken at STAREAST, STARWEST conferences and has had software testing articles published in Better Software magazine SD Times magazines.
