Automation Test Cases Guidelines

Last update: April 6th 2006

This document describes:-

1. The directory to use when storing an OCI / WEB test case, the naming convention for the test cases, the directory structure to store the commands, the naming convention for the commands, the expected coverage of an test case and the different test suites when executing the test cases.It will be very important to follow the naming conventions, because there will be so many tests cases and commands that the only way to avoid to get lost will be to be really well organised. 2. Points to Remember while Automation. 3. How the Automation User are used and reserved within the automated test cases (Resource Manager). 4. How to configure the Test Automation Tool (TAT) before executing Automated Test Cases

OCI Automated Test Cases Guidelines

1.

OCI Test Cases Directory Structure.

There are three types of OCI Test Cases a) Positive scenario/Normal Test Cases. b) Error Validation Test Cases. c) Authorization Test Cases.

The directory structure for storing the OCI test cases is based on the OCI schema as defined in Carver or Beach: 1. http://carver/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/ 2. http://beach.mtl.broadsoft.com/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/ The OCI test cases can be divided under the following categories: System Enterprise ServiceProvider Group User Services o SystemServices o ServiceProviderServices

o o o

EnetrpriseServices GroupServices UserServices

In subversion, under Automation\test\trunk\Regression\TestCases\OCI, the following directories will store the OCI test cases:

Examples If you write a test case for Huntgroup, from the OCI schema: http://carver/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/Services/OCISchemaServiceHuntGroup.xsd

http://beach.mtl.broadsoft.com/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/Services/ OCISchemaServiceHuntGroup.xsd
You can see the OCI commands associated with the HuntGroup (Hunt Group is a Service): Requests in this schema file: GroupHuntGroupAddInstanceRequest GroupHuntGroupDeleteInstanceRequest GroupHuntGroupGetAvailableUserListRequest GroupHuntGroupGetInstanceListRequest GroupHuntGroupGetInstanceRequest GroupHuntGroupModifyActiveInstanceListRequest GroupHuntGroupModifyInstanceRequest GroupHuntGroupModifyInstanceWeightedCallDistributionRequest SystemHuntGroupGetRequest SystemHuntGroupModifyRequest The first 8 commands starts with "GroupHuntGroup", this means that they are commands at the Group Level, so when you write test cases for these commands, you will put the test cases in the GroupServices directory:

Automation\test\trunk\Regression\TestCases\OCI\Services\GroupServices The last 2 commands start with "SystemHuntGroup", so they are System commands; this means that you write their OCI test cases in the SystemServices directory: Automation\test\trunk\Regression\TestCases\OCI\Services\SystemServices

Another example would be ThreeWayCall: http://carver/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/Services/OCISchemaServiceThreeWayCall.xsd http:// beach.mtl.broadsoft.com/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/Services/OCISchemaServiceThreeWayCall.xsd

Requests in this schema file: ServiceProviderThreeWayCallGetRequest SystemThreeWayCallGetRequest SystemThreeWayCallModifyRequest So, for ServiceProvider OCI commands, the test cases will be in:

ServiceProviderThreeWayCallModifyRequest

Automation\test\trunk\Regression\TestCases\OCI\Services\ServiceProviderServices

And for System OCI commands, the test cases will be in: Automation\test\trunk\Regression\TestCases\OCI\Services\SystemServices

For an Add Service Provider test case, it would go in: Automation\test\trunk\Regression\TestCases\OCI\ServiceProvider Note that the directory is not:

Automation\test\trunk\Regression\TestCases\OCI\Services\ServiceProviderServices Because this is not a Service test case, it is a test case for the creation of a Service Provider. The OCI Schema that goes with it can be found in: http://carver/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/OCISchemaServiceProvider.xsd http://beach.mtl.broadsoft.com/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/OCISchemaServiceProvider.xsd

2. OCI Test Cases Name.

To write the test cases, you must follow the OCIschema, and the name of the testcases should be based on the schema. For example, the name for the basic Push To Talk Service test case is: OCISchemaServicePushToTalk_TC.xml It comes from the schema: http://carver/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/Services/OCISchemaServicePushToTalk.xsd http://beach.mtl.broadsoft.com/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/Services/OCISchemaServicePushToTalk.xsd

For some OCI schema, there will be only a few test cases, because you can cover all the OCI commands within one test case. But for some OCI schema, there will be many test cases in order to cover all the commands. In this case, try to re-group the commands that can be put together into one test case and choose a name that will be meaningful. Take the Services Provider Schema for example: http://carver/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/OCISchemaServiceProvider.xsd http://beach.mtl.broadsoft.com/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/OCISchemaServiceProvider.xsd

Requests in this schema file: ServiceProviderAccessDeviceAddRequest ServiceProviderAccessDeviceDeleteRequest ServiceProviderAccessDeviceGetListRequest ServiceProviderAccessDeviceGetRequest13mp2 ServiceProviderAccessDeviceModifyRequest ServiceProviderAddRequest13mp2 ServiceProviderAdminAddRequest14 ServiceProviderAdminDeleteRequest ServiceProviderAdminGetListRequest14 ServiceProviderAdminGetPolicyRequest14 ServiceProviderAdminGetRequest14 ServiceProviderAdminModifyPolicyRequest14

ServiceProviderAdminModifyRequest You can all the AccessDevice commands put in one test case, The test case name would be: OCISchemaServiceProvider_ServiceProviderAccessDevice_TC.xml And the commands it would cover are: ServiceProviderAccessDeviceAddRequest ServiceProviderAccessDeviceGetListRequest ServiceProviderAccessDeviceModifyRequest ServiceProviderAccessDeviceDeleteRequest ServiceProviderAccessDeviceGetRequest13mp2

You can put all the Admin commands in one test case, The test case name would be: OCISchemaServiceProvider_ServiceProviderAdmin_TC.xml And the commands it would cover are: ServiceProviderAdminAddRequest14 ServiceProviderAdminDeleteRequest ServiceProviderAdminGetListRequest14 ServiceProviderAdminGetPolicyRequest14 ServiceProviderAdminGetRequest14 ServiceProviderAdminModifyPolicyRequest14 ServiceProviderAdminModifyRequest

You can put all the Service Pack commands in one test case, this test case name would be: OCISchemaServiceProvider_ServiceProviderServicePack_TC.xml And the commands it would cover are: ServiceProviderServicePackAddRequest ServiceProviderServicePackAddServiceListRequest ServiceProviderServicePackDeleteRequest ServiceProviderServicePackGetDetailListRequest ServiceProviderServicePackGetListRequest ServiceProviderServicePackGetServiceUsageListRequest

