Adaptive Timing Overivew

Timing and hard-coded waits to prevent flaky tests are things of the past. During execution, Functionize supports Adaptive Timing, meaning it determines how long to wait when trying to locate an element before timing the test out. We consider multiple vectors for timing data: from the original test model, previous runs, and previous actions in the current execution.  Functionize always attempts to execute as fast as possible, as fast as the application under test will allow it.

Functionize offers multiple avenues to address timing within a test case:

• Timeout Settings
• Smart Wait Actions
• Timing Model Overrides

Timeout Settings

Timeout Settings can be controlled at multiple levels, at the Team, Project and individual Test Settings. The maximum time the execution engine waits can be specified as the Missing Element Timeout setting at all three leves. By default, this is set to 15 seconds.

Team Settings (must have Team Admin permission)

Project Settings (must have Project Admin permission)

Test Settings

See User Guide: Test Settings

Smart Wait Actions

Functionize provides the capability to add Smart Wait Actions to a test case if a user needs granular control over how fast a test executes, in addition to the default Timeout Settings mentioned above. Functionize utilizes Smart Waits to optimize your test runs. These Smart Waits analyze the network traffic on a page and dynamically wait for the page to load, reducing the likelihood of tests failing due to loading issues.

Smart Wait Actions can be added in multiple ways to your test case, whether you are recording your test with Architect, using the Quick Add feature on the Test Details page, and/or using Slider View.

See User Guide: Wait Actions

Timing Model Overrides

Timing Model Overrides can be managed at both the Project and Test Setting levels.

Project Settings (must have Project Admin permissions)

Test Setting

This allows you to control how long the Functionize AI Timing Model waits for an element to appear. The more Aggressive the setting used, the faster the AI timing model executes, and the more Conservative the setting used, the slower the AI timing model executes. By default, the Timing Model setting at both the Project and Test levels is set to '5.'

For example, if your application sends a Toast notification message confirming the successful creation of an object (i.e., order number or ticket number) that may only appear for 1-2 seconds. If you need your test to verify and confirm that Toast message, you may have to adjust the Timing Model to be more aggressive— for example, to '3.'