QA 7: Test hujjatlari — Test Plan, Strategy, Checklist, Test Case va Traceability Matrix

🧪 QA Engineer — Zero to Hero

QA 7: Test hujjatlari — Test Plan, Strategy, Checklist, Test Case va Traceability Matrix

Holat: 2026-yil oktabr. Dars ISTQB CTFL v4.0.1 syllabus'ining 1.4.3 (testware), 1.4.4 (traceability), 5.1 (test plan, entry/exit criteria) va 5.3.2 (test hisobotlari) bo'limlariga tayanadi. Hujjat shablonlari ISO/IEC/IEEE 29119-3 g'oyalariga mos, lekin Agile jamoa uchun yengillashtirilgan. Barcha misollar xayoliy DemoBozor v2.0 relizi asosida.

Bu darsdan keyin siz: jamoa o'qiydigan, ishlatadigan va yangilab boradigan test hujjatlarini yozasiz — keraksiz qog'ozbozliksiz.

• test strategy va test plan'ni farqlaysiz va bir sahifalik test plan yozasiz;
• checklist va test case'ni qachon ishlatishni bilasiz, yaxshi test case yozasiz;
• test run statuslarini to'g'ri qo'llaysiz (Failed va Blocked farqi);
• traceability matrix tuzib, talablar qamrovini hisoblaysiz;
• reliz yakunida test completion report tayyorlaysiz.

Mundarija

1. Nega hujjatlashtiramiz
2. Test hujjatlari xaritasi
3. Test strategy va test plan
4. Namuna: DemoBozor v2.0 uchun bir sahifalik test plan
5. Checklist'lar
6. Test case anatomiyasi
7. Test suite, test run va statuslar
8. Requirements Traceability Matrix (RTM)
9. Test hisobotlari: progress va completion
10. Test management vositalari
11. Gherkin — tirik hujjat
12. Amaliy mashqlar
13. Xulosa
14. Manbalar

1. Nega hujjatlashtiramiz {#nega-hujjat}

Yangi QA ko'pincha ikki chekkaning biriga tushadi: yo hech narsa yozmaydi ("hammasi boshimda"), yo har bir tugma uchun 40 qadamli test case yozadi va uni hech kim o'qimaydi. Ikkalasi ham xato.

Test hujjatlari quyidagilar uchun kerak:

Qancha yozish kerak? Javob — kontekstga bog'liq (ISTQB'ning "testing is context dependent" printsipi, QA 2):

• startapdagi kichik Agile jamoa — yengil hujjatlar: bir sahifalik plan, checklist'lar, Jira'dagi acceptance criteria;
• to'lov tizimi, bank, tibbiyot — batafsil test case'lar, RTM, imzolangan hisobotlar;
• hamma joyda — bug report'lar va reliz yakunidagi hisobot albatta yoziladi.

🧠 Esda tuting: Hujjat — o'zi maqsad emas. Agar hujjatni hech kim o'qimasa va u yangilanmasa, u faqat vaqt o'g'irlaydi. Har bir hujjat uchun "buni kim, qachon o'qiydi?" deb so'rang.

