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: Hide Root Cause unless Priority is High
- Screen: Global Issue Create
- Target Field: Root Cause
- Scope: Bug
- Condition: Priority not equals High
- Action: Hide field

A Show field rule on its own wouldn't work here: the field is visible unless a rule hides it, so a field that should appear only for High priority is hidden with the opposite condition.

2. Test with Matching Context​

Verify rule applies when it should:

Test case: Create Bug with Priority = Low

  • Expected: Root Cause field disappears
  • Verify: Field is hidden
  • 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 = High → Root Cause stays visible
  • Create Story with Priority = Low → the rule doesn't hide Root Cause (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 values:

Common edge cases:

  • Empty values: Field has no value (null, undefined)
  • Nothing selected: An option field with no option picked. "Is empty" is met here, and so is "not equals" on a select list
  • Special characters: Field contains quotes, commas, special symbols
  • Letter case: Comparisons ignore case, so "Backend" and "backend" match the same condition
  • Multiple selections: Multi-select fields with various combinations
  • Long text: Fields with very long content
  • Saved value on Transition: An option field that isn't on the transition screen is read from the issue, so the condition sees the value from before the transition

Example edge cases:

Condition: Approvals Needed (checkboxes) contains Finance

Edge cases to test:
- Only Finance ticked (should trigger)
- Finance and Legal ticked (should trigger)
- Only Legal ticked (should NOT trigger)
- No box ticked (should NOT trigger; "is empty" would be met here)
- Finance ticked, then unticked (rule should stop applying)

Testing checklist:

  • Test with empty/null field values
  • Test "is empty" conditions with nothing selected in option fields
  • Test with special characters if field is text
  • Test with very long text if field is text
  • Test all combinations for multi-select fields
  • On Transition, test conditions on option fields that aren't on the screen: set the value on the issue first, then open the transition

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 hides a field in some cases, Rule B requires it in others
  • Conditional dependencies: Rule depends on field affected by another rule

Example interaction test:

Rule 1: Hide Root Cause when Priority not equals High AND Priority not equals Critical
Rule 2: Require Root Cause when Priority = Critical

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

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, nothing selected, 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:

  • Hide field rule: field disappears when the condition is met and comes back when it no longer is
  • Show field rule: brings back a field that another rule hides (on its own it changes nothing, because the field is already visible)
  • Hidden field retains value if user filled it (Create screen)
  • Rule doesn't apply to issue types outside its scope

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)
  • A value changed by hand stays when other fields change
  • When the rule's Smart Value source field or one of its condition fields changes, the field goes back to its value from before the rule, and the rule sets its value again if its conditions still match
  • On the Create screen, changing the issue type applies the rule's value again
  • 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 Formify
  • 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 empty fields, option fields with nothing selected, 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.