accenture products & platforms (app) accenture health

Alias Framework Reference Guide

Copyright © 2020 Accenture All Rights Reserved. 1

Accenture Products & Platforms (APP)

Accenture Health & Public Services

Accenture Human Services Suite

ALIAS Framework Reference Guide



Table of Contents

1. Overview ............................................................................................................................................................................ 3

1.1. Audience ................................................................................................................................................................................... 3

1.2. Tools .......................................................................................................................................................................................... 3

2. ALIAS Structure ................................................................................................................................................................. 4

2.1. Alias Framework Structure ........................................................................................................................................................ 4

3.1.1. src (source code file) ................................................................................................................................................... 4

3.1.2. config ........................................................................................................................................................................... 6

3.1.3. models ....................................................................................................................................................................... 11

3.1.4. scripts ........................................................................................................................................................................ 12

3.1.5. SourceDataFiles ........................................................................................................................................................ 16

2.2. How Database and Web Services Work Together? ................................................................................................................ 16

2.3. Project Dependecies – Core POM dependencies ................................................................................................................... 19

3. How to Use the Alias Project ........................................................................................................................................... 20

3.1. Script Creation ......................................................................................................................................................................... 20

3.2. Generate POM ........................................................................................................................................................................ 23

3.3. Script Execution....................................................................................................................................................................... 26

3.4. Generate Report ...................................................................................................................................................................... 28

4. Alias Capabilities ............................................................................................................................................................. 30

4.1. Accessibility Feature ................................................................................................................................................................ 31

4.1.1. How to test Accessibility in Alias Framework: ............................................................................................................ 32

1.1.2 How to view Accessibility Results in a Script Flow .................................................................................................... 34

5.1. Other Alias Capabilities ........................................................................................................................................................... 37

6. Appendix.......................................................................................................................................................................... 38

6.1. Alias Command Index ............................................................................................................................................................. 38

6.2. Install Maven ........................................................................................................................................................................... 38

7. Revision History .............................................................................................................................................................. 44



1. Overview

This document provides instructions on how to setup Accenture Logic Inspection and Auditing System (ALIAS) automation framework and steps for creating new test scripts using the framework and executing them.

Note: ALIAS is a testing automation tool.

1.1. Audience

• Developers

• Testers

1.2. Tools

The following table provides the tools required to setup the ALIAS project.

Note: You must install these tools prior to setting up the ALIAS project in the order given below:

Table 1: Tools for ALIAS Setup

Tool Download Link

Java (Windows) Latest version available on Java site

Eclipse (version 4.8.0)

Eclipse-IDE-Java-Developers (Windows 64-bit)

Eclipse Cucumber Plugin

https://cucumber.github.io/cucumber-eclipse/update-site/

GIT http://10.3.16.31:8080/ Where 10.3.16.31 is the Server IP and 8080 is the Port number

https://www.eclipse.org/downloads/packages/release/2019-12/r/eclipse-ide-java-developers

https://cucumber.github.io/cucumber-eclipse/update-site/

http://10.3.16.31:8080/



2. ALIAS Structure

This section explains the Alias_client project structure and it’s configuration.

2.1. Alias Framework Structure

The Alias_client project consists of the following main artifacts:

3.1.1. src (source code file)

– Src contains all the classes that the framework generates. You can classify them as follows:

▪ Glue code is generated for the reusable components. This is the only source code that the Alias_client

project users must check in. Reusable components are available for all other users.

▪ When a user creates / updates any reusable feature, the corresponding reusable Java class that contains

the glue code is generated upon executing the feature. Refer to the below screenshot as an example:

Figure 1 Reusable Java Class with Glue Code

▪ When a scenario name is followed by : : <Java Class Name>, it indicates the corresponding scenario is

reusable.

Notes:

▪ While assigning a scenario name, ensure it is unique. That way you can consider the given name as a glue

code that you can reuse in other scenarios. For example: log into ABMS is a scenario name and Then is a

syntax.

▪ Java class name (for example: ABMS_Login) must also be unique. Else Alias overrides an existing

generated classes.

▪ When you update the reusable scenario in a feature, make sure to check in the generated class.

▪ The POM generator generates the POM classes which are used for script execution. These files are

generated automatically after you make updates to the model file(s). You need not maintain or check them

in manually.

▪ The below snippet shows how the generated structure looks like. You must run PagePOMgenerator class to

generate or regenerate these files after the model file updates.

Figure 2 Structure of Generated POM Classes



– The source code folder contains the following resources, as shown in the screenshot below:

▪ config

▪ model

▪ Scripts

▪ SourceDataFiles

Figure 3 Resources in Source Code Folder



Let’s review the resources in detail below:

3.1.2. config

- Includes the automationConfig.json, env.json, queries.json, and webService.json files.

Let’s look at each of these files in more detail:

Below is the automationConfig.json file that provides the main configuration settings to execute scripts.