ServiceProviderServicePackGetUtilizationListRequest

You can put all the commands that create, modify, list and delete a Service Provider in one test case. The test case name could probably be: OCISchemaServiceProvider_TC.xml And the commands it would cover are: ServiceProviderAddRequest13mp2 ServiceProviderGetListRequest ServiceProviderGetRequest13mp2 ServiceProviderModifyRequest

3. OCI Commands Directory Structure.

The directory structure for storing the OCI commands is similar to the directory structure for the OCI test cases. Except that since there are so many Services commands, the services commands are divided between the commands that Modify or Add the instance of the services and the commands that Queries or Get the services. The OCI commands can be divided under the following categories: - System - Enterprise - ServiceProvider - Group - User - modifySystemServices - modifyEnetrpriseServices - modifyServiceProviderServices - modifyGroupServices - modifyUserServices - getSystemServices - getServiceProviderServices - getEnterpriseServices - getGroupServices - getUserServices In subversion, under Automation\test\trunk\Regression\Commands\OCI, the following directories will store the OCI commands:

10

Under each directory, there is a response directory, this is where the expected responses messages that will be received when executing the OCI commands will be stored. For example, in a test case, an action does a get of Push To Talk service. The get command (UserPushToTalkGetRequest.xml) will be stored under: Automation\test\trunk\Regression\Commands\OCI\getUserService And the expected response (UserPushToTalkGetResponse_oneUser.xml) to the get command will be stored under: Automation\test\trunk\Regression\Commands\OCI\getUserService\Responses

4.

OCI Commands Naming Convention.

When you write an OCI command, you first create a file that holds the OCI commands with all the parameters, and the name of this should be the name of the command. Then, you can write OCI commands that modify only one parameter at the time (minOccurs="0"). The name of that file will be the name of the OCI command followed by an underscore and the name of the parameter that it modifies.

11

For example, the name of the file for the OCI command that configure all the parameters for Call Forward Always will be named: UserCallForwardingAlwaysModifyRequest.xml The content of the file will be: <?xml version="1.0" encoding="ISO-8859-1"?> <BroadsoftDocument protocol="OCI" xmlns="C" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sessionId xmlns="">%%%OCI_SESSION_ID%%%</sessionId> <command xsi:type="UserCallForwardingAlwaysModifyRequest" xmlns=""> <userId>%%%INVENTORY::RANDOM::OCI_CATEGORY::OCI_TARGET::USER_ID%%%</userId> <isActive>%%%STATUS%%%</isActive> <forwardToPhoneNumber>%%%PHONENUMBER%%%</forwardToPhoneNumber> <isRingSplashActive>%%%RINGSPLASHACTIVE%%%</isRingSplashActive> </command> </BroadsoftDocument>

Then you need to write an OCI command that modify only the parameter isActive. The name of the OCI file will be: UserCallForwardingAlwaysModifyRequest_isActive.xml The content of the file will be: <?xml version="1.0" encoding="ISO-8859-1"?> <BroadsoftDocument protocol="OCI" xmlns="C" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sessionId xmlns="">%%%OCI_SESSION_ID%%%</sessionId> <command xsi:type="UserCallForwardingAlwaysModifyRequest" xmlns=""> <userId>%%%INVENTORY::RANDOM::OCI_CATEGORY::OCI_TARGET::USER_ID%%%</userId> <isActive>%%%STATUS%%%</isActive> </command> </BroadsoftDocument> As you can see, in the OCI command file, the parameters forwardToPhoneNumber and isRingSplashActive are not present.

Then you need to write an OCI command that modify only the parameter forwardToPhoneNumber. The name of the OCI file will be: UserCallForwardingAlwaysModifyRequest_forwardToPhoneNumber.xml

12

The content of the file will be: <?xml version="1.0" encoding="ISO-8859-1"?> <BroadsoftDocument protocol="OCI" xmlns="C" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sessionId xmlns="">%%%OCI_SESSION_ID%%%</sessionId> <command xsi:type="UserCallForwardingAlwaysModifyRequest" xmlns=""> <userId>%%%INVENTORY::RANDOM::OCI_CATEGORY::OCI_TARGET::USER_ID%%%</userId> <forwardToPhoneNumber>%%%PHONENUMBER%%%</forwardToPhoneNumber> </command> </BroadsoftDocument> As you can see, in the OCI command file, the parameters isActive and isRingSplashActive are not present.

Then you need to write an OCI command that modify only the parameter isRingSplashActive. The name of the OCI file will be: UserCallForwardingAlwaysModifyRequest_isRingSplashActive.xml The content of the file will be: <?xml version="1.0" encoding="ISO-8859-1"?> <BroadsoftDocument protocol="OCI" xmlns="C" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sessionId xmlns="">%%%OCI_SESSION_ID%%%</sessionId> <command xsi:type="UserCallForwardingAlwaysModifyRequest" xmlns=""> <userId>%%%INVENTORY::RANDOM::OCI_CATEGORY::OCI_TARGET::USER_ID%%%</userId> <isRingSplashActive>%%%RINGSPLASHACTIVE%%%</isRingSplashActive> </command> </BroadsoftDocument> As you can see, in the OCI command file, the parameters isActive and forwardToPhoneNumber are not present.

There is no file that modifies only the userId, because the userId is the key to determine on which user the OCI command must be executed (It does not have minOccurs="0"). We can say that isActive, isRingSplashActive and forwardToPhoneNumber are optional parameters, meaning they are not required to be always present when using the command UserCallForwardingAlwaysModifyRequest.

13

We can say that the userId is a mandatory parameter, because the UserCallForwardingAlwaysModifyRequest need this parameter to be executed. To determine if a parameter is optional or mandatory, you must refer to the OCI schema.

Lets look at the Call Forward Always Schema http://carver/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/Services/OCISchemaServiceCallForwardingAlways.xsd http://beach.mtl.broadsoft.com/svn/trunk/AS/CommonAS/src/com/broadsoft/conf/OCISchema/Services/ OCISchemaServiceCallForwardingAlways.xsd

- <xs:complexType name="UserCallForwardingAlwaysModifyRequest"> - <xs:annotation> <xs:documentation>Modify the user level data associated with Call Forwarding Always. The response is either a SuccessResponse or an ErrorResponse.</xs:documentation> </xs:annotation> - <xs:complexContent> - <xs:extension base="core:OCIRequest"> - <xs:sequence> <xs:element name="userId" type="UserId" /> <xs:element name="isActive" type="xs:boolean" minOccurs="0" /> <xs:element name="forwardToPhoneNumber" type="OutgoingDNorSIPURI" nillable="true" minOccurs="0" /> <xs:element name="isRingSplashActive" type="xs:boolean" minOccurs="0" /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema>

