diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc
index a75d6314aab..cec19b9185e 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc
@@ -4,7 +4,7 @@
 Once the TestContext framework loads an `ApplicationContext` (or `WebApplicationContext`)
 for a test, that context is cached and reused for all subsequent tests that declare the
 same unique context configuration within the same test suite. To understand how caching
-works, it is important to understand what is meant by "`unique`" and "`test suite.`"
+works, it is important to understand what is meant by "unique" and "test suite."
 
 An `ApplicationContext` can be uniquely identified by the combination of configuration
 parameters that is used to load it. Consequently, the unique combination of configuration
@@ -15,8 +15,8 @@ framework uses the following configuration parameters to build the context cache
 * `classes` (from `@ContextConfiguration`)
 * `contextInitializerClasses` (from `@ContextConfiguration`)
 * `contextCustomizers` (from `ContextCustomizerFactory`) – this includes
-  `@DynamicPropertySource` methods as well as various features from Spring Boot's
-  testing support such as `@MockBean` and `@SpyBean`.
+  `@DynamicPropertySource` methods, bean overrides (such as `@TestBean`, `@MockitoBean`,
+  `@MockitoSpyBean` etc.), as well as various features from Spring Boot's testing support.
 * `contextLoader` (from `@ContextConfiguration`)
 * `parent` (from `@ContextHierarchy`)
 * `activeProfiles` (from `@ActiveProfiles`)
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc
index 6e3c268f639..c95363d9462 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc
@@ -18,9 +18,9 @@ Do not run tests in parallel if the tests:
 * Use Spring Framework's `@DirtiesContext` support.
 * Use Spring Framework's `@MockitoBean` or `@MockitoSpyBean` support.
 * Use Spring Boot's `@MockBean` or `@SpyBean` support.
-* Use JUnit 4's `@FixMethodOrder` support or any testing framework feature
-  that is designed to ensure that test methods run in a particular order. Note,
-  however, that this does not apply if entire test classes are run in parallel.
+* Use JUnit Jupiter's `@TestMethodOrder` support or any testing framework feature that is
+  designed to ensure that test methods run in a particular order. Note, however, that
+  this does not apply if entire test classes are run in parallel.
 * Change the state of shared services or systems such as a database, message broker,
   filesystem, and others. This applies to both embedded and external systems.