Website QA intelligence for teams who ship
Guides Tool Comparisons QA Glossary Archive RSS Feed
HomeGlossaryFeature Flag

Feature Flag

A feature flag is a conditional configuration mechanism that allows teams to enable or disable specific website functionality in production environments without code deployment. It acts as a runtime switch that controls which features are visible to different user segments, enabling controlled rollouts, instant rollbacks, and testing variations. Feature flags separate the act of deploying code from releasing features to end users.

Feature flags work by wrapping new functionality in conditional statements that check flag values stored in external configuration systems or databases. When code executes, it queries the flag service to determine whether to show the new feature or fall back to existing behavior. Flags can target users based on criteria like geographic location, user ID, device type, or random percentage splits. Advanced implementations support gradual rollouts where a feature starts at 1% of traffic and scales up over time. The flag state can be modified instantly through management dashboards without touching application code.

For website QA teams, feature flags create both opportunities and challenges. They enable testing in production with real user data while limiting blast radius if issues emerge. QA teams can validate features with internal users before public release, and instantly disable problematic functionality without emergency deployments. However, flags multiply the number of application states that require testing. A website with five active flags has 32 possible combinations of enabled and disabled features. QA teams must develop strategies for testing critical flag combinations and ensure proper functionality across different user segments receiving different experiences.

Common mistakes include leaving expired flags in code indefinitely, creating technical debt and increasing complexity. Teams often underestimate the testing burden of multiple flag states, leading to untested combinations reaching production. Another pitfall is using flags for long-term configuration rather than temporary feature releases, which violates their intended purpose. Some teams fail to establish clear ownership of flag lifecycle management, resulting in abandoned flags that clutter the codebase. Inadequate monitoring of flag performance can also mask issues affecting specific user segments.

Feature flags fundamentally change website delivery workflows by enabling continuous deployment practices. They support trunk-based development where all developers merge to the main branch frequently, with flags controlling feature visibility rather than code branches. This approach reduces merge conflicts and enables faster feedback cycles. For user experience, flags enable personalization and gradual feature introduction that can improve adoption rates. They also support compliance requirements in regulated industries by allowing instant feature disabling when issues arise. However, they require disciplined flag hygiene practices and comprehensive testing strategies to prevent introducing inconsistent user experiences or creating maintenance overhead.

Why It Matters for QA Teams

Feature flags mean QA must test multiple states of the application: feature on, feature off, and the transition between them. An untested flag combination can cause bugs visible only to certain user segments.

Example

An e-commerce team at a major retailer is launching a new checkout flow that consolidates payment and shipping into a single page. Rather than replacing the existing two-step checkout for all users simultaneously, they implement a feature flag called 'single_page_checkout'. Initially, the flag is enabled only for internal employees and a control group of 2% of users in non-peak hours. The QA team tests both checkout experiences, ensuring order completion, payment processing, and analytics tracking work correctly for both flag states. They discover the new flow has higher conversion rates but causes issues with certain third-party payment providers. Using the flag dashboard, they immediately disable the feature for users with affected payment methods while keeping it active for others. Over two weeks, they gradually increase the flag percentage from 2% to 100% while monitoring conversion rates, error rates, and customer support tickets, ultimately replacing the old checkout flow entirely.