14

You can tell that isActive, isRingSplashActive and forwardToPhoneNumber are optional parameters, because of minOccurs="0" in their description. You can see that the description of userid does not contain minOccurs="0", it means that it is a mandatory parameter. We also write OCI command that nulls the (nillable=true) parameters. This can be done in command file as: <?xml version="1.0" encoding="ISO-8859-1"?> <BroadsoftDocument protocol="OCI" xmlns="C" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sessionId xmlns="">%%%OCI_SESSION_ID%%%</sessionId> <command xsi:type="GroupAdminModifyRequest" xmlns=""> <userId>%%%USERID%%%</userId>

<firstName xsi:nil="true"/>
</command> </BroadsoftDocument>

The name of that file will be the name of the OCI command followed by an underscore the name of the parameter that it modifies underscores nil. For Example: GroupAdminModifyRequest_firstName_nil.xml

NOTE:
When you write an OCI test cases, the easiest way to get the format of a command, is to open a telnet session on the server, type auditail, execute the equivalent command in the Web or CLI interface and capture the OCI command that will be printed to the telnet session. But it is really important that you verify that the command format corresponds to the OCI schema. And you must verify which parameters are mandatory and which one are optional.

15

5. Deprecated Commands.
Deprecated commands are mentioned In FS with its Impact. Whenever there is an deprecated command there must be its new command. After that we always use new command in new Test Cases. Deprecated command doesnt mean that it is removed from server or it will not work, so whenever an FS contains a deprecated command we must verify it in our Test Case to check that it is still working. Now, the important task is to decide that whether we should create a new Test Case for that deprecated command or to modify the existing one.

Suppose an Add16 command is deprecated and a new Add18 and Get18 commands are added. There must be a Get16 command also corresponding to the Add16 command (can find it in schema file). So, it is better to create a new Test Case with name as <OldTestCase>_18.xml and its new parameter file. We add an instance with deprecated Add16 command and get it with new Get18 command and check the value of newly added parameters in response. Similarly we add an instance with new Add18 command and get it with old Get16 command and verify the response. Then complete the rest Test case according to the Schema and using new Get18 command. Add with deprecated ------ get with new Get. Add with new ----------------get with old Get. Rest of the actions in Test Case with new Get command.

If Modify16 command is also deprecated then we use this deprecated command with all parameters in Test Case and rest of the Test Case will use new Modify18 command. Add with deprecated ------ get with new Get. Add with new ----------------get with old Get. Modify with deprecated---get with new Get. Rest of the actions in Test Case with new Get and new Modify command.

If Get16 command is deprecated then we create a new Test Case TC_18.xml containing all new Get18 commands and one

16

deprecated Get16 command.

If all commands Add16, Modify16 and Get16 are deprecated, then we also have Add18, Modify18 and Get18 commands. Now, we will verify all possible combinations for old and new Add/Modify and Get commands. New Add---------------------------------------------------------Deprecated Get Deprecated Add-----------------------------------------------New Get New Modify (with all parameters) -----------------------Old Get Deprecated Modify (with all parameters) -------------New Get Rest of the actions in Test Case with new Add, modify and Get commands.

Also there is Deprecated commands section in FS, we also verify that impact in our Test Case accordingly.

6. Content of the Test Case.

A basic OCI test case should contains the actions to do the following: Send an OCI command that contain all the possible parameters for a command; Do a get to verify that the parameters were set to the values that were sent in the first OCI command. Verify that an OCI command can be sent when it contain all the mandatory parameters plus one of the optional parameters. Do a get to verify that the change made with the previous command was done. Repeat the above to steps with all the optional parameters. Make sure that all the possible values for a parameter are tried. Make sure that nillable parameters are tried to set nil. At last, Set all the default values and remove all the traces that Test case has created (This default action(s) must be executed when test case Fails at any place). - Default values for the parameter(s) can be viewed from the FS. o As an example, please look the following test case: Automation\test\trunk\Regression\TestCases\OCI\Services\UserServices\OCISchemaServicePushToTalk_TC.xml

17

7. OCI Error Validation Test Case

An Error Validation test case should contains the actions to do the following: Verify that an OCI command is sent when it contains all the mandatory parameters plus one of the optional parameters with incorrect value and an expected error response is coming. Incorrect values are as follow: a. Maximum Length + 1 b. Minimum Length 1 c. Invalid Value (according to data type, e.g. if it is Boolean then its invalid value can be abc) d. Empty Value Verify that any Error Validation behaviour which is mentioned in FS is covered in Error Validation Test Case. In some cases for example in Trunk Group, we try to assign a user from any other Automation Group and check for proper error message. We can do this by OCI only, As we cannot assign any Unavailable user by web page.(Web contains a list of available users only). We try to create an instance with same name which already exist, and check for proper error message.

As an example, please look the following test case:

Automation\test\trunk\Regression\TestCases\OCI\Services\UserServices\OCISchemaServicePushToTalk_ErrorValidation_TC.xml

8. OCI Authorization Test Cases.

Whenever there is an OCI command in an FS, Its authorization level is also defined. For example:

18

For command ServiceProviderMeetMeConferencingGetRequest Authorization level in FS is written as: Authorization level: Service Provider Authorization level service provider means we can send this command to server when login as Service Provider or System admin, But not when login with Group or user admin. A command can be send to server by admin of its authorization level or its higher level according to the hierarchy. Hierarchy from top to bottom is: System --> Service Provider or Enterprise --> Group ->User Now, there are two types of Authorizations: 1. Positive Authorization Verify that Success response comes when a command is send by its authorized admin or higher level admin from its authorization level according to the hierarchy. 2. Negative Authorization Verify that an Error response comes when a command is send by lower level admin from its authorization level according to the hierarchy. For this we create new Test Case and use corresponding wrapper in it, so that it opens a session for that level . TC name would be <Normal Test case name>_Authorization_<Level> For example: TC: - OCISchemaServiceConnectedLineIdentificationPresentation_Authorization_User_TC.xml Wrapper used in action OpenOCIInterface :- Wrapper\OCI\OpenOCI_User_Wrapper.xml TC: - OCISchemaServiceConnectedLineIdentificationPresentation_Authorization_Group_TC.xml Wrapper used in action OpenOCIInterface :- Wrapper\OCI\OpenOCI_GROUP_Wrapper.xml TC: - OCISchemaServiceConnectedLineIdentificationPresentation_Authorization_SP_TC.xml Wrapper used in action OpenOCIInterface :- Wrapper\OCI\OpenOCI_SP_Wrapper.xml We also create a different Parameter file for all these Test Cases.

