Data Types and Testing

From WikiContent

Revision as of 18:55, 17 January 2010 by Karennjohnson (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Data type testing is usually a short test cycle I use solely to focus on finding issues related to data types. I tighten my testing focus, meaning I limit what I’m looking for and go directly after finding defects in that direction. Data type testing is a highly focused test cycle.

I begin with getting a copy of the entity-relationship (ER) model. Locate certain data types, here are three of my favorites:

  1. Blobs, clobs, texts and other large data types
  2. Dates and timestamps
  3. ENUMS

I often use a set of highlighters, color-coding data types as I work. Once I have my highlighted ER model, I use the model like a map on my course to find bugs.

1. Blobs I execute an assortment of operations with blobs (I’ll refer to blobs meaning any of the large data types). Operations meaning: what activities can I do with this bit of data? Can I export, import, or print the blob? If the blob is a field included on a report then what happens when I print or print preview the report? Blobs are not searchable data types, so I check that data fields that are stored as a blob are not included on any search functionality in the application. I also step through CRUD operations with blobs: create, read, update and delete with a blob. If I enter a large amount of data into a blob, then I know when I step through update and delete, that I’ll be testing a large field wit a large amount of data. Any operation I can do with blobs that require the application to "work" with a large data field such as saving it in memory or loading or updating an application’s cache is possible place to find an issue. In basic terms, big fields often cause trouble.

2. Dates and Timestamps The testing question I ask myself is: whose time is it? What timestamp is being used on an object? Is it the server time or the user’s local time? One quick test and I’ll know the answer.
Next I think about time precision especially when time is being changed – daylight savings, timestamps from users in different locations.
And a third situation I think about is data migrations. When data is being migrated what timestamps are associated with each object and what if any date or timestamp fields will be maintained or updated?

3. ENUMS This is the data type often used for drop down fields. Can I author new values for a drop down? How or what process pushes those new values to the user? Can I find a caching bug? What if I use the new ENUM on an entry and then delete the drop down (ENUM) value, can I find a referential integrity defect?

There are many other data types. Each data type poses unique boundary conditions that can be explored, possible issues with truncating data when users enter more than is expected or wrapping issues with numeric values when larger numbers than expected are entered.

When you review the ER model, you can speculate which data types merit specific testing. Any data types that have been changed by the database vendor from one version of the database to the next, warrants a test.

When time is limited (and it usually is) I might test with only one of each of these data types as I’ve learned that either these types of defects have been anticipated holistically for an application or not.

Personal tools