View all services
Talk to QA Advisor
Browse the Knowledge Hub74 resources
/Test Cases/Feature flag and rollout test cases

Test cases

Feature flag test cases, for when the flag service does not answer

Twenty eight cases covering unreachable flag services and last known good configuration, bucketing that must stay stable per user and across devices, rollouts that grow without reshuffling, kill switch propagation, server and client evaluation mismatch, interacting flags, client side overrides and stale flag cleanup.

28cases/8coverage types/5security cases/FreeCSV download

All 28 test cases, ready to copy

Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.

Last updated

28 worked examples

FF-01

Enable and disable a flag end to end

TypeFunctionalPriorityHigh
Test data
A flag toggled on, then off, with the feature exercised in both states
Expected result
Feature appears and disappears within the stated propagation window, and both states are fully functional rather than the off state being untested.
FF-02

Fall back safely when the flag service is unreachable

TypeNegativePriorityHigh
Test data
Make the flag service time out at application start and mid session
Expected result
Documented defaults apply and the application works. A flag system that fails closed makes itself a single point of failure for every feature it gates.
FF-03

Serve the last known good configuration during an outage

TypeStatePriorityHigh
Test data
Take the flag service offline after a successful fetch
Expected result
Cached values continue to apply rather than reverting to bundled defaults, so an outage does not silently disable a feature that was live.
FF-04

Keep a user in the same bucket across requests

TypeBoundaryPriorityHigh
Test data
One user loading a 50 per cent rolled out feature twenty times
Expected result
Same variant every time. Bucketing on a stable identifier rather than randomly is what stops the feature flickering on and off between page loads.
FF-05

Keep bucketing stable across devices and sessions

TypeStatePriorityHigh
Test data
The same signed in account on two devices, and before and after signing in
Expected result
Consistent variant once identified, and the transition from anonymous to signed in is handled by a documented rule rather than reassigning mid journey.
FF-06

Distribute a percentage rollout accurately

TypeBoundaryPriorityHigh
Test data
A 10 per cent rollout evaluated across a large set of identifiers
Expected result
Approximately 10 per cent receive it within a stated tolerance, and the distribution is not skewed by sequential identifiers hashing unevenly.
FF-07

Grow a rollout without reshuffling existing users

TypeBoundaryPriorityHigh
Test data
Increase a rollout from 10 to 25 per cent
Expected result
Everyone already in the group stays in it and new users are added. A recalculation that removes the feature from existing users looks like a regression to them.
FF-08

Apply targeting rules in a documented order

TypeFunctionalPriorityHigh
Test data
A user matching an allow list, a percentage rule and an exclusion simultaneously
Expected result
Precedence is documented and applied consistently, and the interface can show which rule decided the outcome for a given user.
FF-09

Evaluate a flag for an anonymous visitor

TypeBoundaryPriorityHigh
Test data
A flag evaluated with no user identity available
Expected result
A documented default applies and evaluation does not throw, since a flag written assuming a signed in user will break every public page.
FF-10

Kill a feature quickly

TypeStatePriorityHigh
Test data
Disable a live flag and measure the time until every client stops serving it
Expected result
Propagates within the stated window. A kill switch that takes twenty minutes is not a kill switch during an incident.
FF-11

Keep server and client evaluation consistent

TypeBoundaryPriorityHigh
Test data
A flag evaluated during server rendering and again in the browser
Expected result
Same result. A mismatch produces a hydration error or a visible flash of the wrong variant on every page load.
FF-12

Avoid a flash of the wrong variant

TypeFunctionalPriorityHigh
Test data
A page load where flag values are fetched asynchronously
Expected result
The user never sees the control variant briefly replaced by the test variant, since that flicker invalidates the experiment and looks broken.
FF-13

Handle interacting flags

TypeBoundaryPriorityHigh
Test data
Two related flags in all four on and off combinations
Expected result
Every combination is functional, including the one nobody intended to ship, since flags are rarely disabled in the order they were enabled.
FF-14

Keep the disabled path working as the flag ages

TypeStatePriorityHigh
Test data
A long lived flag turned back off after months in the on state
Expected result
Old path still works. Code behind a flag that has been on for months is untested code, and turning it off during an incident is when that is discovered.
FF-15

Handle a flag that no longer exists

TypeNegativePriorityHigh
Test data
Delete a flag still referenced in code, and request an unknown flag key
Expected result
Falls back to the in code default without throwing, and the orphaned reference is surfaced for cleanup rather than failing silently.
FF-16

Enforce the correct type for a flag value

TypeNegativePriorityMedium
Test data
A boolean flag returning a string, and a numeric flag returning null
Expected result
Type mismatch falls back to the default rather than producing a truthy string that silently enables a feature.
FF-17

Migrate data safely behind a flag