a. Command with authorization level System can be send by System admin only and not with SP, Enterprise, Group and User admin. b. Command with authorization level SP (or Enterprise) can be send by System admin or SP (or Enterprise) admin and not with Group admin or User admin.

19

c.

Command with authorization level Group can be send by System admin, SP (or Enterprise) admin and Group admin and not by User admin.

d. Command with authorization level User can be send by System, SP (or Enterprise), Group and user admin.

9. Test Case Structure.

When you write a test case, you have to make sure that once the test case finish executing, any service that was enabled should be disabled, any item that was added to a list is deleted at the end of the test case. Because we don't want any service to stay enabled once the test case complete Let's see an example where if an Action would fail, Intercept User would stay enabled: <ActionData> <ActionDataInfo id="OpenOCIInterface" timeout="0"> <NextAction condition="PASS" id="ConfigureUserInterceptUser_AllFields"/> <NextAction condition="FAIL" id="CloseOCIInterface"/> </ActionDataInfo> </ActionData> <ActionData> <ActionDataInfo id="ConfigureUserInterceptUser_AllFields" timeout="0"> <NextAction condition="PASS" id="GetUserInterceptUser_AllFields"/> <NextAction condition="FAIL" id="CloseOCIInterface"/> </ActionDataInfo> </ActionData> <ActionData> <ActionDataInfo id="GetUserInterceptUser_AllFields" timeout="0"> <NextAction condition="PASS" id="ConfigureUserInterceptUser_announcementSelection"/> <NextAction condition="FAIL" id="CloseOCIInterface"/> </ActionDataInfo> </ActionData> [...] <ActionData> <ActionDataInfo id="GetUserInterceptUser_transferPhoneNumber" timeout="0"> <NextAction condition="PASS" id="DeactivateUserInterceptUser_AllFields"/ > <NextAction condition="FAIL" id="CloseOCIInterface"/> </ActionDataInfo> ActionData>

</

<ActionData> <ActionDataInfo id="DeactivateUserInterceptUser_AllFields" timeout="0"> <NextAction condition="PASS" id="CloseOCIInterface"/> <NextAction condition="FAIL" id="CloseOCIInterface"/> </ActionDataInfo> </ActionData> <ActionData> <ActionDataInfo id="CloseOCIInterface" timeout="0"/> </ActionData> If Action GetUserInterceptUser_AllFields FAIL for some reason, then the NextAction on the FAIL condition is CloseOCIInterface, this means that the Action DeactivateUserInterceptUser_AllFields will not be executed and Intercept User will stay enabled on this user.

20

A good test case structure would be to have a FailTC action where DeactivateUserInterceptUser_AllFields is executed after this action. As follows: <ActionData> <ActionDataInfo id="OpenOCIInterface" timeout="0"> <NextAction condition="PASS" id="ConfigureUserInterceptUser_AllFields"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> </ActionData> <ActionData> <ActionDataInfo id="ConfigureUserInterceptUser_AllFields" timeout="0"> <NextAction condition="PASS" id="GetUserInterceptUser_AllFields"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> </ActionData> <ActionData> <ActionDataInfo id="GetUserInterceptUser_AllFields" timeout="0"> <NextAction condition="PASS" id="ConfigureUserInterceptUser_announcementSelection"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> </ActionData> [...] <ActionData> <ActionDataInfo id="GetUserInterceptUser_transferPhoneNumber" timeout="0"> <NextAction condition="PASS" id="DeactivateUserInterceptUser_AllFields"/ > <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> </ActionData> <ActionData> <ActionDataInfo id="FailTC" timeout="0"> <NextAction condition="FAIL" id="DeactivateUserInterceptUser_AllFields"/> <NextAction condition="PASS" id="DeactivateUserInterceptUser_AllFields"/> </ActionDataInfo> <ActionInterfaceData actionType="Fail" interfaceType="ToolInterface"/> </ActionData> <ActionData> <ActionDataInfo id="DeactivateUserInterceptUser_AllFields" timeout="0"> <NextAction condition="PASS" id="CloseOCIInterface"/> <NextAction condition="FAIL" id="CloseOCIInterface"/> </ActionDataInfo> </ActionData> <ActionData> <ActionDataInfo id="CloseOCIInterface" timeout="0"/> </ActionData> Any test case should have a FailTC action, and after this action, you do the cleanup of your test case. This will avoid to leave services enabled on a user. I just want to point out that for the Actions that follow FailTC, the NextAction on a FAIL condition should NOT be FailTC action, otherwise, you will have a loop. For example, do not do that: <ActionData> <ActionDataInfo id="FailTC" timeout="0"> condition="FAIL" id="DeactivateUserInterceptUser_AllFields"/> id="DeactivateUserInterceptUser_AllFields"/> </ActionDataInfo> actionType="Fail" interfaceType="ToolInterface"/> </ActionData> <NextAction <NextAction condition="PASS" <ActionInterfaceData

21

<ActionData> <ActionDataInfo id="DeactivateUserInterceptUser_AllFields" timeout="0"> <NextAction condition="PASS" id="CloseOCIInterface"/> condition="FAIL" id="FailTC"/> </ActionDataInfo> </ActionData> <ActionDataInfo id="CloseOCIInterface" timeout="0"/> </ActionData>

<NextAction <ActionData>

In the above example, if DeactivateUserInterceptUser_AllFields fails, you will loop since you will go back to FailTC and FailTC will go to DeactivateUserInterceptUser_AllFields etc.

10. Naming Convention For Test Cases Actions.

When writing a test case, the name given to the actions should be meaningful. If you look at the Push To Talk test case: Automation\test\trunk\Regression\TestCases\OCI\Services\UserServices\OCISchemaServicePushToTalk_TC.xml You will see that when an action modifies a parameter, the name of the action actually contain the name of the parameter it modify. For example, the action that modifies the allowAutoAnswer parameter is called: ConfigurePTT_allowAutoAnswer.

11. Test Suites and OCI Login User.

To execute an OCI command you can log with different type of login ID: System admin, Service Provider Admin, Enterprise Admin, Group Admin and User. Under each OCI test case directory there is one or more Test Suite file. Any test case that is ready to be executed should be added to the test suite file of its same directory. For example, if you look at the following directory: Automation\test\trunk\Regression\TestCases\OCI\Services\UserServices The test suite files are: OCISchemaUserService_SystemAdmin_TS.xml and OCISchemaUserService_UserLogin_TS.xml

22

