1. Účel a platnost metodiky

• Zodpovědnost za dodržování: Všichni členové projektového týmu (QA inženýři, UAT testeři, Analytici, Vývojáři), kteří reportují chyby do centrálního trackovacího nástroje (Jira, GitLab, HPALM, JunoOne).
• Pravidlo nulové tolerance: Defekty, které nerespektují povinnou strukturu Issue šablony, nebudou propuštěny procesem „Bug Triage“ a budou vývojovým týmem okamžitě vráceny do stavu Rejected nebo Need More Info.

2. Architektura a povinné parametry Issue Šablony

Každý reportovaný defekt musí obsahovat následující datové bloky. Ignorování kteréhokoliv z těchto bloků invaliduje celý report.

A. Issue Summary

Titulek nesmí obsahovat vágní popisy. Musí okamžitě identifikovat zasaženou komponentu a povahu selhání.

• Předepsaný formát: [Název_Modulu/Komponenty] - Stručný popis selhání a za jakých podmínek nastalo
• Příklad správného zápisu: [Order Façade] - API vrací HTTP 500 Timeout při odeslání payloadu nad 5 MB

B. Prerekvizity a identifikace prostředí (Environment & Context)

Kód se chová odlišně napříč infrastrukturou. Pro zajištění reprodukovatelnosti je nutné definovat exaktní stav prostředí v době exekuce testu.

• Verze a Build: Přesné označení nasazené verze
• Prostředí: Specifikace nodu a prostředí
• Klientské specifikace: Typ prohlížeče, verze OS
• Testovací data: ID uživatele, testovací data, nebo použité heslo, pod kterým k chybě došlo.

C. Sekvence reprodukce

Nejdůležitější blok šablony. Musí obsahovat deterministický, krok za krokem popsaný postup, jak uvést systém do chybového stavu od nulového bodu.

• Kroky nesmí obsahovat předpoklady. Musí jít o exaktní akce.

D. Expected vs. Actual Result

Definice porušení kontraktu (SLA) nebo funkční specifikace.

• Očekávaný výsledek: Musí odkazovat na schválený design nebo analytický dokument
• Skutečný výsledek: Reálné chování systému v době testu

E. Evidence & Logs

Report bez důkazů je považován za neplatný. V závislosti na úrovni testování je vyžadováno:

• Frontend/UI testy: Screenshoty s vyznačeným problémem, případně video záznam průchodu.
• Backend/API testy: Kopie zaslaného payloadu (JSON/XML), přesná chybová odpověď serveru, nebo výpis logu z nástroje (Kibana / OpenSearch / Zabbix).

3. Implementace šablony

Tato šablona musí být technicky vynucena (nastavena jako Default Description) na úrovni projektu v nástroji Jira / GitLab pro typ úkolu Bug / Defect.

### 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. Vizuální diagram: Anatomie dokonalého Issue

Tento diagram vizualizuje čistě samotnou strukturu šablony – ukazuje, z jakých povinných bloků se skládá kvalitní tiket, aby poskytl vývojářům vše potřebné pro úspěšné řešení.