This blog is published by

Deepak Baliga

Testing has been traditionally viewed as an exercise of observing and commenting on the behavior of an “application under test“. Testers have been always groomed to be honest to the “requirements” that form the basis of solutions. Then came the era of scale and the consequent resource contention issues that software (and associated hardware). “Nonfunctional Requirements” also got added as a new dimension to testing. But the focus still remained the same – application behavior. As applications grew to become integrated solutions and then platforms, the philosophy of testing remained the same.

A parallel view for testing evolved in the meantime – primarily led by the data warehouse world – a concept that looked at software as a “means” to achieving data transformation, processing and reporting. Testing can also be viewed as data in motion. Of course, the functions that retrieve, store, transmit, process and syndicate/present data are as important as the data itself from a testing standpoint, but then – as long as the data moves in an expected fashion from the source to the end under a spectrum of conditions, the product can be deemed “Quality Assured“.

A few aspects of data centered testing  – One needs a thorough understanding of

• The journey points of the data across the solution stack.
• Transient conditions that impact (by design or by virtue of the environment – read production environment, co-existing applications, hardware degradation, load balancers, cloud scaling behaviors, etc.)
• Expected processing logic of the data by the app/solution/platform functions – Can be a modification (as in computational logic), a transformation of the form (such as to an HDFS file system), Derived processing (referencing the data and presenting new data as a relation to it, analytics and reporting can also be viewed under this), etc.
• The spectrum of data that would be realistically needed to be studied – as close to business or production-like data.
• Adverse situations that may impair the data journey (negative testing) or corrupt the data that is in motion.

There are several more of such dimensions that could be used to build a framework for testing.

Is data-centered testing a better than traditional app focused testing? Some key points in its favor

• It focuses on what the end-user wants ultimately. After all, content is king, and it is information that the end-user is seeking.
• It would trigger the right testing questions and answers – with the tester not being subject to distractions caused by an abnormal obsession with an application’s attributes – a.k.a functional specs.
• It could be a basis for testing under incremental development processes. A part of the “data journey” can be incrementally and absolutely (integration tests as well as end to end tests)
• Could lend more easily to several test optimization and visualization techniques such as state transition, branch analysis, etc.

The next level of detail could be in how one could achieve a reasonable level of effectiveness of the implementation of such a concept on the ground. That would involve the right methods to sample the data in motion, comparison mechanisms, test data management and test results correlation to business requirements.

Read complete blog