FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: REUSABLE TEST AUTOMATION ASSETS LIBRARY
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor,
SERVICES LIMITED Nariman Point, Mumbai,
Maharashtra 400021, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter, in general, relates to software testing automation,
in particular, to systems and methods for creating and maintaining a library of reusable test automation assets.
BACKGROUND
[0002] Over the past several years, test automation efforts within enterprises have
grown tremendously, resulting in creation of large number of test automation assets or artifacts, such as test automation scripts, which tends to automate entire test automation phases or several key-activities within those phases. A large enterprise, for example, may have a significant number of ongoing test automation projects at any point of time involving large number of users, such as test analysts and test automation engineers. Generally, a variety of test automation assets are developed in every test automation project based on project requirements, application to be tested, and various other parameters.
[0003] In general, various test automation teams within the enterprise create multiple
test automation assets during every test automation project. As mentioned previously, these test automation assets are developed keeping in mind the current test automation project requirements or current software application to be tested. In order to reuse the same test automation assets in other test automation projects, modifications have to be made, to make the test automation assets compatible with the other test automation projects. In certain cases, if the modifications to be made are considerably large, reusing the test automation asset may in turn increase the complexity of the task, the test automation teams may prefer to develop new test automation assets. Further, various test automation teams within the enterprise may develop similar test automation assets as developed by other test automation teams, due to lack of internal communication or knowledge sharing across the test automation teams, leading to creation of duplicate or redundant test automation assets within the enterprise. Thus, lack reuse of test automation assets within the enterprise result in duplication of work and non optimum usage of test automation resources of the enterprise.

SUMMARY
[0004] This summary is provided to introduce concepts related to creating and
maintaining a library of reusable test automation assets. These concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] In one implementation, a reusable test automation assets library system
comprises a categorization module configured to identify a technological platform associated with the at least one reusable test automation asset based on at least one categorization rule. Further, the categorization module is configured to store the at least one reusable test automation asset into a technology-based category within a library of reusable test automation assets, based at least on the identified technological platform.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is described with reference to the accompanying
figure(s). In the figure(s), the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figure(s) to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figure(s), in which:
[0007] Fig. 1 illustrates a reusable test automation assets library system, in accordance
with an embodiment of the present subject matter.
[0008] Fig. 2 illustrates a method for creating and maintaining a library of reusable
test automation assets, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0009] Conventionally, each of the test automation teams within an enterprise creates
various test automation assets or artifacts during every test automation project. Such test automation assets may include, for example, test automation scripts developed for testing various software applications, such that overall testing time and efforts are reduced. In

general, such test automation assets are developed keeping in mind the current test automation project or software application to be tested, thus these test automation assets may not be considerably useful for accomplishing other test automation projects. Either considerable modifications or tweaks have to be made for making the test automation assets compatible with the other test automation projects, or new test automation assets altogether are developed for carrying out other test automation projects.
[0010] In certain cases, various test automation teams within the same enterprise may
develop similar test automation assets as developed by other test automation teams, leading to creation of redundant test automation assets within the same enterprise across various test automation projects. The development of redundant test automation assets within the enterprise, results in wastage of time and resources of the enterprise. Further, owing to lack of reuse of test automation assets across different test automation projects and different test automation teams, enterprise wide test automation is generally considered a next release activity.
[0011] Conventionally, some of the enterprises implement a common repository for
storing various test automation assets. Such a common repository serves as a mechanism of sharing the test automation assets across different test automation teams within an enterprise. However, questions such as: “who will create the repository?”, “how such a repository can be populated and maintained to maximize facilitate reuse of the test automation assets?” and “how a desired test automation asset, which a user is looking for can be easily searched and obtained from such a repository?” are certain questions that the conventional approaches fails to address.
[0012] Further, the conventional repositories are domain specific. For example, a
repository may be specific to a domain, such as banking, manufacturing or an insurance domain. The test automation assets in a domain specific repository are not interoperable. Accordingly, in one example, the test scripts or test cases pre-existing in a repository having banking domain related test automation artifacts may not be used in testing an application relating to the insurance domain.
[0013] In accordance with the present subject matter, systems and methods of creating
and maintaining a library of reusable test automation assets are described. In one

