Enterprise test system platform and associated method for interoperable test data management, test development, test libraries and test workflow management and automation

This Invention provides a system-level framework for an enterprise-level test environment. The environment provides test development, automation, and execution processes for product validation and verification, and allows the interoperability of test cases, data, equipment information, and results across various enterprise platforms. The system, with its processes and methods, provides various mechanisms for managing test configurations, developing test plans, managing test data, and developing test reports from one or more test-stations and/or from one or more test equipment(s) for one or more Device(s) Under Test (DUT). These mechanisms include, but are not limited to, functions such as data management and sharing, test library reusability, test station management, test configuration management, test execution, test report development, and data mapping/plotting. The system can be customized to support scalable enterprise requirements. The development of the standardized data handling and communication processes and methods allows inter-system communication and interoperability of test information across various platforms.

FIELD OF INVENTION

The field of invention relates to an enterprise level test environment which provides a method for test configuration, developing and managing test data and test reports in interoperable ways across various testing platforms.

BACKGROUND OF THE INVENTION

Generating, collecting, analyzing and consuming test data are keys to business intelligence for companies. Managing the creation of test plans, test automation, test data and then utilization of very expensive assets becomes a discipline and process of its own. The tests are often too complex to do manually and far too time consuming to be executed in a manufacturing environment. This testing process is not only time consuming but also resource intensive and thereby negatively impacting impacts the overall system design productively. The framework of database and test tools wrapped around this process is referred to as a test automation framework. Test automation is a key component of test processes and critical to enhancing the productivity of the overall team. Such infrastructure provides these companies with a competitive advantage in systematically defining test plans and then quickly achieving automation and generating large amounts of intelligent product critical data.

Automatic Testing Equipment (ATE) industry has pushed to develop a framework which would support the sharing of test information, data and results across various enterprise platforms. Usually the test engineer develops a test plan comprising of design of the testbed, equipment, test specification and other testing requirements. Based on the test plan, the test equipment is assembled and testing team orchestrates the automation requirements and further collects, analyzes and reports the data upon test completion. Such a process of developing tool sets that automate the test activity is known as business process automation.

The test process for any given company can encompass test plan development, equipment selection, automation software development, data collection and storage, data analysis, test report/data sheet assembly and publication, supply chain test monitoring (contract manufacturing), test station utilization, test station reservation and scheduling, test asset calibration and tracking, and manufacturing execution system (MES).

Technologically, the testing system and their framework can be classified into three main groups of systems. The first one represents the multiple standalone station which do not share any data, computing resources (such as server, data storage among others), test & data formats. These systems are highly fragmented and have a significantly different test data and process format from one test station to another. This configuration represents fragmentation to the extreme end where the test data format may vary from one test-station to another test-station within the same group resulting in an extremely inefficient system.

The second group of testing systems and framework include a system with its own dedicated file server where the test data and the test plans are centrally deposited and stored within an organization or a group. This obviously provides a more centralized approach to the standalone system as described above. In such configuration test plans typically begin with engineers developing text to spreadsheet plans with various individual formats and storage locations. These then translate into individual automation plans and automation solutions with minimal amounts of reusability. In both above cases, once automation is developed and in place, the production, storage, analysis and publications of results ranges from local text files to haphazardly organized file shares.

The third approach is a client-server based system for configuring and managing the test station and test data and process. This involves a structured and organized approach to managing the data and its format for providing higher degrees of interoperability to users within the same group or organization. The structured approach gains efficiencies in structuring data however creates a very proprietary and investment intensive system. The system in such scenario may not be interoperable within geographically dispersed group/organization and will definitely not be interoperable across various organizations.

Each of these approaches introduces several challenges and therefore inefficiencies within the organization. Each of these traditional methods means internal investment of proprietary systems which, one at a time, provide business process automation to the phases above. Companies have previously followed an evolutionary path to address this process. Such unstructured management of test plans and handling of test data and results leads to productivity losses due to issues related to data portability, data organization and absence of a common platform for sharing the data within organizations and among other organizations. This creates confusion in organization of results as well as communication and publication challenges. Format of result publications and analysis reports vary from one organization to another and in many cases from one group within an organization to another group within the same organization. The absence of a unified standards and process for such test data sharing and management leads to a challenge in data management.

