Added the initial ADR document (#24627)

* Added ADR documents, in order to improve test code quality and consistency, which help
* to document important test-related decisions with reasoning
* to Improve long-term clarity and team alignment
* to establish consistent guidelines how to write tests

Author: ibalosh

e2e/adr/0001-aaa-test-structure.md

@@ -0,0 +1,40 @@
+# Adopt Arrange–Act–Assert (AAA) Pattern for All Tests
+
+## Status
+Proposed
+
+## Context
+
+Our tests are currently written in different styles, which makes them harder to read, understand, and maintain.
+
+To improve **readability** and make it easier to **debug failing tests**, we want to standardize the structure of tests by following the well-known **Arrange–Act–Assert (AAA)** pattern.
+
+## Decision
+
+We will adopt the AAA pattern for tests. Every test should follow this structure:
+
+1. **Arrange**: Set up data, mocks, page state, or environment
+2. **Act**: Perform the action being tested
+3. **Assert**: Check the expected outcome
+
+## Guidelines
+
+- ✅ Multiple actions and assertions are **allowed** as long as they belong to a **single AAA flow**
+- 🚫 **Repeating the full AAA structure in a single test is discouraged**, except for performance‑sensitive tests where setup cost is prohibitively high
+- ✂️ If a test involves multiple unrelated behaviors, **split it into separate test cases**
+- 🧼 Keep tests focused and predictable: one test = one scenario
+
+## Example
+
+```ts
+test('user can view their post', async ({ page }) => {
+  // Arrange
+  const user = await userFactory.create();
+  const post = await postFactory.create({ userId: user.id });
+
+  // Act
+  await page.goto(`/posts/${post.id}`);
+
+  // Assert
+  await expect(page.getByText(post.title)).toBeVisible();
+});

e2e/adr/README.md

@@ -0,0 +1,21 @@
+# Architecture Decision Records (ADRs)
+
+This directory contains Architecture Decision Records (ADRs) specific to the E2E test suite.
+
+ADRs are short, version-controlled documents that capture important architectural and process decisions, along with the reasoning behind them.  
+They help document **why** something was decided — not just **what** was done — which improves transparency, consistency, and long-term maintainability.
+
+Each ADR includes the following sections:
+
+- `Status` – `Proposed`, `Accepted`, `Rejected`, etc.
+- `Context` – Why the decision was needed
+- `Decision` – What was decided and why
+- `Guidelines` – (Optional) How the decision should be applied
+- `Example` – (Optional) Minimal working example to clarify intent
+
+## Guidelines for contributing
+
+- We follow a simplified and slightly adapted version of the [Michael Nygard ADR format](https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/locales/en/templates/decision-record-template-by-michael-nygard)
+- Keep ADRs focused, short, and scoped to one decision
+- Start with `Status: Proposed` and update to `Status: Accepted` after code review
+- Use sequential filenames with a descriptive slug, for example: `0002-page-objects-pattern.md`