Add feature flag tests to the definition of done

doc/development/contributing/merge_request_workflow.md

@@ -264,6 +264,8 @@ requirements.
 1. Peer member testing is optional but recommended when the risk of a change is high. This includes when the changes are [far-reaching](https://about.gitlab.com/handbook/engineering/development/#reducing-the-impact-of-far-reaching-work) or are for [components critical for security](../code_review.md#security).
 1. Regressions and bugs are covered with tests that reduce the risk of the issue happening
    again.
+1. Code affected by a feature flag is covered by [automated tests with the feature flag enabled and disabled](../feature_flags/index.md#feature-flags-in-tests), or both
+   states are tested as part of peer member testing or as part of the rollout plan.
 1. [Performance guidelines](../merge_request_performance_guidelines.md) have been followed.
 1. [Secure coding guidelines](https://gitlab.com/gitlab-com/gl-security/security-guidelines) have been followed.
 1. [Application and rate limit guidelines](../merge_request_application_and_rate_limit_guidelines.md) have been followed.

doc/development/feature_flags/index.md

@@ -530,8 +530,9 @@ Feature.remove(:feature_flag_name)
 ## Feature flags in tests
 
 Introducing a feature flag into the codebase creates an additional code path that should be tested.
-It is strongly advised to test all code affected by a feature flag, both when **enabled** and **disabled**
-to ensure the feature works properly.
+It is strongly advised to include automated tests for all code affected by a feature flag, both when **enabled** and **disabled**
+to ensure the feature works properly. If automated tests are not included for both states, the functionality associated
+with the untested code path should be manually tested before deployment to production.
 
 When using the testing environment, all feature flags are enabled by default.