implementation, a plurality of user groups are created, and a set of users within an enterprise are associated with each of the user groups. The job of creating and maintaining the library is divided amongst such user groups by assigning certain roles and responsibilities to each of the user groups. For examples, a user group, namely, 'Creator' can be created, and assigned with the roles and responsibilities for creating new reusable test automation assets, and validating pre-existing reusable test automation assets extracted from other data sources.
[0014] The library is created, for example, by obtaining reusable test automation
assets from a user group having pre-assigned roles and responsibilities for creating or identifying reusable test automation assets. Subsequent to obtaining, the reusable test automation assets are categorized into various categories, such as technology based categories enabling users to easily locate and utilize these test automation assets. Such a library helps in achieving enterprise wide test automation by maximizing the reuse of the test automation assets across different testing projects within the enterprise.
[0015] While aspects of systems and methods for creating and maintaining a library of
reusable test automation assets can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system architecture(s) and method(s).
[0016] Fig. 1 illustrates a reusable test automation assets library system 102, in
accordance with an embodiment of the present subject matter.
[0017] The reusable test automation assets library system 102 (hereinafter referred to
as a system 102) may be implemented as any of a variety of conventional computing devices, including, servers, a desktop personal computer, a notebook or portable computer, a workstation, a mobile computing device, and a laptop. Further, in one implementation, the system 102 may be a distributed or centralized network system in which different computing devices may host one or more of the hardware or software components of the system 102. In another implementation, the various components of the system 102 may be implemented as a part of the same computing device.
[0018] In one implementation, a plurality of users may use the system 102 for creating
and maintaining a library 104 of reusable test automation assets. The library 104 can be implemented either as an external repository (as shown in the fig. 1) associated with the

system 102 via a wired network or a wireless network. Alternatively, the library 104 can be implemented as an internal repository within the system 102.
[0019] The system 102, according to an implementation of the present subject matter,
obtains one or more reusable test automation assets 122 from users within the enterprise, categorizes the reusable test automation assets 122 into various categories to create and maintain the library 104. For this purpose, the system 102 includes one or more processor(s) 106, a memory 108 coupled to the processor(s) 106, and interface(s) 110. The processor(s) 106 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 106 are configured to fetch and execute computer-readable instructions and data stored in the memory 108.
[0020] The interface(s) 110 may include a variety of software and hardware
interfaces, for example, interface for peripheral device(s) such as a keyboard, a mouse, an external memory, a printer, etc. Further, the interface(s) 110 may enable the system 102 to communicate over a network, and may include one or more ports for connecting the system 102 with other computing devices, such as web servers and external databases. The interface(s) 110 may facilitate multiple communications within a wide variety of protocols and networks, such as a network, including wired networks, e.g., LAN, cable, etc., and wireless networks, e.g., WLAN, cellular, satellite, etc.
[0021] The memory 108 may include any computer-readable medium known in the art
including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The system 102 also includes modules 112 and data 114.The modules 112 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. The modules 112 include a group creation module 116, a categorization module 118, and other module(s) 120. The other module(s) 120 may include programs or coded instructions that supplement applications and functions on the system 102, for example, programs in the operating system.

[0022] The data 114, amongst other things, serves as a repository for storing data
processed, received, and generated by one or more of the modules 112. The data 114 includes the reusable test automation assets 122, group creation rules 124, categorization rules 126, and other data 128. The other data 128 may include data generated as a result of the execution of one or more modules in the other module(s) 120.
[0023] According to an embodiment of the present subject matter, the group creation
module 116 within the system 102 creates a plurality of user groups for the purpose of creating and maintaining the library 104 of reusable test automation assets. In one implementation, the group creation module 116 creates the user groups upon receiving group creation instructions from an administrator. In another implementation, the group creation module 116 creates the user groups based on various predefined group creation rules 124 stored within the data 114.
[0024] A set of users within an enterprise are associated with each of the user groups.
The group creation module 116, for example, identifies the set of users by scanning an employee database or a repository containing information about the employees. Such databases may also be conventionally available in many enterprises. Such information may include experience, expertise area of the employees, their interests and qualification, etc. As a result of such scanning, the group creation module 116 identifies and associates a set of users with each user group. In one implementation, the group creation module 116 may identify the set of users suitable to be associated with the user group, and generate a prompt for an administrator, to validate if the identified set of users matches with the user group.
[0025] Once the users are identified and associated with the user groups, the group
creation module 116 assigns certain roles and responsibilities to each of the user groups in order to divide the job of creating and maintaining the library 104 amongst the user groups. The group creation module 116 may, for example, notify the users about the roles and responsibilities assigned to them. In one implementation, penalties or strict actions may apply, when the users associated with such user groups fails to perform the assigned roles and responsibility. For example, it may have an impact on the performance rating of the user, which in turn has an impact on the yearly appraisal.

