test automation · web viewthe purpose of this document is to provide information on the test...

Test Automation Architecture and GuidelinesVersion 1.0

TABLE OF CONTENTS

1 INTRODUCTION................................................................................................41.1 PURPOSE....................................................................................................41.2 SCOPE........................................................................................................41.3 OVERVIEW..................................................................................................4

2 TEST AUTOMATION ARCHITECTURE...........................................................52.1 SUITE DRIVER.............................................................................................72.2 SUITE TABLE...............................................................................................72.3 SCRIPT DRIVER...........................................................................................72.4 DRIVER TABLE............................................................................................72.5 TEST SCRIPTS.............................................................................................72.6 DATA TABLES..............................................................................................72.7 LIBRARIES...................................................................................................72.8 OBJECT REPOSITORY..................................................................................82.9 ENVIRONMENT.............................................................................................82.10 RECOVERY SYSTEM....................................................................................82.11 REPORTS....................................................................................................82.12 APPLICATION UNDER TEST..........................................................................8

3 TEST AUTOMATION PHASES.........................................................................93.1 DEVELOPMENT PHASE.................................................................................93.2 EXECUTION PHASE......................................................................................9

4 BEST PRACTICES TO MEET QUALITY FACTORS......................................104.1 MAINTAINABILITY.......................................................................................10

4.1.1 Complete Data Abstraction..................................................................104.1.2 Modular Design...................................................................................114.1.3 Object repository.................................................................................12

4.2 RELIABILITY...............................................................................................124.2.1 Exception Handling..............................................................................124.2.2 Recovery from Failures........................................................................144.2.3 Screen Resolution...............................................................................144.2.4 Frozen Release of AUT.......................................................................154.2.5 Regular Expressions............................................................................154.2.6 Synchronization...................................................................................154.2.7 Test Case Independence.....................................................................16

4.3 REUSABILITY.............................................................................................174.4 PORTABILITY.............................................................................................174.5 CONFIGURABILITY......................................................................................174.6 USABILITY.................................................................................................174.7 DISCERNABILITY........................................................................................19

4.7.1 Indent Blocks of Code..........................................................................19

Copyright © 2004 Virtusa Corporation Test Automation Architecture, Confidential 5/9/2023

1

4.7.2 Use With and End With Statement......................................................194.7.3 Scripting Standards.............................................................................194.7.4 Action Template...................................................................................194.7.5 Comments...........................................................................................204.7.6 Continuation Operator.........................................................................21

4.8 PERFORMANCE..........................................................................................224.8.1 Use Select Case Statement instead of Nested if loops.......................22

5 FOLDER STRUCTURE...................................................................................23

6 SCRIPTING CONVENTIONS..........................................................................246.1.1 Test Scripts..........................................................................................246.1.2 Generic Functions...............................................................................246.1.3 Application Specific Functions.............................................................246.1.4 Data Sheets.........................................................................................246.1.5 Reusable Actions.................................................................................246.1.6 Variable Naming Conventions.............................................................256.1.7 Constant Naming Conventions............................................................256.1.8 Repository Files...................................................................................25

7 Sample Template.............................................................................................25


2

Document Revisions

Date Version Description Author28-Apr-2005 1.0 Initial Ramesh Raavi

Definitions, Acronyms, and Abbreviations

Term DescriptionAUT Application Under TestQTP Quick Test Professional


3

1 Introduction

1.1 PurposeThe purpose of this document is to provide information on the test automation framework for ING TPA Payroll manual test cases. This document can be viewed as a reference guide for those involved in building and maintaining automated test scripts.

The intended audiences for this document are ING TPA Payroll team, Virtusa Test Automation Team and Project Management Team.

1.2 ScopeThe document will describe the following:

1. Introduction2. Test Automation Architecture3. Test Automation Phases4. Best Practices to Meet Quality Factors5. Folder Structure6. Scripting Conventions7. Change Management8. References9. Index

1.3 Overview<TBD>


4

2 Test Automation ArchitectureThe below block diagram shows the architecture at a high level. The Architecture framework consists of the following key items:

1. Suite Driver2. Suite Table3. Script Driver4. Driver Table5. Test Scripts6. Data Tables7. Libraries8. Object Repository9. Environment10.Recovery System11.Reports12.Application Under Test


5

Figure 2-1 ING Test Automation Architecture