The inefficiencies and absence of a unified process have led to a need for an automated enterprise test system framework which allows various organizations to share data across multiple test platforms. To further leverage this unified environment a configurable test-case library can be developed and shared across several platform's based on test equipment specifications and Design Under Test (DUT) requirements. Users may then use existing test-cases and avoid developing the specific test-cases for their design thereby, adding efficiency to this overall process. Automatic Test Markup Language (ATML) has been recognized as a standard which provides XML based test information exchange among various ATEs making them interoperable.

SUMMARY

This invention allows a more open and interoperable enterprise solution. In this case a test case library can be developed and shared across several platforms based on the test equipment specifications and the Design Under Test (DUT) requirements. Users can then use these existing test cases and avoid developing the specific test cases for their design thereby, adding efficiency to this overall process. Further the invention provides a framework where the testing results can be shared and deciphered across multiple platforms and users. In order to ensure functionality such as interoperability of test data across multiple systems/platforms, a standard such as but not limited to ATML is followed for the overall system design.

The test station client side of the overall system is referred as the Agent which is executing on a Local Test Station connected to the Device Under Test. The agent maintains a constant communication with the backend system and overall application. The agent is responsible for data collection, data assembly and transporting it to the backend server system comprising of database servers, application servers, configuration and user management system server and reporting system server among other hardware components.

The backend server system stores the data from all the connected test stations. The data organization is dependent upon a specific test plan. This data is then reorganized for efficient data analysis and report generation. Test equipment and availability can be tracked and linked to the test plan in support of project scheduling and management. This capability supports a single-site or world-wide capability. Assets can be tracked and the database capability of this product enables calibration and maintenance information to be monitored.

The system user is able to mine the data in order to perform engineering analysis and overall report generation. Engineering analysis workflow allows a user to select a part of the whole data, assign mathematical analysis functions for issues such as performance judgment, reliability analysis, characterization and manufacturing test among others. As the product development lifecycle moves into the manufacturing and commercialization phase, such automated tests will continue to be run on each product as it moves through the manufacturing workflow. Such analysis is the key component of business intelligence analysis phase for a product development and manufacturing organizations.

The test plan development component provides a standardized method of developing the test plan. This component supports plan development across multiple users and locations. The test development component would further allow sharing the test plan and obtaining its approval from other stakeholders. The test plans can be linked to equipment availability and test software, and may be used as the basis for the actual test flow execution. The Test Software Library management component is interfaced with test plan development component. This automation system component maintains one or more reusable software libraries. Any user connected with the overall system can access any part of the library or add other test routines to the existing library.

The system further provides users the ability to create and manage the reports of test data in a consistent and simplified manner. Customizable reports developed using the tools within this system, can be published, stored, and distributed from within the system. Reports can also be reusable to allow similar information to be reported over time or location using new data. This capability not only allows a user to monitor in-house processes, it also allows the user to monitor contract manufacturing or distant sites. These reports can further be published with various levels of access control with other users within a group, entity or outside of entity.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1represents an embodiment of the overall system, i.e. an enterprise tool for planning, executing, managing, collecting, storing, analyzing and reporting data related to automated testing. The various users of the system may be test operators, test engineers, design engineers, managers, quality assurance staff, customers and vendors.

The Device Under Test (DUT) is referenced as100.100may be either a physical device or a software component where test observations and measurements may be conducted. Examples of devices include, but are not limited to electronics components and systems like semiconductor chips, processors, circuit board assemblies and components. Physical devices may also extend to mechanical items and mechanical products such as metal fasteners, pressure tanks and engine components. A device may also be further extended to support measurement of physiological organisms in the bioscience domain. Data collection is not exclusively associated with physical objects. Software modules may also be tested and characteristics of the software could be measured and analyzed and may therefore also be considered as a unit under test. Data collected and managed by the system originates from observations and measurements of100. Such measurements may be, but are not limited to, sensor measurements, analog and digital voltages, characteristic observations, performance criteria, and collection of software statistics. Specific part states or environmental stimuli like voltage, temperature, and device mode can be generated and used to stimulate100. These measurements and stimuli are generated and imparted to the Device via interfaces102and104.102are the interfacing signals connecting one or more test equipments106with device100. The interfacing signal may connect through wired or wireless logical media. Test equipment106is used to generate stimuli and conduct measurements and observations on100.106may consist of, but is not limited to oscilloscopes, power supplies, logic analyzers, protocol analyzers, or dynamometers. These may generally be but are not limited to off the shelf equipment, which interface with device100via interface item102and with the test controller via110.110is the physical and logical protocol layer which is used to connect106with test controller120.120comprises of a physical processing device such as a PC116, in combination with an Agent118and Test Software114. Layer110enables, commands and controls communication from test controller120to test equipment106. These control interfaces may be but are not limited to GPIB (General Purpose Interface Bus), serial, USB, wired and wireless Ethernet. On the test equipment measurement side,106may record measurements or may only be a data collection method from which data is passed back to test controller120. In the latter case,114would processes the data and create a resultant measurement and judgment.

