#Using Parameters in Test Cases - Examples

Parameters can be referenced in test cases, requirements, and shared steps using the parameter name wrapped in double curly braces: \{\{PARAMETER_NAME\}\}.

#Example Usage

If you have a parameter named BASE_URL with value https://api.example.com, you can reference it in:

• Test Case Steps: “Navigate to {{BASE_URL}}/login”
• Requirements: “The API endpoint {{BASE_URL}}/users should return user data”
• Shared Steps: “Call {{BASE_URL}}/api/health”

When the test case, requirement, or shared step is used, \{\{BASE_URL\}\} will be replaced with https://api.example.com.

#Parameter Resolution

• Parameters are resolved at runtime when test cases are executed
• If a parameter doesn’t exist, the reference remains as \{\{PARAMETER_NAME\}\}
• Project parameters override workspace parameters with the same name
• Parameters are case-sensitive

#Use Cases

#Environment Configuration

• Create BASE_URL parameter with different values for dev/staging/prod
• Reference \{\{BASE_URL\}\} in test cases
• Update the value once to change the environment for all tests

#User Credentials

• Create TEST_USER_EMAIL and TEST_USER_PASSWORD parameters
• Use secret parameters for passwords
• Reference them in test cases for login steps

#API Endpoints

• Create API_ENDPOINT parameter
• Use it across multiple test cases
• Change the endpoint URL in one place

#Configuration Values

• Create TIMEOUT parameter for test timeouts
• Create RETRY_COUNT parameter for retry logic
• Reference them in shared steps

#Dynamic Data

• Create parameters for data that changes frequently
• Update values without modifying test cases
• Maintain consistency across test artifacts

#Best Practices

When using parameters:

1. Naming Convention: Use UPPERCASE with underscores for consistency (e.g., BASE_URL, API_KEY)
2. Descriptive Names: Use names that clearly indicate the parameter’s purpose
3. Documentation: Add descriptions to explain parameter usage and values
4. Environment-Specific: Use parameters for environment-specific values (dev, staging, prod)
5. Centralized Values: Store commonly used values as parameters to avoid duplication
6. Project Scope: Use “Selected Projects” for project-specific parameters
7. Regular Review: Periodically review parameters to remove unused ones
8. Secret Parameters: Use secret parameters for sensitive data like passwords and API keys
9. Version Control: Document parameter changes and their impact
10. Testing: Test parameter references before deploying to production

#Next Steps

• Learn about Custom Fields to extend data capture
• Explore Shared Steps to create reusable test steps
• Read about Project Management to understand project-level parameters