diff --git a/docs/e2e-system-tests/0_GettingStarted.md b/docs/e2e-system-tests/0_GettingStarted.md
new file mode 100644
index 0000000..871d8ae
--- /dev/null
+++ b/docs/e2e-system-tests/0_GettingStarted.md
@@ -0,0 +1,78 @@
+---
+sidebar_position: 1
+---
+
+# Getting Started
+
+This section provides instructions for setting up the Cypress-Cucumber test environment to ensure a smooth onboarding process.
+
+---
+
+## 1. Pre-requisites
+
+Before getting started, ensure the following tools are installed:
+
+- Node.js: Download Node v18
+- Git: Download Git
+- Browser: (Recommended: Microsoft Edge) Download Edge Browser
+- IDE: Choose any IDE (Recommended: VS Code)
+- Optional Tools: GitHub Desktop App
+- Recommended VS Code Extensions:
+  - Cucumber (Gherkin) Full Support
+  - EditorConfig
+  - Prettier
+
+---
+
+## 2. Cloning the Repository
+
+- To get the project files locally, follow these steps:
+
+  ```bash
+  git clone <repository-url>
+  cd <repository-folder>
+  ```
+
+Make sure you have access to the repository using your organization's credentials.
+
+---
+
+## 3. Setting Up Environment Configuration
+
+1. Duplicate the `template.env.json` file located in the `env_variables` directory:
+
+   - Rename the duplicated file to `local.env.json`.
+   - Update `local.env.json` with your credentials and environment-specific variables from 1Password.
+     - Ensure that the credentials match the correct namespace vault (staging, dev, etc.) in 1Password.
+
+2. This configuration is required for accessing APIs, authentication, and other environment-specific services.
+
+---
+
+## 4. Installing Dependencies
+
+- Use the following command to install all necessary project dependencies:
+
+  ```bash
+  npm ci
+  ```
+
+---
+
+## 5. Running Cypress Tests
+
+Once the setup is complete, you can run the tests:
+
+- To run all tests in headless mode:
+
+  ```bash
+  npm run cy:headless:stable:local
+  ```
+
+- To run tests interactively in the Cypress UI:
+
+  ```bash
+  npm run cy:gui:stable:regression:staging:local
+  ```
+
+For more details on additional configurations and test options, refer to the [`Running Tests Guide`](https://github.com/hpi-schul-cloud/e2e-system-tests/blob/main/docs/running_tests_guide.md) section in README.
diff --git a/docs/e2e-system-tests/1_ProjectStructure.md b/docs/e2e-system-tests/1_ProjectStructure.md
new file mode 100644
index 0000000..3dfe4e9
--- /dev/null
+++ b/docs/e2e-system-tests/1_ProjectStructure.md
@@ -0,0 +1,82 @@
+---
+sidebar_position: 2
+---
+
+# Project Structure
+
+Understanding the project directory layout will help you navigate and manage the Cypress-Cucumber E2E test framework effectively. This section provides a detailed breakdown of the folder structure and the purpose of each component.
+
+---
+
+## Project Directory Layout
+
+```sh
+(root)
+|
+|---- .github/
+|     |____ automatic-trigger.yml          # GitHub Actions workflow for automatic triggers
+|     |____ manual-trigger.yml             # GitHub Actions workflow for manual runs
+|     |____ scheduled-trigger.yml          # GitHub Actions workflow for scheduled runs
+|     |____ main.yml                       # GitHub Actions workflow for reusable jobs
+|
+|---- .vscode/                             # Settings for recommended VS Code extensions
+|
+|---- env_variables/
+|     |____ template.env.json              # Template for credentials & environment variables (rename as `local.env.json`)
+|
+|---- cypress/
+|     |___ downloads/                      # Downloaded files during tests
+|     |___ fixtures/                       # Test data files
+|     |___ e2e/                            # Gherkin feature files
+|     |___ screenshots/                    # Screenshots taken on test failures
+|     |___ support/
+|         |___ custom_commands/            # Custom Cypress commands used in tests
+|         |___ pages/                      # Page Object methods for better test modularity
+|         |___ step_definitions/           # Step definitions for feature files
+|         |___ commands.js                 # Custom Cypress commands configuration
+|         |___ e2e.js                      # Global hooks and configurations
+|     |___ videos/                         # Recorded test run videos
+|
+|---- docs/
+|     |___ tags.md                         # Documentation on test framework usage
+|
+|---- reports/                             # HTML reports and related assets
+|
+|---- logs/                                # Logs generated during test runs
+|
+|---- node_modules/                        # Project dependencies
+|
+|---- scripts/
+|     |____ aggregate-json-files.sh        # Script to aggregate JSON files in CI
+|     |____ runSchoolApi.js                # Script to interact with the School API
+|
+|---- .editorconfig                        # Editor configuration for consistent formatting
+|---- .gitattributes                       # Git attributes for line endings and diff
+|---- .prettierignore                      # Files and folders ignored by Prettier
+|---- .prettierrc                          # Prettier configuration for code formatting
+|---- .gitignore                           # Git ignore rules
+|---- reporter.js                          # Custom reporter for generating HTML reports
+|---- cypress.config.json                  # Cypress configuration settings
+|---- LICENSE                              # License file
+|---- package-lock.json                    # npm package lock file
+|---- package.json                         # Project dependencies and scripts
+|---- README.md                            # Project documentation and setup guide
+
+```
+
+### Explanation of Key Directories and Files
+
+- **.github/:** Contains CI/CD workflows for automated, manual, and scheduled test executions.
+- **.vscode/:** Recommended settings for VS Code extensions to maintain consistent coding standards.
+- **env_variables/:** Holds environment configuration files. Duplicate `template.env.json` and rename it to `local.env.json` for local testing.
+- **cypress/:** The main directory for Cypress tests.
+- **fixtures/:** Stores reusable test data.
+- **e2e/:** Contains all Gherkin .feature files.
+- **support/:** Includes custom commands, page objects, and step definitions.
+- **videos/ & screenshots/:** Captures test artifacts.
+- **docs/:** Additional documentation for tags, configurations, and best practices.
+- **reports/:** Contains HTML reports generated after test runs.
+- **scripts/:** Helpful scripts for CI/CD and API interactions.
+- **.prettierrc & .editorconfig:** Configuration files to enforce consistent coding styles.
+- **cypress.config.json:** Central configuration file for Cypress test settings.
+- **reporter.js:** Custom script to generate detailed HTML reports.
diff --git a/docs/e2e-system-tests/2_CodeConventions.md b/docs/e2e-system-tests/2_CodeConventions.md
new file mode 100644
index 0000000..1a147fc
--- /dev/null
+++ b/docs/e2e-system-tests/2_CodeConventions.md
@@ -0,0 +1,251 @@
+---
+sidebar_position: 3
+---
+
+# Code Conventions
+
+This guide provides coding conventions and best practices for writing feature files, naming folders, files, methods, and step definitions. Following these conventions will ensure consistency and maintainability across the test framework.
+
+---
+
+## 1. Writing Feature Files
+
+### Template Structure
+
+Use the following template when creating a feature file:
+
+```gherkin
+Feature: <Description of the user story or functionality>
+
+  <As a --user--, I want to ---perform an action--- so that ---I can achieve a certain goal--->
+
+  Scenario: <Short description of the scenario>
+
+    Given <precondition>
+    When  <action or interaction with the application>
+    Then  <expected outcome>
+```
+
+### Guidelines
+
+- **"When"** statements describe actions or interactions with the application.
+- **"Then"** statements describe the expected results of those actions.
+- Multiple **"When"** statements can precede a single **"Then"** statement:
+
+  ```gherkin
+  When <action 1>
+  When <action 2>
+  Then <result>
+  ```
+
+- It is acceptable to have multiple **"Then"** statements:
+
+  ```gherkin
+  When <action>
+  Then <result 1>
+  Then <result 2>
+  ```
+
+- Avoid using **"And"** statements. Use only **"When"** and **"Then"** for clarity.
+
+---
+
+## 2. Using Parameters in Feature Files
+
+**Leveraging Example Tables with `Scenario Outline`**
+
+When you need to run the same scenario with different sets of test data, use `Scenario Outline` along with Example Tables. This approach makes your test cases more efficient and maintainable.
+
+`Scenario Outline` allows you to define steps with placeholders (`<parameter>`) that are substituted with values from the `Examples` table.
+
+- **Example Usage**
+
+  ```gherkin
+  Feature: Create and delete a class
+
+  As a teacher, I want to create and delete classes
+  so that I can manage my courses effectively.
+
+  Scenario Outline: Teacher creates and deletes a class
+      Given a user with the role "<role>"
+      When the user creates a class named "<className>"
+      Then the class "<className>" should be visible in the list
+      When the user deletes the class "<className>"
+      Then the class "<className>" should no longer exist
+
+  Examples:
+      | role     | className  |
+      | teacher  | Math101    |
+      | teacher  | Science202 |
+      | admin    | History300 |
+
+  ```
+
+**_Explanation_**
+
+- The `Scenario Outline` defines the test steps using parameters like `<role>` and `<className>`.
+- The `Examples` table provides multiple sets of data for each parameter.
+- Each row in the`Examples` table will generate a separate test case with the specified values.
+
+**_Benefits of Using Scenario Outlines_**
+
+- **Reusability:** Allows you to reuse the same test steps for multiple sets of test data.
+- **Maintainability:** Reduces code duplication and makes it easier to update test data.
+- **Clarity:** Keeps the .feature file organized and easy to read.
+
+---
+
+## 3. Using Parameters for Special Test Data
+
+In addition to `Scenario Outlines`, you can directly use parameters within feature files to specify dynamic values, such as task titles, or other context-specific data.
+
+**Example:**
+
+```gherkin
+Feature: User login
+
+  Scenario: Valid user login
+    Given a user with the username "testUser" and password "Password123"
+    When the user logs in
+    Then the user should be redirected to the dashboard
+```
+
+In this case, parameters are directly embedded within the scenario steps without an `Examples` table.
+
+---
+
+## 4. Writing Step Definitions for Scenario Outlines
+
+**_Step Definitions Example_**
+
+Ensure that your step definitions are designed to handle the dynamic parameters from your feature files:
+
+```js
+Given('a user with the role {string}', role => {
+  cy.loginAsRole(role)
+})
+
+When('the user creates a class named {string}', className => {
+  cy.createClass(className)
+})
+
+Then('the class {string} should be visible in the list', className => {
+  cy.verifyClassExists(className)
+})
+
+Then('the class {string} should no longer exist', className => {
+  cy.deleteClass(className)
+  cy.verifyClassDeleted(className)
+})
+```
+
+**_Explanation_**
+
+- The `{string}` syntax captures the parameter from the feature file.
+- Each step is linked to the corresponding scenario, making your tests highly modular and reusable.
+
+---
+
+## 5. Naming Conventions
+
+**_Folder Names_**
+
+- Use `snake_case` for longer folder names.
+  - Example: `common_logins`
+
+**_Feature File Names_**
+
+- Syntax: `verb + noun`
+  - Example: `createCourse.feature`
+
+**_Page Object File Names_**
+
+- Syntax: `page + noun`
+  - Example: `pageCourse.js`, `pageCommonCourse.js`
+
+**_Class Names Inside Page Objects_**
+
+- Syntax: `FirstWord_SecondWord`
+  - Example: `Course`, `Course_Common`
+
+**_Method Names Inside Classes_**
+
+- Syntax: `verb + noun (CamelCase)`
+  - Example: `fillCourseCreationForm()`
+
+**_Variable Names_**
+
+- Syntax: `verb + noun or noun + verb (CamelCase)`
+  - Example: `userEmail`, `loginButton`
+
+**_Data-testid Naming Convention_**
+
+Test IDs are used to select elements on the web page, including buttons, input fields, and sections.
+
+- Syntax: `firstword-secondword-thirdword`
+  - Example: `content-card-task-menu-edit-icon`
+- Usage: Assign test IDs to elements using:
+
+  ```html
+  <button data-testid="add-course-button">Add Course</button>
+  ```
+
+---
+
+## 6. Writing Classes and Methods
+
+**_Guidelines_**
+
+- Assign test data IDs to a `static` variable with a `#` prefix so it indicate as a private variable within the class.
+- Break down complex interactions into smaller methods within the class for better modularity.
+- Refer to examples in the current end to end repository for guidance.
+
+---
+
+## 7. Writing Step Definitions
+
+**_Step Definition Folder Structure_**
+
+- Create a step definition file within `cypress/support/step_definitions/` based on the module name (e.g., rooms, courses, teams).
+- The naming convention for step definition files is based on the module name, followed by `.spec.js`.
+- Example:
+  - `editCourseSteps.spec.js`
+  - `commonCourseSteps.spec.js` (for shared steps across multiple scenarios)
+
+**_Guidelines_**
+
+- Follow the same sequence as the feature file for consistency.
+- Create one common step definition file that can be reused across tests within the same module or across modules.
+- For module-specific step definitions, comment out any common steps and include a reference to their location.
+
+**_Example 1: Dedicated Module Step Definitions_**
+
+```js
+// editCourseSteps.spec.js
+Given('a user is logged in', () => { ... });
+
+When('the user edits the course details', () => { ... });
+
+Then('the course should be updated', () => { ... });
+```
+
+**_Example 2: Referencing Common Step Definitions_**
+
+```js
+// commonCourseSteps.spec.js
+Given('a user is logged in', () => { ... });
+
+// editCourseSteps.js
+// Commented out common steps with reference
+// Refer to: commonCourseSteps.spec.js
+When('the user edits the course details', () => { ... });
+
+Then('the course should be updated', () => { ... });
+```
+
+---
+
+## 8. Additional Best Practices
+
+- Use consistent folder and file names as per the naming conventions above.
+- Keep the user journey sequence the same in both .feature files and step definition files to enhance readability.
diff --git a/docs/e2e-system-tests/3_Tags.md b/docs/e2e-system-tests/3_Tags.md
new file mode 100644
index 0000000..db9316b
--- /dev/null
+++ b/docs/e2e-system-tests/3_Tags.md
@@ -0,0 +1,95 @@
+---
+sidebar_position: 4
+---
+
+# Tags
+
+This section explains the tagging system used for Cypress and Cucumber tests. Tags help categorize and selectively run tests based on environments, test stability, or purpose.
+
+---
+
+## Tag Descriptions
+
+- **@stable_test:** Tests that are stable and expected to pass in all environments.
+- **@regression_test:** Tests run before a release to ensure core functionality.
+- **@school_api_test:** Tests interacting with the school API.
+- **@staging_test:** Tests specific to the staging environment.
+- **@pr:** Tests run during the CI process for Pull Requests.
+- **@unstable_test:** Tests that may fail intermittently due to environmental factors.
+- **@group-A / @group-B:** Tags for grouping tests in parallel execution.
+- **@schedule_run:** Tests tagged for scheduled runs in CI.
+
+---
+
+## Tag Hierarchy
+
+- **Feature-level tags** apply to all scenarios within that feature, unless overridden at the scenario level.
+
+**Examples:**
+
+- **`@regression_test & @stable_test`**
+
+  ```gherkin
+  @regression_test
+  Feature: Account Management
+
+  @stable_test
+  Scenario: Edit email as an internal user
+      Given I am logged in as an internal user
+      When I navigate to the account settings
+      Then I should see that my email is editable
+  ```
+
+- **`@unstable_test`**
+
+  ```gherkin
+  @unstable_test
+  Feature: Add-ons Management
+
+  Scenario Outline: Access Add-ons page
+      Given I am logged in as '<user_role>'
+      When I navigate to the Add-ons page
+      Then I should see the Add-ons interface
+
+  Examples:
+    | user_role |
+    | admin     |
+    | teacher   |
+  ```
+
+- **`@school_api_test & @staging_test`**
+
+  ```gherkin
+  @regression_test
+  @stable_test
+  Feature: User Management
+
+  Scenario: Admin manages users
+      Given I am logged in as an admin
+      When I add a new user
+      Then the user should appear in the list
+
+  @school_api_test
+  Examples: School API
+      | user_role | user_email            |
+      | admin     | admin@school.com      |
+
+  @staging_test
+  Examples: Staging
+      | user_role | user_email            |
+      | teacher   | teacher@staging.com   |
+  ```
+
+- **`@pr`**
+
+  ```gherkin
+  @pr
+  Feature: Critical Paths
+
+  Scenario: Verify homepage loads
+      Given the application is deployed
+      When I navigate to the homepage
+      Then the homepage should load correctly
+  ```
+
+For detailed information on the full usage of tags, please refer to the [full documentation](https://github.com/hpi-schul-cloud/e2e-system-tests/blob/main/docs/tags.md) in README.
diff --git a/docs/e2e-system-tests/_category_.json b/docs/e2e-system-tests/_category_.json
new file mode 100644
index 0000000..7485132
--- /dev/null
+++ b/docs/e2e-system-tests/_category_.json
@@ -0,0 +1,8 @@
+{
+  "label": "e2e-system-tests",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Learn about the e2e tests repo."
+  }
+}
\ No newline at end of file