[0026] In one implementation, the group creation module 116 creates the user groups
including a creator group, an executor group, an operational manager group, a senior manager group, and a library manager group. The creator group includes users, such as test automation engineer and a power user. The executor group includes users, such as developers, business analysts, and manual testers. The operational manager group includes users, such as test managers. The senior manager group includes users, such as test directors. The library manager group includes users, such as library administrator, business user automation owners, and library architects.
[0027] In said implementation, the group creation module 116 may assign the creator
group the roles and responsibilities of creating reusable test automation assets, identifying pre-existing reusable test automation assets, determining automation quotient, implementing various standards on the test automation assets, reusing available collection of the test automation assets for regression, creating automation execution manuals, and assisting nontechnical users. The group creation module 116 may assign the executor group roles and responsibilities of searching the library for the scripts that are ready for execution, execution of the scripts through multiple models, and providing feedback on potential automation areas. The group creation module 116 may assign the operational manager group the roles and responsibilities of creating and maintaining project performance metrics, planning future automation requirements and resources, training and team enablement. The group creation module 116 may assign the senior manager group roles and responsibilities of tracking reports and adoption metrics, and tracking Return On Investments (ROI). The group creation module 116 may assign the library managers group roles and responsibilities of cataloguing updates, test automation assets maintenance, updating the test automation assets standards, troubleshooting and providing helpdesk support, reviewing enterprise-performance reports.
[0028] In one implementation, the categorization module 118 within the system 102
obtains the reusable test automation assets 122 from a user group, for example, the creator group having pre-assigned roles and responsibilities of creating the reusable test automation assets 122 and identifying pre-existing reusable test automation assets 122 from various internal and external sources. The internal data sources may include data sources available within the enterprise. While, the external sources includes World Wide Web (web).

[0029] In another implementation, the categorization module 118 obtains the reusable
test automation assets 122 from an extraction module (not shown in the figure) within the other module(s) 120. The extraction module, for example, extracts the reusable test automation assets 122 from various internal data sources, such as data sources available within the enterprise, or external data sources, such as the web based on one or more predefined extraction rules stored within the other data 128. In said implementation, the extraction module may direct the extracted reusable test automation assets 122 to be validated from a user associated with the user groups, for example, the creator group. For example, the user may be prompted to validate if the extracted reusable test automation assets 122 can be included within the library 104. If validated, the reusable test automation assets 122 are passed on to the categorization module 118 for storage within the library 104.
[0030] Upon receiving the reusable test automation assets 122, the categorization
module 118 identifies technological platform associated with the reusable test automation assets 122 based on a plurality of predefined categorization rules 126. According to one categorization rule, keywords associated with the assets are compared with pre-stored keywords that can uniquely distinguish the technological platforms. For example, a reusable function written in C language may have keywords such as “studio.h” and “printf”, and the reusable function written in C++ language may have keywords such as “iostream” and “cout”. According to another categorization rule, syntax associated with the asset is compared with the pre-stored syntax of the codes or functions associated with the technological platforms to identify the technological platform associated with the reusable test automation assets 122.
[0031] Once the technological platform is identified, the categorization module 118
stores the reusable test automation assets 122 into corresponding predefined technology-based categories within the library 104. For example, if a reusable function based on the Java technology is identified, then the reusable function is placed into a Java category within the library. In case no appropriate category is found in the library 104, a new category can be created. Thus, in the above mentioned example, if no category related to Java technology is found in the library 104, a new category for storing Java related assets can be created by the categorization module 118 for incorporating the obtained reusable function.

[0032] In one implementation, the plurality of technology-based categories within the
library 104 includes a SAP category, an Oracle category, a Java category, an ActiveX category, a .Net category, a C category, a C++ category, a PeopleSoft category, a WebServices category, a VisualBasic category, a Terminal_Emulator category, a Siebel category, and various Web based categories.
[0033] In one implementation, the reusable test automation assets 122 described
herein are reusable functions. The categorization module 118 categorizes the reusable functions into various technology-based categorizes, such as SAP, Oracle, Java, .Net, etc. The reusable functions can be utilized for developing various application-specific test automation scripts. According to the business requirement and application to be tested, the user can develop desired test automation scripts in a short span of time, using suitable reusable functions. For example, if an automation script is to be created for testing a software application based on SAP platform, then reusable functions in a SAP category can be utilized in quickly developing the automation script for testing SAP based application. Thus, the creation of automation scripts itself is facilitated, and such scripts may also be stored as reusable test automation assets 122 within the library 104. Further, the reusable test automation scripts can be utilized across the test automation projects. For example, a test script based on the SAP technology can be utilized to test a variety of SAP based applications, thus, the same script can be reused in a multiple test automation projects with either no modification or minimum modification. Further, such scripts are easier to locate, as the user looking for SAP related automation script can find the desired script in the SAP category.
[0034] In addition to the technology-based categories, the categorization module 118
may create various other categories, such as business related categories and general utility categories, and categorizes the reusable test automation assets 122 into these categories. The business related categories may include reusable assets specific to a business or domain. For example, reusable functions specific to a banking domain that can be used across a range of technologies for testing various software applications related to the banking domain. The testing assets placed in the business related category may also accelerate development of automated business scenarios, test cases, etc. The general utility category may include other reusable assets that are not specific to certain technology, business or domain. For example, assets related to browser, security, administration, Test Object, and Excel Object.

