Conroe ISD Knowledge Base

Page 7: Testing Processes (Test Process Function)

The Test Process function allows designers to simulate end-to-end execution of a process without affecting live production data or sending premature notifications to end users. Executing test runs is a critical step before publishing any new or modified form workflow.

🧪 What is the Test Process Function?

The Test Process feature opens a sandboxed execution session of your process diagram. It allows you to:

Capability

Submit test data through initiating forms.

Step through downstream User Tasks as assigned users.

Verify dynamic path routing across Gateways.

Inspect process Variable Values at each step of the workflow.

Confirm that Service Tasks (Email, Save to Repository, Webhook) execute as expected.

🚀 How to Run a Test Process

▶️ Step 1: Launch Test Mode

  1. In the Process Designer Diagram, click the Test button in the top menu bar.

image-20260910-200355.png
  1. If your process has multiple start events, select the specific Start Event or Initiating Form you wish to simulate.

  2. Click Start Test.

📝 Step 2: Complete the Initial Form

  1. A new browser tab will launch containing the initiating form.

  2. Input realistic test data into the fields to trigger your target process conditions.

  3. Verify that Field Rules and Lookup Rules fire correctly as you fill out the form.

  4. Click Submit.

Verification: Confirm the form submits successfully without validation errors and presents the expected submission confirmation page.

🔍 Step 3: Monitor Flow & Advance Tasks

  1. Go back to the Laserfiche Forms Website

  2. Click on the Monitor Button

  3. Select the process you just started (You should see a test next to the name)

  4. To advance an active User Task, click directly on the User Task link and fill out that task

  5. Complete the user task form (e.g., approve/reject) and submit.

  6. Continue working through the process to verify all pieces work

    1. Do not forget to test edge cases and input validation!

Indicator

Meaning

Green Highlighting / Checkmarks:

Represents completed activities and followed sequence paths.

Blue Highlighting / Active Icons:

Represents currently active tasks waiting for user action.

Verification: Confirm that the active highlight moves to the expected downstream step or gateway path based on the action button clicked.

⚙️ Step 4: Inspect Variables and Service Tasks

  1. Open the Variables side panel in the test monitor.

  2. Review the current values assigned to each variable (varVariableName) to confirm data is persisting accurately across process boundaries.

  3. Click on completed Service Tasks (e.g., Save to Repository or Email) to review execution logs, mapped parameters, and status codes.

💡 Key Test Scenarios to Validate

Ensure your test protocol covers all paths and edge cases prior to publishing:

Test Scenario

Action

Expected Result

Branching Logic

Run separate tests with values that trigger every outgoing branch of Exclusive (XOR) or Inclusive (OR) gateways.

Process routes down the correct conditional sequence flow each time.

Required Field Validation

Attempt to submit forms while leaving mandatory fields blank.

Submission is blocked, and clear error highlights appear on missing inputs.

Approval / Rejection Paths

Test all action buttons (Approve, Reject, Request Info).

The instance follows the specific path wired to each outcome button.

Sub-Process Execution

Step through tasks nested inside embedded sub-processes or call activities.

Data maps correctly into the sub-process and returns expected outputs upon completion.

💡 Best Practices for Process Testing

Practice

Notes

Use Process Test Rules:

If your workflow sends live emails or calls external APIs, configure Process Test Rules (from Page 4) to bypass live integrations during test mode.

Test with Multiple Roles:

If tasks are assigned to different groups/roles, test the view for each role to ensure users only see the fields and actions intended for them.

Clear Test Data:

Test instances are marked as test runs in reporting, but ensure test files saved to the repository during testing are cleaned up if necessary.