Who ya gonna call? Auto-generate procedure calls for clean and maintainable tests

In this webinar, we’ll show you how QF-Test 11 can recognize matching procedures from your library while recording sequences and automatically insert the corresponding calls.

You can also use the same mechanism to clean up existing test cases automatically and replace individual nodes with structured procedure calls. The result is cleaner tests and consistent reuse.

Transcript

Daniel Rieth, QF-Test Software Developer
Ute Erler, QF-Test Software Developer and the person primarily responsible for the Procedure Recording feature

The Problem

When creating new tests, long sequences of mouse clicks, inputs, checks, and other QF-Test nodes are often created. At the same time, carefully designed procedures often already exist that take edge cases into account, ensure reliable test execution, and improve maintainability.

In a distributed team, however, there is no guarantee that test authors know about and use these existing procedures. Without support, this therefore results in test cases that reproduce the same logic again as individual nodes.

Procedure Call Recording solves this problem by automatically converting sequences of nodes into calls to existing procedures. This can be done both during recording and afterward through a conversion.

The key advantage is that the existing procedures are actually used. As a result, changes to the underlying functionality only need to be made in the procedure rather than in every individual test.

How It Works

The feature essentially consists of three components:

Procedure Call Definition

The Procedure Call Definition describes the characteristic actions of a procedure. It specifies which sequence of nodes should be recognized as a call to that procedure.

The definition is described using YAML notation and can be configured in detail. This makes it possible to specify which nodes are expected, the order in which they must occur, which of them are optional, and under what conditions a node is considered a match.

Conversion Function

The Conversion Function compares recorded or already existing sequences of nodes with the Procedure Call Definitions.

When a matching definition is found, QF-Test replaces the corresponding individual nodes with a call to the defined procedure. For example, a sequence of mouse clicks and inputs becomes a single procedure call with the corresponding parameters.

Recording Log

The Recording Log is particularly useful when creating and debugging Procedure Call Definitions. It shows which expected nodes were recognized and at which point a definition no longer matches the actual recording.

This makes it possible to understand why a definition did not match and what adjustment is required.

Automatically Recognizing Simple Procedures

As an initial demonstration, an application for calculating property tax is used. It already contains procedures for opening and canceling the dialog for creating a business.

A normal recording would only contain the corresponding mouse clicks. However, using More Node Operations → Record Nodes Again as Procedure Calls, these nodes can subsequently be converted into calls to the existing procedures.

The corresponding Procedure Call Definitions can be generated directly from the existing procedures. For short and unambiguous procedures, this automatic generation often works without any further adjustments.

The demonstration also shows that procedure calls can already be created during recording. To do this, Procedure Call Recording is enabled. The recorded actions are then immediately checked against the existing Procedure Call Definitions.

Procedure Call Definitions and the Recording Log

An automatically generated definition describes, among other things:

• the associated procedure,
• its priority,
• the expected order of the nodes,
• the expected components and events,
• optional nodes, and
• procedure parameters, where applicable.

A simple definition can, for example, expect a mouse click on a specific button.

More complex procedures can also be described. For example, if a button for discarding changes is optionally displayed after clicking a Cancel button, this second step can be defined as optional.

The Recording Log makes it visible how this definition is processed: first, the expected Cancel button must be found; afterward, the optional click on the button for discarding the changes can follow.

More Complex Definitions with Conditions and Placeholders

Not every automatically generated definition is immediately robust enough. A procedure for changing the language serves as an example.

The UI contains two possible toggle buttons, one for German and one for English. The automatic generation initially recognizes these as possible alternatives and represents them as a Choice Group.

The demo shows, however, that the components actually used do not exactly match the automatically generated definitions. One reason is that the component’s ID changes depending on the current state.

The definition can therefore be refined. Instead of using only the ID, for example, the Class of the component can be used. This allows the definition to initially recognize a Toggle Button in a more general way.

For an even more precise distinction, Conditions can be used. A Condition can, for example, check whether the ID of a component begins with specific text.

Placeholders are used for this purpose. During recording, they provide concrete properties of the node currently being processed, such as the ID of a component. These values can be compared within a Condition or output as procedure parameters.

This allows a definition to distinguish, for example, whether the German or English Toggle Button was used and accordingly generate de or en as the procedure parameter.

Automatically Recording Procedure Parameters

Procedure Call Definitions can not only recognize that a procedure was used; they can also take over the parameters used during recording.

For this purpose, the Set Procedure Call Parameter node is used. Recorded values can thus be automatically extracted from text or selection actions and passed on as parameters of the procedure call.

This makes it possible, for example, to derive a language parameter from the component that was actually clicked.

The Different Groups

Expected nodes are organized into groups. Three groups are particularly relevant.

Sequential Group

A Sequential Group expects its nodes in a specific order.

For example, a definition can expect:

1. a mouse click,
2. a text input, and
3. a check afterward.

The order is relevant. Repetitions can be defined for individual nodes. A node can also be marked as optional.

An optional node essentially corresponds to a Repeat section that also permits zero occurrences.

Choice Group

A Choice Group describes several possible alternatives. It is expected that one of the contained nodes or branches will occur.

This is suitable, for example, for if/else behavior. In the language-changing procedure, either the German or the English Toggle Button can be selected.

