diff --git a/documentation/spring-boot-docs/src/docs/antora/modules/reference/pages/features/developing-auto-configuration.adoc b/documentation/spring-boot-docs/src/docs/antora/modules/reference/pages/features/developing-auto-configuration.adoc
index 9812eea86fb..366d85912fa 100644
--- a/documentation/spring-boot-docs/src/docs/antora/modules/reference/pages/features/developing-auto-configuration.adoc
+++ b/documentation/spring-boot-docs/src/docs/antora/modules/reference/pages/features/developing-auto-configuration.adoc
@@ -252,6 +252,9 @@ If the auto-configuration is relatively straightforward and does not have option
 
 If "acme" has a basic set of dependencies that are required to work, but you want to express a more opinionated view, then having a separate starter is a good option.
 
+When testing "acme" features, you may need test-specific auto-configurations.
+For example, you could offer a way to replace external dependencies with in-memory alternatives.
+A separate test-scoped starter can be created for this purpose, following the same principles.
 
 
 [[features.developing-auto-configuration.custom-starter.naming]]
@@ -265,6 +268,7 @@ As a rule of thumb, you should name a combined module after the starter.
 For example, assume that you are creating a starter for "acme" and that you name the auto-configure module `acme-spring-boot` and the starter `acme-spring-boot-starter`.
 If you only have one module that combines the two, name it `acme-spring-boot-starter`.
 
+If "acme" also has a test-scoped starter, name it `acme-spring-boot-starter-test`.
 
 
 [[features.developing-auto-configuration.custom-starter.configuration-keys]]