Jira

1. Co je Jira?

Jira je nástroj od společnosti :contentReference[oaicite:0]{index=0} používaný pro řízení práce, vývoje software, správu úkolů, sledování chyb (bugů) a organizaci práce v agilních týmech. Nejčastěji se používá ve Scrum nebo Kanban týmech.

V QA oblasti Jira slouží hlavně pro:

  • evidenci bugů a jejich životního cyklu,
  • sledování user stories a acceptance criteria,
  • správu sprintů a release plánů,
  • komunikaci mezi QA, vývojem, Product Ownerem a managementem,
  • traceability mezi požadavky, testy a releasy.

K čemu se Jira používá v QA?

  • čtení zadání funkcionalit,
  • kontrola acceptance criteria,
  • zakládání bug reportů,
  • komunikace s developery a analytiky,
  • sledování release verzí,
  • přidávání evidence z testování,
  • správa testovacích tasků,
  • sledování průběhu sprintu.

2. Základní pojmy v Jira

Issue

Obecné označení pro položku v Jira. Může to být:

  • Story – funkcionalita z pohledu uživatele
  • Bug – chyba v aplikaci
  • Task – obecný úkol
  • Sub-task – menší část většího úkolu
  • Epic – větší celek obsahující více stories
  • Spike – technický nebo analytický průzkum

User Story

User story popisuje požadavek z pohledu uživatele.

As a customer,
I want to save my payment card,
So that I can pay faster next time.

Acceptance Criteria

Podmínky, které musí být splněny, aby byla funkcionalita považována za hotovou.

- User can save Visa and Mastercard
- Card number is masked
- Invalid card shows validation error
- Saved card appears after next login

Acceptance criteria jsou základ pro přípravu testů a ověření funkcionality.

3. Agile, Scrum a sprinty

Scrum sprint

Sprint je časově omezené období (například 2 týdny), během kterého tým doručuje funkcionality.

Typický průběh sprintu:

  • Sprint Planning
  • Development
  • Testing
  • Bug fixing
  • Regression testing
  • Sprint Review
  • Retrospective

Kanban

Kanban používá kontinuální tok práce bez sprintů. Tickety se přesouvají mezi stavy podle aktuálního průběhu.

4. Workflow v Jira

Workflow určuje životní cyklus ticketu.

Typické workflow:

  • To Do – úkol čeká na práci
  • In Progress – vývoj probíhá
  • Code Review – kontrola kódu
  • Ready for Testing – připraveno pro QA
  • In Testing – probíhá testování
  • Blocked – něco brání pokračování
  • Done – hotovo
  • Reopened – problém se vrátil

Co znamená Blocked?

Testování nebo vývoj nemůže pokračovat například protože:

  • nefunguje prostředí,
  • chybí data,
  • API vrací chybu,
  • funkcionalita není nasazená,
  • existuje kritický blocker bug.

5. Priority vs Severity

Severity

Jak moc chyba ovlivňuje systém.

  • Critical – pád aplikace, ztráta dat
  • High – důležitá funkcionalita nefunguje
  • Medium – částečný problém
  • Low – kosmetická chyba

Priority

Jak rychle musí být chyba opravena.

  • Highest
  • High
  • Medium
  • Low
  • Lowest

Severity většinou určuje QA nebo technický tým, priority často Product Owner nebo business.

6. Jak správně reportovat bug

Dobrý bug report musí být:

  • jasný,
  • reprodukovatelný,
  • stručný,
  • technicky přesný,
  • bez emocí.

Špatný příklad

"Payment nefunguje."

Takový bug neposkytuje dostatek informací.

Správná struktura bug reportu

  • Summary – stručný popis
  • Environment – build, OS, browser, device
  • Preconditions – co musí být splněno
  • Steps to reproduce – kroky reprodukce
  • Expected result
  • Actual result
  • Severity
  • Attachments – screenshoty, logy, videa

7. Ukázka profesionálního bug reportu

Summary:
Wallet payment is displayed as successful while provider status is PENDING.

Environment:
- Android 15
- Samsung S23
- App build 4.8.1
- Production EU region

Preconditions:
User has valid wallet account and sufficient balance.

Steps to reproduce:
1. Log in as retail customer
2. Open Wallet
3. Start payment for EUR 120
4. Confirm payment with Face ID
5. Observe payment result screen

Expected result:
Application displays Pending authorization state until provider confirms payment.

Actual result:
Application immediately displays Payment successful.

Severity:
High

Priority:
High

Attachments:
video.mp4
network-response.json
screenshot.png

8. Práce s Jira boardem

Scrum board

Scrum board se používá pro sprinty.

  • Backlog
  • Sprint backlog
  • Active sprint
  • Burndown chart

Kanban board

Kanban board sleduje kontinuální tok práce bez sprintů.

Co lze na boardu sledovat?

  • stav ticketů,
  • blokery,
  • rozpracovanou práci,
  • kapacitu týmu,
  • progress sprintu.

9. JQL (Jira Query Language)

JQL slouží k vyhledávání ticketů.

Základní příklady:

project = PAYMENTS

status = "In Testing"

assignee = currentUser()

priority = High

type = Bug

project = PAYMENTS AND status != Done

project = PAYMENTS AND assignee = currentUser()

project = PAYMENTS AND sprint in openSprints()

text ~ "payment"

