Cameron Laird's personal notes on database testing

"Databases are Software, Too", and deserve treatment as such; that is, what we've learned about how best to create and maintain software in general largely applies to databases. In particular, databases deserve to be tested.

That's not as obvious institutionally as it might appear to you as an individual. "Data" and "test" (or "quality assurance" or "quality control") groups are often managed rather distantly; they might be not only separate departments, but separate in their governance all the way to the executive rank, reporting variously to CTO, CIO, CFO, and so on. Data teams have a rich and important culture, but it's not one that has, to this point, emphasized testing.

There are several aspects of "database testing" that I think will particularly interest such individual practitioners as front-line testers, directors of development, and, by extension, CIOs:

• synthesis of test data;
• "configuration management" [more references] of database artifacts including DBMS, schema, data, and loading scripts;
• exploratory testing support for database introspection [references to related pages]
• management of dualities including: schema-data; DBMS-application; client-server; procedure-declaration; test-proof; ...
• ...

Other articles I've written that touch on this subject are:

• "Replicated Databases Improve Development, Testing, and Collaboration"
• "Why QA Must Have Its Own Databases"
• ...

  ---

  
  Cameron Laird's personal notes on database testing/claird@phaseit.net