{ "jira":{ "enabled":false, "url":"", "userName":"", "password":"", "project":"ALIAS", "application":"ABMS" }, "grid":{ "enabled":true, "url":"http://localhost:4444" }, "alias":{ "env":"Prodfix_7.3.x", "scenarioGeneratorMode":true, "rowBasedData":false, "enableAccessibilityTest":false, "screenshotsOnErrorOnly":true, "pageLoadWait":"0", "logLevel":"debug", "uploadPath":"src/main/resources/SourceDataFiles/upload/" }, "target":{ "browser":"chrome", "device":"Desktop", "headlessMode":false } }



The below table provides the details on the element included in the automationConfig.json file and it’s configuration

settings:

Table 2 Element Included in the automationConfig.json File

Element Configuration Settings Description

JIRA "enabled":false, Enabled means any unique script failure is uploaded as a defect in JIRA while running a report.

Values can either be true or false.

True: Indicates that Alias will upload an error for the

failed script as a defect in JIRA.

False: Indicates that Alias will not upload an error for

the failed script a defect in JIRA.

"url":"", Displays the URL for JIRA

"userName":"", Shows the username used to create a defect uploaded in JIRA

"password":"", Shows the password for the corresponding username used to create a defect uploaded in JIRA

"project":"ALIAS", Shows the JIRA project where the defect is created

"application":"ABMS Shows the application for which the defect is created

Grid "enabled":true, Values can either be true or false. True indicates that Alias will execute scripts on

selenium grid previously created.

False indicates that Alias will execute scripts in the

user’s local desktop.

"url":"http://localhost:4444" Display the URL for the selenium grid.

Alias "env":"Prodfix_7.3.x", Shows the name of the environment that Alias uses to look for the environment details in the .json file for script execution.

"scenarioGeneratorMode":true, Values can either be true or false. True means Alias will generate the reusable components when a reusable scenario is executed. False means Alias will not generate the reusable components when a reusable scenario is executed.

"rowBasedData":false, Values can either be True or False.




True means Alias will use the first row in the data

sources as an index to find data.

False means Alias will use the first column in the data sources as an index to find data.

"enableAccessibilityTest":false, Values can either be true or false. True means Alias will run any page used in a script during execution through the axe framework. False means Alias will not run any page used in a script during execution through the axe framework.

"screenshotsOnErrorOnly":true, Values can either be true or false. True means Alias will only capture screenshots when an error happens during execution. False means that Alias will capture a screenshot on every single step during script execution. Note that setting this to False may help in debugging however can lead to a huge file size.

"pageLoadWait":"0", pageLoadWait settings is a framework level settings that is applicable to the entire project. Currently, there is no wait between the page refresh within a script.

"logLevel":"debug" Debug option logs more information such as Xpath for each field into the Output section of the test report.

This is applicable for the Alias developer.

"uploadPath":"src/main/resources/SourceDataFiles /upload/"

Project location where Alias looks for files that need to be uploaded to the target application during script execution.

Note: This location may vary in the Jenkins box. Hence, this property is externalized.

Target "browser":"chrome",

Defines the web driver / browser that Alias will use for the script execution. Web Driver options: IE, Firefox, Chrome

"device":"Desktop",

The browser rendering mode that Alias will use to execute the script. Desktop is the default option. Another option is mobile that opens the browser in the emulator mode and is only enabled for the chrome browser. This means if you want to test a script in the mobile mode, browser option should be chrome.

"headlessMode":false True means the script is being executed in the local desktop and will run in the headless mode. This




indicates the script will only run in the memory without opening any browser. False means script will not run in the headless mode and Alias will open a browser.

Below is the env.json file that sets up the url and unique name for each environment.

Note: You can create any number of applications. The application name should the application name given in the metadata

files.

"version":"1.0",