6

2.1 Suite DriverSuite Driver is a script used to maintain and execute the test suites. This script would take the inputs from the suite table. Suite driver gives user the flexibility to execute the required test suite (Regression suite, Smoke suite, BVT suite etc.).For example, to execute only Smoke test suite, the suite driver would invoke the respective script driver, which would run the appropriate scripts.This script will trigger Script driver to execute selected suite in the suite table. Test suite status would be reporting to Test Reports.

2.2 Suite TableIt is repository of all test suites to be tested. Suite table would provide the information to the suite driver to act upon the script driver. The following table illustrates the Suite Table.

2.3 Script DriverScript Driver is a script used to maintain and execute respective test scripts. This Script would take the inputs from the Driver table.For example,

2.4 Driver TableIt is repository of all test cases to be tested. Driver table would provide the information to the script driver to act upon the test scripts. The following table illustrates the Driver Table.


7

2.5 Test ScriptsTest cases (from the existing manual test cases) are being identified and converted to automation test scripts. Test scripts are executed to achieve the test objective defined in driver table. All test scripts would take test data from data tables. The test scripts would reuse components from the Business and Generic libraries. This test scripts would take object information from the Object Repository. After Executing, Pass or Fail details would report to Test Results.

2.6 Data TablesThe test data would be maintained in Data tables, and organized by functional topics. The architecture would use the ‘data driven approach’ to retrieve test data required by the test scripts.

2.7 LibrariesLibraries would help avoid code duplication across the test suite and promote code reuse. Libraries are also logically divided into Generic and Business.

Generic Library: Generic library incorporates canonical functions and procedures of the each framework that would be reused by all the test scripts in the architecture. These generic functions can contact the Object Repository, Test Scripts and Script Driver.

Example: fgCloseAllbrowsers() is used before or after executing the test script.

Business Library: Business library pertains to functions and procedures related to business tasks/functions of the ING application. These business functions also contact the Object Repository, Test Scripts and Script Driver.

Example: fbTableValidator() is used to validate the contents of the table in the business logic.


8

2.8 Object RepositoryObject repository is an interface between test scripts and the application objects. It consists all AUT objects logical names and physical properties. Object Repository will be shared across the test suite. All business and generic functions are also able to access the Object Repository.

2.9 EnvironmentEnvironment is a XML file used to define all error messages, minimum wait time, maximum wait time, location of the screen shots (if application fails) and location of the Test report.

2.10 Recovery SystemRecovery system is used to recover the automation suite from major errors in the AUT (show stoppers), or minor failures (login failures), or any unexpected errors (browser popup’s) at runtime. These errors makes almost impossible to continue with test execution. In such situations, the recovery mechanism will stop or recovery from the failures or recovery from the unexpected events.

2.11 ReportsEach script execution report would contain stepwise Pass/Fail information. These reports would be easily accessible and allow detailed analysis.

2.12 Application Under Test<TBD>

3 Test Automation PhasesThere are two phases involved with the creation, setup, and implementation of the Test Automation Framework: Development Phase and Execution Phase.

3.1Development PhaseDuring the Development Phase the following activities are performed:

Test Scripts are created and debugged in QTP.


9

Test Scripts are uploaded into the Test Scripts folder and link with Script driver. Test Data is maintained in a Data Tables and is stored in the Data folder. Generic, Business Library functions are stored in the Library folder and use in

Test scripts. Start-up script, Clean-up scripts are stored in the Environment folder. Object Repository files are stored in the Repository folder and it used by test

scripts. All Reusable actions are stored in the Reusable Actions folder. Test Reports are stored in the Reports folder.

3.2 Execution PhaseDuring the Execution Phase the following activities are performed:

Script Driver is executed via the Suite driver script. Test scripts are executed via the Script driver. Start-up script, Clean-up script and Environment files are retrieved from the

Environment folder. Test Data is retrieved from the Data tables. Generic, Business Libraries functions are retrieved from the Library folder. Object Repository files are accessed from the Repository folder. Test reports are captured in the Customized Report Log files.

The typical test script execution flow is as follows:

1. In Script Driver Load all run-time test settings (Object repository, Generic, Business library, Recovery System, Data Tables and etc.) by executing a Start-up script.

