Skip to main content

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 field

2. 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:

Condition: Estimated Cost > 10000

Edge cases to test:
- Cost = 10000 (exactly at boundary - should NOT trigger)
- Cost = 10001 (just over boundary - should trigger)
- Cost = 9999 (just under boundary - should NOT trigger)
- Cost = empty (no value - should NOT trigger)
- Cost = 0 (zero - should NOT trigger)
- Cost = negative value (if possible - handle appropriately)

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:

Rule 1: Show Root Cause when Priority = High
Rule 2: Require Root Cause when Priority = Critical

Test cases:
- Priority = High → Root Cause shows, not required (Rule 1 only)
- Priority = Critical → Root Cause shows AND required (both rules)
- Priority = Low → Root Cause hidden (neither rule)

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:

  1. Disable rule in production
  2. Test modified rule in sandbox
  3. Verify no regressions
  4. Re-enable in production
  5. 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:

Rollback Plan​

If rule causes problems in production:

Immediate action:

  1. Disable problematic rule
  2. Verify issue is resolved
  3. Communicate to users (if needed)

Investigation:

  1. Review rule configuration
  2. Test in sandbox to reproduce issue
  3. Identify root cause
  4. Fix and re-test

Re-deployment:

  1. Test fix in sandbox
  2. Re-enable in production
  3. Monitor closely for 24 hours

Design:

Organization:

Configuration:

Troubleshooting:

Performance:

Thorough testing prevents bugs and builds confidence in your rule set. Invest time in testing upfront to avoid issues in production.