Choice Groups can also contain repetitions and optional content.

Unsorted Group

An Unsorted Group is suitable for multiple nodes whose order does not matter.

A typical example is a form in which several text fields are filled in. For matching, it may be relevant that certain inputs occurred, while the order of those inputs should not be fixed.

For individual nodes within a Sequential Group, a Repeat can alternatively be used. An Unsorted Group is particularly useful when several different nodes should be recognized independently of their order.

Complex Procedure: “New Winery”

A more extensive demonstration uses the New Winery procedure. It performs several actions:

• entering data into various text fields,
• selecting a federal state,
• selecting a viticultural use,
• interacting with a table,
• entering a property-tax assessment rate,
• optionally opening the calculation scheme, and
• saving the new entry.

The automatically generated Procedure Call Definition does not initially work completely. The example shows how such a definition can be made more robust step by step.

Excluding Mouse Events from the Recording

A problem arises because a user may first click into a text field before entering text. However, the actual procedure does not require this mouse click.

Instead of adding an optional mouse click to the definition for every individual text field, an Ignore Definition can be used.

Since QF-Test 11.0.2, the following option can be used directly:

Ignore the following nodes for procedure call recording

This can be used, for example, to exclude Mouse Events on text fields from Procedure Call Recording. Specific clicks on a table can also be ignored in this way.

As a result, the definition is independent of whether the user initially clicks into a field or navigates there using the keyboard, for example.

Ignoring Keyboard Events

The same principle can be applied to keyboard events. During manual input, for example, Tab, Enter, Backspace, or other keys may occur between the actual relevant actions.

Such events can be excluded using an Ignore Definition. A Condition can check the <Keycode> of the event and ignore specific keycodes.

This keeps the Procedure Call Definition focused on the actions that are relevant from a functional perspective, rather than making it dependent on the specific interactions of the test author.

Combining Multiple Text Inputs

A single logical text input can also consist of multiple Text Input Events during recording. This can happen, for example, when a user enters part of a text, deletes it, and then corrects it.

One option is to define a Repeat for the corresponding node. If several different nodes can occur independently of one another, an Unsorted Group is more suitable.

When generating procedure parameters, multiple consecutive inputs can also be combined. If, for example, the values are concatenated without a separator, multiple recorded Text Inputs can once again produce the original parameter value.

Describing Nodes in Detail

The expected nodes can be described more precisely using numerous properties.

For a mouse click, for example, properties of the event can be taken into account. Components can be identified using, among other things, the following characteristics:

• ID,
• Class,
• other component attributes, and
• Conditions.

Key Events can also be described using their keycode.

In addition, repetitions, optional nodes, and procedure parameters can be specified for individual definition elements.

The YAML definition can be edited directly. The corresponding editing function helps ensure that the required structure and indentation are maintained correctly.

Using the Recording Log for Debugging

The Recording Log is not only relevant for actual recordings. It can also be used when subsequently converting existing sequences of nodes.

If a Procedure Call Definition does not match, the log can be used to trace step by step which expected node was not recognized.

The basic approach is to follow the definition in the log until reaching the point where the actual recording deviates from the expected structure. The definition can then be adjusted, for example, by using a different component description, a Condition, a Repeat, or an optional node.

Automatic Procedure Parameters for Complex Recordings

Parameters can also be automatically taken from the recording for longer procedures.

In the New Winery example, the business name, ownership area, and assessment rate, among other values, are taken from the corresponding inputs. Procedure Call Recording automatically creates these as parameters of the subsequent procedure call.

This means that the test author does not have to manually enter the parameters into the generated procedure call afterward.

Outlook

The Procedure Call feature is intended to be expanded further. Two planned or currently developing integrations are particularly highlighted.

Integration with Keyword Driven Testing

Procedure Call Recording is intended to be integrated with Keyword Driven Testing.

This will allow procedure calls to be displayed in a form that is easier for business departments to understand. Instead of displaying merely a procedure path with parameters, the test can, for example, be represented as freely formulated text or as a keyword-based action.

The feature is particularly interesting for users who want to formulate tests more strongly at the business level. A beta version is already being used by customers.

Integration with AI

QF-Test’s AI functions are also intended to be connected with Procedure Call Recording.

QF-Test can already generate tests using AI and use an AI Instruction Node to execute actions with the UI. The goal is for such automatically generated actions to be mapped directly to existing procedures.

This is intended to apply both to AI-generated test sets and to the recording of actions executed within an AI Instruction Node.

Conclusion

Well-designed and robust Procedure Call Definitions help ensure that existing procedures are actually used in tests.

Procedure Call Recording can be used both during recording and subsequently during conversion.

Procedure Call Definitions can be generated automatically from existing procedures and then refined as needed. For more complex cases, the following mechanisms are available, among others:

• Sequential Groups,
• Choice Groups,
• Unsorted Groups,
• Conditions,
• Placeholders,
• optional nodes,
• Repeat sections,
• Ignore Definitions, and
• automatic procedure parameters.

For more complex procedures, a certain amount of familiarity with the definition language is required. However, the available mechanisms make it possible to specify very precisely which recordings should be recognized as calls to a particular procedure.