diff --git a/docs/source/core/data-structures/fci-fcc.rst b/docs/source/core/data-structures/fci-fcc.rst
index 2d87fde79fe7..85a10caaca1e 100644
--- a/docs/source/core/data-structures/fci-fcc.rst
+++ b/docs/source/core/data-structures/fci-fcc.rst
@@ -407,7 +407,7 @@ The FCC API is defined in ``Zend/zend_API.h``.
    Mandatory field, the number of arguments that will be provided to this call to the function.
 
 ``consumed_args``:
-   Specifies positional arguments whose ownership is transfered to the function being called. This
+   Specifies positional arguments whose ownership is transferred to the function being called. This
    is used as an optimization to avoid an unnecessary ``Z_ADDREF_P()``/``zval_ptr_dtor()`` when the
    value is not used after the call. Only one argument can be specified at once with
    ``zend_fci_consumed_arg(n)`` (zero-based), and the value must not be a reference. Must be set to
diff --git a/docs/source/miscellaneous/writing-tests.rst b/docs/source/miscellaneous/writing-tests.rst
index 40e273b6fd71..c589fed734bc 100644
--- a/docs/source/miscellaneous/writing-tests.rst
+++ b/docs/source/miscellaneous/writing-tests.rst
@@ -459,7 +459,7 @@ When creating temporary files it is a good idea to use an extension that indicat
 file, eg .tmp. It's also a good idea to avoid using extensions that are already used for other
 purposes, eg .inc, .php. Similarly, it is helpful to give the temporary file a name that is clearly
 related to the test case. For example, mytest.phpt should create mytest.tmp (or mytestN.tmp, N=1,
-2,3,...) then if by any chance the temporary file isnt't removed properly it will be obvious which
+2,3,...) then if by any chance the temporary file isn't removed properly it will be obvious which
 test case created it.
 
 When writing and debugging a test case with a ``--CLEAN--`` section it is helpful to remember that
@@ -1625,7 +1625,7 @@ section just stating a filename where to load the expected output from.
 
 **Description:** Code that is executed after a test completes. It's main purpose is to allow you to
 clean up after yourself. You might need to remove files created during the test or close sockets or
-database connections following a test. Infact, even if a test fails or encounters a fatal error
+database connections following a test. In fact, even if a test fails or encounters a fatal error
 during the test, the code found in the ``--CLEAN--`` section will still run.
 
 Code in the clean section is run in a completely different process than the one the test was run in.