# 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](#nega-hujjat) 2. [Test hujjatlari xaritasi](#hujjatlar-xaritasi) 3. [Test strategy va test plan](#strategy-plan) 4. [Namuna: DemoBozor v2.0 uchun bir sahifalik test plan](#test-plan-namuna) 5. [Checklist'lar](#checklistlar) 6. [Test case anatomiyasi](#test-case) 7. [Test suite, test run va statuslar](#suite-run) 8. [Requirements Traceability Matrix (RTM)](#rtm) 9. [Test hisobotlari: progress va completion](#hisobotlar) 10. [Test management vositalari](#vositalar) 11. [Gherkin — tirik hujjat](#gherkin) 12. [Amaliy mashqlar](#mashqlar) 13. [Xulosa](#xulosa) 14. [Manbalar](#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: | Maqsad | Hujjatsiz nima bo'ladi | | ---------------------- | ------------------------------------------------------------- | | **Muloqot** | PO "nimani testlayapsiz?" deb so'rasa, aniq javob yo'q | | **Qamrov nazorati** | Qaysi talab tekshirilmay qolganini hech kim bilmaydi | | **Takrorlanuvchanlik** | Regression'ni har safar boshqacha, eslab qolganicha qilasiz | | **Yangi xodim** | Yangi QA ikki hafta "nimani bosish kerak"ligini so'rab yuradi | | **Audit va tartib** | Fintech yoki tibbiyot loyihasida tekshiruvdan o'tolmaysiz | **Qancha yozish kerak?** Javob — kontekstga bog'liq (ISTQB'ning "testing is context dependent" printsipi, [QA 2](/ios-lessons/qa-principles-istqb)): - 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: | Faoliyat | Testware (ish mahsulotlari) | | --------------------- | ------------------------------------------------------------------------------------------------------------ | | Rejalashtirish | Test plan, jadval, risk register, entry/exit criteria | | Monitoring va nazorat | Test progress report'lar, boshqaruv qarorlari | | Tahlil | Prioritetlangan test condition'lar (masalan, acceptance criteria) | | Dizayn | Test case'lar, test charter'lar, coverage item'lar, test data va muhit talablari | | Implementatsiya | Test procedure'lar, manual va avtomatik skriptlar, test suite'lar, test data, muhit elementlari (stub, mock) | | Bajarish | Test log'lar, defect report'lar | | Yakunlash | Test completion report, takomillashtirish bo'yicha vazifalar, olingan saboqlar | ![Test hujjatlari ierarxiyasi va traceability matrix](/lessons/images/qa/qa_07_test_artifacts.svg) 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} | | Test strategy | Test plan | | ---------- | -------------------------------------------------------------------------------- | ----------------------------------------------------- | | **Daraja** | Tashkilot yoki mahsulot | Aniq loyiha yoki reliz | | **Umri** | Uzoq (yillab) | Reliz tugaguncha | | **Savol** | "Biz umuman qanday testlaymiz?" | "Shu relizni qanday, qachon, kim bilan testlaymiz?" | | **Mazmun** | Test darajalari, avtomatlashtirish yondashuvi, vositalar, muhitlar, bug jarayoni | Scope, risklar, jadval, odamlar, entry/exit criteria | | **Misol** | "API va E2E testlar CI'da har PR'da ishlaydi" | "v2.0 uchun muddatli to'lov 9–20 noyabrda testlanadi" | 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. | Maydon | Qiymat | | ------------------- | ------------------------------------- | | **Hujjat** | TP-DB-2.0 — Test plan, DemoBozor v2.0 | | **Versiya / holat** | 1.1 / Tasdiqlangan | | **Muallif** | QA Lead | | **Tasdiqladi** | Product Owner | | **Sana** | 2026-yil 30-oktabr | **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](/ios-lessons/qa-performance-k6)). - **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** | Rol | Mas'uliyat | | --------------------- | -------------------------------------------------------- | | QA Lead | Plan, risklar, kunlik holat, completion report | | QA muhandis (2 nafar) | Test dizayni, bajarish, bug report, avtomatik regression | | Dasturchilar | Unit testlar, bug tuzatish, staging'ga deploy | | Product Owner | Acceptance criteria, ustuvorlik, go/no-go qarori | | DevOps | Staging muhiti, test data, monitoring | **4. Muloqot** - Kunlik standup'da QA holati; seshanba va payshanba — bug triage. - Kunlik progress — jamoa chatida; haftalik — PO'ga qisqa hisobot. **5. Risklar** | Risk | Ehtimol | Ta'sir | Choralar | | ------------------------------------------- | ------- | ------ | ------------------------------------------------------------------------------------- | | Muddatli to'lov grafigida yaxlitlash xatosi | O'rta | Yuqori | Decision table + BVA; 3 xil summa uchun qo'lda hisoblangan kutilgan natija | | Humo sandbox beqaror | Yuqori | O'rta | Testlarni erta boshlash; provayder bilan aloqa; mock | | Kirill tarjimasi kechikadi | O'rta | O'rta | Psevdo-lokalizatsiya bilan erta tekshiruv ([QA 25](/ios-lessons/qa-a11y-l10n-visual)) | | Promo-kodni qayta ishlatish (pul yo'qotish) | O'rta | Yuqori | Parallel so'rovlar bilan test ([QA 24](/ios-lessons/qa-security)) | **6. Test yondashuvi** - **Darajalar:** system testing (funksional), API testing, E2E regression. - **Texnikalar:** EP, BVA, decision table, state transition ([QA 5](/ios-lessons/qa-test-design-1), [QA 6](/ios-lessons/qa-test-design-2)); har yangi funksiyaga kamida bitta exploratory sessiya. - **Avtomatlashtirish:** mavjud Playwright regression to'plami har kecha staging'da ishlaydi ([QA 21](/ios-lessons/qa-ci-cd)). - **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** | Bosqich | Sana | | ----------------------------- | ------------ | | Test dizayni, test data | 2–6 noyabr | | Funksional test va bug'lar | 9–20 noyabr | | Regression, release candidate | 23–26 noyabr | | Reliz | 27 noyabr | 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: | Yomon | Muammo | Yaxshi | | -------------------------- | ----------------------- | ---------------------------------------- | | "Login ishlaydi" | Juda umumiy | "To'g'ri SMS kod bilan kirish mumkinmi?" | | "Hamma narsani tekshirish" | Tekshirib bo'lmaydi | Aniq band'larga bo'lish | | "Build staging'da" | Bu entry criteria | Checklist'dan olib tashlash | | "Lint xatolari yo'q" | CI avtomatik tekshiradi | Checklist'dan olib tashlash | --- ## 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. | Maydon | Ma'nosi | Misol | | --------------------- | ---------------------------- | ------------------------------------------------------- | | **ID** | Noyob raqam | `TC-AUTH-005` | | **Sarlavha** | Nima va qaysi sharoitda | "3 noto'g'ri koddan keyin raqam 15 daqiqaga bloklanadi" | | **Modul / komponent** | Qayerga tegishli | Autentifikatsiya | | **Talab** | Bog'langan talab yoki story | `DB-104` | | **Ustuvorlik** | Bajarish tartibi | P1 | | **Turi** | Pozitiv / negativ / chegara | Negativ | | **Old shartlar** | Testdan oldin bo'lishi shart | Test akkaunt `+998 90 000 00 05` bloklanmagan | | **Test data** | Aniq qiymatlar | Noto'g'ri kod: `111111` | | **Qadamlar** | Raqamlangan harakatlar | Pastdagi jadval | | **Kutilgan natija** | Kuzatiladigan, aniq natija | Pastdagi jadval | | **Holat** | Oxirgi run natijasi | Passed / Failed / ... | **TC-AUTH-005: 3 noto'g'ri koddan keyin raqam 15 daqiqaga bloklanadi** | # | Qadam | Kutilgan natija | | --- | ----------------------------------------------------------------------- | -------------------------------------------------------- | | 1 | Ilovani oching, `+998900000005` raqamini kiriting, "Kod olish"ni bosing | Kod kiritish ekrani, 120 soniyalik taymer | | 2 | `111111` kodini kiriting | "Kod noto'g'ri. 2 ta urinish qoldi" | | 3 | `222222` kodini kiriting | "Kod noto'g'ri. 1 ta urinish qoldi" | | 4 | `333333` kodini kiriting | "Raqam 15 daqiqaga bloklandi" xabari, kod maydoni o'chiq | | 5 | Ilovani yopib qayta oching, shu raqamga kod so'rang | Kod yuborilmaydi, qolgan blok vaqti ko'rsatiladi | Postcondition: test akkaunt 15 daqiqa bloklangan — keyingi testlar uchun boshqa akkaunt ishlating yoki blokni test hook bilan bekor qiling. ### Yomon va yaxshi test case ```text 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. ```text 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} | Tushuncha | Ma'nosi | Misol | | -------------------- | --------------------------------------------- | -------------------------------------- | | **Test suite** | Maqsad bo'yicha guruhlangan test'lar to'plami | "Checkout regression", "Smoke — 25 ta" | | **Test run / cycle** | Suite'ni aniq build va muhitda bajarish | "v2.0.0 (412), staging, 18-noyabr" | | **Test log** | Bajarish yozuvlari | Kim, qachon, qaysi build, natija, izoh | Statuslar (nomlari vositaga qarab biroz farq qiladi): | Status | Qachon qo'yiladi | | ---------------------- | ------------------------------------------------------------------------------------------------ | | **Passed** | Haqiqiy natija kutilganga to'liq mos | | **Failed** | Haqiqiy natija kutilgandan farq qiladi → bug report | | **Blocked** | Testni bajarib bo'lmaydi: muhit ishlamaydi, oldingi qadamdagi bug yo'lni to'sgan, test data yo'q | | **Skipped** | Ongli ravishda o'tkazib yuborildi (scope'dan tashqari, platformaga tegishli emas) | | **Not run / Untested** | Hali bajarilmagan | | **Retest** | Bug tuzatildi, qayta tekshirish kerak | **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: | Talab | Tavsif | Test case'lar | Natija | Bug'lar | | ------- | ------------------------------------------- | ------------------------------- | ------------ | ------------------ | | REQ-201 | Muddatli to'lov: yosh 18–65 | TC-201-01…06 | ✅ Passed | — | | REQ-202 | Muddatli to'lov: summa 500 000 – 30 000 000 | TC-202-01…06 | ❌ Failed | BUG-517 | | REQ-203 | Muddatli to'lov: 3/6/12 oy | TC-203-01…04 | ✅ Passed | — | | REQ-210 | Promo-kod: 6–12 belgi, A–Z va 0–9 | TC-210-01…08 | ✅ Passed | — | | REQ-211 | Promo-kod har foydalanuvchiga bir marta | TC-211-01…03 | ⚠️ Blocked | — | | REQ-220 | Humo bilan to'lov | TC-220-01…05 | ✅ Passed | BUG-498 (yopilgan) | | REQ-230 | Interfeys kirill alifbosida | — | ⛔ Test yo'q | — | | — | — | TC-999 "Apple Pay bilan to'lov" | Not run | — | **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: | | Test progress report | Test completion report | | ---------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Qachon** | Muntazam: har kuni yoki haftada | Bir marta: reliz, daraja yoki sikl tugaganda | | **Mazmun** | Davr, progress va chetlanishlar, to'siqlar va aylanma yo'llar, metrikalar, yangi risklar, keyingi davr rejasi | Xulosa, plan va exit criteria bo'yicha baho, plandan chetlanishlar, to'siqlar, metrikalar, yopilmagan risk va bug'lar, olingan saboqlar | | **Uslub** | Qisqa, norasmiy | Shablon bo'yicha, rasmiyroq | **Kunlik progress (jamoa chatiga):** ```text 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)** | Bo'lim | Mazmun | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | **Xulosa** | Reliz testlari 26-noyabrda yakunlandi. Exit criteria bajarildi. Tavsiya: **Go**, ma'lum muammolar ro'yxati bilan | | **Test case'lar** | Jami 240: Passed 221, Failed 9, Blocked 6, Not run 4 (hammasi P3) | | **Bajarilish** | 230/240 = 95,8%; pass rate 221/230 = 96,1% | | **Bug'lar** | Jami 47: Blocker 1, Critical 3, Major 14, Minor 21, Trivial 8. Tuzatilgan va tekshirilgan — 39; ochiq — 8 (Major 2, Minor 4, Trivial 2) | | **Exit criteria** | P0/P1 — 100% bajarildi ✅; pass rate ≥ 95% ✅; ochiq Blocker/Critical yo'q ✅; 2 ta ochiq Major — PO tasdiqlagan aylanma yo'l bilan ✅ | | **Chetlanishlar** | Humo sandbox 2 kun ishlamadi → 6 ta test Blocked qoldi, ular mock bilan qisman tekshirildi | | **Qolgan risklar** | Humo real muhitda faqat production smoke bilan tekshiriladi; BUG-517 (summa chegarasi xabari) v2.0.1 ga | | **Saboqlar** | To'lov sandbox'iga bog'liqlikni kamaytirish uchun contract test va mock kerak ([QA 11](/ios-lessons/qa-api-advanced)) | > **⚠️ 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 | Qisqacha | Qachon mos | | -------------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------- | | **TestRail** | Alohida test management tizimi: case'lar, run'lar, hisobotlar, Jira integratsiyasi | O'rta va katta jamoalar | | **Qase** | Zamonaviy interfeysli test management, API va avtomatlashtirish natijalarini import qilish | Startaplar va o'sayotgan jamoalar | | **Zephyr** | Jira ichida ishlaydigan test management (SmartBear) | Jamoa butunlay Jira'da yashasa | | **Xray** | Jira ichida ishlaydigan test management, test'lar Jira elementlari sifatida | Jira + qat'iy traceability | | **Allure TestOps** | Avtomatlashtirilgan va qo'lda testlar natijalarini birlashtiradi | Avtomatlashtirish ko'p bo'lgan jamoalar | | **TestLink** | Eski ochiq kodli vosita | Faqat eski loyihalarda uchraydi | | **Google Sheets / Notion** | Oddiy jadval | Juda kichik jamoa, boshlang'ich bosqich | 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](/ios-lessons/qa-sdlc-stlc-agile)) 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: ```gherkin 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 "" promo-kodini kiritadi Then tizim "" 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).
💡 Javobni ko'rish | ID | Sarlavha | Ma'lumot | Kutilgan | | --------- | -------------------------------------------- | -------------------------- | ------------------------------------------------ | | TC-REV-01 | DELIVERED buyurtmaga to'g'ri sharh saqlanadi | 5 yulduz, 10 belgilik matn | Sharh saqlanadi va mahsulot sahifasida ko'rinadi | | TC-REV-02 | Matn 9 belgi — rad etiladi | 4 yulduz, 9 belgi | "Kamida 10 belgi", sharh saqlanmaydi | | TC-REV-03 | Matn 1000 belgi — qabul qilinadi | 3 yulduz, 1000 belgi | Saqlanadi, matn kesilmaydi | | TC-REV-04 | Matn 1001 belgi — rad etiladi | 3 yulduz, 1001 belgi | "Ko'pi bilan 1000 belgi" | | TC-REV-05 | Yulduz tanlanmagan — rad etiladi | 0 yulduz, 50 belgi | "Bahoni tanlang" | | TC-REV-06 | SHIPPED buyurtmaga sharh mumkin emas | SHIPPED buyurtma | "Sharh qoldirish" tugmasi yo'q; API'da xato kodi | | TC-REV-07 | Boshqa xaridorning buyurtmasiga sharh (API) | Begona `orderId` | Rad etiladi, sharh saqlanmaydi | TC-REV-02…04 — BVA, TC-REV-06 — state, TC-REV-07 — avtorizatsiya (xavfsizlik). Bitta talabdan kamida uch xil texnika chiqdi.
### Mashq 2: yomon test case'ni tuzating ```text 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.
💡 Javobni ko'rish **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. ```text 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.
### 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.
💡 Javobni ko'rish | Talab | Test case'lar | | ---------- | ------------- | | REQ-1 | TC-A, TC-B | | REQ-2 | TC-B | | REQ-3 | TC-C | | REQ-4 | — | | (talabsiz) | TC-D | - 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.
### 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.
💡 Javobni ko'rish | Holat | Status | Izoh | | ----- | ------------------------------------------- | -------------------------------------------------------------------------------- | | a | **Failed** | Test bajarildi, natija farq qiladi → bug report | | b | **Blocked** | Test bajarilmadi; muhit muammosi alohida bug sifatida yoziladi | | c | **Skipped** | Platformaga tegishli emas | | d | **Retest** | Tasdiqlovchi test (confirmation testing) kerak | | e | Bug emas — **test case'ni yangilash** kerak | Testware ham talab bilan birga yashaydi; eskirgan test noto'g'ri "Failed" beradi |
### 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.
💡 Javobni ko'rish 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.
### 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?"
💡 Javobni ko'rish - **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.
--- ## 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](/ios-lessons/qa-bug-reports) ## Manbalar {#manbalar} 1. [ISTQB — Certified Tester Foundation Level Syllabus v4.0.1 (PDF)](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf) 2. [Wikipedia — ISO/IEC 29119](https://en.wikipedia.org/wiki/ISO/IEC_29119) 3. [Wikipedia — Software test documentation (IEEE 829)](https://en.wikipedia.org/wiki/Software_test_documentation) 4. [Cucumber — Gherkin reference](https://cucumber.io/docs/gherkin/reference/) 5. [TestRail](https://www.testrail.com/) 6. [Qase](https://qase.io/) 7. [Zephyr (SmartBear)](https://smartbear.com/test-management/zephyr/) 8. [Xray](https://www.getxray.app/) 9. [Qameta — Allure TestOps](https://qameta.io/) 10. [TestLink](https://testlink.org/)