2. Call Test Script from the Script Driver.3. Define and initialize variables that will be used during test script execution.4. Retrieve related test data from the appropriate Data Tables.5. Invoke and use the Generic, Business Library functions.6. Call the appropriate Reusable Actions to execute common functionality

embedded in the script scope.7. Execute test logic and test conditions in the script to achieve the intended

functionality.8. Report the test results at the end of the execution.9. Release memory resources by calling Clean-up script from script Driver.

4 Best Practices to Meet Quality FactorsThe success of a good Test Automation project in the long run can only be judged on how the best practices are applied to the framework in order to meet the following quality factors.

i. Maintainabilityii. Reliabilityiii. Reusabilityiv. Portability


10

v. Configurabilityvi. Usabilityvii. Discernabilityviii. Performance

4.1 MaintainabilityMaintainability is the ease with which a script be corrected when an error is encountered, be adapted if environment changes, or be enhanced if requirements change. The following standards can help minimize the time required to actually build and maintain test scripts.

1. Complete Data Abstraction2. Modular Design3. Object repository

4.1.1Complete Data AbstractionThe architecture is designed to separate input data from the script logic. Test data that is required for the entire script will be maintained in the Data Tables. It is easy to export/import data from the data tables. If the data needs to be changed (to change the inputs and outputs), it can be carried out independent of script changes. Based on functionality, the Test data is maintained in separate Data tables.

4.1.2Modular DesignBreaking the script down into modular functions makes the code easier to maintain. Changes in common functionality of the system would affect the test suite. A long succession of executable lines of code or repeating lines can be consolidated into a single function to make the script much shorter and more modular.

Script modularity can be achieved by using:1. Generic, Business Library2. Actions and Reusable Actions


11

3. Start-up and Clean-up scripts

4.1.2.1 Generic, Business LibraryThe architecture generic, Business library will minimize the impact of rework by providing a single place of maintenance. Thus, a change that affects a lot of scripts can be isolated to just a few modifications to the ING Application.

specific, Navigation, Data verification and Report functions. Each of these functions will return a value indicating whether the function was successful and leave the system in a known state.

4.1.2.2 Actions and Reusable ActionsAn action divides a test script into logical units. A more modular and efficient test suite can be designed by dividing a test script into multiple actions by creating new actions and inserting calls to them, or by inserting calls to existing reusable and external actions.

With reusable code, the length of test script code can be minimized and another layer of action calls can be abstracted to provide one more level of modularity to increase the script versatility and maintainability.

The following example uses the RunAction statement to run two reusable actions namely LoginNAW, and OpenNAWApplication.

4.1.2.3 Start-up and Clean-up scriptsStart-up script is used to set up the test execution environment prior to a test run. This script will be basically used to select appropriate add-ins required for test execution, to setup screen resolution, load the Generic, Business file (.vbs file) into resources tab, load Object Repository, load Recovery system and data tables at run time.Cleanup scripts essentially close all the open browsers of the AUT and release all the memory resources.

4.1.3 Object repositoryAll the user interface object information (Pages, buttons, Lists and etc.) is wrapped in Object Repository. The object repository concept would shield the underlying changes in physical description from the test script logic in turn minimizing the impact of change. Tool shared objected repository concept would be implement for this architecture. If any changes to object descriptions can be adapted in one single location.


12

4.2 ReliabilityReliability is the probability that the automation test suite will provide failure free operation with consistent test results in a stated condition (for instance, the frozen release of the AUT) for a fixed interval of time.

4.2.1 Exception Handling The architecture will utilize the built-in exception-handling mechanism (i.e., Recovery Scenarios) and Exception functions. Therefore, pre-defined exceptions such as unforeseen pop-up windows like Security Alerts; Proxy Alerts etc. can be handled at script level to ensure test script execution continuation.

The “On Error Resume next” statement will be used at the beginning of each procedure or function to prevent run-time error messages to be displayed and proceed with the subsequent statement to facilitate uninterrupted execution.

The “On Error GoTo 0” will be used at the end of the function in order to disable error handling, that has been previously enabled using the “On Error Resume Next” statement.

The following code illustrates a SecurityAlert exception function the clicks on the “Yes” button whenever the Security Alert window is displayed.


13

Figure 4-2 Exception Handling


14

