1. Purpose and validity of the methodology

• Responsibility for compliance: All project team members (QA engineers, UAT testers, Analysts, Developers) who report bugs to a central tracking tool (Jira, GitLab, HPALM, JunoOne).
• Zero tolerance rule: Defects that do not respect the mandatory structure of the Issue template will not be released by the "Bug Triage" process and will be immediately returned to the Rejected or Need More Info state by the development team.

2. Architecture and Mandatory Parameters of Issue Templates

Each reported defect must contain the following data blocks. Ignoring any of these blocks invalidates the entire report.

A. Issue Summary

The headline must not contain vague descriptions. They must immediately identify the affected component and the nature of the failure.

• Prescribed format: [Module_Name/Component] - Brief description of the failure and under what conditions it occurred
• Example of correct notation: [Order Façade] - API returns HTTP 500 Timeout when sending a payload over 5 MB

B. Prerequisites and Environment & Context

The code behaves differently across the infrastructure. To ensure reproducibility, it is necessary to define the exact state of the environment at the time of test execution.

• Version and Build: Exact designation of the deployed version
• Environment: Node and Environment Specifications
• Client Specifications: Browser Type, OS Version
• Test data: The user ID, test data, or password used under which the error occurred.

C. Reproduction sequence

The most important block of the template. It must contain a deterministic, step-by-step procedure for bringing the system into an error state from zero point.

• Steps must not contain assumptions. They must be exact actions.

D. Expected vs. Actual Result

Definition of a contract violation (SLA) or functional specification.

• Expected result: Must refer to an approved design or analytical document
• Actual result: Real system behavior at the time of the test

E. Evidence & Logs

A report without evidence is considered invalid. Depending on the level of testing, the following is required:

• Frontend/UI tests: Screenshots with the problem marked, or a video recording of the passage.
• Backend/API tests: A copy of the sent payload (JSON/XML), the exact error response of the server, or a log dump from the tool (Kibana / OpenSearch / Zabbix).

3. Implement the template

This template must be technically enforced (set as Default Description) at the project level in Jira/GitLab for the Bug/Defect task type.

### 1. Environment & Context
* **Environment:** [e.g., TEST-1 / PRE-PROD]
* **Build / Version:** [e.g., v.1.0.45]
* **Browser / OS (if applicable):** [e.g., Chrome 114 / Windows 11]
* **Test Data Used:** [e.g., user_ID: 987654321]

### 2. Steps to Reproduce
1. [Step 1: Navigate to / Call API endpoint...]
2. [Step 2: Insert data / Trigger action...]
3. [Step 3: ...]

### 3. Expected Result
* [Describe what should happen according to the documentation/design.]

### 4. Actual Result
* [Describe what actually happened. Be specific.]

### 5. Evidence & Attachments
* [Insert logs, screenshots, JSON payloads, or HTTP response headers here.]

4. Visual Diagram: The Anatomy of a Perfect Issue

This diagram visualizes the template structure itself – it shows what mandatory blocks a quality ticket consists of to provide developers with everything they need for a successful solution.