Environments

Overview

Environments in Test Orchestration allow you to configure different runtime settings for your workflows. An environment defines where and how your tests execute, including URLs, credentials, configurations, and other environment-specific parameters.

🌐 Multiple Deployment Targets

Think of environments as different deployment targets—development, staging, production, QA—each with their own settings. The same workflow runs differently in each environment.

---

What Are Environments?

An Environment is a collection of configuration settings that define:

• Target System - URLs, endpoints, servers to test against

• Credentials - Usernames, passwords, API keys for that environment

• Variables - Environment-specific values and parameters

• Capabilities - Devices, browsers, browsers available

• Performance Thresholds - Expected response times, SLAs

• Data Sources - Test data locations specific to environment

Environment Lifecycle

Development
    ↓ (after testing)
Staging
    ↓ (after validation)
Production

Each environment has its own configuration

---

Built-In Environments

Test Orchestration comes with standard environments:

Development Environment

Purpose: Local development and quick testing
Characteristics:
• Usually runs on localhost or internal servers
• Uses test/mock data
• Immediate feedback on changes
• No external dependencies
• Fast execution

Typical Configuration:

Base URL: http://localhost:3000
API Endpoint: http://localhost:8080/api
Database: Local test DB
User: dev_user

Staging Environment

Purpose: Pre-production testing
Characteristics:
• Mirrors production as closely as possible
• Uses staging-only data
• Full integration testing
• Performance testing
• Security testing

Typical Configuration:

Base URL: https://staging.company.com
API Endpoint: https://staging-api.company.com
Database: Staging DB (production-like)
User: test_user

Production Environment

Purpose: Live system validation
Characteristics:
• Uses actual production systems
• Limited testing (read-only typically)
• Smoke tests only
• Critical path validation
• High caution required

Typical Configuration:

Base URL: https://app.company.com
API Endpoint: https://api.company.com
Database: Production DB (read-only)
User: monitoring_user

Testing/QA Environment

Purpose: Comprehensive testing
Characteristics:
• Isolated test environment
• Full data manipulation allowed
• Complete test coverage
• Performance baselines

Typical Configuration:

Base URL: https://qa.company.com
API Endpoint: https://qa-api.company.com
Database: QA DB (full access)
User: qa_user

---

Creating Custom Environments

Step-by-Step

1. Navigate to Environments

   • Open your project

   • Click Settings → Environments

   • Or from Project Settings → Environments

2. Create New Environment

   • Click + Add Environment or New Environment

   • Enter environment name (e.g., "UAT", "Integration Test")

3. Configure Properties

   • Environment Name - Descriptive identifier

   • Description - Purpose and notes

   • Environment Type - Development, Testing, Staging, Production

   • Status - Active, Inactive, Archived

   • Visibility - Who can use this environment

4. Set Base Configuration

   • Base URL - Primary application URL

   • API Endpoint - API server endpoint

   • Timeout Settings - Default timeouts

   • SSL/TLS Settings - Certificate handling

5. Add Environment Variables

   • Define variables for this environment

   • Examples: API keys, credentials, server addresses

   • See Variables section below

6. Configure Capabilities

   • Available browsers, devices, platforms

   • Resource allocation

   • Execution preferences

7. Save Environment

   • Review configuration

   • Click Create or Save

   • Environment is now available for workflows

---

Environment Variables

What Are Environment Variables?

Environment variables are configuration values specific to an environment. They're like project variables but with environment-specific values.

Variable Types

Type	Example	Usage
String	staging.api.com	URLs, endpoints, names
Number	30	Timeouts, counts, thresholds
Boolean	true	Feature flags, toggles
Secret	api_key_xyz	Passwords, tokens, keys
Array	["admin", "user"]	Lists of values
Object	{host: "localhost", port: 5432}	Complex configuration

Creating Environment Variables

1. Open Environment

   • Select the environment to configure

   • Click Edit or Variables

2. Add Variable

   • Click + Add Variable

   • Configure:

     • Variable Name - CAPS_SEPARATED (e.g., API_BASE_URL)

     • Type - String, Number, Boolean, Secret, Array, Object

     • Value - The actual value for this environment

     • Description - What this variable is for

     • Required - If it must be provided