OCISchemaUserService_SystemAdmin_TS.xml will execute the test cases while logged as admin, while OCISchemaUserService_UserLogin_TS.xml will execute the test cases while logged as a user. Look at the Test Suite parameter files and you will understand the difference.

12. Format To Write and OCI Test Case

1. ADD command with mandatory parameters. 2. GET command with all parameters. 3. ADD command with all parameters(ie with optional parameters) 4. GET command 5. MODIFY command with all Parameters 6. GET command 7. MODIFY command with individual parameter modified 8. GET command for each 9. MODIFY command if any parameter is nillable=true 10. GET command without that nillable parameter 11. MODIFY command to set the default value of all parameters (This must also be executed in Fail condition) 12. DELETE command to delete all which you have created while automating (This must also be executed in Fail condition)

23

WEB Automated Test Cases Guidelines

1. Web Test Case Directory Structure.
There are two types of Web Test Cases: a) Positive Scenario / Normal Test Cases b) Error Validation Test Cases The directory structure for storing the Web test cases is based on the existing web levels:

24

The Web test cases can be divided under the following levels: System Service Providers Enterprises Groups Users Administrators

In subversion, under Automation\test\trunk\Regression\TestCases\Web, the following directories will store the Web test cases:

25

Examples If you write a test case for Call Forward Always Web page at the User level, the test case will be stored in: Automation\test\trunk\Regression\TestCases\Web\Users

If you write a test case for Three-Way Call at the System level, the test case will be stored in: Automation\test\trunk\Regression\TestCases\Web\System

2. Web Test Cases Name.

To write the test cases, you must follow the Web level structure, and the name of the testcases should be based on the Web levels. The test case name must indicate the name of the Service/Web page it verifies as well as the level it is located. For example, for Call Forward Always Web page at the User level, the test case name will be: CallForwardAlwaysUserLevel_TC.xml This test case will verify the following web page: http://addressOfYourAS/User/CF/Always/

For example, for Three Way Call Web page at the System level, the test case name will be: ThreeWayCallSystemLevel_TC.xml

26

This test case will verify the following web page: http://addressOfYourAS/Operator/Services/ThreeWayCall/ For example, for Three Way Call Web page at the Service Provider level, the test case name will be: ThreeWayCallServiceProviderLevel_TC.xml This test case will verify the following web page: http://addressOfYourAS/ServiceProvider/ThreeWayCall/

3. Web Commands Directory Structure.

The directory structure for storing the Web commands is the same as the directory structure for the Web test cases. The Web commands can be divided under the following levels: - System - Service Providers - Enterprises - Groups - Users - Administrators In subversion, under Automation\test\trunk\Regression\Commands\Web, the following directories will store the Web commands:

4. Web Test Case Structure and Commands files Naming Convention.

There are two types of web commands:

27

Command that allows navigating and reaching a specific web page. These commands do not actually test the web pages: it goes through and it just check a few items to make sure it is the right web page. Command that allows testing and verifying an actual web page. These commands really verify the web page, try to click on every button, fill all the text boxes, click on every check box, and try all the possible values.

The Web commands name will also follow the Web level structure. A command name should indicate if it is a navigate command or a verify command. In a test case, almost each web page that is visited is an action and requires an XML file. For many test cases, we will follow the same path to reach a web page. So instead of having each test case to contain a long xml file with all the entire steps to reach one web page, we divide each step in small file that will be used by every test case that uses the same path. So if a web page change, we will modify only one file to fix the problem.

28

For example, here are the actions for a test case that goes at the user level and test Call Forward Always page. The test case is the following: \Automation\test\trunk\Regression\TestCases\Web\Users\CallForwardAlwaysUserLevel_TC.xml 1. First step, you need to login to the web: you will open a web session with your AS, enter the user id and password and click on the Login link. It is done with the following command : Automation\test\trunk\Regression\Commands\Web\Login.xml At the end of this action, you will be in the following Web page (If log in with System Admin):

2. We are now at the system level and we want to go the user for which we will configure Call Forward Always, so you will click the user link in the System web page above, you will enter the LastName of your user, do a search, then you will click on your users link and you will be in the user web page. This is done in the following command file: \Automation\test\trunk\Regression\Commands\Web\System\NavigateToUserLevel.xml

29

This file is stored in the System directory because it starts to execute command in a web page at the system level. The name of the file is NavigateToUserLevel.xml because once the command has completed executing; you will have navigated up to the User level. At the end of this action, you will be in the following Web page:

3. We are now at the user level, and to configure Call Forward Always we have to go to the Incoming Calls Page. It is done with the following command : Automation\test\trunk\Regression\Commands\Web\Users\NavigateToIncomingCallsUserLevel.xml This file is stored in the User directory because it starts to execute command in a web page at the user level. The name of the file is NavigateToIncomingCallsUserLevel.xml because once the command has completed executing; you will have navigated up to the Incoming Calls page at the User level. At the end of this action, you will be in the following Web page:

30

4. We are now in the Incoming Call Web page; we need to go to the Call Forward Always web page and verify the Title, WebTip, Text present etc. to ensure that we are on the right page. It is done with the following command : Automation\test\trunk\Regression\Commands\Web\Users\NavigateToCallForwardAlwaysUserLevel.xml This file is stored in the User directory because it starts to execute command in a web page at the user level. The name of the file is NavigateToCallForwardAlwaysUserLevel.xml because once the command has completed executing; you will have navigated up to the Call Forward Always page at the User level. At the end of this action, you will be in the following Web page:

31

5. We are now in the Call Forward Always web page. It is time to test the page itself: try to click on every button, fill all the text boxes, click on every check box, and try all the possible values. It is done with the following command : Automation\test\trunk\Regression\Commands\Web\Users\VerifyCallForwardAlwaysUserLevel.xml This file is stored in the User directory because it executes a command in a web page at the user level. The name of the file is VerifyCallForwardAlwaysUserLevel.xml because it configures the different fields and tests the Call Forward Always page at the User level.

The advantage of having many commands like that is because once the steps to reach a web page are written in a file, it can be used by the other test case. For example, if someone writes a test case to verify Call Forward Busy Web page. All the steps to get to the Incoming Calls page are already written, the same xml files will be used by the Call Forward Busy test case as well. And if one day, one of the pages that must be navigated to get to the Incoming Calls page is changed, we will have to modify only one file to fix the problem.

32

5. Naming Convention For Web Test Cases Actions.