4.2.2 Recovery from Failures Failures can be defined as major errors in the AUT (show stoppers), or minor failures (login failures) that make it almost impossible to continue with test execution. In such situations, the error handling mechanism will stop the test execution and send out an email or page to notify the appropriate personnel about the test failure, so that they can take the appropriate corrective action.

The following example illustrates a scenario to handle Login failure. “ExitRun” statement exits the test execution and the emailOut() function sends the required email or page.

4.2.3 Screen Resolution

A fixed screen resolution is required during the development and test execution phases to avoid resolution errors. This guideline applies only to a limited set of automated cases such as a situation where QTP cannot recognize a particular object in its object form and there may be a necessity of mapping the particular object to a standard QTP form. In these exceptional cases QTP features like Virtual Objects or Low Level Recording can also be used (even though Bear does not recommend them as a rule).


15

4.2.4 Frozen Release of AUTA frozen release of the AUT is recommended for the Test Automation Suite development. This will ensure that object description changes and new functionality enhancements will not have any impact on the Test Automation Suite.

4.2.5 Regular Expressions A regular expression is a string that specifies a complex search phrase and enables QTP to identify objects as well as text strings with varying values.

For Example, Let us assume that a web element displays the current version of AUT with the label “version v5.5.3”. Since the AUT release number changes with every new build, the label can be wild carded using regular expression as ‘version v*’”

4.2.6 Synchronization Latencies and timing uncertainties in the response time for the AUT depend upon various factors such as total elapsed "round-trip" time; network speed and type of connectivity (i.e., if VPN connectivity is used to connect to the server the response time is very high).

Synchronization points, Exist and WaitProperty functions will be used in the test scripts to handle anticipated timing issues. For instance these will be used while waiting for an object property to have a desired value, waiting for a window to be displayed or a page to load. “Timer” function can be used to capture the amount of time each synchronization point actually waits.The following example uses the Timer function to determine the time it takes to iterate a For...Next loop for 10 times:


16

Figure 4-3 Timer Function

4.2.7 Test Case Independence Each script is completely independent from the previous script i.e. test script must be designed to have the same initial conditions and end conditions. Dependencies are only at functional level, but at the design level each script is independent with its own recovery mechanism.

If an initial condition of a script is to “launch an AUT”, then the end condition should be “Exit from AUT”. This ensures that the test script does not fail for multiple iterations.


17

4.3 ReusabilityThe scripts are designed to reuse existing code from other sections of the test suite. Reusable chunks of code would be identified while creating the test suite.The reusable code can be classified into two categories. 1. Canonical components under the generic library; 2. Businesses components under the business library.

4.4 PortabilityThe architecture would be designed in such way that all test suite contents would be packaged in a single folder, to allow implementation in any of the Test Director folders.

The folder structure is defined in Section 4.1. Test scripts would be parameterized to avoid hard coding. All test scripts would be designed to adapt to any of the user and dynamically identify headings and objects at runtime.

4.5 Configurability

Configurability implies the ability of the Test automation suite to adapt to different test execution environments, browsers, and different execution sequences.

The test suite is configured in such a way that it can be executed on different test environments. For instance the hosting location for a particular web-site can be stored in a global environment variable so that even if the hosting location changes, it can be changed at one point.

Ability of the automated test suite to accommodate multiple test execution sequences.

For example a global data table listing the test script names will be used to drive a test execution cycle. Symbol (“X”) in the Keyword column of the global data table will be populated against each test script name to indicate that this particular test script should be executed in the test cycle. QTP will execute only the test scripts marked with “X” and skip the test scripts that are blank. This ensures the flexibility to execute different test types (regression, smoke, etc).

4.6 Usability

Usability is the ease with which the test script executor can perform the following:

1. Install the automated test suite2. Understand the overview of the test suite3. Execute the test scripts4. Interpret the test execution results


18

Increased usability can be achieved by following:

Test Reporting

The out-of-the-box reporting of QTP test execution results is done via the default “Test Result” tool that can be invoked either automatically or on demand at the end of each test run. However the information presented there often is not comprehensive enough or it provides too much technical detail, which can be overwhelming to a manager or a business user. In addition, the format of the default test results cannot be readily modified or exported to other tools. By using Excel spread sheets to externally report the QTP execution results. This will be implemented throughout the framework by utilizing the report function.

These customized report log file pinpoints the test execution results with the following fields:

