QW2002 Paper 9A2 Joshua Kitchen (IBeta) Legacy Data Conversion: Making Coffee

Key Points

• Likely Difficulties/Risks:
  a. Managerial
     i. Lack of visibility at the project management/project sponsor level
     ii. Scarcity of testing resources
     iii. Lack of environments/Poor environmental performance
     iv. Lack of business analyst/subject matter expert involvement
     v. Turf issues
  b. Technical
     i. High number of defects
• Do’s and Don’ts of Data Conversion Testing (rules of thumb)
• Key Indicators (How do I know I’m doing it right/wrong)
  a. Application schedule
  b. Data model slip
  c. Performance tuning schedule
  d. Resource rhythm
  e. Defect counts, including sub-counts of defect classification

Presentation Abstract

Converting data from a legacy application is a lot like making coffee.

The existing data (grounds/beans) work well enough in their current state (if you like pulling beans out of the bag or eating spoonfuls of grounds, but then we already know we want a new app, don’t we?). To work properly, however, in our new application the data must undergo change. So first the grinding, either from beans or from a courser grade of grounds (cleansing garbage data from the system prior to trying to converting it), then the pouring into the filter and running hot water through it (conversion to new schema, applying different integrity rules, interpolating new fields from existing ones, etc.) until the finished coffee finally resides in the pot (the new application database). In theory, if all went well, what’s in the pot is what was desired; the user can drink it and be well satisfied with the temperature, the flavor, the aroma, the viscosity…but theory and fact often part company. So who do we want to drink the first cup, our user group/customer or our testing group? That was my answer, too.

About the Author

Joshua Kitchen hails from ‘lots of different places’; he was commissioned from Cincinnati, Ohio, but after graduating the Naval Academy in 1990, he spent the next decade making his home in a variety of different locales, including Florida, Idaho, Hawaii, and California. A mathematics and system background was augmented by exhaustive training in engineering courtesy of the Navy’s nuclear power program, and proven at sea aboard the USS Indianapolis, on which he received his final commission of lieutenant and his qualification as ship’s engineer. Post-Navy, he moved on to work with expert systems for Pilkington in their quality assurance department, and in the process earned his Black Belt in Six-Sigma techniques. From Pilkington, he moved on to iBeta, a software quality assurance firm in Denver, Colorado, where he finished his ASQ certification in software quality assurance engineering and proceeded to implement his training and experience from a variety of sources as one of the companies directors.