It depends on how you're managing your feature flags. Ideally, you're using a flagging system that allows you to target specific users or segments of users so that an untested feature isn't inadvertently enabled for all your users. Some feature management systems (like LaunchDarkly) allow you to target users any way you want.

For example, a common workflow (for teams who use feature flags) is to release a new feature under a flag that's only turned on for the team that's working on that feature. So, even if the feature hasn't been tested, it's guaranteed that only the right eyes are seeing that feature.

This allows your dev team to continue to work on the feature and test it in production (if that's appropriate). Of course, a full set of tests should cover that feature before it's release, but it's nice that devs have a way to iterate quickly without the hangups of a process that didn't involve feature flags.

It depends on how you're managing your feature flags. Ideally, you're using a flagging system that allows you to target specific users or segments of users so that an untested feature isn't inadvertently enabled for all your users. Some feature management systems (like LaunchDarkly) allow you to target users any way you want.

For example, a common workflow (for teams who use feature flags) is to release a new feature under a flag that's only turned on for the product team that's working on that feature. So, even if the feature hasn't been tested, it's guaranteed that only the right users have access to that new feature.

This allows your product team to continue to work on the feature and test it in production (if that's appropriate). Of course, a full set of tests should cover that feature before it's released, but it's nice that product teams have a way to iterate quickly without the hangups of a process that didn't involve feature flags.