Host Machine <TBD> Time Stamp Executor Test Script Name Test Case Name Action/Function Name Verification Result Captured Data (suppose a new account is opened, the account number is

captured and stored in the results) Result (PASS/FAIL)

This external log file eliminates unnecessary information in the QTP standard reports so that users will be able to go through these reports and comprehend the execution results of the test scripts.

DocumentationDetails of the following topics will be documented:

User guide for script execution. Maintenance guide for future enhancements. Test data requirements at run-time.


19

4.7 Discernability Discernability is the distinctness that makes perception easy. This can be achieved by using the following techniques:

4.7.1 Indent Blocks of Code

The QTP editor incorporates the auto indent feature, which is intended to improve readability and minimize code errors.

4.7.2 Use With and End With Statement ‘With’ statement will be used to perform a series of statements on a specified object without the need to re-qualify the name. For example, to change a number of different properties on a single object, place the property assignment statements within the ‘With’ control structure and refer the object once.

4.7.3 Scripting Standards Industry available scripting standards (presented in the following link) will be followed for better understanding of the purpose and logic of the automation scripts.

http://msdn.microsoft.com/library/en-us/script56/html/vbsCodingConventions.asp

4.7.4 Action Template Action Template will include the following attributes: Name, Author, Date, Description, Revisions, Information about the Data Tables, and Parameters. The Action Template that will be used in Bear automation is as shown below. At the beginning of each test script Action Template is loaded to provide the above-mentioned details for the script.


20

http://msdn.microsoft.com/library/en-us/script56/html/vbsCodingConventions.asp

4.7.5 Comments

A standardized commenting structure will be followed for test scripts and functions to give more clarity.

4.7.5.1 Scripting Comments

The Documentation Column in the Keyword View of QTP will be used as a read-only auto-documentation of what each step does in an easy-to-understand sentence. This column also enables the user to add manual steps to business components, even before the AUT is ready to be tested, as well as enter pertinent information about steps in a test script.


21

4.7.5.2 Comment Structure for function related information

The following illustrates the commenting structure that will be followed for every function that is added to the library. The comments include Function Name, Description, Input parameters, Output parameters, Date Created, Created By and Test Automation Suite Version details to give more clarity.

4.7.6 Continuation Operator


22

A continuation operator ( _ ) will be used if the code is too lengthy to give more clarity.

4.8 Performance

The time it takes an automation script to execute depends on a many different factors. Certain programming practices can increase this execution time and must be avoided:

4.8.1 Use Select Case Statement instead of Nested if loops

Nested “if” loops take longer to execute, thereby reducing the performance of the test automation tool. Bear guidelines recommend the use of “Select Case” statements instead of nested “if” loops.

In the following example, there are 8 conditions based on the AccountType and the use of the “Select Case” statement is demonstrated.

The script should be written in such a way that it takes minimum amount of time and system resources for test execution. Some important factors are:

Usage of synchronization points Using wait statements Loading a large amount of data into memory Proper checklists. Checking only the most necessary properties.

The following events would be implemented in the architecture to improve the performance of the Test suite.

Avoid Wait statements in test scripts. Set global default wait time for all test scripts.


23

Identify reusable components and use them efficiently. Get required test data for the current script in a single query.

5 Folder structure The architecture would use a consistent folder structure across the applications, which varies only with the way test cases are organized within the applications.

The folder structure for the Test Automation project will be as follows.

Folder Description/CommentsEnvironmentLibrary Contains generic library and business library functions used

across the test scripts. This Library functions would access Repository.

Repository Contains complete application objects (buttons, windows, list boxes) information with logical names. All test scripts and library files access this Repository.

Results Result folder contains all customized test results.Script Driver Contains Driver script, which is used to execute the test

script.Suite Driver Contains Suite Driver script, which is used to maintain and

execute the Script driver.Test Data Contains Test Data, which is accessible to all the test

scripts.Test Scripts Contains all ING automated test scripts. This test scripts

would access Test Data, Repository and Library.


24

6 Scripting Conventions Scripting Conventions help to design code in a structured and standardized format.

6.1.1 Test Scripts<TBD>

6.1.2 Generic Functions

Must consist of characters of the alphabet. Must start with ‘fg’ (function) or ‘sg’ (procedure). Name must stand for the functionality of the function. If more than one word is used, the first letter of every word should be in

upper case. Numerals are not allowed in the names. Actions can be used as the reusable functions.