TypeStatePriorityHigh
Test data
A flag switching between an old and a new data path, toggled after data is written through the new one
Expected result
Data written under one path is readable under the other, or the flag is documented as one way and the interface prevents reverting.
FF-18

Restrict who can change a flag

TypeSecurityPriorityHigh
Test data
A non privileged user attempting to change a flag through the interface and the API
Expected result
Refused on both paths, and changing a production flag requires the same authorisation as a deployment because the effect is identical.
FF-19

Audit every flag change

TypeSecurityPriorityHigh
Test data
Enable, adjust the percentage, then disable a flag
Expected result
Each change records actor, timestamp, previous and new value, so a behaviour change can be correlated with a flag change during an incident.
FF-20

Prevent a client from overriding a flag

TypeSecurityPriorityHigh
Test data
Alter the flag value in client storage, in a cookie and in a request parameter
Expected result
Ignored for any flag that gates access or entitlement, since a client controlled override turns a feature gate into a free upgrade.
FF-21

Keep flag payloads free of sensitive configuration

TypeSecurityPriorityHigh
Test data
Inspect the flag payload delivered to the browser
Expected result
Contains no internal endpoint, key or unreleased product name, since everything sent to the client is public regardless of whether the flag is off.
FF-22

Gate access to the feature on the server too

TypeSecurityPriorityHigh
Test data
Call the endpoint behind a disabled feature directly
Expected result
Refused. A flag that only hides the interface leaves the functionality fully reachable by anyone who reads the client bundle.
FF-23

Support a per user override for support and testing

TypeFunctionalPriorityMedium
Test data
An override applied to one account by a support user
Expected result
Takes effect for that account only, is visible in the audit trail, and expires or is easy to find and remove rather than persisting forgotten.
FF-24

Evaluate flags without adding latency

TypePerformancePriorityHigh
Test data
A page evaluating many flags, with the flag service slow
Expected result
Evaluation is local against cached configuration rather than a network call per flag, and a slow service does not delay page rendering.
FF-25

Handle a burst of flag evaluations

TypePerformancePriorityMedium
Test data
High request volume with flags evaluated on every request
Expected result
Throughput is unaffected and the flag service is not called per request, since polling per evaluation turns it into a hard dependency at peak.
FF-26

Report exposure accurately for an experiment

TypeStatePriorityMedium
Test data
A running experiment with exposure events recorded
Expected result
Exposure is recorded when the variant is actually shown rather than when the flag is evaluated, otherwise the analysis counts users who never saw it.
FF-27

Identify and remove stale flags

TypeStatePriorityMedium
Test data
A flag at 100 per cent for months and one at zero per cent for months
Expected result
Both are surfaced for removal, since accumulated permanent flags multiply the untested combinations in the codebase.
FF-28

Keep the interface coherent in both variants

TypeAccessibilityPriorityMedium
Test data
Both variants navigated by keyboard and screen reader, including a variant that removes a control
Expected result
Focus order and labelling are correct in both, and removing a control in one variant does not leave focus on an element that no longer exists.

What goes in each field

ID

Required

Stable identifier, prefixed by module.

Test case

Required

What is being verified, in one line.

Type

Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.

Priority

Risk based. Anything that exposes an unfinished feature, flickers a user between variants, or makes the flag service a single point of failure for the whole application is High.

Test data

The specific values, including the invalid and boundary ones.

Expected result

Required

The precise observable outcome, including message text where the wording itself is the requirement.

How To Use This

Take the flag service offline

Toggling a flag on and watching the feature appear proves the happy path. These four conditions decide whether the flag system is safe to depend on.

Make the flag service unreachable

If the application fails closed, you have made the flag service a single point of failure for every feature it gates. Failing to documented defaults is the only safe answer.

Load the same page twenty times

One user on a 50 per cent rollout must get the same variant every time. Random rather than stable bucketing flickers the feature on and off and invalidates the experiment.

Raise the rollout from 10 to 25 per cent

Everyone already in should stay in. A recalculation that drops existing users out reads to them as a feature being taken away, and they will report it as a bug.

Turn off a flag that has been on for months

The disabled path is untested code by now. Discovering that during an incident, when turning the flag off is your rollback, is the worst possible moment.

What Most Sets Miss

Why flag systems fail at the worst moment

A feature flag system is infrastructure that every request depends on, and the first question to ask of it is what happens when it is not there. If evaluation blocks on a network call, a slow flag service becomes a slow application. If an unreachable service means features default off, then one outage disables everything you have ever gated. Serving the last known good configuration during an outage is the behaviour that matters most, because reverting to bundled defaults silently switches off a feature that was live and nobody will connect the two events.

