Browse the Knowledge Hub74 resources
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat 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
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
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.
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 improvementTesting 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 servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 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 cases26 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 cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 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 cases26 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 cases24 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 cases26 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 cases25 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 cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Test cases for net banking transactions
Test cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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.