[0035] In one implementation, the categorization module 118 may further categorizes
the reusable test automation assets 122 into several other categories, for example, categorizes based on the type of test automation assets, which are hereinafter referred to as test automation assets-based categories. Such test automation asset-based categories may include reusable functions category, reusable automation scripts category, etc.
[0036] The system 102 thus obtains the reusable test automation assets 122 from a
user group, for example, the creator group, identifies and stores the reusable test automation assets 122 in the library 104, thereby creating and updating the library 104 periodically. The library 104 thus created can be maintained or managed by various users associated with other user groups that are assigned roles and responsibility of maintaining and managing the library 104, as indicated previously. Thus, the library 104 can be created and maintained in a collaborative fashion, where the users within the enterprise that are associated with one or more of the users groups performs their part of the roles and responsibility to create and maintain the library 104.
[0037] Such a library 104 of reusable test automation assets 122 offers significant
advantages in, for example, reducing the resources, expense, and overall testing time and efforts in software testing within the enterprise, thereby achieving enterprise-wide automation. Further, the technology-based categorization of the test automation artifacts within the library 104 provides domain interoperability. For example, the test scripts within the SAP category may be used across the domains for testing various SAP based applications, irrespective of whether it is used for testing an application related to banking domain or insurance domain.
[0038] Fig. 2 illustrates a method 200 for creating and maintaining a library of
reusable test automation assets, in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed

computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[0039] The order in which the method is described is not intended to be construed as a
limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.
[0040] At block 202, at least one reusable test automation assets is obtained. In an
implementation, the categorization module 118 within the system 102 obtains the at least one reusable test automation assets from a user associated with a user group. It will be appreciated that various user groups can be created by the group creation module 116 within the system 102, and multiple users can be associated with each of the user groups based on their experience, qualification, current occupancy, etc. Such user groups may be assigned certain roles and responsibilities for populating, enriching and maintaining the library of reusable test automation assets. Accordingly, the system 102 may include a notification module to notify a user, for example, through an email notification the roles and responsibilities assigned to him.
[0041] The users may create new reusable test automation assets and/or identifies and
extracts reusable test automation assets from various publically available test automation related information resources on the World Wide Web (web), for example, forums, blogs, websites containing various test automation assets. In one implementation, the system 102 may include an extraction module configured to extracts reusable test automation assets 122 from the web, using web crawlers and other similar tools known in the art. In one embodiment, each user may have a computing device and access the system 102 through their respective computing device to provide the test automation assets created by them. In said implementation, upon extraction of the reusable test automation assets, the system 102 may prompt validation by a user whether the extracted reusable test automation assets 122 can be incorporated into the library 104.
[0042] At block 204, a technological platform associated with the at least one reusable
test automation asset is identified. In one implementation, the categorization module 118

within the system 102 identifies the technological platform associated with the obtained reusable test automation asset 122 based on the categorization rules 126. For example, one or more categorization rules 126 can be applied to the reusable test automation asset 122 to identify the technological platform associated with the reusable test automation asset 122.
[0043] According to one categorization rule, keywords associated with the reusable
test automation asset 122 are compared with pre-stored keywords that can uniquely distinguish the technological platforms. According to another categorization rule, syntax associated with the reusable test automation asset 122 is compared with the pre-stored syntax of the codes or functions associated with the technological platforms to identify the technological platform associated with the reusable test automation asset 122. In said implementation, the system 102 may prompt a user group or an administrator to validate whether the identified technological platform of the obtained reusable test automation asset is correct or not. In another implementation, the categorization module 118 categorizes the obtained reusable test automation asset 122 based on a business domain or a general utility associated with the obtained reusable test automation asset 122.
[0044] At block 206, the reusable test automation asset is stored into a technology-
based category in the library 104. It will be understood that the library 104 is data comprising reusable test automation assets 122 that may be stored in the memory of the system 102 or may be stored in an external data repository associated with the system 102. In one implementation, a plurality of technology-based categories, such as Oracle, SAP, .Net, and VisualBasic are created in the library 104, and reusable test automation assets 122 are incorporated into appropriate categories based on the identified technological platform. For example, reusable test automation assets related to Oracle technology are incorporated into an Oracle category. In case no appropriate category related to the identified technological platform is found in the library 104, a new category can be created and the reusable test automation assets 122 are incorporated into the new category.
[0045] Although embodiments for systems and methods for creating and maintaining
a library of reusable test automation assets have been described in language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and

