The test improves the process.
Tests show how a process really runs. If a test case deviates from the model, TAOM detects it – and asks: forgotten in the process, a variant or just a test path?
The answer creates a new model version. The process owner (GPO) approves it. Only then does it apply – and training and documentation are informed.
Test runs automatically produce new or optimised BPMN process models.
Click through: from the approved model via the changed test run to the adapted model – as a draft until the process owner approves.
From test run to a better model
Whoever tests finds gaps in the process. So far they end up in a log, in a meeting and at some point perhaps in the model. In TAOM they directly become a suggestion at the right step.
What TAOM notices by itself
Nobody has to report a deviation. The tester can additionally set “does not match the model” by hand.
| Trigger in the test | How TAOM detects it |
|---|---|
| E2E test case: station inserted | Station without a step or without a connection in the model’s path |
| E2E test case: order changed | Order of the stations differs from the path in the model |
| E2E test case: station removed | Mandatory step in the model without a station |
| Step deleted or moved in the model | The test case’s identifier points nowhere |
| Test run “passed with deviations” | Tester’s note at the station |
| Excel upload with new test cases | Rows without the identifier of a model step |
If the deviation lies in a linked model, TAOM suggests the location there – the draft is created in the affected model.
One question, three answers
Was the step forgotten in the process, does it only apply under a condition, or does it not belong to the process at all? Only someone who knows the process knows that. TAOM asks the question – and implements the answer.
Forgotten in the process
The step always belongs to it.
- New draft version with the step in the right place
- Name, role and system come from the test case
- Role matching the RACI matrix
Process variant
The step only applies under a condition.
- Selectable per case: a branch with a condition in the same model
- or a separate variant model with a reference
- Both as a draft version
Test path only
Test preparation or workaround, not part of the process.
- Model remains unchanged
- Test case is marked
- Traceable in reporting
Pure reviewers with the add-on licence may also decide – after all, only a draft is created. Only those who may approve according to field control may approve.
New version – and who approves it
Every model version has a status. The latest approved one always applies. Test runs, test evidence and the user manual state the version and its status.
Controlled via field control
The customer decides who may approve – with the roles from the project organisation.
- Field “Approve model version” – template: GPO and administrator
- Rule “Four eyes for model versions”: enforce (template) or only log – then with the note “approved without a second person”
- Without a GPO on the model, another role with approval rights approves; the model prompts you to name a GPO
Approval and rejection are recorded with the person’s identifier, time and comment in the history and in the provenance seal.
Excel: test cases there and back
Business departments often prefer writing test cases in Excel. That works – without losing the link to the process.
The test plan becomes a model
If there is no model for the test cases yet, it is created from the test plan – at the level in the enterprise process model that the user assigns.
With AI connection
Webuser, Webuser Pro, Enterprise with agent connection.
- The AI agent builds the model as usual
- With the EU AI label (AI origin)
- Draft – the GPO approves (Human in the Loop)
Without AI connection
For example Enterprise without agent connection.
- One shape per test step, one lane per role
- The editor connects the shapes in the order of the Excel rows
- The user adds branches, events and systems – then approval by the GPO
After approval, everyone is informed
A changed process often needs changed training and documentation. TAOM triggers that.
What a deviation costs today – a model calculation
Without a tool, a deviation is searched for, discussed, re-modelled, approved and passed on – by several people.
Model calculation, not a measurement. All times in this table are assumptions for a typical case. They show the possible benefit – not a measured improvement. You record the actual effort in TAOM as actual times in the project times; then the measured value stands next to the assumption.
| Activity per deviation | today (assumption) | with TAOM (assumption) | why |
|---|---|---|---|
| Extract the deviation from test logs | 0,5 h | 0 h | TAOM detects it itself |
| Agree: forgotten, variant or test path (3 people × 1 h) | 3,0 h | 1,0 h | Case is available with test case and model; two people are usually enough |
| Update the model | 1,0 h | 0,1 h | Draft is created from the test case |
| Obtain and document approval | 1,0 h | 0,1 h | Approval on the model, note automatic |
| Trigger training and documentation | 0,5 h | 0 h | Issue or card is created automatically |
| Per deviation | 6,0 h | 1,2 h | around 80 % less |
| 30 deviations in one test cycle | 180 h | 36 h | around 144 person-hours less |
Model calculation with assumptions, not a measurement. It depends on how cleanly the process was described beforehand.
Answered briefly
Does the tester have to report deviations?
No. TAOM compares the test case with the path in the model. Setting “does not match the model” by hand is also possible.
Does a tester change the model this way?
No. Only a draft is created. It only becomes valid with approval by the GPO or another role with approval rights.
What happens in case of a rejection?
The version gets the status rejected and remains visible in the history. This also applies to a model or variant that resulted from re-engineering. The test case remains open with “rejected – adapt test case”.
Can the creator approve themselves?
Not in the template (four-eyes principle). The administrator can set the rule “Four eyes for model versions” to “only log” – then “approved without a second person” appears in the history and provenance seal.
Which licence do I need?
Re-engineering is part of the Testing and verification add-on licence – see feature matrix.
Can I import test results via Excel?
No. Execution and result stay in TAOM so that screenshot, evidence and the four-eyes principle fit together.
Test and improve in one go.
Process re-engineering is part of the Testing and verification add-on licence – per reviewing person, own term, cancellable separately.