Action Types

Overview

Action Types are special nodes you can add to your Test Orchestration workflows that perform specific functions beyond standard test script execution. These actions help you control workflow logic, manage timing, send communications, and handle data operations.

---

Available Action Types

🔄 Control Flow Actions

Actions that control how your workflow executes:

Wait

Pause workflow execution for a specified duration.

• Add delays between steps

• Allow time for data synchronization

• Create realistic user think-time

Retry

Stop

📧 Communication Actions

Send notifications and communications:

Action	Purpose	Use When
Send Email	Email notifications to stakeholders	Reporting results or alerts
Slack	Send messages to Slack channels	Team notifications
Teams	Microsoft Teams notifications	Enterprise communication

📊 Data Actions

Handle and manage data:

Action	Purpose	Use When
Data Hub	Store and retrieve test data	Sharing data between workflows
Extract Data	Extract values from test results	Using output in next steps
Comment	Add documentation to workflows	Recording notes and context

---

Wait Action

Purpose

Pause workflow execution for a specified duration. Useful for:

• Allowing backend processing time

• Waiting for email delivery

• Database synchronization

• User think-time simulation

Configuration

Wait Action
├── Duration: 5 seconds / 2 minutes / 1 hour / Custom
├── Unit: Seconds / Minutes / Hours
└── Notes: Document why you're waiting

Examples

Wait for Email Delivery

Step 1: Send verification email via API
    ↓
Wait Action: 30 seconds
    ↓
Step 3: Check email inbox for message

Database Synchronization

Step 1: Create new user in system
    ↓
Wait Action: 2 minutes
    ↓
Step 3: Query database to verify user exists

Best Practices

• ✅ Use minimum necessary wait time

• ✅ Document why each wait is needed

• ✅ Consider using polling instead of fixed waits when possible

• ❌ Avoid excessive wait times that slow down workflows

• ❌ Don't use for error handling (use Retry instead)

---

Retry Action

Purpose

Automatically retry failed steps with exponential backoff. Handles:

• Transient network failures

• Temporary service unavailability

• Race conditions

• Flaky tests

Configuration

Retry Action
├── Max Attempts: 1-10 attempts
├── Initial Delay: Starting delay in seconds
├── Backoff Strategy: Linear / Exponential / Fixed
├── Max Delay: Maximum wait between retries
└── Retry On: Specific error types (optional)

Retry Strategies

Linear Backoff

Attempt 1: Fails immediately
Wait: 5 seconds
Attempt 2: Fails
Wait: 10 seconds
Attempt 3: Succeeds

Exponential Backoff

Attempt 1: Fails immediately
Wait: 2 seconds
Attempt 2: Fails
Wait: 4 seconds
Attempt 3: Fails
Wait: 8 seconds
Attempt 4: Succeeds

Fixed Delay

Every retry waits the same duration
Attempt 1: Fails
Wait: 5 seconds
Attempt 2: Fails
Wait: 5 seconds
Attempt 3: Succeeds

Examples

API Retry with Exponential Backoff

Retry Configuration:
- Max Attempts: 5
- Initial Delay: 2 seconds
- Backoff: Exponential
- Max Delay: 30 seconds

Database Query Retry

Retry Configuration:
- Max Attempts: 3
- Initial Delay: 1 second
- Backoff: Fixed
- Retry On: Timeout errors

Best Practices

• ✅ Use appropriate backoff strategy for your use case

• ✅ Set reasonable max attempts (3-5 usually sufficient)

• ✅ Consider total wait time (attempts × delays)

• ✅ Log retry attempts for debugging

• ❌ Don't use indefinite retries

• ❌ Avoid retrying permanent errors (404, 401)

---

Stop Action

Purpose

Conditionally terminate workflow execution. Use for:

• Stopping on critical failures

• Skipping remaining steps when not needed

• Validation gates

• Conditional workflow termination

Configuration

Stop Action
├── Condition: When to stop
├── Stop Type: Graceful / Abrupt
├── Message: Reason for stopping
└── Exit Status: Pass / Fail / Inconclusive

Conditional Stop

Stop based on:

• Previous step results

• Data values

• Environment variables

• Custom expressions

Examples

Stop on Missing Data

If: Required test data not found
Then: Stop workflow
Status: Fail
Message: "Cannot proceed without test data"

Conditional Progression

Step 1: Check feature flag
If: Feature is disabled
Then: Stop workflow
Status: Pass (marked as skipped)

Best Practices

• ✅ Use clear messages explaining why workflow stopped

• ✅ Document conditions that trigger stops

• ✅ Consider impact on reporting

• ❌ Don't use as error handling (use proper error handling instead)

• ❌ Avoid unexpected workflow terminations

---

Send Email Action

Purpose

Send email notifications from your workflows. Use for:

