Note: This document clarifies and expands on the meaning of some posts that may contain business vocabulary, engineering jargon or technical terms.
--- --- ---
Test Data (specifically database test data)
Databases are often tested prior to releasing any development changes into business use. If a malfunction or problem is detected then the same test needs to be repeated after a fix has been applied, in order to audit that a fix has been successful. Owning managed test data is valuable to the business since it allows for a test to be repeated many times, this saves time-sheet time since the managed test data does not have to be designed and created from first principles.
Managed test data is version-ed and is in itself tested against requirements created by the business. Such test data needs mechanisms or computer software algorithms that can inject (or replace) such data into a system under test. It is a best practice that test data should be identifiable as being distinctly different from normal business data, the reason for this is to mitigate against the possibility that business functions (or business reports) SHOULD NOT MAKE ACCIDENTAL USE of such test data even, if that data is found to exist within the production system.
For completeness – unmanaged test data has dubious value since, if a test is found to pass or fail, the test person is none the wiser as to deduce if a fix is required. One of the design requirements of test data, is that, the test data is designed to induce a deliberate test fail in order to allow validation and checking of a system-under-tests ability to correctly handle BAD data. Conversely, the objective of test data that is designed to induce a deliberate test PASS is to proof that a system-under-test does not fail when processing the GOOD data.