Bucketing has to be deterministic and it has to be stable in two directions. Within a session, a user who is bucketed randomly per evaluation will see the feature flicker between page loads, which looks broken and destroys any experiment measuring it. Across a rollout increase, users already in the group have to stay in it: recalculating the hash when the percentage changes will pull some existing users out, and to them a feature disappearing is a regression they will report. Both come free with hashing a stable identifier, and both are broken by anything else.

The kill switch is the reason flags exist and its latency is rarely measured. A flag that takes twenty minutes to propagate is not a kill switch during an incident, it is a slow deployment with extra steps. The neighbouring problem is server and client evaluation disagreeing, which produces either a hydration error or a visible flash of the wrong variant on every load, and that flash is enough to invalidate an experiment even when the feature itself works.

Finally, flags accumulate and each one doubles the combinations. Two related flags mean four states, and at least one of those states is a combination nobody intended to ship but which is reachable because flags are not disabled in the order they were enabled. Code behind a flag that has been on for months is untested code. And any flag gating access or entitlement has to be enforced on the server, because a flag that only hides the interface leaves the functionality fully reachable to anyone who reads the client bundle.

Suggest an improvement

Testing a release or rollout pipeline?

QAble tests progressive delivery end to end, including fallback behaviour, bucketing correctness, kill switch latency and the disabled path that becomes your rollback.

DevOps transformation services

More test case sets

View all

Test cases for a login page

Test cases
25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.

Test cases for a registration form

Test cases
28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.

Test cases for search functionality

Test cases
28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.

Test cases for a shopping cart

Test cases
27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.

Test cases for checkout and payment

Test cases
30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.

Test cases for file upload

Test cases
28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.

Test cases for forgot password

Test cases
26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.

Test cases for OTP verification

Test cases
26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.

Test cases for user roles and permissions

Test cases
26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.

Test cases for form validation

Test cases
27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.

Test cases for a date picker

Test cases
26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.

Test cases for pagination

Test cases
24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.

Test cases for push notifications

Test cases
26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.

Test cases for reports and data export

Test cases
25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.

Test cases for a chatbot

Test cases
28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.

Test cases for net banking transactions

Test cases
28 cases on duplicate debits from a retried request, concurrent transfers against one balance, daily limits across channels, beneficiary cooling periods, second factor binding and reconciliation.

Test cases for wallet and UPI payments

Test cases
28 cases on payments that time out with no response, idempotency on retry, racing balances, caps across devices, collect request fraud, mandates and refunds.

Test cases for insurance claim submission

Test cases
28 cases on coverage at the date of loss, waiting periods, deductibles and sub limits, exclusions and riders, duplicate claims and settlement reconciliation.

Test cases for patient records in an EHR

Test cases
28 cases on duplicate detection and merge, wrong patient entry, units of measure, allergy and interaction alerting, break glass access and audit of reads.

Test cases for CRM lead management

Test cases
28 cases on duplicate leads under concurrency, routing and the unrouted fallback, round robin races, territory visibility, conversion and bulk import.

Test cases for an ERP purchase order

Test cases
28 cases on approval thresholds, amendments that must reset approval, budget commitment races, over receipt tolerance, three-way match and duplicate invoices.

Test cases for OTT video playback

Test cases
28 cases on bitrate recovery after a dip, DRM renewal mid stream, concurrent stream limits and leaked slots, resume conflicts, ad cue points and offline expiry.

Test cases for game level progression

Test cases
28 cases on save corruption during a crash write, cloud save conflicts, offline queue replay, unlock gating, currency exploits and purchase restore.

Test cases for a REST API

Test cases
28 cases on status code correctness, cross tenant resource access, mass assignment, idempotent retries, cursor pagination, rate limits and contract drift.

Test cases for SSO and social login

Test cases
28 cases on linking an account on an unverified email, state and code replay, redirect allow lists, token signature and issuer, deprovisioning and session rotation.

Test cases for subscription and billing

Test cases
28 cases on mid cycle proration, duplicate and out of order webhooks, renewal double charges, dunning and grace, trials, coupons, metered usage and tax.

Test cases for data tables, filters and sorting

Test cases
28 cases on unstable sorts across pages, filters that must reset pagination, selection surviving a filter change, bulk action scope and export fidelity.

Test cases for session timeout and concurrent login

Test cases
28 cases on tokens that survive sign out, refresh token reuse, idle against absolute lifetime, multi tab expiry, session limits and remote revocation.

Test cases for a multi step form wizard

Test cases
28 cases on values lost to back navigation, refresh and session expiry, step skipping, server side revalidation, duplicate submission and conditional branches.

Test cases for email verification

Test cases
28 cases on token reuse and expiry, invalidating earlier links, account enumeration, header injection, safe address change and mail scanner prefetching.

Test cases for dashboards and analytics widgets

