diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 7830f5e575..dba2a9cce8 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -904,8 +904,8 @@ If your tests make any database queries, use subclasses
 ``TransactionTestCase`` inherits from :class:`~django.test.SimpleTestCase` to
 add some database-specific features:
 
-* Resetting the database to a known state at the beginning of each test to
-  ease testing and using the ORM.
+* Resetting the database to a known state at the end of each test to ease
+  testing and using the ORM.
 * Database :attr:`~TransactionTestCase.fixtures`.
 * Test :ref:`skipping based on database backend features <skipping-tests>`.
 * The remaining specialized :meth:`assert*
@@ -914,7 +914,7 @@ add some database-specific features:
 Django's :class:`TestCase` class is a more commonly used subclass of
 ``TransactionTestCase`` that makes use of database transaction facilities
 to speed up the process of resetting the database to a known state at the
-beginning of each test. A consequence of this, however, is that some database
+end of each test. A consequence of this, however, is that some database
 behaviors cannot be tested within a Django ``TestCase`` class. For instance,
 you cannot test that a block of code is executing within a transaction, as is
 required when using
@@ -1314,12 +1314,12 @@ by at least one test through ``databases``.
 
 However, a big part of the time taken to run a Django ``TestCase`` is consumed
 by the call to ``flush`` that ensures that you have a clean database at the
-start of each test run. If you have multiple databases, multiple flushes are
+end of each test run. If you have multiple databases, multiple flushes are
 required (one for each database), which can be a time consuming activity --
 especially if your tests don't need to test multi-database activity.
 
 As an optimization, Django only flushes the ``default`` database at
-the start of each test run. If your setup contains multiple databases,
+the end of each test run. If your setup contains multiple databases,
 and you have a test that requires every database to be clean, you can
 use the ``databases`` attribute on the test suite to request extra databases
 to be flushed.
@@ -1333,7 +1333,7 @@ For example::
             call_some_test_code()
 
 This test case class will flush the ``default`` and ``other`` test databases
-before running ``test_index_page_view``. You can also use ``'__all__'`` to
+after running ``test_index_page_view``. You can also use ``'__all__'`` to
 specify that all of the test databases must be flushed.
 
 The ``databases`` flag also controls which databases the