When writing a test case, the name given to the actions should indicate whether it is a navigate or a verify action and should indicate at which level the command is executed. If you look at the Call Forward Always test case: \Automation\test\trunk\Regression\TestCases\Web\Users\CallForwardAlwaysUserLevel_TC.xml You will see that the names of the web action are actually the name of the xml command that they execute. For example: <ActionData> <ActionDataInfo id="NavigateToUserLevel" timeout="0"> <NextAction condition="PASS" id="NavigateToIncomingCallsUserLevel"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> <ActionInterfaceData actionFile="Commands/Web/System/NavigateToUserLevel.xml" actionType="SendMessage" interfaceType="WebInterface"/> </ActionData> <ActionData> <ActionDataInfo id="NavigateToIncomingCallsUserLevel" timeout="0"> <NextAction condition="PASS" id="NavigateToCallForwardAlwaysUserLevel"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> <ActionInterfaceData actionFile="Commands/Web/Users/NavigateToIncomingCallsUserLevel.xml" actionType="SendMessage" interfaceType="WebInterface"/> </ActionData> <ActionData> <ActionDataInfo id="NavigateToCallForwardAlwaysUserLevel" timeout="0"> <NextAction condition="PASS" id="VerifyCallForwardAlwaysUserLevel"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> <ActionInterfaceData actionFile="Commands/Web/Users/NavigateToCallForwardAlwaysUserLevel.xml" actionType="SendMessage" interfaceType="WebInterface"/> </ActionData> <ActionData>

33

<ActionDataInfo id="VerifyCallForwardAlwaysUserLevel" timeout="0"> <NextAction condition="PASS" id="CloseWebSession"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> <ActionInterfaceData actionFile="Commands/Web/Users/VerifyCallForwardAlwaysUserLevel.xml" actionType="SendMessage" interfaceType="WebInterface"/> </ActionData>

6. Test Suites and Web Login User.

To execute web test case you can log with different type of login ID: System admin, user, Service Provider Admin, Group Admin, Read Only Admin etc. Under each Web test case directory there is one or more Test Suite file. Any test case that is ready to be executed should be added to the test suite file that it is applicable to. For example, if you look at the following directory: C:\Automation\test\trunk\Regression\TestCases\Web\Users The test suite files are: WebUserLevel_UserLogin_TS.xml and WebUserLevel_SystemAdminLogin_TS.xml WebUserLevel_SystemAdminLogin_TS.xml will execute the test cases while logged as admin, while WebUserLevel_UserLogin_TS.xml will execute the test cases while logged as a user. Look at the Test Suite parameter files and you will understand the difference.

When login as a user, you end up directly at the user level, this means that the test cases that are executed when login as a user will not require the command: \Automation\test\trunk\Regression\Commands\Web\System\NavigateToUserLevel.xml Because of that, we need to create test case for User Login and test cases for Admin Login.

34

When a test case is for Admin Login, there is no mention in the test case name. When the test case is for user Login, the name should mention it as follows: Automation\test\trunk\Regression\TestCases\Web\Users\CallForwardAlwaysUserLevel_UserLoginTC.xml While for Admin Login, the test case name is: Automation\test\trunk\Regression\TestCases\Web\Users\CallForwardAlwaysUserLevel_TC.xml

NOTE: We test the web with all the different kind of user: Provisioning admin, System Admin, Service Provider Admin, Group Admin, etc according to the hierarchy. We also test the web pages that are localized. It is to ensure that we can Log in with different Admins. For this we have Normal Admin (English Language) and Localized Admin (Automation language). When Log in with Localized admin, there is a string A_ written before every Text, Button, Link, Title, Web Tip etc. so that we can verify that it is log in with localized admin. We always write an variable %%%LOCALIZATION%%% before every element, and value of it is given in Test Suite parameter file. So that a single command file is used for both- Localized admin and Normal Admin.

Wrapper Files to Be Used

OCI Wrapper files are stored at Subversion under: Automation\test\trunk\Regression\Wrapper\OCI Wrapper files are used to send the command on a session (opened or on newly created session) and place the response command file in waiting state. For example:

35

Wrapper\OCI\Execute_OCI_command_Wrapper_OpenedSession.xml This wrapper is used whenever a session is already opened in Test Case by OpenOCIInterface action, And command is to be send on it. Session name is identified by a parameter OCI_SESSION_NAME mentioned in action parameter list. This name must be same as given in OpenOCIInterface action.

Wrapper\OCI\Execute_OCI_command_Wrapper.xml This wrapper is used whenever a new session needs to be opened particularly for that action. In this wrapper, It first open a new session->Send the OCI command on this session-> And finally close that session. Session is opened with name ACTION_ID mentioned in action parameter list. We do not need to open a session by OpenOCIInterface action separately.

There are many more wrapper files in folder used at different Test Cases according to the requirement. For Example: Wrapper\OCI\Execute_OCI_command_GROUP_Wrapper.xml Wrapper\OCI\Execute_OCI_command_SP_Wrapper.xml Wrapper\OCI\Execute_OCI_command_User_Wrapper.xml etc.

These are used when a Test Case/Action is required to open an independent session for different admin levels (User, Group, Service Provider etc).

Points To Remember For OCI and Web Automation

Always use values from Inventory, Do not hardcode the values.

38

Follow Proper naming convention for Test cases and Command Files. Test Case ID in TestCaseDataInfo id should be same as Test Case name without extension. o For example- If test case name is OCISchemaServiceCallForwardingAlways_TC.xml then its Id must be OCISchemaServiceCallForwardingAlways_TC.

Write proper description in TestCaseDataInfo description. Store OCI Test case related to Services in regression\TestCases\OCI\Services\... folder and other test cases in regression\TestCases\OCI\... folder.

Test Case should be listed in its corresponding Test Suite. If Test Case Pass or Fails at any action, It must clear all the traces it created and set default values if required. Test Case should cover all commands or possible scenarios according to requirement mentioned in FS. Error Validation Test Case is mandatory. OCI command Files which are modifying any optional parameter should be named as CommandName_ParameterModified. For deprecated commands, we verify them also in TC in last. When modifying a command file, make sure to Grep that file name on Trunk\regression\TestCases folder to verify that which Test Cases are using that file (They also need to be updated).

Always perform SVN Update on Schema folder and regression folder before starting automation. Execute the Test Case twice, to ensure that no Traces are left by Test Case. Always use Automation Users, Group and service Provider/Enterprise in Test Case. If any action (command) get passed which should not pass, Since command is not made to be accessible for that

38

