diff --git a/source/fusiondirectory/development/automatedtesting/index.rst b/source/fusiondirectory/development/automatedtesting/index.rst
index 3216fab868b17b662dc214958afb914f9e23f017..62c5d2884d45f84b4fe1970de0a774ca41f75c5e 100644
--- a/source/fusiondirectory/development/automatedtesting/index.rst
+++ b/source/fusiondirectory/development/automatedtesting/index.rst
@@ -3,9 +3,9 @@ Testing
 
 The base project for testing is called `automated-testing`. Here all source code for the tests and test framework is placed.testing
 
-###########
+#############
 Prerequisites
-###########
+#############
 
 In order for the existing tests to be running properly, some prerequisites are needed:
 
@@ -16,9 +16,9 @@ In order for the existing tests to be running properly, some prerequisites are n
     * DSA server: some tests need a dsa server to be available in on the machine, this is done by modifying the orchestrator.conf file from your configuration path to have `tester` as both username and password
 
 .. setup:
-###########
+#####
 Setup
-###########
+#####
 
 In order to run the tests properly you need to follow the next steps:
 
@@ -46,18 +46,18 @@ In order to run the tests properly you need to follow the next steps:
         * `FAILED` for failed test along with a short message (for troubleshooting see :ref:`troubleshooting`)
 
 .. troubleshooting:
-###########
+###############
 Troubleshooting
-###########
+###############
 
 For every failed test we have implemented in our framework some features to help us troubleshoot:
 
     * If the test is running in a visual interface we are taking a screenshot of the last visual screen of the driver (this is saved in the screenshots folder that you defined in `qa/src/resources/testsConfig.ini` file)
     * We are putting logs in a file (saved in the same screenshots folder, the logs help following the workflow of the test and monitor where it crashed and why)
 
-###########
+#################
 Project structure
-###########
+#################
 
 All important modifiable parts of the code base are inside `qa` folder:
 
@@ -92,9 +92,9 @@ All important modifiable parts of the code base are inside `qa` folder:
 
                 * `installation` folder has only one test that verifies the functionality of the installation page
 
-###########
+###################
 How to write a test
-###########
+###################
 
 Before starting writing a test you should decide where to place it and in order to figure this out you need to answer the question `What am I testing?` and if the answer is a plugin `abc`, you should place your test in `plugins/abc` folder. Then, create a class in the right folder with a proper name, ending in `Test`. In the class constructor define the `initLdifs` array with the names of all needed ldfis for your test, or leave it a n empty array if none is needed. If you are altering the FusionDirectory related concepts make sure to revert the changes before the test ends or create an `@AfterEach` annotated method that will be automatically called after the tests ends. If you need to fetch elements from the web interface, try first to look into `FusionDirectoryTestCase.java` file because most of the times the method already exists. We prefer this because the tests will be kept cleaner like that and if any name convention changes it is easier to maintain the tests. Any test method has to be annotated by `@Test` (or similar ones like `@RepeatedTes(n)` or `@ParameterizedTest(methodName)`) in order to be run with gradle. Before pushing to gitlab you should try 3 things: