Blog Series: QA Reimagined – Navigating Agile, AI and Automation-Part 4

Part 4: Testing in Motion – Feature Flags, Trunk-Based Dev, and the QA Mindset Shift

Previously in this series:

In Part 3, I focused on how automation needs to evolve to support modern Agile teams — not just in coverage or tooling, but in how we think about feedback, risk, and delivery flow.

This time, we look at two game-changers in software delivery: feature flags and trunk-based development (TBD). Together, they’re reshaping not just how we release — but how, when, and what we test.

And QA needs to adapt.

The Challenge of Continuous Change

As teams move toward faster release cycles — sometimes daily or even hourly — the QA landscape shifts beneath our feet. We no longer have the luxury of waiting for “final” builds or stable UIs.

Instead, we now test in motion:

Features under development are already merged. Releases are decoupled from deployments. Flags are used to control exposure, experimentation, and rollback.

This is exciting — but also messy.

Without the right mindset and structure, testing can become disconnected from real risk and real users.

Feature Flags: Power and Responsibility

Feature flags (also called toggles) give teams control over when and how features are released. With a flip of a switch, we can:

– Test features in production without exposing them to users

– Deploy incomplete features safely

– Roll out gradually (e.g., 10% of users)

– Run A/B experiments

But with great flexibility comes a new QA burden.

QA Considerations with Feature Flags:

Are you testing both the on and off states of each flag? Are your tests flag-aware — or are they failing when a flag is inactive? How are flag configurations handled across test environments? Do you have a strategy to clean up stale flags?

Feature flags give agility — but without QA awareness, they also add complexity and blind spots.

Trunk-Based Development (TBD): Fast, Frequent, and Fragile (if you’re not ready)

TBD encourages small, frequent changes merged into a shared main branch. It reduces long-living branches and the painful merges that come with them.

Combined with CI/CD, it allows near-continuous delivery.

But for QA, it creates three key shifts:

1. Testing Must Be Contextual and Incremental

You don’t test a “release candidate” anymore — you test the latest commit. This means automation needs to be intelligent and fast (see Part 3). Manual testing shifts toward exploration, not catch-all regression.

2. Quality Signals Must Be Real-Time

Build failures, test alerts, and flag mismatches need to surface quickly. Slack notifications, dashboards, and trend tracking help teams respond in hours — not sprints.

3. Everyone Must Own Risk

With TBD, the feedback loop is tight. There’s no time for QA to “catch it later.” Developers, QA, and product must collectively assess change impact.

In trunk-based workflows, QA can’t be reactive. It must be embedded.

Patterns I’ve Seen Work Well related to TBD and Feature Flags

Over the last few years, here’s what I’ve seen help teams succeed when combining flags + TBD:

Flag-Aware Automation

Automated tests are written with both flag states in mind. Feature flag states are injected or mocked during test runs. CI pipelines run a matrix of tests with flags toggled.

Exploratory Testing in Context

Exploratory sessions are run while features are toggled on — not just post-release. Teams test both behavior and rollback impact.

Change Impact Awareness

Teams use tools or metadata to track which services or flags a code change touches. This helps QA prioritize test coverage and exploratory focus.

Documentation in Motion

Feature flag status and test coverage are visible and traceable (via Confluence, Jira, etc.) Flags are part of the Definition of Done — including clean-up plans.

But What Happens Without QA Adaptation?

In teams that don’t align QA to these practices, I often see:

False positives from automation when flags are off Missed test coverage because toggled-off features go untested Painful rollback bugs when off-state behavior isn’t validated Confusion over what’s tested vs. what’s “released”

The result? Features are in production but invisible to QA — and that’s a dangerous place to be.

How to approach This as a QA Leader

When coaching teams or leading internal quality transformation, here are the principles I use:

1. Design your tests to account for configuration, not just functionality

2. Define test strategies for both feature flag states — and clean them up

3. Integrate flag visibility into your test reporting and dashboards

4. Use toggle-aware scenarios when possible (“Given flag X is on…”)

5. Involve QA in release toggling and flag planning — not just test execution

And most importantly:

Have a shared understanding of what “tested” and “done” actually mean in this new world.

Closing Thoughts: QA’s Role is Shifting — Again

As release and deployment decouple, and change becomes constant, QA is no longer a final check. It’s a continuous lens.

In a world of feature flags and trunk-based commits, testing is never done — it’s always in context.

Our job isn’t to resist that — it’s to bring clarity to it.

Quality in motion needs visibility, adaptability, and a QA mindset that’s not afraid to evolve.

Up Next:

In the next post, I’ll dive into how AI is actually being used to support modern QA — beyond the hype.