level (say user level) so we Delete it in the FailTC section by using admin credentials for that to we need to use "Wrapper\OCI\Execute_OCI_command_Wrapper.xml" (this wrapper file initiate new session and get closed.

38

We need to create a parameter file for each Test Case to avoid dependency (parameter file contains the value of variable which you declare in your test case). Naming convention for parameter file is same as test case - (Test case name)_TC_Parameters.xml

Add a comment when we have deprecated impact as <!--

Deprecated impact --> Added this Test Case as per the FS: MR88469-FR91038-

Add comment when we add new TC or modify the existing TC as e.g. <! --

ClassMarkFS-R170 --> and we can add that which parameter or data types are changed. Automation tracking sheet should be properly updated if feature with TCs is completed. Check for flow of actions, No action should skip. TC should be present in all Regression folders in with feature is submitted. Common Error Validation response files should used instead of creating new one wherever possible.

Common Errors while executing Test Cases:

Loop in Test case: There can be a loop in test case. For example Action1 fail condition is Action2, and Action2 fail condition is Action1. BCCT Error, Server refused to register protocol: Local machine IP is not added in network Access List on AS. It is done as-

39

o o

Goto AS_CLI and login with ID lo password admin. Goto AS_CLI/System/NetworkAccessLists/OCI/Provisioning> . Perform add <Local Machine IP>. Perform get to verify.

Key not found in parameter list: Some variable that is used in command file is not given/defined in parameter list or somewhere else.

Points to verify while Review

40

Values are used from Inventory. Test Case ID in TestCaseDataInfo id is same as Test Case name without extension. Test Case is listed in its corresponding Test Suite. All the instances created are deleted and default values are set at End of TC. A comment is added if TC is created or modified. o As <! -Added or Modified Test Case as per the FS: <FS Name> -->

Automation tracking sheet is properly updated if Automation is completed. No action is skipped. TC is present in all Regression folders in with feature is submitted. Common Error Validation response files are used instead of creating new one.

Automation Resources Management

41

1.

Inventory File Overview.

On the system under test, 59 users are provisioned. These users are called the Automation users. They are dedicated to the automated test cases. They are divided under 6 groups falling under 1 Service Provider and 2 Enterprises. There are SIP and MGCP users. Each group is provisioned with a Huntgroup, a Call Center, an Auto Attendant and a Voice Portal.

Service Provider / Enterprise WestCoastSP (Service Provider)

Group

SIP users numbers

MGCP users numbers

Group Services Auto Attendant: 360-213-1046 Huntgroup: 360-213-1047 Call Center: 360-213-1048 Voice Portal: 360-213-1049 Auto Attendant: 403-290-2146 Huntgroup: 403-290-2147 Call Center: 403-290-2148 Voice Portal: 403-290-2149 Auto Attendant: 306-787-4346 Huntgroup: 306-787-4347 Call Center: 306-787-4348 Voice Portal: 306-787-4349 Auto Attendant: 204-334-6546 Huntgroup: 204-334-6547 Call Center: 204-334-6548 Voice Portal: 204-334-6549 Auto Attendant: 902-367-8746 Huntgroup: 902-367-8747 Call Center: 902-367-8748 Voice Portal: 902-367-8749

Vancouver

360-213-1001 to 360-213-1006

360-213-1007 to 360-213-1010

Calgary

409-290-2101 to 409-290-2110

None

PrairiesEnt (Enterprise)

Regina

306-787-4301 to 306-787-4301 to

None

Winnipeg

204-334-6501 to 204-334-6501

None

EastCoastEnt (Enterprise)

Charlottetown

902-367-8701 to 902-367-8706

902-367-8707 to 902-367-8710

42

Halifax

902-484-9801 to 902-484-9806

902-484-9807 to 902-484-9810

Auto Attendant: 902-484-9846 Huntgroup: 902-484-9847 Call Center: 902-484-9848 Voice Portal: 902-484-9849

Each user is listed in the Inventory file. For example: <ResourceData name="Calgary_2101" description="SIP Calgary 2101"> <AttributeData parameter="PHONE_NUMBER" value="4032902101"></AttributeData> <AttributeData parameter="PHONE_EXTENSION" value="2101"></AttributeData> <AttributeData parameter="USER_ID" value="ca2101"></AttributeData> <AttributeData parameter="USER_PWD" value="mtllab"></AttributeData> <AttributeData parameter="GROUP_ID" value="calgary"></AttributeData> <AttributeData parameter="SERVICE_PROVIDER_ID" value="WestCoastSP"></AttributeData> <AttributeData parameter="FIRST_NAME" value="calg2101"></AttributeData> <AttributeData parameter="LAST_NAME" value="calgary"></AttributeData> <AttributeData parameter="DISPLAY_NAME" value="calg2101 calgary"></AttributeData> <AttributeData parameter="CHANNEL" value="7"></AttributeData> <AttributeData parameter="CATEGORY" value="SIP_USER"></AttributeData> <AttributeData parameter="CATEGORY" value="SIP_USER_Calgary"></AttributeData> <AttributeData parameter="RESERVABLE" value="true"></AttributeData> </ResourceData> Each user has one or more CATEGORY tag. This tag is used to reserve the resource. For example, for an OCI command in a test case, if you want to use a user in the group Calgary, instead of writing the userid in the command, an inventory key must be specified. Instead of sending the OCI command with the <userId> field as follows: <userId>ca2101</userId> You will send the userid in this format: <userId>%%%INVENTORY::RANDOM::SIP_USER_Calgary::USERA::USER_ID%%%</userId> When the OCI command will be executed, it will reserve a user in group Calgary and replace the string %%%INVENTORY::RANDOM:: SIP_USER_Calgary::USERA::USER_ID%%% with the userid of the user that is reserved for the duration of the test case. USERA can be any string; it simply needs to be a unique identifier for your resource. This will allow reserving more than one resource of the same category within one test case. For example, you may want to use two users in group Calgary.

43

For example: <?xml version="1.0" encoding="ISO-8859-1"?> <BroadsoftDocument protocol="OCI" xmlns="C" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sessionId xmlns="">%%%OCI_SESSION_ID%%%</sessionId> <command xsi:type="UserCallForwardingAlwaysModifyRequest" xmlns=""> <userId>%%%INVENTORY::RANDOM::SIP_USER_Calgary::USERA::USER_ID%%%</userId> <isActive>true</isActive> <forwardToPhoneNumber>%%%INVENTORY::RANDOM:: SIP_USER_Calgary::USERZ::PHONE_NUMBER%%%</ forwardToPhoneNumber> <isRingSplashActive>true</isRingSplashActive> </command> </BroadsoftDocument>

2. OCI Test Cases Application

When writing OCI commands, instead of identifying the userid with the following string: <userId>%%%INVENTORY::RANDOM::SIP_USER_Calgary::USERA::USER_ID%%%</userId> We will use the following format: <userId>%%%INVENTORY::RANDOM::OCI_CATEGORY::OCI_TARGET::USER_ID%%%</userId> This will allow that any OCI command used in a test case can be used in any other test case as well even if the test case uses a user from a different group. The value of OCI_CATEGORY and OCI_TARGET is then specified in the action file of the test case. For example, you have the following OCI command file: (UserCallForwardingAlwaysModifyRequest.xml) <?xml version="1.0" encoding="ISO-8859-1"?> <BroadsoftDocument protocol="OCI" xmlns="C" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sessionId xmlns="">%%%OCI_SESSION_ID%%%</sessionId> <command xsi:type="UserCallForwardingAlwaysModifyRequest" xmlns=""> <userId>%%%INVENTORY::RANDOM::OCI_CATEGORY::OCI_TARGET::USER_ID%%%</userId> <isActive>%%%STATUS%%%</isActive>

44

<forwardToPhoneNumber>%%%PHONENUMBER%%%</forwardToPhoneNumber> <isRingSplashActive>%%%RINGSPLASHACTIVE%%%</isRingSplashActive> </command> </BroadsoftDocument>

In a testcase, you will execute the OCI command as follows: <ActionData> <ActionDataInfo id="ConfigureCFA" timeout="0"> <NextAction condition="PASS" id="GetCFA"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> <ActionInterfaceData actionFile="Wrapper\OCI\Execute_OCI_command_Wrapper_OpenedSession.xml" actionType="Macro" interfaceType="ToolInterface"/> <ActionPropertyData parameter="CommandToSend" value="Commands\OCI\modifyUserService\UserCallForwardingAlwaysModifyRequest.xml"/> <ActionPropertyData parameter="ResultMessage" value="Commands\OCI\OCISuccessResponse.xml"/> <ActionPropertyData parameter="STATUS" value="true"/> <ActionPropertyData parameter="PHONENUMBER" value="%%%INVENTORY::RANDOM::USERB_CATEGORY::USERB::PHONE_NUMBER%%%"/> <ActionPropertyData parameter="RINGSPLASHACTIVE" value="true"/> <ActionPropertyData parameter="OCI_CATEGORY" value="USERA_CATEGORY"/> <ActionPropertyData parameter="OCI_TARGET" value="USERA"/> <ActionPropertyData parameter="OCI_SESSION_NAME" value="OCISchemaServiceCallForwardingAlways_TC"/> </ActionData> And the value for USERA_CATEGORY is defined in the parameter file of the test case. The reason why we again use a variable and we dont put the value of OCI_CATEGORY directly in the action is because in the test case, we will execute many OCI commands on the same user, so if we would like to change the category of the USER that we use, we will need to modify this value everywhere in the test case. If this is a variable and the value is defined only in the parameter file of the test case, it is easy to change the category of a user. This is why we DONT do that: <ActionData> <ActionDataInfo id="ConfigureCFA" timeout="0"> <NextAction condition="PASS" id="GetCFA"/> <NextAction condition="FAIL" id="FailTC"/> </ActionDataInfo> <ActionInterfaceData actionFile="Wrapper\OCI\Execute_OCI_command_Wrapper_OpenedSession.xml"

45

actionType="Macro" interfaceType="ToolInterface"/> <ActionPropertyData parameter="CommandToSend" value="Commands\OCI\modifyUserService\UserCallForwardingAlwaysModifyRequest.xml"/> <ActionPropertyData parameter="ResultMessage" value="Commands\OCI\OCISuccessResponse.xml"/> <ActionPropertyData parameter="STATUS" value="true"/> <ActionPropertyData parameter="PHONENUMBER" value="%%%INVENTORY::RANDOM::USERB_CATEGORY::USERB::PHONE_NUMBER%%%"/> <ActionPropertyData parameter="RINGSPLASHACTIVE" value="true"/> <ActionPropertyData parameter="OCI_CATEGORY" value="SIP_USER_Calgary "/> <ActionPropertyData parameter="OCI_TARGET" value="USERA"/> <ActionPropertyData parameter="OCI_SESSION_NAME" value="OCISchemaServiceCallForwardingAlways_TC"/> </ActionData>

46

Configuring the Test Automation Tool (TAT)

In a typical Test Automation environment, the test Automation Tool will be installed on the PC of all the users that will execute automated test cases.

1. Setting the Base and Message Path

Depending if you want to execute the Automated Test cases on a release, you must configure the Message and Base paths. - From Configuration menu, open the Tool Options dialog box. - Select the Base Path tab; - Enter the path where the C:\Automation\Releases1\Trunk\regression directory was checkout from subversion; - Press Apply.

47

Select the Messages Path tab; Enter the path where the test/releases/Rel_13.0/Regression/Messages directory was checkout from subversion; Press Apply and OK.

48

2. Configuring the Resource Manager in Local Mode

From Configuration menu, open the Tool Options dialog box. Select the Resource Manager tab. For the Resource Manager Location, select Local; If the Resource Manager Server State indicates Running, press stop and wait for dialog box indicating that the Resource Manager has stop. Press OK; Then configure the RM Inventory File. Select the inventory file corresponding to the system under test. The file is located at: regression\Properties\inventories\India regression\Properties\inventories\Montreal Note: you must select the Inventory file itself, not only the path to the directory where the file is located; Press Apply; or

49

Press the Start button and wait for a dialog box indicating that the resource Manager has started.

You may want to verify that the Inventory file was successfully loaded. This can be verified by opening the RM manager log file. The logs file is in the log directory under the test Automation Tool directory. For example: C:\Program Files\Broadsoft\TestAutomationTool\logs\RMServer_30-11-05.log If the Inventory file was successfully loaded, the following message should be present in the log file:

30-Nov-2005 9:28:57 AM com.broadsoft.automation.server.resourcemanager.ResourceManager load WARNING: Inventory file C:\automation\trunk\Regression\Properties\inventories\inventory_SOLARIS_ascluster7.mtl.broadsoft.com.xml successfully loaded! 30-Nov-2005 9:28:57 AM com.broadsoft.automation.server.resourcemanager.ResourceManager init INFO: Resource Manager Server initialized!

50

3. Configuring the Resource Manager in Remote Mode

From Configuration menu, open the Tool Options dialog box. Select the Resource Manager tab. If the Resource Manager Server State indicates Running, press stop and wait for dialog box indicating that the Resource Manager has stop. Press OK; (Note that this step is done to ensure that the Resource Manager does not run) For the Resource Manager Location, select Remote; Enter the Resource Manager Port: 25010; Enter the Resource Manager Address. This is the IP Address of the Remote PC. Press OK since the Tool Configuration is completed for the User PC.

51

51