• Test completion reports

• Failure alerts

• Test result summaries

• Stakeholder notifications

Configuration

Send Email Action
├── Recipients: Email addresses
├── Subject: Email subject
├── Body: Email content (supports variables)
├── Attachments: Optional report files
└── Schedule: When to send (on success/failure/always)

Email Template Variables

Available variables in email:

{workflow_name}
{workflow_status}
{execution_time}
{start_time}
{end_time}
{total_tests}
{passed_tests}
{failed_tests}
{report_link}

Example Email Configuration

Recipients: [email protected], [email protected]
Subject: Test Results - {workflow_name}
Body:
  Workflow: {workflow_name}
  Status: {workflow_status}
  Duration: {execution_time}
  
  Summary:
  - Total Tests: {total_tests}
  - Passed: {passed_tests}
  - Failed: {failed_tests}
  
  View full report: {report_link}
  
Send On: Always

---

Slack / Teams Actions

Purpose

Send real-time notifications to Slack or Microsoft Teams. Use for:

• Immediate failure alerts

• Workflow completion notifications

• Team updates

• Status reports

Configuration

Slack/Teams Action
├── Channel: Select channel
├── Message: Notification content
├── Attachments: Include report summary
└── Trigger: When to send notification

Message Templates

Slack Example:
Channel: #qa-testing
Message: "🚀 {workflow_name} completed"
Include: Pass/fail summary

Teams Example:
Channel: QA Team
Message: "@QA Team - {workflow_name} failed"
Include: Error details and logs

---

Data Hub Action

Purpose

Centralized data management across workflows. Use for:

• Storing test results

• Sharing data between workflows

• Building data repositories

• Historical data tracking

Data Hub Operations

Operation	Purpose
Store	Save data for future use
Retrieve	Get previously stored data
Update	Modify stored data
Delete	Remove data entries
Query	Search stored data

Example: Data Hub Workflow

Workflow 1: Create Test User
  └── Data Hub: Store user credentials
      ├── Key: "test_user_001"
      └── Value: {username, password, email}

Workflow 2: Validate User (runs later)
  └── Data Hub: Retrieve user credentials
      ├── Key: "test_user_001"
      └── Use in login test

---

Comment Action

Purpose

Add documentation and notes to workflows. Use for:

• Explaining complex sections

• Recording assumptions

• Documenting known issues

• Adding team notes

Comment Format

Comment: "This wait is necessary because the 
database needs 30 seconds to sync after user creation.
See ticket JIRA-1234 for context."

Best Practices for Comments

• ✅ Explain "why" not "what"

• ✅ Reference related tickets/issues

• ✅ Document known limitations

• ✅ Add dates and authors when relevant

• ❌ Don't leave outdated comments

• ❌ Avoid over-commenting obvious steps

---

Combining Actions in Workflows

Example 1: Robust API Test

Step 1: Call API endpoint
    ↓
Retry Action (max 3 attempts, exponential backoff)
    ↓
If failed after retries:
  ├── Send Email: Notify team
  ├── Send Slack: Alert #devops
  └── Stop: Mark as failed

If successful:
  ├── Wait: 2 seconds for data sync
  ├── Step 2: Verify data in database
  └── Comment: "Database sync takes ~2 seconds"

Example 2: Complex Workflow

Workflow Start
  ├── Step 1: Check prerequisites
  │    └── Stop: If prerequisites missing
  ├── Step 2: Create test data
  │    └── Data Hub: Store for next workflow
  ├── Step 3: API call
  │    └── Retry: Max 5 attempts
  ├── Step 4: Wait for email
  │    └── Wait: 60 seconds
  ├── Step 5: Verify email received
  ├── Send Email: Test results
  └── Workflow End

---

Best Practices

✅ Do

• Use actions to make workflows more robust

• Document why each action is needed

• Test workflows with actions enabled

• Monitor action performance

• Use appropriate timeouts and retry counts

• Combine actions strategically

❌ Don't

• Overuse wait actions (impacts execution time)

• Use retry for permanent errors

• Create overly complex action chains

• Forget to test before scheduling

• Ignore notification failures

• Mix too many action types

---

Troubleshooting

Issue: Workflow hangs on Wait action

Solution:

• Check if wait duration is too long

• Verify system resources

• Review workflow logs

Issue: Retries not helping

Solution:

• Verify the error is transient

• Adjust backoff strategy

• Increase max attempts if needed

• Consider if error is permanent

Issue: Email/Slack not sending

Solution:

• Verify integration is configured

• Check recipient addresses

• Review permission settings

• Test notification settings

---

Related Topics

• Execution Flow

• Error Handling

• Notifications

• Conditional Execution

• Workflow Patterns

---

Next Steps

• Learn about Data Propagation

• Explore Workflow Patterns

• Create your first workflow