Test controller120commands and communicates with100via112,108, and104to control states, program modes, load executable programs, read back information, and other tasks.

104is the physical interface to access device connections on100. Such interfaces are the logical and physical communications and access points required to connect the Device Interface Equipment108to the device under test100. Communication channels include but are not limited to SPI, I2S and other industry standard or proprietary standards.

The Device Interface Equipment is referenced by108. This is generally but not limited to customer interface circuit, software test harnesses, or physical fixture required for100to have test and or command and control points made available for120. Interface108may contain items such as relays, customer circuitry, special mechanical adapters, or anything else required to control and communicate with100.

Physical and logical interfacing protocols such as JTAG, USB Serial and I2S and other industry standard or proprietary protocols is referenced by112and is employed for connecting test controller120with Device Interface Equipment108. This interface is used to pass bi-directional information between the test controller120and the device interface equipment108.

Test Software114comprises test routines and test sequencers. Test routines are algorithms and software implementations executing on the hardware/PC116that are responsible for implementing test and measurement procedures. Procedures are implemented using combination of instrument control, device control, device stimuli, protocols, sensor observations and processing routines to calculate measurements and observations. Test sequencers provide the test routine execution order, control and results partitioning and organization.

Agent118is responsible for detecting/receiving notification of results from the test software114then encrypting, compressing, and submitting packaged resultant data to data receiver module126via an internet interface124. Agent118also maintains periodic communication with the configuration management subsystem138via internet interface124to verify eligibility and connectivity for data upload.FIGS. 2 and 3further illustrate the agent status process and data upload process. An agent must be operating on each test controller participating in the system.

Hardware/PC116is any type of computer and operating system, either industry standard or proprietary, which can execute Test Software114including test routines and analysis. It provides the logical and physical interfaces to connect with110,112, and124; and human interfaces to connect and interact with122via116.

122represents an entire Test-Station as a sub-system/module, comprised of components labeled100to120.122is the physical and logical association of all the devices, equipment, algorithms and interfaces for the conducting of tests. Test-Station122is managed by the overall system disclosed as part of this invention.122may vary from the sub-system configuration described above to another sub-system configuring comprising of different components or its variants. Further,122may be placed in a single deployment or as a part of larger system including numerous test stations in close proximity or in geographically distributed locations.123indicates that there may be any number of instances of the test station. The test stations may or may not be the same and they may or may not be in the same geographical location.

124represents the web-services connections between Test-Station Subsystem122and data collection and configuration management subsystems, which provide a communication and data transportation function between the test station and the rest of the system. This interface is used by multiple participants in the system and is a broker between the data receiver(s)126, agent(s)118and configuration management module138.

126will receive encrypted and/or compressed data packets from the124. Data receiver126accepts the data packets, decrypts and decompresses them, and checks the integrity of the data packets. There could be multiple instances of Data receiver126configured and executing simultaneously on one or more servers or configurations. Further126may be geographically dispersed based on the system configuration requirements.

Recovered data packets from126are transmitted to Data Parser128. There may be multiple Data Parser instances of128executing on various data formats.128stores the parsed datasets into an appropriate backend data repository130.130can be but is not limited to databases and file storage. Instances of126,128and130may be geographically collocated or distributed.

The data repository130stores decrypted, decompressed, parsed, validated data. There may be one or more instances of data repositories on any given site as well as geographically distant deployments. Furthermore,130provides data organization and logical and efficient access (retrieval) to other components of the overall system. Data in130may be later annotated and commented on by other system participants.

Data from data repository130is accessed by physical application servers132, containing the logical and physical items124-150. These are servers with processors, memory, writable media, power supplies and located in temperature controlled facilities such as a data center.

134is the configuration management repository. This houses meta-data associated with the system configuration information. The configuration management subsystem can be implemented as, but is not limited to, a database. It can be but is not limited to storage of usernames, passwords, payment information, station information and workspace saving and other information associated with the configuration management module138.

