Meticulous builds browser tests from interactions with the application. It can replay scenarios on a new version and show the changes for review.

The official Meticulous guide to recording and checking sessions. Open the source

Scripts from the application

Meticulous uses browser sessions as source material for checks. The developer proposes to start with the internal environment, record actions and associate checks with the process of accepting changes. The service compares the app’s versions when re-starting and helps to see where the behavior has diverged. This is convenient for a long path across multiple screens, which is manually repeated at each edit.

The short entry must pass the state of interest. If the button appears only after loading the list, stopping on an empty screen will not give material to check further actions.

Edit Form Change

In the training application, the employee opens the card, changes the name and returns to the list. Write down this path with a test record. After changing the form, check at what step the new result appeared. If the indentation has increased, this may be an expected design revision. If the list has stopped showing an updated name, analyze the response and the state of the interface after saving.

Separately repeat the path with the field check error. Recording a successful session by itself does not show what the user will see with an unacceptable value.

What to write in the first stage

To begin with, an internal version with synthetic data is suitable. Determine what queries and data get into the record before expanding the scope of surveillance. Compare the result with the expected user action. The difference between the versions shows the site to be checked, and the decision on the admissibility of the change is left to the command.

Suitable tasks

Repeat the user path after changing the interface
Disassess version differences by script steps

Features

Strengths

Uses recorded browser actions to prepare checks
Document recording installation on the internal environment

Things to consider

Limitations

Verification depends on written and prepared scenarios
To record, use the allowed test environment and check the data composition

Selection and conditions

Free access: Not confirmed
Trial period: Not confirmed
No sign-up required: Not confirmed
Russian interface: Not confirmed
Local installation: Not confirmed
API: Not confirmed

“Not confirmed” means there is not enough information. The feature may still be available; check the developer’s terms.

Input formats: Code, Text
Result: Text

Terms

Check the current connection conditions with Meticulous. The public instruction describes the setting, and the scope of use is agreed separately. To record, use the allowed test environment and check the data composition

From task to first result

Practical example

Task: Repeat the user path after changing the interface
What to prepare: Training interface for card editing, test account and two versions of the application.

Task brief or prompt

Write down the card opening, saving a new name and returning to the list. Repeat the session on the new version and open the step where the result changes.

Expected result

Comparison of browser script before and after the update.

How to check the result

Divide the expected design change and loss of the preservation result.
Check the path with the field error separately.

An editorial teaching example of a task brief, not the result of hands-on testing of the service. Check that the required mode is available, that you have rights to the source material and that the intended use of the result is permitted.

Check details

Official sources

This description is based on the developer’s material. Features, prices and availability may change; check the primary source before use.