Test cases
28 cases on reconciling against source rows, widgets that disagree, timezone aggregation, zero baselines, no data shown as zero and permission leaks in aggregates.

Test cases for booking and reservation

Test cases
28 cases on concurrent bookings for the last slot, inventory holds that leak, payment without a booking, cancellation boundaries and channel sync.

Test cases for mobile app install and update

Test cases
28 cases on migration chains across skipped versions, crashes during post upgrade migration, forced update lockouts, deep links and clean reinstall.

Test cases for accessibility (WCAG 2.2 AA)

Test cases
28 cases on keyboard only completion, focus management, live region announcements, contrast, reflow at 320 pixels, target size and screen reader verification.

Test cases for performance and load

Test cases
28 cases on spikes with no ramp, recovery after peak, soak and leak detection, pool exhaustion, cold caches, retry storms and data correctness under load.

Test cases for the OWASP Top 10

Test cases
28 cases on broken access control, mass assignment, injection across every input surface, credential stuffing, session invalidation, SSRF and exposed secrets.

Test cases for cross browser compatibility

Test cases
28 cases on storage that throws in private mode, blocked third party cookies, engine date parsing, mobile viewport units, in app browsers and ad blockers.

Test cases for database and data integrity

Test cases
28 cases on uniqueness under concurrency, lost updates, counter races, orphaned rows, migration and backfill safety, replica lag and verified restores.

Test cases for localisation and multi language support

Test cases
28 cases on text expansion, concatenated sentences, plural rules, locale date parsing, decimal separators, right to left layout, collation and encoding.

Test cases for outbound webhooks

Test cases
28 cases on retry backoff and dead letter stores, one dead consumer degrading the pipeline, payload signing and replay windows, out of order delivery and endpoint SSRF.

Test cases for background jobs and queues

Test cases
28 cases on work outliving the visibility timeout, idempotent handlers, poison messages, priority starvation, scheduler overlap across instances and graceful drain.

Test cases for real time features and websockets

Test cases
28 cases on messages lost in the reconnect gap, half open connections, per channel authorisation, tokens expiring mid connection, backpressure and fanout across instances.

Test cases for file storage and media processing

Test cases
28 cases on signed URL scope and expiry, serving before scanning completes, content type sniffing, metadata stripping, orphaned objects and derivative failures.

Test cases for CSV import and bulk operations

Test cases
28 cases on reruns duplicating successes, delimiters inside quoted fields, byte order marks, leading zeros, ambiguous dates and bulk action scope.

Test cases for Android app lifecycle and permissions

Test cases
28 cases on state lost to process death, configuration changes, permanent permission denial, revocation while backgrounded, doze and battery restrictions.

Test cases for iOS app lifecycle and permissions

Test cases
28 cases on the keychain surviving uninstall, suspended termination, limited photo access, allow once location, app switcher snapshots and biometric invalidation.

Test cases for wearable app sync

Test cases
28 cases on data recorded away from the phone, duplicate records on resync, full buffers, clock drift, health permissions, battery budgets and unworn readings.

Test cases for VR and AR experiences

Test cases
28 cases on the frame rate comfort floor, tracking loss, guardian boundaries, involuntary camera movement, AR anchor drift and spatial data privacy.

Test cases for IoT device pairing and telemetry

Test cases
28 cases on offline buffering and reconnect floods, fleet wide reconnection storms, shared credentials, wrong device clocks and stale queued commands.

Test cases for embedded firmware update

Test cases
28 cases on power loss mid write, automatic rollback and health confirmation, signature and anti rollback checks, staged rollouts and recovery mode.

Test cases for user profile and account settings

Test cases
28 cases on partial saves reported as success, optimistic updates the server rejected, mass assignment through a profile form, avatar content inspection and session invalidation.

Test cases for account deletion and data export

Test cases
28 cases on export links that must be authorised and expiring, deletion cascading to storage, caches, logs and processors, grace periods, legal holds and deadlines.

Test cases for consent and cookie management

Test cases
28 cases on cookies and tracking requests firing before consent, reject parity with accept, tag manager bypass, withdrawal, cached banners and server side forwarding.

Test cases for notification preferences and delivery

Test cases
28 cases on opt outs honoured on one channel and ignored on another, marketing sent as transactional, unsubscribe scope, imports resetting consent and digest timezones.

Test cases for admin impersonation and support access

Test cases
28 cases on actions attributed to the customer instead of the admin, credential exposure, chained and upward impersonation, session expiry and immutable access records.

Test cases for audit logs and activity history

Test cases
28 cases on forged entries through log injection, immutability and tamper detection, actor attribution across impersonation and jobs, retention and legal holds.

Want your rollout controls proven, not assumed?

QAble covers functional, state and security paths with ISTQB-certified engineers. Start with a free QA audit of your delivery pipeline.

Talk to QA Advisor