DUCOA 14 - Data Driven Test Processing: An Example

It is easy to assume that “Number of Derived or Generated Composed Tests required to be created = Number of Test Iterations prescribed or Number of UI Control specific Input Data Instances”. That is, if there are 5 unique instances of UI Control specific Input Data Instances (5 Iterations), the Test Automation Engineering or Development Team needs 5 Derived or Generated Composed Tests pertaining to the Test Case in question.

That essentially gets translated into 5 Tests in the context of the Test Automation Platform or Infrastructure or Framework. The complexity involved in this layer of translation, however, remains transparent to the Test Engineers (The Direct Consumers of the Automated Test). This is another instance or layer of abstraction (Reverse Abstraction: One to Many) that takes place in case of Test Cases that are Data Driven.

To begin with simplicity and stay simple :-), let's assumes that, in this example, there is just one UI Control, in the context of The Test in question, which receives each of the 5 different instances of the UI Control specific Input Data over each of the 5 iterations of the test-case execution. What if there is not just one, but, are more UI Controls that receive Input Data over each of the iterations of test-case execution?

Let’s enhance the above example and assume that, instead of one, there are 5 unique UI Controls, in the context of The Test, that receive Input Data and there are 5 unique UI Controls that display Output Data during each of the iterations of test execution. What happens in this case? If there are still 5 iterations of the test required to be automated, here is what is done. 

The Product or System Test Engineer provides the exact sets of UI Control specific Input Data and Expected Output Data Set for each iteration. The instances of the Derived Composed Test get generated based on this Input Data and Expected Output Data Set. This is the reflection of the Abstracted Data Driven Framework (ADDF) in action. However, in the context of the abstracted form of the Data Driven Framework Design, generated Composed Tests may or may not not have any dependency on any external data source. That remains a matter of design choice. The test, anyway, resides outside the automation code. And, the Test Data resides within or outside the Base Composed Test. That keeps the whole affair a lot simple.

There remains no need to refer or look into multiple sources while troubleshooting or going through (analyzing) test-execution results in case the Test Data resides within the Base Composed Test. Keeping the data outside the Base Composed Test allows more flexibility and maintainability, however. Irrespective of the design choice exercised, when it comes to the Derived Composed Tests, it becomes easier to read and understand the test-execution results, as it becomes possible to see what was done, when, on which UI Control, with which Input Test Data if an appropriate tracing and logging mechanism is implemented to capture this processing. The Test Automation Platform Code is still kept relatively simple and that allows ease of maintenance and debugging the code, when required.  Next Page >>

Creative Commons License
DUCOA 14 - Data Driven Test Processing: An Example by Debi Prasad Mahapatra is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Comments

Popular Posts