ReferenceIntermediate4-6 min reference
Feature Flags Testing
Feature flags decouple deploy from release — code ships dark and is switched on later. Great for delivery, hard for QA: every flag doubles the possible states, and the flag's value can differ per environment, user, or percentage rollout. This sheet is how to test them sanely; the flag-combination matrix utility is linked below.
Flag types
| Type | Purpose |
|---|---|
| Release toggle | Hide unfinished work; remove after launch |
| Ops / kill switch | Turn a feature off in an incident |
| Experiment (A/B) | Variant per user segment |
| Permission / entitlement | Per-plan or per-user access |
What to test
- Both paths: feature on and off (off is the one teams forget).
- The default value when the flag service is unreachable (fail safe?).
- Targeting: the right users/segments get the right variant.
- Toggle at runtime: flipping it doesn't corrupt an in-flight session.
- Cleanup: stale release flags removed; no dead code paths.
Taming the combinations
You can't test every flag permutation. Prioritise:
- Each flag on and off in isolation.
- Known interactions between flags that touch the same feature.
- The production-intended combination (what users will actually get).
Use the feature-flag test-matrix utility to enumerate the combinations that matter.
Common mistakes
- Testing only the flag on state, never off.
- Forgetting the default/fallback when the flag provider fails.
- Ignoring flag interactions on a shared feature.
- Leaving stale flags that quietly change behaviour later.
- Assuming the flag value is the same across environments.
// Related resources