For example: public function fgOpenWebPage()

6.1.3 Application Specific Functions

Must consist of characters of the alphabet. Must start with ‘fb’ (function) or ‘sb’ (procedure) followed by the AUT Name. Name must stand for the functionality of the function. If more than one word is used, the first letter of every word should be in

upper case. Numerals are not allowed in the names. Actions can be used as the reusable functions.

For example: public function fbNAWOpenAccount( )

6.1.4 Data Sheets

Test Data sheet must consist of letters and start with a lower case ‘dt’.

For example: dtMaster

6.1.5 Reusable Actions

Action name must consist of letters and start with a lower case ‘r’

For example: rLogin


25

6.1.6 Variable Naming ConventionsTo enhance readability and consistency, use the following prefixes with descriptive names for variables in code.

Data Type Prefix ExampleBoolean Bln blnFoundByte Byt bytRasterDataDate (Time) Dtm dtmStartDouble Dbl dblToleranceError Err errOrderNumInteger Int intQuantityLong Lng lngDistanceObject Obj objCurrentSingle Sng sngAverageString Str strFirstName

6.1.7 Constant Naming ConventionsConstant variables must be separated using the underscore (_) character.For example: CON_USER_LIST_MAX, CON_NEW_LINE

6.1.8 Repository FilesThe Repository File name convention is as follows: File name must consist of letters Must follow the following format:

o Project_Module_Function.tsr or Project_Actor_Function.tsr. If the name of an object or window in the Object Repository is ambiguous,

then it must be renamed in the format ObjectType_Label

7 Sample Template

'************************* Property Of BankOne ************************'Script Name: 'Author: 'Date of Design: 'Date of last Revision: 'Data Sheets: 'Functions Called: 'Description: Select transfer to without transfer from'**********************************************************************Option Explicit

'Start Test Dim oDb,oRecordset,oWshellDim strPageRT,strService,strActionDim strTransferFrom,strTransferToDim strLibName,strUserId,strPassword,strCurrentTestPath,strRoot


26

Dim strAcctType

'Set user-defined environment variables

Set oWshell = Createobject("WScript.shell")strCurrentTestPath = oWshell.currentdirectorystrRoot = Mid(strCurrentTestPath,1,Instrrev(strCurrentTestPath,"Test"))strLibName = strRoot & "Lib\CommonLib.vbs"ExecuteFile strLibNameCall SetEnvironmentVariables(strRoot)

'Retrieve data from Datbasesheet'Create the connection object.Set oDb = CreateObject("ADODB.Connection")oDb.ConnectionString = Environment.Value("ConnectString")oDb.Open

'Query datatableSet oRecordset=oDb.Execute("Select USERID, PASSWORD From AT”);

'Go to top of RecordSet'Assign data from Recordset to current program variables

strUserId = Trim(oRecordset.Fields("USERID"))strPassword = Trim(oRecordset.Fields("PASSWORD"))

'Relase the the DB variablesSet oRecordset = NothingoDb.CloseSet oDb = Nothing'Close database

'Login on Application

Call TMSLogin(strUserId,strPassword)Browser("Bank One Intranet").FullScreen

'Step 1'Get page title and compare

strPageRT = UCase(Trim(Browser("Bank").Page("Name").GetROProperty("title")))strPageRT = mid(strPageRT,InStr(strPageRT,"-")+2)

If strPageRT="BUSINESS SUMMARY" ThenReport Reporter,micPass,"Step 1” ," page displayed”

ElseReport Reporter,micFail,"Step 1"," page did not displayed”ExitRun(0) 'To stop test execution and exit the test

End If

'Step 2strService = "Account"

strAction = "Transfer Funds"Call ServicesTable(strService,strAction)'Get page title and compare


27

strPageRT=UCase(Trim(Browser("Bank").Page("Name").GetROProperty("ti")))strPageRT = mid(strPageRT,InStr(strPageRT,"-")+2)

If strPageRT="TRANSFER FUNDS" ThenReport Reporter,micPass,"Step 2” ," page displayed”

ElseReport Reporter,micFail,"Step 2"," page did not displayed”ExitRun(0) 'To stop test execution and exit the test

End If

call TMSLogout()call CloseAllBrowsers()


28

test automation · web viewthe purpose of this document is to provide information on the test...

Documents