methods are disclosed as exemplary implementations for creating and maintaining a library of reusable test automation assets.

I/We claim:
1. A reusable test automation assets library system (102) comprising:
a processor (106); and
a categorization module (118) coupled to the processor (106), wherein the
categorization module (118) is configured to:
identify a technological platform associated with at least one reusable test automation asset based on at least one categorization rule; and
store the at least one reusable test automation asset into a technology-based category within a library (104) of reusable test automation assets based at least on the identified technological platform.
2. The reusable test automation assets library system (102) as claimed in claim 1, wherein the at least one reusable test automation asset is one of a reusable function and a reusable automation script.
3. The reusable test automation assets library system (102) as claimed in claim 1, wherein the technology-based category is one of a SAP category, an Oracle category, a Java category, a .Net category, an ActiveX category, a C category, a C++ category, a PeopleSoft category, a Web Services category, a VisualBasic category, a terminal emulator category, and a Siebel category.
4. The reusable test automation assets library system (102) as claimed in claim 1, wherein
the at least one categorization rule identifies the technological platform based on comparison of one or more keywords associated with the at least one reusable test automation asset with pre-stored keywords associated with a plurality of technological platforms.
5. The reusable test automation assets library system (102) as claimed in claim 1, wherein
the at least one categorization rule identifies the technological platform based on comparison of a syntax associated with the at least one reusable test automation asset with pre-stored syntax associated with a plurality of technological platforms.
6. The reusable test automation assets library system (102) as claimed in claim 1, wherein
the at least one reusable test automation asset is extracted from an external data source.

7. The reusable test automation assets library system (102) as claimed in claim 1, wherein
the at least one reusable test automation asset is obtained from a user associated with a creator group.
8. The reusable test automation assets library system (102) as claimed in claim 1, wherein
the reusable test automation assets library system (102) further comprises a group creation module (116) configured to:
create a plurality of user groups, wherein the plurality of user groups includes at least a creator group; and
assign roles and responsibilities to each of the plurality of user groups for creating and maintaining the library (104), wherein the creator group is assigned roles and responsibilities of at least one of creating reusable test automation assets and identifying pre-existing reusable test automation assets.
9. A method of creating and maintaining a library of reusable test automation assets, the
method comprising:
obtaining at least one reusable test automation asset from a user associated with a creator group;
identifying a technological platform associated with the at least one reusable test automation asset based on at least one categorization rule; and
storing the at least one reusable test automation asset into a technology-based category within the library, based at least on the identified technological platform.
10. The method as claimed in claim 9, wherein the at least one reusable test automation asset is one of a reusable function and a reusable automation script.
11. The method as claimed in claim 9, wherein the technology-based category is one of a SAP category, an Oracle category, a Java category, a .Net category, an ActiveX category, a C category, a C++ category, a PeopleSoft category, a Web Services category, a VisualBasic category, a terminal emulator category, and a Siebel category.
12. The method as claimed in claim 9, wherein the method further comprising:
creating a plurality of user groups, wherein the plurality of user groups includes the creator group; and
assigning roles and responsibilities to each of the plurality of user groups for creating and maintaining the library, wherein the creator group is assigned roles and

responsibilities of at least one of creating reusable test automation assets and identifying pre-existing reusable test automation assets.
13. The method as claimed in claim 9, wherein the categorization rule identifies the technological platform based on comparison of one or more keywords associated with the at least one reusable test automation asset with pre-stored keywords associated with a plurality of technological platforms.
14. The method as claimed in claim 9, wherein the categorization rule identifies the technological platform based on comparison of syntax associated with the at least one reusable test automation asset with pre-stored syntax associated with a plurality of technological platforms.
15. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
obtaining at least one reusable test automation asset from a user associated with a creator group;
identifying a technological platform associated with the at least one reusable test automation asset based on categorization rules; and
storing the at least one reusable test automation asset into a technology-based category within a library of reusable test automation assets, based at least on the identified technological platform.