Pokročilejší příklady:

project = PAYMENTS
AND type = Bug
AND severity = Critical
AND status != Done

project = MOBILE
AND fixVersion = "5.8"
AND labels = regression

updated >= -7d

reporter = currentUser()

status CHANGED TO "Ready for Testing" AFTER -1d

K čemu je JQL užitečné?

  • vyhledávání otevřených bugů,
  • sledování regression bugů,
  • filtrování release ticketů,
  • kontrola blockerů,
  • vytváření dashboardů.

10. Evidence a debugging

Co přikládat do bugů:

  • screenshoty,
  • video z reprodukce,
  • console log,
  • network log,
  • HAR soubor,
  • API response,
  • stack trace.

Nástroje často používané s Jira:

  • Chrome DevTools
  • Postman
  • Charles Proxy
  • Fiddler
  • BrowserStack
  • TestRail
  • Xray
  • Confluence

11. Jira a test management

Mnoho firem propojuje Jira s test management nástroji:

  • Xray
  • Zephyr
  • TestRail

Díky tomu lze:

  • psát test cases,
  • spouštět test runs,
  • evidovat výsledky testů,
  • propojovat testy s bugy a stories,
  • sledovat test coverage.

12. Regression testing

Regression testing ověřuje, že nová změna nerozbila staré funkcionality.

Příklad:

Vývojář upraví login přes Google. Je potřeba ověřit:

  • standard login,
  • Apple login,
  • reset hesla,
  • MFA,
  • session timeout.

13. Release testing

Před produkčním releasem se často provádí:

  • smoke testing,
  • sanity testing,
  • regression testing,
  • exploratory testing.

Smoke testing

Rychlá kontrola, že aplikace je vůbec použitelná.

Sanity testing

Kontrola konkrétní opravené oblasti.

Exploratory testing

Volnější testování založené na zkušenosti a hledání nečekaných problémů.

14. Edge cases a negativní testování

Příklady edge cases:

  • prázdné pole,
  • extrémně dlouhý text,
  • speciální znaky,
  • neplatný formát dat,
  • duplicitní requesty,
  • timeout API,
  • výpadek internetu během akce.

Příklad negativního testu:

Expected:
User cannot register with invalid email format.

15. Traceability

Traceability znamená propojení:

  • business požadavků,
  • user stories,
  • test cases,
  • bugů,
  • release verzí.

Díky tomu lze dohledat:

  • co bylo testováno,
  • co bylo opraveno,
  • který release obsahuje fix,
  • jaké testy pokrývají funkcionalitu.

16. Root Cause Analysis (RCA)

Root Cause Analysis hledá skutečnou příčinu problému.

Příklad:

Bug se projeví ve frontend aplikaci, ale skutečný problém je:

  • v API,
  • v databázi,
  • v cache,
  • v konfiguraci prostředí,
  • v timeoutu externí služby.

17. API testing a Jira

Bugy často nevznikají pouze ve frontend UI.

QA často kontroluje:

  • HTTP status codes,
  • response body,
  • JSON schema,
  • response time,
  • authorization,
  • error messages.

Nejčastější status codes:

  • 200 OK
  • 201 Created
  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found
  • 500 Internal Server Error

18. Nejčastější chyby při reportování bugů

  • Neúplné kroky reprodukce
  • Chybějící evidence
  • Nesprávně určená severity
  • Testování pouze happy path
  • Nedostatečné ověření edge cases
  • Zapomenuté regression testy
  • Příliš obecné komentáře
  • Nesledování acceptance criteria

19. Doporučení pro QA práci v Jira

  • Piš bugy tak, aby byly srozumitelné bez dalšího vysvětlení.
  • Vždy ověřuj reprodukovatelnost chyby.
  • Testuj i negativní scénáře.
  • Přemýšlej jako uživatel.
  • Komunikuj stručně a profesionálně.
  • Používej logy a DevTools.
  • Sleduj celý flow aplikace, nejen jednu obrazovku.
  • Kontroluj edge cases.
  • Ověřuj fixy i regresi.
  • Průběžně aktualizuj status ticketů.

20. Nejčastější interview otázky na Jira a QA

Jaký je rozdíl mezi bugem a story?

Story popisuje novou funkcionalitu, bug popisuje chybu.

Co je severity?

Dopad chyby na systém nebo uživatele.

Co je priority?

Jak rychle musí být chyba opravena.

Co je regression testing?

Ověření, že nová změna nerozbila existující funkcionalitu.

Co je smoke test?

Základní rychlé ověření hlavních funkcí aplikace.

Co je sanity test?

Kontrola konkrétní opravené oblasti.

Co je exploratory testing?

Volnější testování zaměřené na hledání neočekávaných problémů.

Co je JQL?

Dotazovací jazyk pro vyhledávání ticketů v Jira.

Jak by měl vypadat kvalitní bug report?

Musí obsahovat jasné kroky reprodukce, expected/actual result, prostředí a evidence.

Jaký je rozdíl mezi verification a validation?

Verification kontroluje, zda byl systém vytvořen správně. Validation kontroluje, zda systém řeší správný business problém.

tisk | prohlášení o přístupnosti | mapa webu

Eucitel.cz - Elektronický učitel - výukové programy pro učitele a žáky
© 2021 Jan Vejmola | Všechna práva vyhrazena.