The configuration management module138comprises Station Configuration and Management Module136and User Configuration and Management Module137.136contains account configuration related information such as the entity owning the stations, the station types, the users assigned for managing a station, equipment associated with a station, among other station attributes. When a user initially attaches a Test Station122to the system,136is invoked and deploys the agent118to the test station122. Together,136and118record all the information associated with the actual deployed station and owner. Additionally,136is responsible for deploying updates to the agent as updates become available.136can also identify and track test equipment106and test software114in the test station122to support station hardware and software maintenance.136also tracks the number of station licenses that have been activated. The details of process flow of module136will be further explained inFIG. 6.

137is the user configuration and management module. This module is responsible for creating users and managing their permissions and preferences within configuration management system138. Every registered user within the system is associated with one or more entity.138plays a vital role in selecting and saving the customized workspace preferences for all users. This module provides them with several advanced system configuration options, such as user workspace, filter and select criteria for data, and organization of results returned from the mined data.FIG. 5, User configurations discusses further details about the user configuration flow.

The payment processing engine140is responsible for accepting and processing payments, managing policies for various payment options, and managing and displaying payment history.140keeps track of the amount of data purchased, the number of user and station licenses purchased and activated among other payment parameters.

The Data Analysis and Visualization Module149comprises the Data Mining Module142, the Data Analysis Module144, the Report Building, Generation, and Publishing Module146and the Data Visualization Module148. The data mining interface142allows system users to interact with data stored in the data repository130by providing capabilities such as browsing, search, filtering and commenting on selected data. The user preference module provides the user-level customized user-interface for interaction with the stored data in130.FIG. 9provides an example illustrating the real user interaction with149for accessing the stored data in data repository130. The Data Mining Module142allows the user to proceed to the Analysis module or to jump directly to the QuickVIEW module. The QuickVIEW flow and process is described in further detail inFIG. 4.

The Data Analysis Module144allows the user to apply standard analytical functions and calculations such as standard deviation, process stability, and others data selected from data repository130. It also supports sending data to and receiving results from external analytic software such as Matlab in order to provide extremely advanced analysis capability. The module allows the user to associate data with user-defined object(s) referred to as (an) output variable(s). The user can further use the output variable as a system object and perform operations and analysis.FIG. 4illustrates the detailed data analysis flow.

The Report Building, Generation, and Publishing Module146allows users to define or reuse their customized reports using data analysis of Data Analysis Module144. Data analysis reports for a selected output variable or group of output variables from144are then assigned to146for publication and sharing with other system users based on user defined permissions. Processed reports and report templates are stored in a configuration management repository134.148is the Data Visualization Module which provides users the capability to interact with the mined and analyzed data against each output variable.

The Test Software Management Module156comprises the Test Sequence definition and management module143and Test Software Library management module145.143provides the capability to develop sequential test flows (test sequences) via the web interface150which can then be downloaded to the test station(s)122and123. The Test Sequence development block143is accessed via the web interface150. From this tool, the user defines a sequential test flow which is subsequently stored in the configuration management repository134. The user may then download this test sequence, via the station configuration and management tool136, to the test station122. The test software114within the test station accepts the sequence and is able to interpret and run the sequence.145allows users to add test software to the configuration management repository134from the web interface150. Software that is added may be flagged as private, in which case only the user or users group make access and use this software. The software may also be flagged as public, which makes the software available to all systems users. The software may be selected from the web interface150and downloaded to the test station122via the station configuration and management tool136. Once the software is downloaded to the test station, the user of the test station may incorporate it into the test program.

Users can interact with the overall system for data visualization and analysis through the user interface150which could be a web-based program executing on any web-browser (on a physical computer or a mobile device such as a tablet) or a client based interface.150serves as a communication layer between web-browser-based front-end152and the backend system.152provides user with capability for interaction with backend system for all functions related to138,140and149as discussed above. The system user154interacts with the overall system for various tasks as discussed above.

