Testing Rules
Testing rules before deploying to production prevents bugs and ensures field behavior works as expected. This guide provides a practical testing workflow and checklist.
Testing Workflow
Follow this five-step process for each rule:
1. Create Rule with Specific Conditions
Setup:
Create rule in test project or sandbox first
Use specific, testable conditions
Keep initial rule simple (add complexity after basic test passes)
Example:
Rule: Show Root Cause for High Priority Bugs
- Screen: Global Issue Create
- Target Field: Root Cause
- Scope: Bug
- Condition: Priority = High
- Action: Show field2. Test with Matching Context
Verify rule applies when it should:
Test case: Create Bug with Priority = High
✅ Expected: Root Cause field appears
✅ Verify: Field is visible
✅ Check: Action applied correctly
What to test:
Correct screen (Create/View/Transition)
Correct project
Correct issue type (scope)
Correct field value (condition)
Correct user role (if user-based condition)
Testing checklist:
☐ Open correct screen (Create issue dialog, Issue View, Transition)
☐ Select issue type matching scope
☐ Set field values to match conditions
☐ Verify action executes (field shows/hides/locks/sets value)
☐ Test as correct user role (if applicable)
3. Test with Non-Matching Context
Verify rule doesn't apply when it shouldn't:
Test cases:
Create Bug with Priority = Low → Root Cause should NOT appear
Create Story with Priority = High → Root Cause should NOT appear (wrong scope)
View existing Bug (wrong screen) → Rule doesn't apply
What to test:
Wrong issue type (outside scope)
Wrong field value (condition not met)
Wrong screen (rule configured for different screen)
Wrong user role (if user-based condition)
Testing checklist:
☐ Test with issue type outside scope
☐ Test with field values not matching condition
☐ Test on different screen (if rule is screen-specific)
☐ Verify rule does NOT apply
☐ Test as different user role (if applicable)
4. Test Edge Cases
Test unusual or boundary conditions:
Common edge cases:
Empty values: Field has no value (null, undefined)
Special characters: Field contains quotes, commas, special symbols
Boundary values: Numeric thresholds (exactly $10,000, not just over/under)
Multiple selections: Multi-select fields with various combinations
Long text: Fields with very long content
Example edge cases:
Testing checklist:
☐ Test with empty/null field values
☐ Test exact boundary values for numeric conditions
☐ Test with special characters if field is text
☐ Test with very long text if field is text
☐ Test all combinations for multi-select fields
5. Test Interactions
Test how rule interacts with other rules:
Scenarios to test:
Multiple rules on same field: Do they conflict or complement?
Sequential rules: Rule A shows field, Rule B requires it
Conditional dependencies: Rule depends on field affected by another rule
Example interaction test:
Testing checklist:
☐ Identify all rules affecting same field
☐ Test with only first rule enabled
☐ Test with both rules enabled
☐ Verify no conflicts (both rules work together)
☐ Check for "hidden required" trap (required field that can be hidden)
Testing Checklist Template
Use this checklist for each new rule:
Pre-deployment testing:
☐ Rule enabled in test/sandbox project
☐ Tested with matching conditions (rule applies)
☐ Tested with non-matching conditions (rule doesn't apply)
☐ Tested edge cases (empty, boundary, special values)
☐ Tested interactions with other rules
☐ Tested with different user roles (if user-based)
☐ Tested on correct screen (Create/View/Transition)
☐ Verified no console errors (check browser dev tools)
Post-deployment verification:
☐ Deployed to production
☐ Tested by actual users (not just admin)
☐ Monitored for support tickets or confusion
☐ Verified performance (no slowdown)
Testing by Rule Type
Show/Hide Field Rules
Test:
✅ Field appears when condition met
✅ Field disappears when condition changes
✅ Hidden field retains value if user filled it (Create screen)
✅ Field doesn't show for wrong issue types
Make Field Required Rules
Test:
✅ Red asterisk appears when condition met
✅ Form won't submit without filling field
✅ Field is visible (can't require hidden field)
✅ Validation works on correct screen (not supported on Issue View)
Lock Field Rules
Test:
✅ Field becomes read-only when condition met
✅ User cannot edit locked field
✅ Empty locked fields are hidden (Issue View behavior)
✅ Field unlocks when condition no longer met
Set Field Value Rules
Test:
✅ Field populates with correct value
✅ User can change pre-filled value (if not locked)
✅ Smart Values calculate correctly
✅ Value persists on form submission
Limit Field Options Rules
Test:
✅ Only specified options appear in dropdown
✅ Hidden options are not selectable
✅ Previously selected hidden option remains (if already set)
✅ Options revert when condition changes
Testing Tools
Browser Developer Tools
Check for errors:
Open browser console (F12)
Look for JavaScript errors
Check network tab for failed requests
Useful for:
Debugging why rule isn't applying
Seeing API errors from Dynamic Screen Rules
Verifying UI Modifications loaded
Test Projects and Sandboxes
Best practice: Test in non-production environment first
Options:
Create test project in production Jira
Use Jira sandbox (separate instance)
Test with test user accounts (different permissions)
Benefits:
Safe to experiment
Can test destructive changes
No impact on real work
Test User Accounts
Create test users with different permissions:
Regular user (no special permissions)
Project admin
User in specific groups (Finance, Managers, etc.)
External user (if applicable)
Test user-based rules:
Verify rules show/hide for correct groups
Confirm role-based conditions work
Check permission-based rules
Common Testing Mistakes
Not Testing as Real Users
Mistake: Only testing as admin Impact: Rules may not work for regular users due to permissions Solution: Test with different user roles and permissions
Testing Only Happy Path
Mistake: Only testing when rule should apply Impact: Rule may apply incorrectly in other contexts Solution: Test both matching and non-matching conditions
Ignoring Edge Cases
Mistake: Not testing boundary values, empty fields, special characters Impact: Rules fail in production with unusual data Solution: Test edge cases systematically
Not Testing Interactions
Mistake: Testing each rule in isolation Impact: Rules conflict when multiple are enabled Solution: Test with all related rules enabled
Deploying Untested Rules
Mistake: Creating rules directly in production Impact: Bugs affect real users immediately Solution: Always test in sandbox or test project first
When to Re-Test
Re-test rules when:
Modifying existing rule (changed conditions or actions)
Adding new rule affecting same field
Jira platform updates (major version changes)
Users report unexpected behavior
Integrating with new apps (potential conflicts)
Re-testing workflow:
Disable rule in production
Test modified rule in sandbox
Verify no regressions
Re-enable in production
Monitor for issues
Performance Testing
For large rule sets (50+ rules):
Test form load times:
Measure: Time from opening form to all modifications applied
Benchmark: Should be under 1 second
Monitor: Browser performance tab
Signs of performance issues:
Slow form loading (spinner icon for 2+ seconds)
Delayed field visibility changes
Browser becomes unresponsive
Solutions:
Simplify complex conditions
Reduce number of rules per screen
Rollback Plan
If rule causes problems in production:
Immediate action:
Disable problematic rule
Verify issue is resolved
Communicate to users (if needed)
Investigation:
Review rule configuration
Test in sandbox to reproduce issue
Identify root cause
Fix and re-test
Re-deployment:
Test fix in sandbox
Re-enable in production
Monitor closely for 24 hours
Related Pages
Design:
Designing Effective Rules - Create testable rules
Organization:
Organizing Rules - Structure rules for easier testing
Configuration:
Creating Your First Rule - Step-by-step creation
Troubleshooting:
Common Issues - Debug rule problems
Debugging Rules - Systematic debugging
Performance:
Performance Considerations - Optimize rule sets
Thorough testing prevents bugs and builds confidence in your rule set. Invest time in testing upfront to avoid issues in production.
Last updated