3. Example Variables

Development Environment:
├── API_BASE_URL = "http://localhost:8080"
├── DB_HOST = "localhost"
├── DB_NAME = "test_db"
├── API_KEY = "dev_key_12345"
├── DEBUG_MODE = true
└── TIMEOUT = 15

Staging Environment:
├── API_BASE_URL = "https://staging-api.company.com"
├── DB_HOST = "staging-db.internal"
├── DB_NAME = "staging_db"
├── API_KEY = "staging_key_67890"
├── DEBUG_MODE = false
└── TIMEOUT = 30

Production Environment:
├── API_BASE_URL = "https://api.company.com"
├── DB_HOST = "prod-db.internal"
├── DB_NAME = "prod_db"
├── API_KEY = "prod_key_secure"
├── DEBUG_MODE = false
└── TIMEOUT = 60

Using Environment Variables

In workflows and nodes, reference environment variables:

${ENV.API_BASE_URL}
${ENV.API_KEY}
${ENV.DB_HOST}
${ENV.DEBUG_MODE}

Example Node Configuration:

API Test Node:
├── Endpoint: ${ENV.API_BASE_URL}/api/users
├── Headers:
│   ├── Authorization: Bearer ${ENV.API_KEY}
│   └── Content-Type: application/json
└── Timeout: ${ENV.TIMEOUT} seconds

Secret Variables

For sensitive data (passwords, API keys), use Secret type:

1. Create variable with type Secret

2. Enter value (encrypted when saved)

3. Value never displayed in logs

4. Can only be viewed by admins

5. Rotated by security team

🔐 Security Best Practices for Secrets

• Never hardcode secrets in workflows

• Always use Secret type variables

• Rotate secrets regularly

• Use vault integration if available

• Audit secret access

• Never share secrets in logs or screenshots

---

Switching Environments

Running Workflow in Different Environment

Method 1: Direct Execution

1. Open Workflow

   • Navigate to the workflow

2. Click Run

   • Click Execute or Run Now

3. Select Environment

   • Choose from available environments

   • Default environment is pre-selected

4. Execute

   • Workflow runs with that environment's settings

Method 2: Scheduled Execution

1. Schedule Workflow

   • Click Schedule on workflow

2. Select Environment

   • Choose environment for this schedule

3. Save Schedule

   • Scheduled runs use this environment

Method 3: Workflow Default

Set a default environment for a workflow:

1. Open workflow

2. Click Settings

3. Find Default Environment

4. Select environment

5. Save

All executions use this environment unless overridden.

Environment-Specific Configuration

Configure different behavior per environment:

Development:
  - Run all tests
  - Detailed logging
  - Performance assertions lenient

Staging:
  - Run all tests
  - Standard logging
  - Moderate performance assertions

Production:
  - Run smoke tests only
  - Minimal logging
  - Strict performance assertions

Implementation:

1. Create If-Then nodes checking environment

2. Branch to environment-specific test paths

3. Use conditional execution

If ${ENV.ENVIRONMENT_TYPE} = "production"
  → Run smoke tests (Node A)
Else
  → Run full test suite (Node B)

---

Environment Management

Viewing Environments

1. Open project

2. Click Settings → Environments

3. See list of all environments:

   • Environment name

   • Type (Dev, Test, Staging, Prod)

   • Status (Active, Inactive)

   • Variable count

   • Last modified date

Editing Environment

1. Select environment

2. Click Edit

3. Modify:

   • Configuration values

   • Variables

   • Capabilities

   • Permissions

4. Click Save

Duplicating Environment

Create a new environment based on existing:

1. Select environment

2. Click Options → Duplicate

3. Provide new name

4. Modify as needed

5. Save

Useful for creating similar environments with slight variations.

Archiving Environment

Remove from active use without deletion:

1. Select environment

2. Click Archive

3. Environment hidden from active list

4. Can be restored later

Deleting Environment

Permanently remove environment:

1. Select environment

2. Click Delete

3. Confirm deletion

4. Cannot be restored

⚠️ Deletion Restrictions

Can only delete if no workflows depend on it. Archive instead if unsure.

---

Multi-Environment Testing

Test the Same Workflow Across Environments

Run identical workflow against multiple environments:

1. Create Workflow

   • Design workflow once

2. Execute in Multiple Environments

   • Dev execution

   • Staging execution

   • Production execution

3. Compare Results

   • Same test, different environment

   • Validate consistency

Environment Promotion

Promote workflows through environments:

Create/Test in Dev
    ↓ (approved)
Promote to Staging
    ↓ (validated)
Promote to Production

Process:

1. Develop workflow in development environment

2. Test thoroughly

3. Execute in staging environment

4. Validate results match expectations

5. Execute in production environment

6. Monitor for issues

---

Environment-Specific Test Data

Test Data Management

Different test data for different environments:

Development:
  - User: [email protected]
  - Account: DEV-12345
  - Data: Full mock data set

Staging:
  - User: [email protected]
  - Account: STAGING-67890
  - Data: Production-like data subset

Production:
  - User: [email protected]
  - Account: PROD-READ-ONLY
  - Data: Live data (read-only)

Data Isolation

Ensure test data doesn't interfere:

1. Use Environment-Specific Users

   • Each environment has unique test users

   • Prevents cross-environment data pollution

2. Prefix Test Data

   • Mark test data with environment: "DEV_User_123"

   • Easily identifies test vs production data

3. Data Cleanup

   • Automated cleanup after tests

   • Prevents data accumulation

   • Keeps environments clean

---

Performance Baselines by Environment

Setting Performance Expectations

Define expected performance for each environment:

Development Environment:
├── API Response: < 500ms
├── Page Load: < 2 seconds
├── Database Query: < 100ms

Staging Environment:
├── API Response: < 200ms
├── Page Load: < 1.5 seconds
├── Database Query: < 50ms

Production Environment:
├── API Response: < 100ms
├── Page Load: < 1 second
├── Database Query: < 25ms

Performance Assertions

Configure performance checks per environment:

1. Open workflow

2. Select API test node

3. Click Assertions

4. Add assertion: "Response time < ${ENV.API_RESPONSE_THRESHOLD}"

5. Threshold automatically adjusts per environment

---

Environment Best Practices

Organization

1. Use Standard Names

   • Development, Staging, Production

   • Everyone knows what they mean

2. Clear Descriptions

   • Document environment purpose

   • Note any special characteristics

3. Consistent Structure

   • Same variable names across environments

   • Different values per environment

Security

1. Secure Credentials

   • Use Secret type variables

   • Store in secure vault if possible

   • Rotate regularly

2. Access Control

   • Limit production environment access

   • Require approvals for prod execution

   • Audit all prod changes

3. Data Protection

   • Never use real customer data in test environments

   • Mask sensitive data in logs

   • Comply with data protection regulations

Maintenance

1. Keep Environments Updated

   • Update URLs when servers change

   • Refresh credentials periodically

   • Update variable values as needed

2. Version Control

   • Track environment configuration changes

   • Document why changes were made

   • Maintain audit trail

3. Documentation

   • Document special environment requirements

   • List dependencies

   • Note manual setup steps if any

---

Environment Troubleshooting

Common Issues

Issue	Cause	Solution
Tests fail in staging but pass in dev	Environment difference	Check environment variables
Cannot access production environment	Permission issue	Request access from admin
API key invalid	Expired or wrong value	Update API key variable
Tests timeout in one environment	Different performance	Adjust timeout per environment

Debugging Environment Issues

1. Verify Variables

   • Check variable values match expectations

   • Ensure variables are defined

2. Test Connectivity

   • Verify URLs are accessible

   • Check network/firewall rules

3. Check Credentials

   • Ensure API keys are valid

   • Verify user permissions

4. Review Logs

   • Check execution logs

   • Look for error messages

   • Trace data flow

---

Summary

• Environments define configuration for different deployment targets

• Environment variables store configuration values specific to each environment

• Same workflow can run against multiple environments

• Secret variables protect sensitive data

• Best practices ensure security and maintainability

---

Related Topics

• Projects - Projects contain environment configurations

• Workflows - Workflows execute within environments

• Run Configuration - Configure execution parameters

• Session Persistence - Maintain state in environments

• Scheduler - Schedule runs across environments

Next: Explore advanced workflows in the Advanced Topics section.