Overview
Bizagi delivers a Resource kit designed to test Bizagi processes automatically in development and testing environments.
This benefits Bizagi Studio users by reducing the time and resources employed when manually validating that all paths in the process workflow behave as expected.
Automatic testing is executed via a separate tool (referred to as Auto Testing tool), which will run previously recorded scenarios without user intervention, while validating that any changes in the process implementation do not affect a given path of the complete process workflow.
The image above illustrates how in a Credit request process, you could create a scenario for each of the three different paths: when the credit type is a personal loan, when it is a mortgage, and when it is a car loan.
And, launch automatic tests to verify that the routing logic behind this process is working properly.
|
The main purpose of the Auto Testing tool is to validate process flows (to check that all paths are properly designed and that the process definition meets the specification from start to end). As such, it should not be expected to test visibility, editability, required expressions, Actions & Validations, or any other aspect derived from the use of Bizagi forms (user interfaces).
This functionality is not shipped in with a Bizagi Studio installation, but provided as a separate tool (free of charge). To download the tool and further explore its resources, click Autotesting for Bizagi. |
HTTP and HTTPS support
Autotesting supports connecting to your processes set up on HTTP or HTTPS.
The following image illustrates how Autotesting works and connects to your processes (via the Work portal) when recording a scenario:
That is:
1.Autotesting deploys a local web service (at the IIS), hosting the recording service that saves a scenario.
2.Through the browser, you load up the Work portal having your processes (via HTTPS.
3.The browser handles those requests having their data and structure, end up recorded into a scenario file.
The following image illustrates how Autotesting works and connects to your processes (via the Work portal) when executing a previously recorded scenario.
That is:
Autotesting relies on the scenario files' requests and establishes communication (via HTTPS or HTTP) with the Work portal in order to execute the scenario.
The following video provides a brief explanation of how the Automatic Testing works:
Automatic testing
Scenarios
Automatic testing runs tests based on scenarios that are recorded once, while manually creating a case and considering a sequence of any number of activities in the Work Portal.
A scenario can include the execution of a process from beginning to end, or simply represent a portion of the complete process (i.e, starting from the beginning but ending any where in between).
These scenarios emulate the behavior of an end user in the Work Portal, sending any needed data previously recorded to Bizagi.
The Auto Testing tool allows you to:
▪Create new test scenarios.
▪Link a test scenario to an existing one.
▪Run test scenarios as many times as defined.
Considerations on how Auto Testing works
•Every time you execute a scenario, Bizagi will create a real case in the database.
When complete (and whether an error is found or not), Bizagi displays the Case ID so that it is easily found in the Bizagi Work Portal. For example, when an execution displays an error, you can log into your Work Portal (not via the Auto Testing tool), open the case and investigate the error.
•Scenarios must be deterministic.
That is, there should be no dynamic data received or input. Bizagi will validate that the scenario's data is exactly the same as the one entered when recording. If something changes the execution will fail. If your process has dynamic data (in dummies or generated codes, etc) you need to Update your scenario and add an Ignored Data Assertion.
•This tool is available for the Development and Testing environments (not for Production).
Otherwise, the Automatic testing tool will not be able to connect to the Bizagi Work portal because the browser itself will prevent un-assisted access to an un-trusted site by itself.
•Whether having the quick login option enabled in Bizagi, the Auto Testing tool will rely on this option when presenting access to the testing user.
Recall that the objective of these tests are not to validate user identity and secure access.
|
Recall that this tool's main purpose is to provide a quick aid for you to validate the routing and business logic behind your process implementation, in your development and test environment. This tool is not aimed at performing stress or concurrency testing.
When running scenarios in multiple threads, make sure you execute them ensuring you do not promote deadlocks by this tool. Consider important aspects such as: •That you don't run simultaneously a same scenario that modifies the same record. •That you consider different machines and different Bizagi users to run the scenarios for a more adequate use of the tool under simultaneous scenarios (that is, when deciding to use multiple threads). |
Supported shapes and restrictions
Consider the following notes about supported modeling shapes and other restrictions regarding Bizagi features.
Sub-Processes
When recording a scenario, navigate into Sub-Process by accessing it from the right panel of the parent case.
Similarly and to return to the parent case, access it from the Sub-Process's right panel. Do not perform this navigation from the Inbox.
Timer events
You may record scenarios where Timer events are involved. When recording, the tool displays the Timer event in the right panel. To continue recording simulating that the waiting time has ended click the Timer event and then Next.
When reproducing, the Auto Testing tool will ignore any waiting time and continue with the normal process flow.
Asynchronous Activities (Web Services, Connectors).
You may record scenarios Asynchronous Activities are involved.
If any of these options are present in the scenario, the Auto Testing tool will resolve it, ignoring asynchronous executions (the Asynchronous Activities will be ran synchronously).
Start forms
Start forms are supported.
Though, keep in mind that if you stop the scenario before completing the start form, any new case will be persisted (accordingly to the inherent definition of the start form feature).
When this happens, the case Id information will be shown as UNDEFINED.
Documents templates, attachments and Widgets
You may record scenarios with document templates, file attachments or Widgets.
Though consider that generating such documents templates, uploading attachments, or processing Widgets are not supported.
If any of these options are present in the scenario, the Auto Testing tool will just ignore them and continue.
This means that despite the lack of displaying an error, any document will be generated, files will not be persisted, nor Widgets will be processed.
Search control
Creation of new records from the Search control are not supported.
First task allocation
Processes in which the case creator user is not the same person allocated to the first task, are not supported.
You would need to temporarily redefine a workload assignment rule if you wish to run automatic testing on such processes.
Further information
•To learn how to install and configure this feature, refer to Configuring Auto Testing.
•To learn how to use this feature, refer to Using Auto Testing.
Last Updated 8/29/2024 3:25:01 PM