FIG. 2shows the process of agent executing on the test controller as described inFIG. 1. As part of the client side of the overall system implementation the process continuously monitors the agent connection status with the backend system. The initial state200of the process is to launch the agent, which may be manually or automatically upon the system start-up. Decision204controls the process flow after the connect attempt202. The subsequent actions of the agent process depend if the connection was or was not successful.206is the process that the agent follows if decision204was negative. At this point, the agent notifies the user, via an icon in the test controller menu bar that the agent was not able to connect to the station configuration and management function136. The agent will iteratively return to202and restart the polling process.208is the process flow the agent follows if decision204was positive. At this point, the agent communicates with the station configuration and management function136and sends136the specifics of the test station that the agent is running on.208then receives confirmation that the agent is either running on a valid test station or that it is not running on a valid test station.212occurs when the agent receives notification from the station configuration and management function136that the agent is not operating on a valid test station. When this happens the agent will notify the user, via the icon in the test controller menu bar, that the station is not a valid test station. In addition the agent will set the “Processing” flag to off in220. This flag is used by the data monitoring functionality of the agent, described inFIG. 3, to enable or disable data upload capability. The agent process will then restart the polling process by returning to202.214is the step in the process that occurs after the agent receives notification from the station configuration and management function136that the agent is running on a valid test station. The agent will then upload additional information about the test station to the station configuration and management function136.216and218are the final steps in a successful connection to136. In216, the agent will notify the user, via the icon in the test controller menu bar, that the test station is connected to the Agile-Test system. In218, the agent will set the “Processing” flag to on which will which will enable the data processing as described inFIG. 3. Finally, the agent will restart the polling process by returning to202.

FIG. 3depicts data-file movement and processing within the agent and transport processes. It shows various possible states a data-file may enter before and during communication with the backend server system. Once the agent is launched in200, it waits for the “Processing” flag, as described inFIG. 2, to be set to on.300is the decision step for evaluating the processing flag. If the flag is set to off, the upload process is denied and the agent continues to monitor the status of the flag. If the flag is set to on, the upload process is allowed to proceed. After validating its connection integrity and station eligibility, the agent initiates the process of data transfer and data parsing through126,128and130(discussed inFIG. 1) then storing the data in130(FIG. 1). In order to move this data file, the agent process module checks the data present in system inbox for being transmitted to the backend system302. The Agent module further could be in a debug state mode or submit state mode. In debug mode306, the system allows the agent to operate normally without submitting files to the backend system servers while in the Agent Mode of Local Submit, the system allows a user to submit the data file to the local database310. This mode may be enabled by the user to allow the agent to submit files to a local database, specified in the agent control panel, in addition to submitting the files to the cloud database(s)124-130inFIG. 1. If the system is not in any of the three above discussed modes, then the system is in transmission mode where the files are submitted to the backend data store. In order to achieve this, the data files are assembled and compressed using the native or a third party compression algorithm312, and then the files are moved to the outbox314to be transmitted. The system at this point checks the assembly of file316, if the file is not assembled properly then the file is moved to the error directory318and the system displays the corresponding error in record uploading status320.318occurs when316determines that an error is present in the data package. At this point the data package is moved from outbox to the ‘error’ directory. After an error has been identified, and the package moved to the error directory, the agent displays an error message via the agent icon in the test controller menu bar. At this point, the agent will resume polling the inbox by returning to302. However if the file was assembled properly, the system continues submitting the file until it gets a proper connection from the backend and the file is submitted. The system communicates with the data receivers126(part ofFIG. 1) to determine if the packaged data was successfully received. Once the file is successfully submitted the system also places the copy of the file to the submitted directory328along with other attributes such as time, stationID, and the user who submitted the file. At this point, the agent will resume polling the inbox, returning to point302.

FIG. 4depicts the user integration for data visualization with the overall system. This illustrates the iterative process of searching, selecting and analyzing data as well as how the data gets reported. The first step in the data processing flow consists of selecting the desired data set from a large data set by limiting the conditional scope of the data400. Such selection of the data set in401is accomplished by selecting and deselecting condition parameters associated with the overall data population. These conditional parameters include the start time of test, unit serial number, test name, test limits, test outcomes, environmental conditions, test station, test operator among others. Output of this stage is fed to Select Data Subset402. This represents an iterative process of performing multiple analyses on multiple data variables. From the reduced data set of402, the user selects I or more similar data subsets to be further analyzed or having the underlying data assessed quickly403. This flexibility allows a user to carry out either detailed analysis on similar types of data over different statistical populations, or quickly visualize the selected data and export and/or download it.

