DPTASM 05: Attributes of DPM’s Productized Test Automation Service Model

How do we describe this model?

1. Just one Strategy, Architecture, Design and Framework: It is about just one high-level Test Automation Strategy and one Test Automation Framework in place. There is primarily just one principal architecture and design. The "architecture and design" dictate how the tools and utilities are integrated and work together. And, not the other way round.

2. Multiple Tools: There are multiple Commercial, Free, Open-source Test OR GUI Automation Tools

3. Technology Specific UI Interaction Functions: There are Functions or Methods for Operation, Action and Verification (Example: Control Class Functions) for various classes of UI Controls and other Granular Actions pertaining to Various Technologies and UI Platforms

4. Pool of Machines: Test Automation Common Infrastructure (TACI) is set up physically at one central location with a number of Physical and Virtual Machines

5. Internally Replicated Infrastructure: The Test Automation Infrastructure (implemented on DUCOA Architecture and Design) is made available on all the Physical and Virtual Machines pooled together to create the Service Delivery Platform (SDP)

6. Identified Test Automation Candidates: All the Products and Applications suitable for Test Automation are identified in advance

7. Minimum Number of Test Automation Tools: Minimum number of Test OR GUI Automation Tools, that can automate tests of maximum number of software applications or products, are identified 

8. Optimization: It is about optimal (maximum) utilization of Tools, Licenses, Capacity of People, Software and Hardware, Knowledge, Lessons Learnt, Skills and Experience

9. Thorough Analysis: Test Automation Core Infrastructure is created after thoroughly analyzing the Products and Applications (and their Tests) suitable for Test Automation

10. Team Composition: The tiny Team that builds and runs the Test Automation Common Infrastructure (TACI) includes a Test Automation Architect (+ Designer), one (or more) Test Automation Engineer(s) or Developer(s), one (or more) Test Automation Deployment Engineer(s)

11. Shared Testing and Documentation Tasks: Testing and Documentation Tasks pertaining to the Test Automation Common Infrastructure (TACI) are shared among the team members based on who is good at what

12. Test Automation Compatible Composed Tests: Service Orders (Test Automation Requirements or what test are required to be automated) are placed with the Test Automation Development and Engineering Team in the form of Test Automation Compatible Composed Tests (TACCTs) by Functional Testers (or their representatives) from various Product or Project Teams. I have described TACCTs in detail in the context of DUCOA Test Automation Framework Architecture and Design, a White Paper I wrote a few years back. The details from the White Paper are available here.

13. Communicating Requirements: Functional Testers (or their representatives) from various Product or Project Teams communicate their Automated Test Execution Service Requirements (what Automated Tests need to be run on what Build and when) to the Test Automation Deployment Engineer. This communication can either be done manually using any formal and informal mechanism or by using technology and tools that support Submission, Queuing, Verification and Processing of Service Requests.

14. Testing the Tests: The Test Automation Deployment Engineer tests the Automated Tests before deploying them in the Automated Test Execution Environment.

15. Maintaining Readiness: The Test Automation Deployment Engineer maintains the "Readiness" of the Test Automation Common Infrastructure (TACI) and installs or sets up required Builds of targeted Software Applications or Products to be tested automatically, Queues up Automated Tests that need to run (or supervises the list of Automated Tests automatically queued up for Run in the Test Automation Common Infrastructure (TACI)). Currently available technologies can be put to use to automate, organize,  systematize, streamline and optimize many of the tasks performed in the scope of this aspect.

16. Test Run Results: Automated Test Run Results are made available to the respective Functional Testers (or their representatives) who belong to various Product or Project Teams.

17. Resource Optimization: The Test Automation Deployment Engineer explicitly ensures the optimal and maximum utilization of all the resources (Tools, Licenses, Time and Hardware)

18. Build Process Integration: Test Automation Service Consumers (Product or Project Teams) may customize their build process to make their Builds (Installable Software) automatically available in the Test Automation Common Infrastructure (TACI).

19. Test Management Integration: Test Automation Common Infrastructure (TACI) is optionally integrated with organization-wide test-management systems. Or, each project or product team establishes its own mechanism of interaction with the Test Automation Common Infrastructure (TACI) through common interfaces exposed by the Test Automation Infrastructure.

20. Influencing Factors: The 'required' size and scope of the Test Automation Common Infrastructure (TACI) (Number of Test Automation Tools, Number of Licenses, Number and Types of Hardware, Number and Type of required peripheral software and their licenses) and the size and Skill Composition of the Test Automation Development and Engineering Team is determined based on the following factors:

   a. Peak Utilization Load
   b. Average Utilization Load
   c. Current Development Needs in Test Automation
   d. Future or Predicted Development Needs in Test Automation
   e. Number of Test Automation Service Consumers at present
   f. Predicted number of Test Automation Service Consumers in future
   g. Predicted growth in the size of the Test Automation Service Consumers in future

21. On-Demand Alteration: The size and scope of the Test Automation Common Infrastructure (TACI) (Number of Test Automation Tools, Number of Licenses, Number and Types of Hardware, Number and Types of required peripheral software and their licenses) and the size and Skill Composition of the Test Automation Development and Engineering Team may be increased or altered if number of Test Automation Service Consumers (Product or Project Teams) goes beyond the threshold that can be efficiently and effectively served by the Test Automation Common Infrastructure (TACI) and the Test Automation Development and Engineering Team.

22. Cost Sharing: Product or Project Teams may share the costs pertaining to the Creation + Maintenance of Test Automation Common Infrastructure (TACI) and costs pertaining to the Automation Engineering and Development Team equally or in proportion to their respective share of usage of the productized service provided by the the Automation Engineering and Development Team. It is purely an internal decision on how the Product or Project Teams share the cost of Test Automation Common Infrastructure (TACI).  Next Page >>