DPTASM 16: The Basis of DPM’s Productized Test Automation Service Model

Figure 1: The Basis of DPM’s Productized
Test Automation Service Model

An Example: Figure 1: The Basis of DPM’s Productized Test Automation Service Model here represents a scenario in which each Product or Project Team possesses its own ‘Test Automation Development and Engineering Team’ and ‘Test Automation Infrastructure’. If there are “m” numbers of Product or Project Teams in the organization, there are “m” number of Test Automation Development and Engineering Teams and “m” number of Test Automation Infrastructures to cater to the Test Automation needs of those “m” numbers of Product or Project Teams. Out of those “m” numbers of Product or Project Teams, there are “n” numbers of Product or Project Teams that have “n” or more software products or applications the tests of which are required, and technically possible, to be automate using just one mainstream Test Automation Tool “T”. Each of those “n” number of Product or Project Teams possesses one or more instances of the Test Automation Tool “T” or a similar tool “S”. To keep this representation simple, let’s assume that the total cost incurred by each Product or Project Team on Test Automation is “x” and the quantified total benefit derived by each Product or Project Team from Test Automation is “X”.

Ingredients of Cost: Each Product or Project Team incurs costs on, pretty much, all or most of the following aspects:

o   Recruitment and Selection of Test Automation Development and Engineering Team
o   Training of Members of Test Automation Development and Engineering Team
o   Test Automation Tool Evaluation
o   Test Automation Tool Procurement
o   Procuring and setting up the Hardware and Software Environment
o   Configuring the Hardware and Software Environment
o   Maintaining the Hardware and Software Environment
o   Test Automation Platform Requirement Engineering and Management
o   Test Automation Platform Architecture and Design
o   Implementation of Test Automation Platform
o   Testing of Test Automation Platform
o   Documentation of Test Automation Platform
o   Maintenance and Enhancement of Test Automation Platform
o   Automation of Tests
o   Testing the Automated Tests
o   Maintenance and Enhancement of the Automated Tests

Ingredients of ‘Time to User’: Many or most of the following aspects influence the ‘Time to User’ factor. ‘Time to User’ denotes the total time elapsed between the point in time where the need for automated test execution is identified for the very first time and the point in time results from the execution of automated tests are actually available to the end-user. In the initial cycle, most of the activities listed below are done within this time elapsed. In the later cycles, it becomes more about just Maintenance and Enhancement Activities, Automation of New Tests, Testing the Automated Tests, Automatic Test Execution and Results Reporting.

o   Recruitment and Selection of Test Automation Development and Engineering Team
o   Training of Members of Test Automation Development and Engineering Team
o   Test Automation Tool Evaluation
o   Test Automation Tool Procurement
o   Procuring and setting up the Hardware and Software Environment
o   Configuring the Hardware and Software Environment
o   Maintaining the Hardware and Software Environment
o   Test Automation Platform Requirement Engineering and Management
o   Test Automation Platform Architecture and Design
o   Implementation of Test Automation Platform
o   Testing of Test Automation Platform
o   Documentation of Test Automation Platform
o   Maintenance and Enhancement of Test Automation Platform
o   Automation of Tests
o   Testing the Automated Tests
o   Automatic Test Execution and Results Reporting
o   Maintenance and Enhancement of the Automated Tests

The Quality Quotient: Every time the Test Automation Platform gets used, almost every part of it gets exercised or used or executed, and thus tested, at least once. In addition to the explicit testing done to verify and validate the Test Automation Platform, every additional cycle of utilization helps in discovering problems and weaknesses in the Test Automation Platform. That, in turn, helps in resolving those problems and weaknesses at the earliest possible. The more the Test Automation Platform gets used, the more it attains reliability and robustness. Thus, every subsequent new user (a Product or Project Team) of the Test Automation Platform gets the service provided by an infrastructure that keeps growing in terms of its reliability and stability. This part is interesting. Increased utilization enhances quality.

The Real Required Result: What is the expected ultimate result in this scenario? Results from the execution of automated tests are the real results. The real result, in this scenario, is one that can be directly consumed or used by the 'end user' of that result to address the ultimate purpose in hand. In that light, none of the following artifacts may be considered as the Real Required Results in this context: The Development Tool or Environment, the Test Automation Platform, the Utilities and Infrastructure created around the Test Automation Platform, the Automated Tests, the Automatic Test Execution environment and the Results Reporting infrastructure.

The Real End User: Who is the real user in this scenario? The user that utilizes the results from the execution of automated tests for any decision making or confirmation or certification, is the real end user. Decision making is the ultimate purpose in hand for the real end user of the result. In that light, none of the following individuals may be considered as the Real End User in this context: The one who creates the Test Automation Platform using a Development Tool or Environment, the one who creates Utilities and Infrastructure using the features of a Development Tool or Environment or the Test Automation Platform, the one who creates Automated Tests using the Test Automation Platform and the Infrastructure, the one who manages the Automatic Test Execution Environment and Process using the given hardware and software environment and the one who manages the Results Reporting Infrastructure and Process.  Next Page >>