2. Test hujjatlari xaritasi {#hujjatlar-xaritasi}

ISTQB har bir test faoliyati o'z ish mahsuloti — testware'ni yaratishini aytadi:

Test hujjatlari ierarxiyasi va traceability matrix

Rasmdagi asosiy g'oya: hujjatlar zanjir hosil qiladi. Talab → test case → natija → bug. Bu zanjir uzilmasa, istalgan savolga javob topiladi: "REQ-202 tekshirildimi?", "BUG-17 qaysi talabga ta'sir qiladi?", "Humo o'zgarsa qaysi testlarni qayta o'tkazamiz?"

3. Test strategy va test plan {#strategy-plan}

ISTQB bo'yicha test plan'ning odatiy mazmuni:

1. Test konteksti — scope, test maqsadlari, test basis.
2. Farazlar va cheklovlar.
3. Stakeholder'lar — rollar, mas'uliyat, yollash va o'qitish ehtiyojlari.
4. Muloqot — shakli, chastotasi, hujjat shablonlari.
5. Risk register — mahsulot va loyiha risklari.
6. Test yondashuvi — test darajalari va turlari, texnikalar, test deliverable'lar, entry va exit criteria, testning mustaqillik darajasi, yig'iladigan metrikalar, test data va muhit talablari, test siyosati yoki strategiyasidan chetlanishlar.
7. Byudjet va jadval.

Batafsil shablon va misollar ISO/IEC/IEEE 29119-3 standartida (u avvalgi IEEE 829 standartining o'rnini egallagan).

Entry va exit criteria alohida e'tiborga loyiq:

• Entry criteria — faoliyatni boshlash shartlari: resurslar (odamlar, muhit, test data) tayyor, testware (testlanadigan talablar, test case'lar) tayyor, test obyekti boshlang'ich sifatga ega (masalan, smoke testlar o'tgan).
• Exit criteria — faoliyat tugadi deyish shartlari: qamrov darajasi, ochiq bug'lar soni, bajarilmagan testlar va "ha/yo'q" shartlar (rejalashtirilgan testlar bajarildi, regression avtomatlashtirildi...).
• Agile'da exit criteria ko'pincha Definition of Done, entry criteria esa Definition of Ready deb ataladi.
• Vaqt yoki byudjet tugashi ham exit criteria bo'lishi mumkin — agar stakeholder'lar qolgan riskni ko'rib chiqib, qabul qilgan bo'lsa.

🎯 Intervyuda: "Test strategy va test plan farqi?" — Strategy tashkilot yoki mahsulot darajasidagi umumiy yondashuv va uzoq yashaydi; plan esa aniq reliz uchun scope, risk, jadval, resurs va entry/exit criteria'ni belgilaydi.

4. Namuna: DemoBozor v2.0 uchun bir sahifalik test plan {#test-plan-namuna}

Quyidagi plan Confluence, Notion yoki Google Docs'ga bir sahifaga sig'adi. Ko'p jamoalar uchun aynan shu hajm yetarli.

1. Kontekst va scope

• Reliz maqsadi: foizsiz muddatli to'lov, yangi promo-kod tizimi, Humo karta va kirill interfeysini chiqarish.
• Scope ichida (yangi): muddatli to'lov (3/6/12 oy, yosh 18–65, summa 500 000 – 30 000 000 so'm); promo-kod v2 (6–12 belgi, bir martalik); Humo bilan to'lov; o'zbek (kirill) interfeysi.
• Scope ichida (regression): SMS orqali kirish, katalog va qidiruv, savatcha, checkout, buyurtma holatlari.
• Scope tashqarisida: admin panel dizayni (v2.1 da), sotuvchi analitikasi, yuklama testi (alohida reja, QA 23).
• Test basis: Jira epic'lari DB-200…DB-230, Figma maketlari, API kontrakti (OpenAPI).

2. Farazlar va cheklovlar

• To'lov provayderining sandbox muhiti ish vaqtida ishlaydi.
• Kirill tarjimalari 13-noyabrgacha tayyor bo'ladi.
• Haqiqiy kartalar ishlatilmaydi — faqat provayder bergan test kartalar.

3. Stakeholder'lar va rollar

4. Muloqot

• Kunlik standup'da QA holati; seshanba va payshanba — bug triage.
• Kunlik progress — jamoa chatida; haftalik — PO'ga qisqa hisobot.

5. Risklar

6. Test yondashuvi

• Darajalar: system testing (funksional), API testing, E2E regression.
• Texnikalar: EP, BVA, decision table, state transition (QA 5, QA 6); har yangi funksiyaga kamida bitta exploratory sessiya.
• Avtomatlashtirish: mavjud Playwright regression to'plami har kecha staging'da ishlaydi (QA 21).
• Muhit: staging (staging.demobozor.example), to'lov sandbox'i; iOS — oxirgi ikki asosiy versiya; Android — analytics bo'yicha top-5 qurilma; web — Chrome, Safari, Firefox.
• Test data: test akkauntlar — yangi mijoz, Premium a'zo, bloklangan raqam; promo-kodlar BAHOR15 (15%), TEJA5 (5%), muddati o'tgan KUZ10.
• Entry criteria: build staging'da, smoke testlar o'tgan, story'larda acceptance criteria bor, test data tayyor.
• Exit criteria: P0/P1 test case'larning 100% i bajarilgan; pass rate ≥ 95%; ochiq Blocker va Critical bug yo'q; ochiq Major bug'lar uchun PO tasdiqlagan yechim yoki aylanma yo'l bor; regression to'plami yashil; 4 ta funksiyaning har biri bo'yicha exploratory sessiya o'tkazilgan.
• Metrikalar: bajarilish %, pass %, jiddiylik bo'yicha ochiq bug'lar, funksiya bo'yicha bug'lar soni, relizdan keyingi 2 haftada topilgan bug'lar.

7. Jadval va resurslar

Baholangan hajm: 18 kishi-kun.

💡 Maslahat: Plan'ni bir marta yozib unutmang. Scope yoki sana o'zgarganda versiyani oshiring va o'zgarishni bir qatorda izohlang. Eskirgan plan — plansizlikdan ham xavfli, chunki unga ishonishadi.

5. Checklist'lar {#checklistlar}

Checklist — tekshiriladigan shartlar ro'yxati, qadam-baqadam ko'rsatmalarsiz. U tajribali tester uchun tez va moslashuvchan. ISTQB tavsiyalari: band'lar ko'pincha savol ko'rinishida; har birini alohida va bevosita tekshirish mumkin; avtomatik tekshiriladigan, juda umumiy yoki entry/exit criteria'ga tegishli band'lar kiritilmaydi; checklist bug'lar tahlili asosida muntazam yangilanadi va haddan tashqari uzaymaydi.

Checklist: SMS orqali kirish (mobil)

• [ ] +998 va 9 raqamli raqamga SMS kod keladimi?
• [ ] SMS'dagi kod klaviatura ustida avtomatik taklif qilinadimi (iOS/Android autofill)?
• [ ] 012345 kabi boshida nol bo'lgan kod qabul qilinadimi?
• [ ] 120 soniyadan keyin kod "eskirgan" deb rad etiladimi?
• [ ] "Qayta yuborish" tugmasi 60 soniyagacha o'chiq turadimi?
• [ ] 3-noto'g'ri urinishdan keyin raqam 15 daqiqaga bloklanadimi va xabar tushunarlimi?
• [ ] Ilova fonga o'tib qaytganda kiritilgan raqam saqlanib qoladimi?
• [ ] Uch tilda (lotin, kirill, rus) barcha xabarlar to'liq ko'rinadimi?

Checklist: savatcha

• [ ] Miqdorni 1 dan kamaytirib bo'lmaydimi, 99 dan oshirib bo'lmaydimi?
• [ ] 51-xil mahsulot qo'shilganda tushunarli xabar chiqadimi?
• [ ] Narx o'zgargan mahsulot savatchada yangi narx bilan ko'rinadimi?
• [ ] Ilovadan chiqib, qayta kirganda savatcha saqlanadimi?
• [ ] Summa 300 000 so'mga yetganda (≥ 300 000) "Yetkazish bepul" yozuvi paydo bo'ladimi?

Yomon checklist band'lari va ularning tuzatilgani:

6. Test case anatomiyasi {#test-case}

Test case — aniq old shartlar, kiritishlar, qadamlar va kutilgan natijalar to'plami. U checklist'dan batafsilroq: boshqa odam ham xuddi shunday bajara oladi.

TC-AUTH-005: 3 noto'g'ri koddan keyin raqam 15 daqiqaga bloklanadi

Postcondition: test akkaunt 15 daqiqa bloklangan — keyingi testlar uchun boshqa akkaunt ishlating yoki blokni test hook bilan bekor qiling.

Yomon va yaxshi test case

YOMON:
Sarlavha: Login testi
Qadamlar: Ilovaga kiring va tekshiring.
Kutilgan: Hammasi ishlaydi.

Muammolar: sarlavha hech narsa demaydi; qaysi raqam, qaysi kod — noma'lum; "tekshiring" — harakat emas; "hammasi ishlaydi" — kuzatib bo'lmaydigan natija. Ikki xil tester buni ikki xil bajaradi.

YAXSHI:
ID: TC-AUTH-001
Sarlavha: To'g'ri SMS kod bilan birinchi urinishda kirish muvaffaqiyatli
Old shart: test akkaunt +998900000001, bloklanmagan; staging muhiti
Qadamlar:
  1. "Kirish" ekranida +998900000001 raqamini kiritib, "Kod olish"ni bosing
  2. Test SMS shlyuzidan kelgan 6 xonali kodni 120 soniya ichida kiriting
Kutilgan natija:
  1. Kod kiritish ekrani va 120 soniyalik taymer ko'rinadi
  2. Bosh sahifa ochiladi, profil ikonkasida foydalanuvchi ismi ko'rinadi

Test case yozish qoidalari

1. Bitta test case — bitta maqsad. "Login va savatcha" emas, ikkita alohida test.
2. Mustaqil. Boshqa testning natijasiga bog'liq bo'lmasin; kerakli holatni old shartda yarating.
3. Aniq ma'lumot. "Biror raqam" emas — +998900000001.
4. Kuzatiladigan natija. "To'g'ri ishlaydi" emas — "Xabar: ..., holat: ..., summa: ...".
5. Old shartlar qadam emas. "Tizimga kiring" — agar test login haqida bo'lmasa, old shartga yozing.
6. Tushunarli sarlavha: [Funksiya] — [Shart] — [Natija].
7. Qisqa. Qadamlar soni 10–12 tadan oshsa, testni bo'lish haqida o'ylang.
8. UI tafsilotlariga ortiqcha bog'lanmang. "Ko'k tugma" emas, "Kod olish" tugmasi.
9. Talabga bog'lang. Bog'lanmagan test — yo ortiqcha, yo talab yozilmagan.

🎯 Intervyuda: "Checklist va test case farqi?" — Checklist nimani tekshirish kerakligini qisqa band'lar bilan beradi va tajribali testerga erkinlik qoldiradi; test case esa old shart, aniq data, qadamlar va kutilgan natija bilan takrorlanuvchanlikni ta'minlaydi. Kritik va regulyatsiya qilinadigan funksiyalarga — test case, qolganiga ko'pincha checklist yetarli.

7. Test suite, test run va statuslar {#suite-run}

Statuslar (nomlari vositaga qarab biroz farq qiladi):

Failed va Blocked farqi — eng ko'p chalkashtiriladigan joy. Failed — test bajarildi va bug topildi. Blocked — test umuman bajarilmadi. Agar Humo sandbox ishlamasa, Humo testlari Blocked, Failed emas: aks holda hisobotda "Humo to'lovi buzilgan" degan noto'g'ri xulosa chiqadi.

8. Requirements Traceability Matrix (RTM) {#rtm}

Traceability — test basis elementlari (talablar, risklar), testware, natijalar va bug'lar o'rtasidagi bog'lanish. ISTQB bo'yicha u qamrovni baholash, o'zgarish ta'sirini aniqlash, auditdan o'tish va hisobotlarni tushunarli qilish uchun kerak.

RTM — bu bog'lanishni jadval ko'rinishida ko'rsatadi. DemoBozor v2.0 uchun:

Ikki yo'nalish:

• Forward (talab → test): har bir talabning testi bormi? REQ-230 ning testi yo'q — qamrovda teshik.
• Backward (test → talab): har bir test qaysidir talabga xizmat qiladimi? TC-999 hech qaysi talabga bog'lanmagan — yo talab yozilmay qolgan, yo test ortiqcha. PO'dan so'raymiz.

Talablar qamrovi: testi bor talablar / jami talablar = 6 / 7 ≈ 85,7%. Exit criteria'da odatda 100% talab qilinadi — demak REQ-230 uchun test yozilmaguncha reliz tayyor emas.

💡 Maslahat: RTM'ni qo'lda Excel'da yuritish katta loyihada tez eskiradi. Jira + test management vositasida (Xray, Zephyr, TestRail, Qase) test case'ni story'ga bog'lasangiz, matritsa avtomatik hosil bo'ladi.

9. Test hisobotlari: progress va completion {#hisobotlar}

ISTQB ikki turdagi hisobotni ajratadi:

Kunlik progress (jamoa chatiga):

QA holati — v2.0, 18-noyabr
Bajarildi: 162/240 (67%) · Passed 151 · Failed 6 · Blocked 5
Yangi bug'lar: 4 (Major 1, Minor 3) · Ochiq Critical: 0
To'siq: Humo sandbox 10:00 dan beri ishlamaydi -> 5 test Blocked,
        provayderga murojaat qilindi (DevOps)
Ertaga: promo-kod regression, kirill interfeysi bo'yicha exploratory sessiya

Test completion report: DemoBozor v2.0 (qisqartirilgan)

⚠️ Diqqat: "Pass rate 96%" degan raqamning o'zi hech narsa demaydi. Qolgan 4% ichida to'lov bug'i bo'lsa, reliz xavfli. Shuning uchun hisobotda doim ochiq bug'lar jiddiyligi va qolgan risklar bo'ladi.

10. Test management vositalari {#vositalar}

Vosita tanlashda narx (rasmiy saytdan tekshiring — tariflar tez-tez o'zgaradi), Jira bilan integratsiya, avtomatik testlar natijasini (masalan, JUnit XML) import qilish, API va hisobotlar sifatiga qarang.

11. Gherkin — tirik hujjat {#gherkin}

Acceptance criteria'ni Gherkin formatida yozish (QA 3) bir vaqtda uchta vazifani bajaradi: talab, test case va — Cucumber yoki playwright-bdd kabi vositalar bilan — avtomatik test. Shuning uchun uni "tirik hujjat" (living documentation) deyishadi: kod o'zgarib, hujjat eskirsa, test yiqiladi va buni darhol ko'rasiz.

QA 5 dagi promo-kod chegaralari Gherkin'da:

Feature: Promo-kod formati
  Rule: Promo-kod 6–12 belgidan iborat, faqat A–Z va 0–9

    Scenario Outline: Uzunlik chegaralari
      Given xaridor savatchasida 350 000 so'mlik mahsulot bor
      When u "<kod>" promo-kodini kiritadi
      Then tizim "<natija>" deb javob beradi

      Examples:
        | kod           | natija                           |
        | BAHOR         | Promo-kod 6–12 belgidan iborat   |
        | BAHOR1        | Format to'g'ri                   |
        | ABCDEF123456  | Format to'g'ri                   |
        | ABCDEF1234567 | Promo-kod 6–12 belgidan iborat   |

Examples jadvalidagi har bir qator — alohida test case: 5, 6, 12 va 13 belgili kodlar, ya'ni 2-value BVA.

12. Amaliy mashqlar {#mashqlar}

Mashq 1: talabdan test case'lar

Talab: "Xaridor faqat o'ziga tegishli va DELIVERED holatidagi buyurtma mahsulotiga sharh qoldira oladi. Baho — 1 dan 5 gacha yulduz, matn — 10 dan 1000 belgigacha." Kamida 5 ta test case yozing (ID, sarlavha, asosiy ma'lumot, kutilgan natija).

<details> <summary>💡 Javobni ko'rish</summary>

TC-REV-02…04 — BVA, TC-REV-06 — state, TC-REV-07 — avtorizatsiya (xavfsizlik). Bitta talabdan kamida uch xil texnika chiqdi.

</details>

Mashq 2: yomon test case'ni tuzating

Sarlavha: Promo-kodni tekshirish
Qadamlar: 1. Saytga kiring. 2. Mahsulot qo'shing. 3. Promo kiriting.
          4. Buyurtma bering va to'lovni tekshiring.
Kutilgan: Chegirma to'g'ri.

Muammolarni sanang va to'g'ri variantini yozing.

<details> <summary>💡 Javobni ko'rish</summary>

Muammolar: sarlavha umumiy; qaysi akkaunt va mahsulot — noma'lum; "promo kiriting" — qaysi kod?; 4-qadamda ikkita maqsad (buyurtma va to'lov); "chegirma to'g'ri" — kuzatib bo'lmaydi, raqam yo'q; talab bilan bog'lanmagan.

ID: TC-210-03
Sarlavha: Amaldagi 15% li promo-kod 250 000 so'mlik savatchaga to'g'ri qo'llanadi
Talab: REQ-210, REQ-211
Old shart: eski mijoz (Premium emas), savatchada 250 000 so'mlik mahsulot,
           BAHOR15 kodini bu akkaunt oldin ishlatmagan
Qadamlar:
  1. Checkout sahifasida promo-kod maydoniga BAHOR15 ni kiriting, "Qo'llash"ni bosing
Kutilgan natija:
  1. Chegirma: -37 500 so'm; yetkazish: 20 000 so'm; jami: 232 500 so'm;
     "Promo-kod qo'llandi" xabari

To'lov va buyurtma yaratish — alohida test case'lar.

</details>

Mashq 3: RTM va qamrov

Talablar: REQ-1 (SMS kod 6 raqam), REQ-2 (kod 120 s amal qiladi), REQ-3 (3 xatodan keyin blok), REQ-4 (qayta yuborish 60 s dan keyin). Test case'lar: TC-A → REQ-1; TC-B → REQ-1, REQ-2; TC-C → REQ-3; TC-D → hech qaysi talabga bog'lanmagan ("Kodni ovozli qo'ng'iroq orqali olish"). RTM tuzing, qamrovni hisoblang va muammolarni ko'rsating.

<details> <summary>💡 Javobni ko'rish</summary>

• Talablar qamrovi: 3 / 4 = 75%. REQ-4 ning testi yo'q (forward traceability'dagi teshik).
• TC-D talabsiz (backward traceability muammosi): yo "ovozli qo'ng'iroq" funksiyasi talablarga yozilmay qolgan, yo test ortiqcha. PO bilan aniqlashtirish kerak.
• Qo'shimcha kuzatuv: REQ-2 faqat bitta testda va u REQ-1 bilan aralash — TC-B yiqilsa, qaysi talab buzilganini darhol bilib bo'lmaydi.

</details>

Mashq 4: Failed yoki Blocked?

Har bir holatga status qo'ying: a) Promo-kod qo'llandi, lekin chegirma 10% bo'ldi (kutilgan 15%). b) Staging'da login sahifasi 502 qaytaradi — checkout testlariga yetib bo'lmaydi. c) Test Android uchun yozilgan, lekin bu run faqat iOS uchun. d) BUG-517 tuzatildi, staging'ga deploy qilindi. e) Test case'dagi kutilgan natija eskirgan — talab o'zgargan, ilova yangi talab bo'yicha to'g'ri ishlayapti.

<details> <summary>💡 Javobni ko'rish</summary>

</details>

Mashq 5: hotfix uchun exit criteria

DemoBozor v2.0.1 hotfix: faqat BUG-517 (muddatli to'lov summasi chegarasi) tuzatildi. 5 ta exit criteria yozing.

<details> <summary>💡 Javobni ko'rish</summary>

1. BUG-517 bo'yicha confirmation test o'tdi (499 999, 500 000, 30 000 000, 30 000 001 qiymatlari — BVA).
2. Muddatli to'lov bo'yicha regression to'plami (TC-201…203) 100% o'tdi.
3. Avtomatik smoke to'plami (checkout, login, to'lov) yashil.
4. Yangi Blocker yoki Critical bug yo'q.
5. Production'da reliz'dan keyin 1 soat ichida monitoringda xatolar soni oshmagani tekshiriladi (shift-right).

Hotfix uchun to'liq regression shart emas — o'zgarish atrofidagi risk bo'yicha tor regression yetarli. Lekin bu qaror rejada yozilishi kerak.

</details>

Mashq 6: checklist'ni tozalang

Quyidagi band'lardan qaysilari checklist'ga mos emas va nega? 1) "Qidiruv ishlaydimi?" 2) "2 belgilik so'rov bilan natijalar chiqadimi?" 3) "Unit testlar CI'da o'tdimi?" 4) "Ilova chiroyli ko'rinadimi?" 5) "Bo'sh natijada 'Hech narsa topilmadi' xabari va tavsiyalar chiqadimi?"

<details> <summary>💡 Javobni ko'rish</summary>

• 1 — juda umumiy: nimani tekshirish kerakligi noaniq. Aniq band'larga bo'ling.
• 2 — yaxshi: savol, bevosita tekshiriladi, chegara qiymati.
• 3 — avtomatik tekshiriladi va entry criteria'ga xos; checklist'ga kiritilmaydi.
• 4 — subyektiv, tekshirib bo'lmaydi. O'rniga: "Matnlar 3 tilda kesilmasdan ko'rinadimi?", "Maket bilan ranglar mosmi?"
• 5 — yaxshi.

</details>

Xulosa {#xulosa}

• Hujjat — muloqot, qamrov va takrorlanuvchanlik vositasi. Hajmi kontekstga bog'liq: startapda yengil, fintech'da batafsil.
• Strategy — tashkilot darajasidagi umumiy yondashuv; plan — aniq reliz uchun scope, risk, jadval, rollar va entry/exit criteria.
• Checklist — tez va moslashuvchan; test case — aniq data va kuzatiladigan natija bilan takrorlanuvchan.
• Failed — bug topildi; Blocked — test bajarilmadi. Ularni chalkashtirish hisobotni buzadi.
• RTM forward va backward traceability bilan qamrovdagi teshiklar va ortiqcha testlarni ko'rsatadi.
• Completion report raqamlar bilan birga ochiq bug'lar, qolgan risklar va saboqlarni beradi.
• Keyingi dars: QA 8: Bug report va Bug Life Cycle — Severity vs Priority, Jira va yaxshi bug yozish san'ati

Manbalar {#manbalar}

1. ISTQB — Certified Tester Foundation Level Syllabus v4.0.1 (PDF)
2. Wikipedia — ISO/IEC 29119
3. Wikipedia — Software test documentation (IEEE 829)
4. Cucumber — Gherkin reference
5. TestRail
6. Qase
7. Zephyr (SmartBear)
8. Xray
9. Qameta — Allure TestOps
10. TestLink