Analyzing results412consists of steps, drive output variable name404, assign to output variable406, associate analysis with output variable408and run analysis410. Analysis of results412could be carried out two possible operations after the data subset(s) are selected in step402: (1) by driving an output variable name404, (2) by assigning to the output variable name406. This allows a user to use the data subset(s) ‘names’ that exist in the database as “output variables”. This (default) case allows the user to keep the data subset(s) name and carry it forward to step408and for inclusion in the final report414. Analysis is performed on “output variables”, so the data subset name(s) in this case are assigned to output variable(s).406allows a user to associate a name different than the data subset(s) name as in case of404with an output variable. Such flexibility allows a user to rename data subset names for the final report414and make it more customizable as per their requirements and needs.408associates any possible analysis types such as mean, standard deviation and maximum among others with any selected output variables from either404or406. Any combination of analysis types may be associated with any combination of output variables. This feeds to the next step of actual analysis410. In addition to built-in analysis types,408and410may also be configured to send data to third-party or proprietary analysis software to enhance the analysis capability of the system. During these steps of400,402,404and406all the selections are stored in the local memory of the system and when the user can save filter and selection options at the backend to save the workspace discussed in detail inFIG. 5. Up to this point, only data pointers have been used to filter and select data subsets. However the actual data has not been processed. During analysis410, the backend servers will execute the assigned analysis types of output variables408on the selected output variables of steps404and/or406. Process414is the assigning of analysis results obtained in410for a report. The user will keep assigning results to a report using the iterative process until completing assigning all the variables to the report as per their requirements. This iterative mechanism,416, of selecting various sets/subsets of data and assigning them to the output variable, executing analysis and assigning the analysis to a report could be executed multiple times until all the requirements for preparing a report is accomplished.

The final step in the data selection and reporting process is publishing the report418. Publishing means the report is formatted into a downloadable human readable format and made visible to a predefined audience. This allows the user to select the group of people who can view a report as well as access permissions associated with the report such as read, write and modify.

The user can also select the option of Fast Access of data432from403. Step432allows the user to quickly view the data and apply some simple data manipulation and visualization techniques424. This processed data can further be either downloaded to the local machine or onto a remote connected memory drive434, applied to a third-party tool/environment such as a matlab, spotfire, Simulink among others436or exported to a third party interface either connected through a web-based environment, application programming interface or a client server application running on host machine438. The QuickVIEW data process allows a fast path from data filter and select to visualization and export.

FIG. 5demonstrates the process of User Workspace Configurations. A user can select the Data Visualization module500(shown inFIG. 1as module148). The user can select one of three options of Workspace Operations Management Module504, Save, Load or Delete. Users interact with large numbers of datasets. During this process, the user may create and manage different perspectives to mine and manage data. These perspectives are referred to as workspace in this invention. The user often may interact with the data in a specific methodological manner or style. It would be more effective and efficient if a user is allowed to save their workspace to later apply these workspace templates to analysis of different sets of data. The user workspace configuration allows such functionality. The user saves a workspace to backend configuration management system138(inFIG. 1). 138then records the state of all user selections510. At this time the entire state of the workspace is collected and represented in the backend system configuration management repository. The user can further associate these states with the selected names512. At this time all the metadata gets associated with the user workspace. The user can load existing workspaces from a backend system configuration management repository506. This would allow users to retrieve the entire state of all user controls, selections and configurations from repository130(FIG. 1) associated with selected workspace514and update the user display with the new workspace516. A user can also request for removing existing workspaces from the backend system configuration management repository. The system prompts the user to confirm removal of workspace522before permanently removing it from the backend system configuration management repository. Upon the user's confirmation, the workspace is removed from the list of saved workspaces in the backend system configuration management repository514.

FIG. 6shows the process of station management. Station management configurations are stored in configuration management module138(shown inFIG. 1) via web-interface150(shown inFIG. 1). The user has the ability to add one or more station602, remove one or more station604, and modify station data606from the high level station management configuration module138via web services.

Upon selecting602, the system checks for the availability of a new license608. If the entity has no more system licenses628, the system requests the user to add new licenses for the entity via their system administration630. However, if the entity has a new license, the system allows the user to download the Agent610. At that time the agent launches and extracts information regarding that particular station and gets installed on the test station612. The agent, the test station and other system information, such as, but not limited to machine name, OS version, system owner, and hardware, is sent back to the backend system and stored in the station management configuration module. The information collected in614is posted back to the system. This becomes part of the permanent station record. The invention tracks the version of agent that is deployed to the test station616. Once the information is received, the backend system checks for the correct installation of the agent618, in case of a successful installation622, the process terminates, otherwise the user is provided with an option to download the agent and install it again on the test station626.

Similarly to adding a station, the user can select to remove one or more station604. The user is then requested to select a station or a group of stations to be removed from the entity station configuration632. Upon confirmation of deleting the station634, the station(s) are removed from the system level station management configuration.

The station user can further modify the default or previously set station attributes such as station name, user name, or any other station attributes in606. In such a scenario the user is prompted to select the station to modify638, and select attributes to modify640. On providing new attributes, the user can confirm the modification642, to save those attributes in the station management and configuration system at the backend.