#Custom Fields Best Practices & Use Cases

#Best Practices

When managing custom fields:

1. Clear Naming: Use descriptive names that indicate the field’s purpose
2. Consistent Types: Use appropriate field types for the data you’re capturing
3. Default Values: Set default values for commonly used fields to speed up data entry
4. Required Fields: Mark fields as required only when necessary
5. Project Scope: Use “Selected Projects” for project-specific fields to avoid clutter
6. View Selection: Only add fields to views where they’re actually needed
7. Dropdown Options: Use dropdowns for standardized values (e.g., severity levels, environments)
8. Documentation: Add descriptions to help users understand field purpose
9. Regular Review: Periodically review fields to remove unused ones
10. Naming Conventions: Establish naming conventions for consistency across fields

#Use Cases

#Component Tracking

• Create a “Component” dropdown field for test cases
• Add options: “Frontend”, “Backend”, “API”, “Database”
• Assign to Testcase and Defect views
• Helps track which component is being tested

#Environment Specification

• Create an “Environment” dropdown field
• Add options: “Development”, “Staging”, “Production”
• Assign to Testcase and Test Run views
• Ensures tests are run in the correct environment

#Priority Scoring

• Create a “Priority Score” number field
• Set default value to 5
• Mark as required
• Assign to Testcase view
• Enables numeric priority ranking

#Automation Status

• Create an “Is Automated” checkbox field
• Set default to “Unchecked”
• Assign to Testcase view
• Tracks which test cases are automated

#Release Association

• Create a “Target Release” text box field
• Assign to Requirement and Testcase views
• Links test cases and requirements to releases

#Next Steps

• Learn about Parameters to manage workspace-level variables
• Explore Shared Steps to create reusable test steps
• Read about Project Management to understand project-level custom fields