"envList": {

"Prodfix_7.3.x": { "release":"7.3.x", "dbDriver": "oracle.jdbc.OracleDriver", "applications": { "ABMS": {

"appUrl": "https://demo.ahps123.com:9901/apsp/paa.portal", "dbUrl":"jdbc:oracle:thin:@10.3.31.101:1521:APSMOC01", "dbUser": "ABMSUSER", "dbPwd":"Aust1n" }, "SSP": {

"appUrl": "https://demo.ahps123.com:9912/apspssp/ssp.portal", "dbUrl": "jdbc:oracle:thin:@10.3.31.101:1521:APSMOC01", "dbUser": "ACSSPUSER", "dbPwd":"Ch1cag0" }, "PE": {

"appUrl": "https://demo.ahps123.com:7901/apspssp/pe.portal" }, "PP": {

"appUrl": "https://demo.ahps123.com:9913/apspssp/provider.portal" } }, "endpointurl" : {

"GetCaseDetailsService": "http://apsp-osb:8011/apsp/37/GetCaseDetailsService",

"VerifyLawfulPresenceService" : "http://apsp-

osb:8011/apsp/37/VerifyLawfulPresenceService" }

https://demo.ahps123.com:9901/apsp/paa.portal%22

https://demo.ahps123.com:9912/apspssp/ssp.portal%22

https://demo.ahps123.com:7901/apspssp/pe.portal%22

https://demo.ahps123.com:9913/apspssp/provider.portal%22

http://apsp-osb:8011/apsp/37/GetCaseDetailsService%22

http://apsp-osb:8011/apsp/37/VerifyLawfulPresenceService%22

http://apsp-osb:8011/apsp/37/VerifyLawfulPresenceService%22



The below example shows how the env.json file sets up the url and unique name for each environment:

This file provides the credentials that Alias uses to access database URL. This file also contains the endpoint URL that a

web service uses for the corresponding environment. In the above env.json file, GetCaseDetailsService is the web service

along with its URL that is used for the applicable environment.

Figure 4; Env.json File Elements Example

Below is the Queries.json file that provides the list of the queries used to execute a feature script. Its’ the SQL query that

corresponds to the query name.

{

"queryList":{

"RIDP Primary Final Decision":"Select RESPONSE_CODE,RESPONSE_CODE_DESCRIPTION,DECISION_CODE from identity_response where IDENTITY_REQUEST_ID=(Select * from (Select IDENTITY_REQUEST_ID from identity_request where last_name='$(Last Name Person 1)') where ROWNUM < = 1) order by CREATEDDTM desc",

"query2":"select * from tab",

"QHP_REF_FLAG_INDICATOR01":"Select QHP_REF_IND from PGM_PERS_DETL where ROWNUM < = 1 order by UPDATED_ON desc;",

"QHP_REF_FLAG_INDICATOR02":"Select QHP_REF_IND from EDBC_PERS where ROWNUM < = 1 order by UPDATED_ON desc;",

"MM_Rescind_Scenario4":"Select p.id pgm_id, p.pgm_code, pers_app_event_id, pers.first_name, pers.last_name, null as pgm_app_event_id, e.event_id, e.type_code, e.type_rsn_code, e.event_date, e.eff_date from event e, pgm p, pgm_pers pp, pers_app pa, pers_app_event pae, case c, pers where pers.id = pp.pers_id and e.event_id = pae.event_id and c.id = p.case_id and p.id = pp.pgm_id and pp.id = pa.pgm_pers_id and pa.id = pae.pers_app_id and c.serial_num_identif = $(CaseNumber)"

}

}

Below is the webService.json file that provides the names of the web service used to execute a feature script. The path

included in the file below is the path for the XML request used for the web service.

{

"templatePath": {

"GetCaseDetailsService": "src\\main\\resources\\SourceDataFiles\\WebServicesData\\xmlTemplates\\GetCaseDetailsService.xml", "VerifyLawfulPresenceService": "src\\main\\resources\\SourceDataFiles\\WebServicesData\\xmlTemplates\\VerifyLawfulPresenceService.xml"

}

}



3.1.3. models

– Provides the metadata files for ABMS, ACSSP, Presumptive Eligibility and Provider Portals. Note that each

application requires its own metadata file and each metadata sheet name should indicate the application name.

– It is a repository of all web elements. It contains required elements such as Screen Name, Label, FieldName,

Type, and Path. The optional elements include isMultiple, Version, Create, WaitTime, Conditional etc.

– Refer to the screenshot below as an example for ABMS model:

Figure 5: ABMS Model Spreadsheet Example

– The elements indicate the following:

▪ Screen Name: Shows the web page to which the web element belongs. Note that each screen can have

one or more page mode hence the screen elements will have different Xpaths based on the page mode. For

instance, view and edit modes for the same screen will have different elements and xpaths. Hence,

separate pages are created allowing the elements that go with a view mode to be grouped together and the

ones with the edit mode to be grouped together.

Label: Indicates the label by which the web element is used in the script. For example: First Name. Label

generally corresponds to the field name or a short form of a field name on the screen. It is used to explicitly

populate a certain field in the test script.

▪ FieldName: Indicates the web element name by which the web element is used by the data source.

“FieldName” is used to link the data sheet (Source Data File) and the current row. In the datasheet, the

FieldName is used to identify the data for the given row/field.

▪ Type: Indicates the type of web element. For example: button, text, dropdown, checkbox, radio, and link.

▪ XPath: Shows the location of the web element on the web page.

▪ Wait Time: Indicates the time Alias looks for the web element before failing the script. This is optional. If

provided, engine will attempt to identify until the provided wait time. Wait time is mentioned in seconds.

▪ Order: Indicates the order in which the web elements are populated on the screen. If not provided, system

will use the default order of elements in the input file.

▪ Mode: Indicates if the given webelement is applicable to all modes or only specific mode below.

• A- All modes – indicates the given element is visible in both Desktop and Mobile render modes.



• D – Desktop only - indicates the given element is visible only in the Desktop render mode.

• M – Mobile only - indicates the given element is visible only in the Mobile render mode.

Key points to keep in mind when creating a model for an application:

– Every line is a unique web element.

– Each web element has required properties that should be defined.

– It is important to NOT have duplicate web element labels for the same web page. Else the existing label will be

overridden by the new one.

– If the screen name has a word popup at the end, it means the screen is a pop up window. For example, ABMS

Add Journal Entry Popup. While populating the data to a pop up screen,, Alias understands to change the view

mode from main window to a popup window.

– Web elements that belong to the same page not necessarily need to be in sequence within the model, however

it is highly recommended.

– For screen names, labels, and field names, follow the below syntax rules.

▪ Do not use special characters. Only use letters, numbers and spaces.

▪ Do not use upper case in the middle of the word. For example: the field name should be written as First

Name instead of FirstName.

▪ Do not leave empty spaces in the beginning or at the end of the names.

3.1.4. scripts

• Contains test scripts written in cucumber for applications for which model/object repository data is captured.

• Steps in the test scripts are written by Gherkin language using syntax such as Given, When, Then, And etc. Let’s

take an example of an existing script below called Login.feature:

Figure 6: Feature File (Script) Example



Let’s discuss each part of the above example below:

• Tags – A tag helps to group the script during execution. It helps to identify the category that the script belongs to.

Tags are also used to identify the applicable jenkins job that will execute the script. For example, @smoke tag will

be picked up by the smoke Jenkins job. Once the jenkins job is run, the final cucumber HTML report groups the

scripts results by tags.@reuse in the above snippet is one example of a tag.

Some key points to keep in mind for tags:

– Scripts that include the @ignore tag will not be executed.

– You can add any amount of tags, as needed. However, it is recommended to review the list of existing tags

before you create a new one.

– Tags are case sensitive. For example, @Smoke and @smoke are considered 2 separate tags.

• Feature - Specifies the feature file name followed by the person’s name who created the feature.

Note: It is highly recommended to provide as much details for each feature in the recommended format shown in

the screenshot below:

Figure 7 Format for Feature

• Background: Defines the data that the script uses for execution. As per Gherkin language, background is executed

each time before a scenario is executed in a feature file. Note that there can be multiple scenarios in a feature file

which means the background will be executed multiple times.

Let’s look at the below snippet as an example:

Figure 8 Format for Background

– Background will always include the step that defines the script name. It is recommended to keep the script name

under 30 characters.

– The syntax used such as Then, When etc. are optional, can be interchanged with one another and/or can be

replaced with an asterisk (*).

– Background also defines the data source for a particular data set. This is only applicable when the data is

needed to use from the data sheet.



For more information on how to define a data source, refer to the instructions defined in How to define a data source process within the Alias Command Index included in the Appendix section of this document.

• Scenario: Scenarios are the series of actions that take place in a script execution. Each scenario is independent of

each other and should be ordered in sequence. You must provide a scenario name following the syntax rules

defined in the models section above.

Below is an example of scenarios in a Login script.

Figure 9 Format for Scenario

– Scenario name can be written in the below 2 ways:

▪ Simple Text ( For example, Preconditions or Close Browser as shown in line 10 and 19 in the above

snippet) – This is a one-time step in a given feature file. Precondition is a scenario defined in the beginning

in order to execute the steps generally needed at the start of the feature and are common to all scenarios.

For example: Opening the browser is a step listed under Precondition as it is not required to be executed for

each scenario in a given feature.

▪ Text separated by : : (For example, Log into ABMS:: ABMS_Login as shown in line 13) – This format

indicates the scenario has reusable components which can be used in other scripts.

Scenario naming format with reusable components: <Unique Scenario Name> : : <Unique Reusable Java Class

Name>

The unique scenario name can be used as a step in any other feature file(s), as needed.



Let’s look how reusable scenario is used in any other feature file:

In our above example, Log into ABMS:: ABMS_Login is a reusable scenario which is also used in another script. Refer to

the screenshot below for Non_Compliance script as an example on how Log into ABMS reusable scenario is used in this

script.

Figure 10 Script Example Using Reusable Scenario

When a reusable scenario is used in another script, it is important to know that the background for the original scenario will

not be executed in the other script unless conditions are defined in the other script. Note that the data set used in a

reusable scenario defined in the original script will need to be also defined in the other script that’s reusing the scenario. In

the above example for ABMS Login script, ABMS Login Data is the data set used which is also defined in the

Non_Compliance feature script, as shown in the screenshot below.

Note that Alias provides the possibility of providing a different data set name. Refer to How to use datasources in the

Command Index included in the Appendix section of this document.

Figure 11: Script Example Using Reusable Scenario Data Set



Below are the key reusable components conditions to keep in mind:

- The scenario name with reusable components cannot be used in any other script in Alias.

- The reusable scenario will be available for use in other script(s) only when it has been successfully executed at least

once in the original script.

- If any changes has been made to a reusable scenario, the updated scenario need to be executed at least once for it

to execute it successfully in the other scripts.

- Do not re use the reusable scenario in the script it was created.

3.1.5. SourceDataFiles

The source data files contain the data files / values used in the test scripts. The data files contain the Field Name, Page Name Reference, and the corresponding values.

Key points to keep in mind for the source data files structure:

• The data is separated by the application type.

• The Field Name column (Column A) is the index of the values. It should never have any empty lines and the last

line should always say the text END.

• The Field Name column should not have duplicate values and should always follow the syntax rules.

• In case of multiple scenarios, each scenario is called out in a different column in the data source file and a script for

each scenario exists in Alias.

• The date pattern used is given below:

– #d(|0|0|0| MM/yyyy) – populates today’s day, month and year

– #d(|+1|0|0| dd/MM/yyyy) – adds one day to today’s day, month and year

Figure 12 Source Data Files Structure

2.2. How Database and Web Services Work Together?

To use the database, the below key things are required:

• Database configurations should be properly set up for the specific application environment you want to use.

– Configurations should be set up in the env.json file. For example: to use Prod fix 7.3.x environment, add the

database driver, database URL, database user and the corresponding password. Alias uses these credentials to

access the given URL.



– Currently, JDBC thin driver is the only database driver supported currently..

• Queries that you want to use should be set up.

– To set up the query, include the name of the query and the query in the env.json file. For example: Name: RIDP

Primary Final Decision. The RESPONSE_CODE, RESPONSE_CODE_DESCRIPTION, and the

DECISION_CODE results from this query. The queries contain the placeholder(s) which will be passed from the

feature or the data file. For example: $(Last Name Person 1). This naming convention followed for the

placeholder is $(FieldName).

– Use a specific command required to execute a query. The below command is used to execute the query.

Engine then takes the query and run it against the database URL, and the user provided in the configuration

settings. The result is saved in the context of the active data set.

Then execute "QueryName" query

– Use a specific command required to validate the contents of the query results. The below command is used to

validate the query.

Then Validate "Response Code" data = "RESPONSE_CODE" from query results

In the above command, "Response Code" is a value provided in the DataSource used, however the

"RESPONSE_CODE" is the result from the query used and should match the name of the column of what was

received.

Note: If validation fails, the script fails here. If successful, the script execution continues.

To use the Web Services, the below key things are required :

• A template of the soap webservice request needs to be specified and is dynamically loaded with the passed values

to hit the soap webservices. The key things for the template that you should keep in mind:

– The dynamic variables should end with # in the soap webservice request template file.

– Ensure that the variable name specified in the template should match with the variable names in the excel sheet

or the captured variables.

– For Example: <gcd:CaseNumber>CASENUMBER#</gcd:CaseNumber>

– Template xml path : src\main\resources\SourceDataFiles\WebServicesData\xmlTemplates

– This is located in the ALIAS_client project. But the template path can be anything and should include the xml file

name in the below mentioned json file.



Json file for Template path :

webService.json, For Example:

{

"templatePath": {

"GetCaseDetailsService": "src\\main\\resources\\SourceDataFiles\\WebServicesData\\xmlTemplates\\GetCaseDetailsService.xml",

"VerifyLawfulPresenceService": "src\\main\\resources\\SourceDataFiles\\WebServicesData\\xmlTemplates\\VerifyLawfulPresenceService.xml"

}

}

Json File for Endpoint Url :

The endpoint URLs are environment specific and should be mentioned in the Env.json. An example of endpoint URLs as specified in the env.json file is as below:

"Prodfix_7.3.x": {

"release":"7.3.x",

"dbDriver": "oracle.jdbc.OracleDriver",

"applications": {

"ABMS": {

"appUrl": "https://demo.ahps123.com:9901/apsp/paa.portal",

"dbUrl":"jdbc:oracle:thin:@10.3.31.101:1521:APSMOC01",

"dbUser": "ABMSUSER",

"dbPwd":"Aust1n"

},

"SSP": {

"appUrl": "https://demo.ahps123.com:9912/apspssp/ssp.portal",

"dbUrl": "jdbc:oracle:thin:@10.3.31.101:1521:APSMOC01",

"dbUser": "ACSSPUSER",

"dbPwd":"Ch1cag0"

},

"PE": {

"appUrl": "https://demo.ahps123.com:7901/apspssp/pe.portal"

},

"PP": {

"appUrl": "https://demo.ahps123.com:9913/apspssp/provider.portal"

}

},

"endpointurl" : {

"GetCaseDetailsService": "http://apsp-osb:8011/apsp/37/GetCaseDetailsService",

"VerifyLawfulPresenceService" : "http://apsp-osb:8011/apsp/37/VerifyLawfulPresenceService"

}



Datasheet for Webservices data which will be used to load the template with values :

src\main\resources\SourceDataFiles\WebServicesData\ WebServicesData.xlsx The usage is as per the other data sheets. For Example:

Then define the data source for "GetCaseDetailsService Data" as file "WebServicesData/WebServicesData.xlsx" with spreadsheet "GetCaseDetailsService" and column 1

Statements that can be used for webservice testing :

1. Then (Trigger|Execute) webservice {string} using template {string} and data from dataset {string} – Takes data from excel sheet and loads the request template with these values.

2. Then Capture {string} data into {string} webservice request variable list- Captures the value of variables to be used to load the request template. One Capture statement for one variable.

3. Then (Trigger|Execute) webservice {string} using template {string} and data from variables - Takes data from variables and loads the request template with these values.

4. Then (Verify|Validate) if the {string} from webservice response equals {string} – Compares if the data from webservice is equal to a string

E.g. Then Verify if the "ResponseCode" from webservice response equals "HX009000"

5. Then (Verify|Validate) if the {string} from webservice response equals {string} variable- Compares the webservice response data with variable.

E.g. Then Verify if the "ResponseCode" from webservice response equals "Response Code" variable

2.3. Project Dependecies – Core POM dependencies

Dependency Version Usage

cucumber-java 4.2.6 Supports Cucumber SDK

cucumber-junit 4.2.6 Junit Cucumber runner

cucumber-core 4.2.6 Cucumber core

cucumber-reporting 4.9.0 Supports cucumber reports generation

junit 4.12 Testing framework for Java

velocity 1.7 For code generation

commons-csv 1.8 CSV support

json 20180813 JSON Support

json-simple 1.1.1 JSON Support

selenium-java 3.11.0 Core selenium SDK

poi 4.1.1 Excel Reading



poi-ooxml 4.1.1 Excel reading

xml-apis 2.0.2 XML processing

poi-ooxml-schemas 4.1.1 Excel reading

commons-io 2.6 IO functionality

ojdbc6 11.2.0.3 Oracle DB support

log4j 1.2.17 Logging

pdfbox 1.8.15 To support PDF processing

jira-rest-java-client-core 5.1.6 JIRA client

fugue 4.7.2 JIRA client

cucumber-reporting 4.9.0 Supports cucumber reports generation

axe-selenium 3 Accessibility testing support

exp4j 0.4.8 Mathematical expression calculation

3. How to Use the Alias Project

As a pre-requisite to use the Alias framework, the Alias_client project should already be setup in Eclipse IDE.

This section provides information on how to use the Alias_client project to create and execute the scripts.

3.1. Script Creation

The scripts are created manually and consists of different components such as tags, feature, background, scenario as explained in the Scripts section above.

Let’s take an example below for an ABMS Login script and understand how different components of this feature file are

linked together and used in the script flow.

Example Of A Feature File Feature: Login By John Jacob Background: Then define the script name as "Login" Then define the data source for "ABMS Login Data" as file "SMOKE_DATA/DataSource_IntegratedApplication.xlsx" with spreadsheet "ABMS_Login" and column 1 Scenario: Preconditions Given a new "Chrome" browser is opened for "ABMS" application Scenario: log into ABMS :: ABMS_Login Then use dataset "ABMS Login Data" Then I set data to the "APSP Login" page and click the "Login" button



Scenario: Close browser Then close the browser

• In the above example, the DataSource_IntegratedApplication.xlsx is the data source used. The below screenshot

shows how the data is set up in this data source. Column 1 referred in the script is Column B in the spreadsheet

below. Similarly, column 2 in the script will be Column C in the data source and so on and so forth. To login into

ABMS, the script will use the data specified in Column B within the ABMS Login tab in the Integrated Application

spreadsheet as shown below. From this point on, the script will only look for the ABMS Login Data until any other

data set is specified.

Note: There can only be one data set used at a time.



Figure 13: Data Source Example

• Next, the script looks at the first scenario and opens the browser by looking at the configuration settings and the

environment defined in the automationConfig.json under the config folder. Then, it looks for the given application for

that specific environment in the env.json file and uses the corresponding URL for that application to open the

browser. In this scenario, the script opens the browser for ABMS application in the Prod 7.3.x environment (as

specified in the Autoconfig.json and env.json files above).

• Next, the script uses the data set (values) specified in the defined data source in the Background section of the

script and uses that data to populate the fields on the given page. The script looks for the field names for the

specified page within the application model spreadsheet. For example, in this scenario the given values in Column B

within the ABMS Login tab of the above Integrated Application data source will be populated in the ABMS Username

and Password fields that appear on the APSP Login screen within the model spreadsheet below.



Figure 14: Model Spreadsheet Example

Some key points to note:

– Alias will ignore any field(s) that does not have a value specified in the datasource.

– If the fields have different values in the data source than the default ones that appear on the application, Alias

will update the value with the one specified in the data source for those fields.

• Finally, once all of the above steps are successfully implemented, the script will close the browser.

Note: It is important to include this scenario at the end of the script, as applicable. If Alias will not close the browser,

the browser will remain open and continue to run in the memory which will cause an issue at some point. Hence it’s

important to close every browser that was opened.

3.2. Generate POM

Once the script is created and saved in a feature file, the next step in the flow is to generate a POM.

Follow the steps below to generate a POM:



• Run PagePomGenerator to generate POM java files. To do that, press Ctrl + Shift + T to open a PagePomGenerator

class file. Then, right click on the file in Project Explorer and select Run As -> Java Application, as shown in the

screenshot below. This step generates all the POM classes.

Figure 15 Open a PagePomGenerator Class File

Note : Ctrl+Shift+ T works only if you are currently in a .java file. Else, the PagePOMGenerator.class can be found under

Maven Dependencies ->alias-core-0.0.1-SNAPSHOT.jar-> com.accenture.alias.arch.generator, as shown in the screenshot

below.



Figure 16 Maven Dependencies

Some key points for generating a POM:

– The POM generator has to be executed every time a model file is updated followed by refreshing the project.

– If there is an issue in any POM generated files or the model file, it is recommended to fix what is wrong in the

model file such as incorrect characters etc., then delete all existing POM packages and then re-run the POM

generator.

Developer Note: POM generator generates the page object model classes based on the model file which are then used for

script execution. It is important to keep in mind that the model itself is not used for script execution, the model file serves as

a base for the page object model classes.

Note: Generated POM files are not supposed to be checked-in to source repository.

Once the POM java files are generated, the next step is to update the automationConfig.json and env.json files settings

based on what you need.

Refer to the config section of this document for more details on the automationConfig.json and env.json files configuration

settings.



3.3. Script Execution

Once you have generated the POM files and updated the automationConfig.json and env.json files, follow the steps below

to begin the script execution process.

1. Generate test sources by running the below command to generate the Junit classes. This generates the Junit

classes and creates a junit for every script in the project.

mvn clean generate-test-sources

Once generated, you can find the Junit in your workspace under src/test/java as shown in the screenshot below:

Figure 17 Junit Classes



2. Next, run the Junit for the script you want to execute or take any existing Junit and update or point that Junit to the

script you want to execute.

– The recommendation is to take any existing Junit and update or point that Junit to the script you want to execute

by updating the features with the script feature you want to execute.

Figure 18 Script Feature

3. Once you updated the feature, right click on the updated Junit and select Run As -> Junit Test, as shown in the

screenshot below.

Figure 19 Execute the Junit

The script then starts to execute. Once the execution is completed, the Alias user can generate a report manually to view

the status of the script.

Note: Don’t check-in the JUnits into the source repo.



3.4. Generate Report

Once the script execution is done, run the ReportGenerator.class similar to PagePOMGeneraotor.class which is covered

in the previous section.

You will see the report (overview-features.html) under target/report/cucumber-html-reports folder.

Note: To see full debug log including xpaths in the report, use the "logLevel":"debug" under Alias property in the

automationConfig.json file.

Feature field shows the link for the script name.

Figure 20 Features Statistics Report

Upon clicking the Feature hyperlink, the below screen appears. This shows the status of each step executed within the

script.

Figure 21 Feature Report – Status of Steps Executed

Upon clicking the expand icon, you can see the status of each step executed within the script. The text highlighted in green

indicates the step passed where as the text highlighted in red color indicates the steps that failed.



Figure 22 Status of Steps Executed – Pass or Fail

Once you further expand the Output section within each step, it displays the data that was used to execute that step. It also provides the XPath used for the buttons and how it was able to successfully execute that step. Additionally, the step that failed shows the java code along with the screenshot for the step that failed. Note that the script execution stops at a step that failed.

Figure 23 Expanded View of Status of the Steps Executed



Figure 24 : Page on which the Script Failed During Execution

Even if one step fails, the script fails.

4. Alias Capabilities



4.1. Accessibility Feature

Alias framework uses AXE Webdriver automation tool to test accessibility which can be integrated with selenium web

driver. AXE tool is supported in Chrome and Firefox, IE and Edge Browsers.

AXE Webdriver uses AXE Rules Version 3.4 which has a set of 83 Rules to test WCAG 2.0 Guidelines.

Based on the user impact, AXE 3.4 rules are classified into 4 types:

• Critical

• Serious

• Moderate

• Minor

AXE Core 3.4 Rules set does not cover entire WCAG 2.0 Guidelines. AXE 3.4 Covers 23 WCAG guidelines out of 40. The

below table provides a list of 17 WCAG rules that must be tested manually.

Note that the below WCAG 2.0 Guidelines must to be tested manually and rest of the guidelines can be tested through the

Alias Framework. Tools like WAVE or AMP tools do not cover the below rules, hence manual testing is required to cover

these rules.

WCAG 2.0 WCAG 2.0-Rule Tool Recommendation

1.2.4 1.2.4 Captions (Live) Not Applicable for Product

1.2.5 1.2.5 Audio Description (Prerecorded) Not Applicable for Product

1.3.3 1.3.3 Sensory Characteristics (Level A) Manual Observation

1.4.2 1.4.2 Audio Control (Level A) Not Applicable for Product

1.4.5 1.4.5 Images of Text: Manual Observation

2.1.2 2.1.2 No Keyboard Trap (Level A) Manual Observation using Keyboard Keys

2.3.1 2.3.1 Three Flashes or Below Threshold (Level A) Not Applicable for Product

2.4.3 2.4.3 Focus Order: Manual Observation using Keyboard Keys

2.4.5 2.4.5 Multiple Ways Manual Observation

2.4.7 2.4.7 Focus Visible: Manual Observation

3.2.2 3.2.2 On Input: Manual Observation

3.2.3 3.2.3 Consistent Navigation: Manual Observation

3.2.4 3.2.4 Consistent Identification: Manual Observation

3.3.1 3.3.1 Error Identification: Manual Observation

3.3.3 3.3.3 Error Suggestion: Manual Observation

3.3.4 3.3.4 Error Prevention (Legal, Financial, Data): Manual Observation



4.1.1. How to test Accessibility in Alias Framework:

Follow the instructions below to allow the pages to go through an accessibility test during script execution:

1. Open the automationConfig.json file in Alias client and set the enableAccessibilityTest flag to True, as shown in the

screenshot below and save the file.

Figure 25: Accessibility Flag in AutomationConfig.json File



2. Open the ‘Parallel_01Test.java’ junit and provide the applicable feature file path (an example shown in the

screenshot below) and save it.

Figure 26: Feature File Path Update

3. Next, right click on the Parallel_01.Test.java junit test and click on Run As and then Junit Test options.

Figure 27: Run Junit Test

This will initiates the script execution process with accessibility check enabled for all pages in a script flow. Next, let’s look at how to generate a report to view the accessibility results.



1.1.2 How to view Accessibility Results in a Script Flow

Follow the steps below to view the accessibility results in a script flow on a report:

1. Once the script execution is done, run the report using report generator by right clicking the ReportGenerator.class and then selecting the Run As and then Java Application options, as shown in the screenshot below:

Figure 28: Report Generator

2. Navigate to the below path in the Reports folder within an Alias_client project:

Alias_client\target\report\cucumber-html-reports’’ and then open the Overview Accessibility file.

Figure 29: Accessibility Results Overview



3. Report will list out the total number of violations including the serious and moderate violations per page within a script

flow.

Figure 30: Accessibility Report

4. Click on the page name hyperlink to see the issues in detail.

Figure 31: View Accessibility Issues in Detail



5. Click on the ‘+’ sign to expand the issue in order to view the issues in detail.

Figure 32: Issues Detailed View

6. Click on the link to see the impacted WCAG criteria 2.0, recoomended solution to resolve the issue, and why it matters.

You can also see other information such as AXE Rule ID, and WCAG impacted guidelines.

Figure 33: Accessibility Issue Detailed Information



5.1. Other Alias Capabilities

The below table provides information about the additional capabilities of Alias. Note that some of the below items are already implemented while some are the roadmap items.

Table 3: ALIAS Capabilities

ALIAS Capability / Features

Description

JIRA Integration

Allows a unique step failure in multiple features/scripts are grouped to create as single defect. If JIRA integration is not enabled, you can see the same information in the error report. The configuration settings details are provided in the automationConfig.json file.

Multi-browser Support Currently supports multiple browsers including IE, Firefox, Chrome

(Almost) Zero Code Includes minimal to zero coding in the script creation process.

Accessibility Testing Pages go through the accessibility testing using the axe framework during script execution.

Webservice Testing Enabled

Responsive Pages Support

Responsive testing can be enabled by changing the device property in automationConfig.json.

CSV support Enabled to support CSV for metadata and data files.

Caching of Excel/CSV input for performance

To improve performance, all the data files are cached at the beginning of the script execution.

Performance Report

Supports measuring the page loads based on the instrumented page and actions in metadata, and creates 2 reports to support consolidated and detailed metrics.

SQL Integration Supports execution of dynamic queries to overwrite input data sets as well to validate UI data.



6. Appendix

6.1. Alias Command Index

Refer to the attached document for the Alias Commands:

ALIAS Command

Index.pdf

6.2. Install Maven

Once Java is successfully installed, download the Apache Maven version 3.6.3 from Binary Zip Archive on your machine. Refer to Install Apache Maven for step by step instructions and tips.

Once Maven is successfully installed, follow the steps below to add environment variables to complete the Maven setup on

your machine:

1. Under Control Panel, select System, and then click Advanced System Settings. The System Properties pop up

window appears as shown in the screenshot below:

Figure 34 System Properties

http://apache.mirrors.lucidnetworks.net/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.zip

https://maven.apache.org/install.html



2. On the System Properties pop up window, click Environment Variables. The Environment Variables pop up

window appears.

Figure 35 System Properties - Options



3. On the Environment Variables pop up window, click the New button.

Figure 36 Environment Variables Pop up Window



4. On the New System Variable pop up window, enter the Variable name and Variable value for Maven and click

the OK button, as shown in the screenshot below.

Note: The Variable value should be the path for the Maven installed on your machine. For example, in this

instance Maven is located under C:\Program Files.

Figure 37 New System Variable Pop up Window

The MAVEN_HOME is now successfully added as a system variable, as shown below.

Figure 38 Add New System Variable



5. Next, ensure to move the newly added MAVEN_HOME variable up the hierarchy. To do this, select the Path

variable on the Environment Variables pop up window, and click the Edit button.

Figure 39 Edit Path Variable

6. On the Edit environment variable pop up window, click the Move Up button until the Variable value for the

MAVEN_HOME variable appears on top of the list, as shown in the screenshot below.

Figure 40 Move Variable Value for MAVEN_HOME



7. At this point, run the command prompt to ensure your settings for the newly installed Maven are effective, as shown

in the screenshot below:

Figure 41 Verify Maven Installation Settings in Command Prompt

The Maven setup is now complete.



7. Revision History

Table 4 Revision History

Revision Date Description Author

02/24/2020 ALIAS Framework Reference Guide Isha Soney

03/07/2020 Alias Command Index Update Added core pom dependencies

Smitha Pillai

accenture products & platforms (app) accenture health

Documents