The Functionize Expression Builder makes adding Variables to your tests quick and easy. You can swiftly insert a variety of data, and our app will do the heavy lifting! Variables open up the ability to test your site more thoroughly by allowing dynamic data for each execution.

What is an Expression?

Functionize defines an Expression as an executable piece of JavaScript code encased in double curly {{ }} brackets. For example:

{{console.log('Hello World!')}}

This will log 'Hello World' into your JavaScript console at runtime. Expressions can be used wherever custom input is allowed within the test. For example, in the value of an Input Action, in the Pre- or Post-Script code for a test, in a Selector Override, or in a Verification Override. Expressions are explicitly expected in a VerifyVariable Action and contain the code that gets executed to verify a variable. They will behave similarly to a Custom JS Action, passing or failing the step based on the response.

What is a Variable?

A Variable, at its most basic, is something that stands in to represent other data. It stands in where you have a piece of data that can be changed for various testing purposes. Variables can be used in place of site credentials, order numbers, cookies, and more.

Scope of Variables

The scope of a Variable determines where it can be referenced. It defines the portion of the program where the variable is valid and accessible.

Here are some common types of variable scope:

1. Local Variables: Variables with local scope are declared within a test case, they are only accessible within a single test and are typically used for temporary storage, these are the most common types of variables for dynamic data when running the test, but you don't want parallel executions of that or other tests to interfere with the data
2. Project Variables: Variables with project scope are declared at the project, global level, they are accessible from anywhere within the project, making them available across all tests within that Project Environment
3. TDM Variables: Variables that provide the capability of passing variables when using TDM Data Sources

Variables are accessed or set within Expressions as an object called fze.local or fze.project respectively. For example, if you would like to use a project variable to set an email when entering the email, the input value will be:

{{fze.project.yourEmailVariableName}}

Variables cannot have spaces and must be valid JavaScript names, accessible via the '.' notation for object access.

Types of Variables:

• Value: This essentially 'hard-codes' a string to be used in the variable during test execution, whatever value is set by the user gets passed into the variable
• Previous Action: The Previous Action takes an attribute from a previous test action, as defined by the user at the time of Variable creation, and passes it into the variable, if the attribute from the previous action is dynamic in nature, it will populate the variable with the dynamic value during test execution
• Cookies Variable: The Functionize cookies variable works as data that a website stores on a user's computer or mobile device through their web browser - Cookies are widely used on the internet to store user preferences, login information, shopping cart items, and other data related to the user's interactions with the website - Functionize can store this cookie data via the Cookies variable to be used with test execution
• HTML Storage Variable: The HTML storage variable, often referred to as 'Web Storage,' is a web browser feature that allows websites to store data locally on a user's device - it provides a way for web applications to store data persistently across sessions, meaning the data will be retained even if the user closes and reopens the browser or navigates away from the page and Functionize can capture this data via an HTML Storage variable to be used during test execution
• Page Variable: Typically refers to a variable in the context of web development and programming that stores information specific to a particular page of a website that can be used to hold data or settings related to the content, layout, or functionality of that specific webpage - Developers often use page variables to dynamically manage and control aspects of a webpage, allowing for more flexibility and customization in the behavior and presentation of different pages within a website and Functionize can capture any of this data stored in Page Variables to be used during test execution
• Resource Variable: Typically used to validate network calls that a page makes and to verify that it loads as expected, for example verify that all network calls are loading as expected and Functionize is able to capture details from these Resource Variables as part of a test execution
• Clipboard: This refers to a temporary storage area provided by the browser or the operating system where users can temporarily store copied data that could include text, images, or other types of content - Web Developers may use these capabilities to enhance user interactions on a website, such as allowing users to copy specific content with a button click and then storing that clipboard content in a variable, Functionize can use it during test execution
• Custom Expression: The Functionize Custom Expression Variable is a programming concept used in various applications, frameworks, and languages that enables Web Developers to define custom expressions or functions that can be evaluated at runtime to produce a value, which can then be used during test execution
• Environment Configuration: Environment Configuration in Functionize allows users to define and manage the environments in which their tests will be executed. These environments can represent different stages of the development lifecycle, such as development, staging, production, or custom setups. Proper configuration ensures that tests run in the correct context, providing accurate and meaningful results. 

What is a Function?

A Function is a reusable block of code that performs a specific task or set of tasks and can take in parameters, execute a series of statements, and return a value. We use functions to allow access to certain types of data via predefined methods. In the fze object, in addition to variables, a set of functions are available to users, as follows:

The following are custom Functionize functions

fze.action([action_id]).[attribute]    // allows you to access previously executed actions' data

fze.cookie([cookie_name]).[attribute]  // allows you to access cookie values by name

fze.clipboard()                        // allows you to access current clipboard contents

fze.resource[[url].[attribute]         // allows you to access resource network traffic

The following are supported natively via JavaScript

localStorage.getItem('storage_name')    // allows you to access HTML5 storage data

document.[attribute]                    // page variable (JavaScript data) access

Examples:

Previous Action

{{fze.action('1234124515534_ABCDEFG6KM').url}}

{{fze.action('1642169353534_QWAKSM66KM').positionX}}

Cookie Value

{{fze.cookie('cookieName')}}

{{fze.cookie('google_tracker')}}

Clipboard

{{fze.clipboard}}

HTML5 Storage

{{localStorage.getItem('my_html5_name')}}

Page Variable

{{document.URL}}

{{document.title}}

Resource Variable

{{fze.resource['wikipedia.org/logo.jpg'].method}}

Environment Configuration Variable

{{fze.env.name}}

Live JavaScript Evaluation

Our Variable Expressions are robust snippets of JavaScript code. Each custom expression is evaluated in the JavaScript on the web page, giving you access to test other functions on your website within the expressions you build. With the help of the Functionize Expression Builder, you can truly customize these variables. In most scenarios, we will try to evaluate the expression while you're creating the test so you can see exactly how it will behave at execution time. For certain scenarios, we may not evaluate the code during test creation, but you can run the test with the {{ }} expression syntax to validate it at runtime.

Supported Fields

Functionize Expressions are supported in the following locations:

• Input Text Values
• Verification Text
• Custom Code Actions
• Selector Override
• Outcome Override
• Pre-Script
• Post- Script

Setting a Variable in Architect

Creating a new Variable or editing a Variable will generate a SetVariable Action in the test. This is done so that these values are set at that moment in time, similar to how they would be set in a line of code.

1. Click the Variables button at the bottom of the Architect to open the Variables panel
2. Click Add Variable to open the Expression Builder sidebar panel, Project Variables that have been created by you or a teammate within this Project, will be displayed in the Variables panel
3. Enter the Name for your variable, in this example, we will use 'searchCriteria'
4. Select the Scope of the Variable: Local or Project - Local Variables exist within the confines of a single test, they must be created and set during test recording to be used at any point in the test case and Project Variables are global to the project, so any other test may use or modify that variable
5. Select the Type of function you will use to help define your Variable, in this example, we will use Value for a predefined number or stringNote: Different Variable Types will open subsequent fields to enter or select the necessary information.
6. Select an Operator to perform on your data, if applicable, for example, here we have selected ToUpperCase, which alters our value entered above, 'Tripod' to 'TRIPOD' as seen in the Result section - see below to learn about the provided Operators
7. The Expression field can be unlocked to customize your expression beyond the provided operators, click the lock  icon to edit the Expression and click the  icon again once finished to re-lock the Expression
8. When your Variable is setup, click Save
9. Your new Local Variable is shown in the Variables panel list and click the X in the upper-left to close the Variables panel
10. The SetVariable Action is now a step in your test

Using and Modifying Variables in Architect

From this point forward, the Variable you've setup can be used in different ways throughout your test. These options can be found by opening the Variables panel via the {x} button and then using the Action … button for the specific variable.

• Insert Value: Enters the Value of the expression into a selected input field
• View Expression: Make changes to your Expression directly without the Expression Builder
• Copy Expression: Copy the Expression to the clipboard and when pasted into an input field, the Expression is evaluated in the JavaScript on the site
• Edit: Opens the Expression Builder to make changes to the Variable
• Verify Value: Opens a modified version of the Expression Builder to create a verification of the variable value - this can be added as a special Verify Action into your test
• Delete: Delete the Variable

Available Variable Types

• Value: Input a specific number or string to be hard coded
• Previous Action: Actions that have already been recorded in Architect can be selected for use as a Variable, a drop-down menu will appear with the steps that are available to select
• Cookie: A drop-down menu will display the Cookies that are available to select, once a Cookie has been selected, a drop-down menu of available Properties for that Cookie will display and finally once the Property has been selected, the value of the said property will display in the Result field
• HTML Storage: A drop-down menu of available Local Storage keys will display
• Page Variable: Enter a local page JavaScript Variable such as 'location' or 'window' and then select the desired Attribute from the menu
• Resource Variable: A drop-down menu will display Resources attached to a page, such as images, stylesheets, icons, etc and once the Resource is selected, the specific Header can be selected to be used for verification, such as with a specific image
• Clipboard: Creates an Expression based on the text you have selected and copied and the copied text will display in the Result field of the Expression Builder
• Custom Expression: Write your own custom JS Expression including predefined JS Functions, Regular Expressions, common Operators, and more - follow the expression syntax as specified earlier in this document

Available Operator Functions

• SubString: Select a string of a certain amount of characters from the given value
• ToLowerCase: Transform all letters in the value to lowercase
• ToUpperCase: Transform all letters in the value to uppercase
• Extract Numbers: Return all the digits in the value without spaces or other characters
• Extract Float: Return the digits in the value between the first character, whatever the type: alpha, numeric, punctuation and the first or next character of punctuation
• Regex: Use Regular Expression patterns to pull different results from the value

Use Cases

Here are some examples of Expressions for different testing purposes.

// Update your total count of orders in a variable by adding 1 to an existing variable

{{fze.local.orderCount = fze.local.orderCount + 1}}

// Combine existing variables to create specific user emails

{{fze.local.email = fze.local.firstName + '@functionizeapp.com'}}

// Set a variable to hold information from an Action recorded earlier in your test

// Select the Previous Action type, select the step, and then select the step attribute

{{fze.local.navigate = fze.action('1645900301653_IYI9Y5RRPM').url}}

// Result: https://www.amazon.co.uk/

// Store the entire value, or use an Operator function to set a specific part of the value

{{fze.local.detection = fze.cookie('session-id')}}

// Result: 261-9164342-6884424

{{fze.local.detection = fze.cookie('session-id').substring(0,4)}}

// Result: abcd

Variables in the Slider View

When a Variable is used within a test, the test result footer will show the current state of all stored Variables in the system. 

Because Variables are stored and verified using Expressions, the Expression Builder and Variables will always show more details about how they are stored and evaluated using JS custom script evaluations. If there is a syntax error, if the Expression has been customized, or if the value is unexpected, it will be displayed within the step, allowing updates to be made as needed.

Resource Variables

Resource Variables are used to validate network calls that a page makes and to verify that it loads as expected. For example, a user may want to use resource variables to perform technical verifications. Resource variables offer a lot of flexibility.

Sample, simple Use Case: Verify that all network calls are loading as expected.

Sample, complex use case: Validating information within the DOM/source code to ensure that data matches the visual elements displayed on a page. Further, ensure that the segmentation is working as expected, and the correct subset of users is having the correct experience based on the information that is loading.

Note: If your use case involves capturing data from recurring API calls with Resource Variables, see this example.

Resource Variables are accessible within Architect.

To begin, it is important to set up which URLs are acceptable to show in the Resource Variable drop-down menu in the Architect.

Adding the Resource Variable URLs in Architect

1. Go to the Team tab in FunctionizeNote: the Team tab is only available to an Functionize Admin.
2. Click on Resource Tracker and then click + Add New Resource to define what URLs should show in the Resource Variable drop-down in Architect
3. This is the Resource Tracker Whitelist
4. Please specify the URL of the resource(s) that need to be tracked in ArchitectNote: Each Resource will be tracked for requestHeaders, responseHeaders, QueryString and associated parameters.
5. If Regex is selected, use the syntax as example: google.com/* or *google.com/* -- as wildcards
6. When ready, click Save resources
7. These will now be available when using a Resource Variable during test creation
8. In order for Resource Variables to be used during test execution, you have to ensure that the Capture network logs setting is ON under Test Settings > Advanced TAB

Applying a Resource Variable

1. Click the + icon in the Architect
2. Click the Variables button
3. Select Resource Variables radio button
4. Select the appropriate URL for verification from the URL drop-down menu
5. Select the Attribute name, in this example, the user is selecting statusCode
6. Select the Operator -  if you need to use one of the following functions on the data from the Resource Variable:
   • Substring
   • ToLowerCase
   • ToUpperCase
   • Extract Numbers
   • Extract Float
   • Regex
7. The Value will auto populate with the current Resource Variable value
8. Click Set Target to enter the Resource Variable Result into the an input field on the website

Capturing a Resource Variable in a Local/Project Variable

1. Click the Variables  icon button in the Architect
2. Click the + Add Variable button
3. Select the variable Scope, enter a variable Name and select variable Type as Resource Variable
4. Select the URL from the drop-down list and select the Resource Variable Attribute, in this example 'statusCode' and if you need to select one of the following functions on the data from the Resource Variable:
   • Substring
   • ToLowerCase
   • ToUpperCase
   • Extract Numbers
   • Extract Float
   • Regex
5. Click Save button to store Resource Variable in your Local/Project variable

Resource Variable Examples

Functionize Resource Variables has the capability to retrieve data from your requestHeaders and responseHeaders, store in Functionize Variables (Local and Project) and use throughout your test execution.  Here are some samples of how to use Resource Variables:

//Retrieve Resource Variable statusCode

fze.local.StatusCode = fze.resource['https://functionizeapp.com/testsites/anaqa/index.php'].statusCode;

//Retrieve Resource Variable requestHeader data

fze.local.RequestHeader = fze.resource['https://functionizeapp.com/testsites/anaqa/index.php'].requestHeaders['User-Agent'];

//Retrieve Resource Variable responseHeader data

fze.local.ResponseHeader = fze.resource['https://functionizeapp.com/testsites/anaqa/index.php'].responseHeaders.date;

Using FZE Object Variables

Variables are stored and made available to JS expressions and scripts, executed in the browser by Functionize, in the form of a variable called fze in the scope of those expressions and scripts. That object itself is read only and has the following attributes:

Objects

fze.local - Object, Read/Write

• This Object is for local variables which need to be available during and after the current step in a single test execution and they will be visible in FE, but will not be available in future runs or other tests in the project

fze.project - Object, Read/Write

• Like local variables, project variables can be used to store data by setting attributes on them, unlike local variables though, project variables are from previous runs, and/or project settings are loaded at the beginning of the test, and changes made to them will persist into future runs and project variables are shared across all tests in a project, so be careful to consider how they may be overwritten, especially in orchestration runs

fze.action("123_ACTION_ID_HERE") Step Object, Read Only

• This method returns the Step Object from the most recent step that matches a given ActionID, if one exists, see below for the contents of the Step Object

fze.step Array of Step Objects, Read Only

• This list contains a Step Object for each step executed so far in this test and the steps ordered descending in chronological order

fze.attributes Object, Read Only

• Attributes contain an object of all attributes of the currently selected element, this includes computed attributes, which are accessible like c_background-color and this object is not necessarily populated until a specific attribute is requested

fze.clipboard String, Read Only

• This read only string value will be populated on each step with the current value of the test machine’s clipboard and this is useful for verifying the value of text added to the clipboard by the app being tested

fze.resource Object, Read Only

• This object contains network call objects that were made since the most recent PageInit, if the flag to provide them is enabled in the test, the resource objects are mapped per URL - if one URL is used multiple times since the most recent PageInit step, all but the first request will have numerals appended to their URL - see below for an example of what could be contained in the resource object

fze.date Object, Read Only

• This is a JS date object created at the time of script injection, it is provided as a static time to use when multiple calls to a current Date are needed in custom code and it is analogous to a local variable like let currentDate = new Date();

Functions

fze.randomPhone(format)Function

• Generates a random phone number in a given format and the format can be any string, and all X characters will be replaced with random integer digitsFor example: +1 (415) XXX-XXXX could return something like +1 (415) 765-4321 or +1 (415) 112-3581, if no format is provided, the default XXX-XXX-XXXX is used.

fze.randomNumber(length)Function

• Generates a random integer number of the given length and defaults to 3 digits

fze.randomNumberString(length)Function

• Generates a string consisting only of integer digits of a given length and defaults to 10 characters

fze.numberInRange(min,max)Function

• Generates a random number inside the provided range and min and max are required arguments

fze.randomString(length)Function

• Generates a random string of alpha numeric characters (upper and lower case) of the specified length. Defaults to 10 characters

fze.randomEmail(domain)Function

• Generates a random email at a specified domain. Defaults to example.com if no domain is provided and email addresses will be a random string of characters between 6 and 8 characters long (inclusive)

fze.randomDoB(minimumAge, maximumAge)Function

• Generates a JS Date object for the birthdate of someone between the minimumAge and the maximumAge provided and if multiple values from that date, like day, month, and year are needed, the object should be saved in a variable and referred to from there

All values written to any parts of the fze object will be serialized and deserialized between each step, so non-privative types will become objects or strings, some values may be typecast before you use them next, and object references will be come dereferenced. Generally, variables are intended to be used as strings:string key pairs.

Step Object

Step Objects represent a step that was executed earlier in the test execution and each has the following attributes

actionIdString

• The Action ID of this step

stepNumber Number

• Denotes which step this was in execution and StepNumbers are 0-indexed with the first page init being step number 0

url String

• The active page url when this step was executed

resultCode String

• The string code for the step’s result:
  • E Error
  • N Fail
  • Y Pass
  • W Warning
  • S Suppress (Optional and failed, or skipped step)

textString, Optional

• The text of the step’s element

valueString, Optional

• The value of the step’s element

attributes Object

• The filtered set of attributes gathered from this step’s element, it does not include computed attributes and this object is not necessarily populated until a specific attribute is requested

elementWidthString, Optional

• The width in pixels of the step’s element

elementHeightString, Optional

• The height in pixels of the step’s element

Example Use Cases

fze.local.thisStepComputedWidth = fze.attributes.c_width

• This sets a local variable equal to the value of the current step’s element’s computed width, if it exists

fze.project.valueToIncrement += 1

• Increments the value of the project variable valueToIncrement by 1 and this change will be available later in this test and in future runs of any test in the same project

fze.local.stepFourClipboard = fze.clipboard

• Save for later use the value of the clipboard during the current step

fze.action("1641833968712_2E6FFQP26P").attributes.href

• If used in an expression or verifyVariable action, this will evaluate to the href attribute of the element from the most recent action with ID 1641833968712_2E6FFQP26P

Notes

• All expressions or scripts (custom code, set variable, and verify variable actions, as well as the PreAction and Post Action scripts of each steps) have variables available to them as long as fze appears somewhere in the expression/script
• Team and project variables are fetched at the beginning of a test. If conflicting changes are made to project or team variables during two or more tests running at the same time, whichever test finishes last will overwrite the values of the earlier test and it is inadvisable to write to the same project variable in multiple tests that could be run in parallel
• It is possible to write to some read only objects in fze however those changes will be lost by the next step at the latest
• Just as in JS, attributes of Objects can be accessed with either dot fze.attributes.href or array notation fze.attributes["href"] with the advantage of the latter being that the attribute name can be determined dynamically
• Because local and project variables are logged out in the slider view, you can debug by saving objects to them. For example, to check which header fields are available in a network resource object, you might use: fze.local.R2 = fze.resource['https://functionizeapp.com/testsites/anaqa/'].requestHeaders;

{
"http://apps.qa01.trustmineral-staging.com/auth/login":
{
"formData":
[],
"method": null,
"queryParams":
{
"from": "/dashboard"
},
"requestBody": "",
"requestHeaders":
{
"Accept": "text/html,application/xhtml%2Bxml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9",
"Accept-Encoding": "gzip,deflate",
"Accept-Language": "en-US,en;q=0.9",
"Sec-Ch-Ua": " Not A;Brand;v=99, Chromium;v=102, Google Chrome;v=102",
"Sec-Ch-Ua-Mobile": "?0",
"Sec-Ch-Ua-Platform": "Linux",
"Sec-Fetch-Dest": "document",
"Sec-Fetch-Mode": "navigate",
"Sec-Fetch-Site": "none",
"Sec-Fetch-User": "?1",
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.61 Safari/537.36 Functionize",
"Via": "1.1 martian-a557ff3b4f16e888b294"
},
"responseBody": "",
"responseHeaders":
{
"Warning": "199 martian proxyconnect tcp: dial tcp 10.240.0.46:3128: connect: connection timed out Tue, 28 Jun 2022 01:08:32 GMT"
},
"status": 502,
"statusCode": 502,
"url": "http://apps.qa01.trustmineral-staging.com/auth/login"
},
"http://apps.qa01.trustmineral-staging.com/auth/login_1":
{
"formData":
[],
"method": null,
"queryParams":
{
"from": "/dashboard"
},
"requestBody": "",
"requestHeaders":
{
"Accept": "text/html,application/xhtml%2Bxml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9",
"Accept-Encoding": "gzip,deflate",
"Accept-Language": "en-US,en;q=0.9",
"Sec-Ch-Ua": " Not A;Brand;v=99, Chromium;v=102, Google Chrome;v=102",
"Sec-Ch-Ua-Mobile": "?0",
"Sec-Ch-Ua-Platform": "Linux",
"Sec-Fetch-Dest": "document",
"Sec-Fetch-Mode": "navigate",
"Sec-Fetch-Site": "none",
"Sec-Fetch-User": "?1",
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.61 Safari/537.36 Functionize",
"Via": "1.1 martian-a557ff3b4f16e888b294"
},
"responseBody": "",
"responseHeaders":
{
"Warning": "199 martian proxyconnect tcp: dial tcp 10.240.0.153:3128: connect: connection timed out Tue, 28 Jun 2022 01:09:04 GMT"
},
"status": 502,
"statusCode": 502,
"url": "http://apps.qa01.trustmineral-staging.com/auth/login_1"
}
}

Using Resource Variables with Recurring API Calls

Functionize has a feature called Resource Variables that are used to validate network calls made by a page and to capture and verify the data in those network calls. There are some use cases that require capturing recurring API calls as resources within your test. The standard Resource Variables functionality can be prone to failure when you need to use a recurring API call as a resource, like fze.resource['myurl_2'] with the _2 suffix. These tend to be variable-numbered resources, and you may not be sure which request contains the data you want to capture.

For this recurring API call scenario, you will need to evaluate which Resource Variable (fze.resource['myurl_2']) request has the payload that you want to capture. This has to be done using a Functionize Custom Code Action. The Custom Code Action will need to specify the parameter you are looking to capture, which may only be part of some of the requests.

In this example, the tester is searching for an authentication token that we need to capture in a Local Variable and then use that Local Variable to enter the token later on in our test flow.

// You must return a boolean value to determine the success or failure of this step.
let limit = 20;
for (let it = 0; it < limit; it++) {
let suffix = ''
if (it > 0) {
 suffix = '_' + it
}
if (typeof fze.resource['https://myurl.com/api/auth/oauth/v4/token' + suffix] != 'undefined') {
 try {
  fze.local.Collect_response = JSON.parse(fze.resource['myurl.com/api/auth/oauth/v4/token' + suffix].responseBody);
 } catch(e) {}
}
}
return typeof fze.local.Collect_response != 'undefined'

The code sequentially iterates through a maximum of 20 recurring resources, examining a unique suffix for each one. For every suffix, it verifies the presence of a responseBody associated with the resource. Upon finding a responseBody, the code assigns it to a local variable, if it can be parsed into JSON. The outcome of the custom code action, either pass or fail, is contingent upon the existence of a valid JSON responseBody.

Performing Element Selection with Variables

Driving Element Selection refers to the process of choosing or identifying the key factors or components that will significantly impact selecting and/or interacting with a specific web object as part of a test case. With Functionize, you can rely on the default machine learning (ML) data to drive your element selection, or you can assist the default selection by providing a specific text string related to the object you want to interact with, obtained in an earlier test step and stored as a Local or Project Variable. This document outlines how to set up and drive element selection using variables effectively.

Setting Up Element Selection Using Variables

Step 1: Create a SetVariable Action

1. Store Text in Variable: Create a SetVariable Action to store the text that will be used in a later test action to drive its element selection. This can be a Local or Project Variable.
   • Example: Action #1.2 captures the text 'USE CASES' from the menu object on the webpage into the Local Variable overrideText.

Step 2: Capture Text During Test Execution

1. Capture Text: During test execution, capture the required text from the web object and store it in the Local Variable.
   • Example: Action #1.2 captures the text 'USE CASES' from the menu object into the Local Variable overrideText.

Step 3: Override Default ML Selection with Variable

1. Advanced Tab Configuration: At the step where you need to override the default ML selection, provide the Variable expression {{fze.local.overrideText}} in the Text field under the Miscellaneous section in the Advanced Tab.
   • Example: In Action #1.3, use the Variable {{fze.local.overrideText}} to drive the element selection.

Step 4: Verify Test Recording

1. ARC Screenshot on Slider View: During test recording, verify the recorded action in the ARC screenshot on the Slider view.
   • Example: Action #1.3 was recorded selecting the 'PRODUCT' menu. 

Step 5: Execute and Verify Test

1. Test Execution Verification: During test execution, verify that the element selection override from the Local Variable is working as expected.
   • Example: At Action #1.3, the test verifies that the 'USE CASES' menu is not equal to 'PRODUCT', using the element selection override from the Local Variable.

Cross-Browser Compatibility

Functionize ensures that the element selectors work across different browsers. However, some browsers may interpret selectors differently. It's important to test your selectors if you require execution across multiple browsers to ensure compatibility.

By following these steps, you can effectively set up and drive element selection using Variables in Functionize, enhancing the precision and flexibility of your test automation process.