# QA 27: Test strategiyasi, metrikalar va QA Lead — risk-based testing, release va jarayon qurish
> **Holat:** 2026-yil oktabr. Bu — "Hero" modulining strategik darsi: test strategiyasini noldan qurish, risk-based testing (ISTQB CTFL v4.0.1 ta'riflari bo'yicha), sifat metrikalari, DORA'ning hozirgi 5 ta metrikasi, reliz qarorlari (go/no-go, Apple phased release, Google Play staged rollout) va QA Lead'ning kundalik ishi. Barcha raqamlar rasmiy manbalardan olingan va "Manbalar" bo'limida ko'rsatilgan.
> **Bu darsdan keyin siz:** "nimani, qanchalik chuqur va qachongacha testlaymiz — va reliz tayyormi?" degan savolga asosli javob bera olasiz.
- DemoBozor kabi mahsulot uchun 1 sahifali test strategiyasi yozasiz;
- risk matritsasi tuzib, test chuqurligini risk darajasiga qarab taqsimlaysiz;
- DRE, escape rate, defect density, flaky rate kabi metrikalarni hisoblaysiz va ularning tuzoqlarini bilasiz;
- go/no-go yig'ilishini olib borasiz va bosim ostida jamoaga to'g'ri qaror chiqarishga yordam berasiz;
- QA jarayonini (triage, review, onboarding, hiring, dashboard) jamoada qura olasiz.
## Mundarija
1. [Hero darajasi: tester'dan sifat strategiga](#hero)
2. [Test strategiyasi nima va nimadan iborat](#strategiya)
3. [Risk-based testing: risk = ehtimollik × ta'sir](#risk)
4. [DemoBozor uchun 1 sahifali test strategiyasi](#namuna)
5. [Muhitlar, test ma'lumotlari va avtomatlashtirish strategiyasi](#muhit-data-avto)
6. [Kirish va chiqish mezonlari](#mezonlar)
7. [Sifat metrikalari: formulalar va tuzoqlar](#metrikalar)
8. [DORA metrikalari va QA'ning ta'siri](#dora)
9. [Reliz boshqaruvi: go/no-go, bosqichma-bosqich chiqarish, rollback](#reliz)
10. [Shift-right: production'dagi sifat](#shift-right)
11. [QA jarayonini qurish va QA Lead roli](#qa-lead)
12. [Bosim ostida qaror: "Juma kuni baribir chiqaramiz"](#bosim)
13. [Etuklik modellari: TMMi](#tmmi)
14. [Amaliy mashqlar](#mashqlar)
15. [O'zingizni tekshiring](#checklist)
16. [Xulosa](#xulosa)
17. [Manbalar](#manbalar)
---
## 1. Hero darajasi: tester'dan sifat strategiga {#hero}
Junior QA "bu tugma ishlayaptimi?" deb so'raydi. Senior QA va QA Lead esa boshqa savollar bilan yashaydi:
| Savol | Kim javob beradi | Qayerda o'rgandik |
| --------------------------------------------- | --------------------------------- | ----------------- |
| Nimani testlaymiz va nimani **testlamaymiz**? | QA Lead + Product Owner | QA 7, shu dars |
| Har bir qismni qanchalik chuqur testlaymiz? | QA Lead (risk asosida) | shu dars |
| Qaysi daraja va turdagi testlar kerak? | QA + dasturchilar | QA 4, QA 16 |
| Qachon testlashni to'xtatamiz? | Chiqish mezonlari (exit criteria) | shu dars |
| Reliz tayyormi? | Go/no-go yig'ilishi | shu dars |
| Sifat yaxshilanyaptimi yoki yomonlashyaptimi? | Metrikalar va trendlar | shu dars |
| Jarayonni qanday yaxshilaymiz? | QA Lead, retrospektiva | shu dars |
Hero darajasidagi QA'ning asosiy ishi — **sifat bilan bog'liq riskni ko'rinadigan qilish** va jamoaga to'g'ri qaror qabul qilishda yordam berish. U "darvozabon" (gatekeeper) emas, balki ma'lumot beradigan, risklarni biznes tilida tushuntira oladigan maslahatchi.
> **🧠 Esda tuting:** "Barcha bug'larni topish" maqsad emas — to'liq testlash imkonsiz ([QA 2](/ios-lessons/qa-principles-istqb)). Maqsad: **muhim risklarni** o'z vaqtida topish va qolgan (residual) risk haqida jamoaga halol ma'lumot berish.
Bu darsdagi barcha misollar kursimizning xayoliy mahsuloti **DemoBozor** (web + iOS + Android + REST API) ustida quriladi.
---
## 2. Test strategiyasi nima va nimadan iborat {#strategiya}
**Test strategiyasi** — mahsulot yoki tashkilot darajasidagi testlashga umumiy yondashuv: qaysi risklarga e'tibor beramiz, qaysi test darajalari va turlari ishlatiladi, qanday vositalar va mezonlar bilan ishlaymiz. **Test plan** esa aniq reliz yoki loyiha uchun: kim, qachon, qayerda, nimani testlaydi ([QA 7](/ios-lessons/qa-test-documentation)).
Oddiy o'xshatish: strategiya — "shaharda qanday harakatlanamiz" (asosan metro, shoshilinch holatda taksi). Plan — "ertaga 9:00 da A nuqtadan B nuqtaga qaysi bekat orqali boramiz".
Strategiya hujjatining odatdagi bo'limlari:
| Bo'lim | Nimaga javob beradi | DemoBozor misoli |
| -------------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------- |
| Kontekst | Mahsulot, foydalanuvchilar, biznes maqsad, cheklovlar | Web + iOS + Android, to'lovlar, 4 til, kichik jamoa |
| Risklar | Nima eng ko'p zarar keltirishi mumkin | To'lov, promo-kod hisob-kitobi, OTP login |
| Qamrov (scope) | Nimani testlaymiz va nimani testlamaymiz | To'lov provayderining ichki logikasi testlanmaydi — faqat integratsiya |
| Test darajalari va turlari | Unit, API, E2E, non-functional | Asosiy og'irlik API qatlamida; E2E faqat kritik yo'llar uchun |
| Texnikalar | Qaysi test dizayn texnikalari | Chegirmalar — decision table, buyurtma — state transition |
| Muhitlar va ma'lumotlar | Qayerda va qanday ma'lumot bilan | Staging + sintetik ma'lumot |
| Avtomatlashtirish | Nima, qaysi qatlamda, qachon ishga tushadi | PR'da smoke, kechasi to'liq regression |
| Non-functional | Performance, security, a11y, l10n | Har relizdan oldin k6 smoke va axe tekshiruvi |
| Mezonlar | Entry/exit criteria, Definition of Done | 0 ta ochiq Blocker/Critical bug |
| Rollar va jarayon | Kim nima qiladi; triage, review | QA har squad ichida, haftasiga 2 marta triage |
| Metrikalar va hisobot | Nimani o'lchaymiz, kimga ko'rsatamiz | Escape rate, crash-free users, flaky rate |
### Strategiya yondashuvlari
Amalda strategiya bir nechta yondashuvning aralashmasi bo'ladi. ISTQB'ning Expert Level Test Management syllabus'ida (2011) ular quyidagicha guruhlangan:
| Yondashuv | Mohiyati | Qachon mos |
| ------------------------------------ | ---------------------------------------------------------------- | -------------------------------------------- |
| **Analytical** (masalan, risk-based) | Talablar yoki risk tahlili asosida ustuvorlik beriladi | Deyarli har doim — asosiy yondashuv |
| **Model-based** | Tizim modeli (holatlar, biznes oqim) asosida testlar | Murakkab holat mashinalari, oqimlar |
| **Methodical** | Oldindan tayyor checklist yoki sifat xarakteristikalari ro'yxati | Takrorlanuvchi mahsulotlar, mobil checklist |
| **Process/standard-compliant** | Tashqi standart yoki regulyator talabiga amal qilish | Moliya, tibbiyot, davlat tizimlari |
| **Consultative** | Ekspertlar va stakeholder'lar maslahati bilan | Yangi domen, mijoz aniq yo'l-yo'riq bergan |
| **Regression-averse** | Mavjud funksiyani buzmaslik — ko'p avtomatlashtirish | Barqaror, tez-tez reliz qilinadigan mahsulot |
| **Reactive** | Tizimga qarab, natijalarga qarab — ko'proq exploratory | Talablar kam, vaqt qisqa, yangi funksiya |
DemoBozor uchun to'g'ri aralashma: **risk-based (asosiy) + regression-averse (avtomatlashtirish) + reactive (exploratory sessiyalar) + methodical (mobil checklist)**.
> **🎯 Intervyuda:** "Test strategiyasi va test plan farqi?" — Strategiya umumiy yondashuv (qanday risklar, qaysi darajalar, vositalar, mezonlar) va kamdan-kam o'zgaradi; plan esa aniq reliz uchun kim/qachon/nima va resurslarni belgilaydi.
---
## 3. Risk-based testing: risk = ehtimollik × ta'sir {#risk}
ISTQB CTFL v4.0.1 ta'rifi bo'yicha **risk** — yuz bersa, salbiy oqibat keltiradigan ehtimoliy hodisa. U ikki omil bilan tavsiflanadi:
- **Ehtimollik (risk likelihood)** — riskning yuz berish ehtimoli;
- **Ta'sir (risk impact)** — yuz bersa, oqibati qanchalik og'ir.
Bu ikki omil **risk darajasini** (risk level) beradi. Miqdoriy yondashuvda risk darajasi = ehtimollik × ta'sir; sifat yondashuvida esa **risk matritsasi** ishlatiladi.
### Loyiha riski va mahsulot riski
| Tur | Nima bilan bog'liq | DemoBozor misoli |
| --------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------ |
| **Project risk** (loyiha riski) | Boshqaruv: muddat, odamlar, yetkazib beruvchilar | Staging muhiti 1 hafta kech beriladi; yagona Android QA ta'tilga chiqadi |
| **Product risk** (mahsulot riski) | Mahsulot sifati: funksiya, hisob-kitob, xavfsizlik, tezlik | Promo-kod chegirmasi noto'g'ri hisoblanadi; OTP brute-force qilinadi |
Testlash asosan **mahsulot riski**ga qarshi kurashadi. Loyiha riski esa test rejasiga ta'sir qiladi (masalan, staging kech bo'lsa — regressiya vaqti qisqaradi).
### Ehtimollik va ta'sirni qanday baholaymiz
1 dan 5 gacha shkala tanlang va har bir ball nimani anglatishini jamoa bilan **oldindan** kelishib oling:
| Ball | Ehtimollik (nima oshiradi) | Ta'sir (nima oshiradi) |
| ---- | ------------------------------------------------------------------- | --------------------------------------------------------------- |
| 1 | Eski, barqaror kod; o'zgarish yo'q | Kosmetik, hech kim sezmaydi |
| 2 | Kichik o'zgarish, tajribali dasturchi | Noqulaylik, oson aylanib o'tiladi (workaround) |
| 3 | O'rtacha murakkablik, bir nechta modulga tegadi | Funksiya qisman ishlamaydi, ba'zi foydalanuvchilar ta'sirlanadi |
| 4 | Yangi texnologiya, murakkab logika, avval ko'p bug chiqqan joy | Asosiy oqim buziladi, pul yoki ma'lumot bilan bog'liq |
| 5 | Butunlay yangi, uchinchi tomon integratsiyasi, shoshilinch yozilgan | Pul yo'qotish, huquqiy muammo, barcha foydalanuvchilar |
> **💡 Maslahat:** Ehtimollikni baholashda tarixdan foydalaning: oldingi relizlarda qaysi modulda ko'p bug chiqqan? "Defektlar to'planadi" printsipi ([QA 2](/ios-lessons/qa-principles-istqb)) bu yerda ishlaydi.
### Risk register (risklar reyestri)
Risklar jadvalda yuritiladi va har relizdan keyin yangilanadi:
| ID | Risk | Ehtim. | Ta'sir | Daraja | Kamaytirish choralari (testlash orqali) | Egasi |
| ---- | ---------------------------------------------------------- | ------ | ------ | ------ | ------------------------------------------------------------------------------------------- | --------- |
| R-01 | Karta to'lovi ikki marta yechiladi yoki umuman yechilmaydi | 4 | 5 | **20** | Decision table + API testlar, idempotentlik testi, double-click, exploratory | QA Lead |
| R-02 | Promo-kod chegirmasi noto'g'ri yoki qayta ishlatiladi | 4 | 4 | **16** | Decision table, BVA, parallel so'rovlar (race), API regression avtomatlashtirish | API QA |
| R-03 | OTP login'da bloklash ishlamaydi (brute-force) | 3 | 5 | **15** | State transition, negative testlar, security tekshiruvi ([QA 24](/ios-lessons/qa-security)) | Mobile QA |
| R-04 | Muddatli to'lov shartlari noto'g'ri tekshiriladi | 3 | 4 | **12** | EP + BVA (yosh 18–65, summa 500 000 – 30 000 000) | Web QA |
| R-05 | Qidiruv natijalari noto'g'ri yoki sekin | 3 | 3 | **9** | EP (2–100 belgi), API testlar, k6 smoke | Web QA |
| R-06 | Push bildirishnoma kelmaydi | 4 | 2 | **8** | Mobil checklist, real qurilmada smoke | Mobile QA |
| R-07 | Sharh formasi validatsiyasi xato | 2 | 2 | **4** | Checklist, exploratory spot-check | Web QA |
| R-08 | Profil rasmi yuklanmaydi | 2 | 1 | **2** | Checklist | Web QA |
### Test chuqurligini risk bo'yicha taqsimlash
| Zona | Daraja | Nima qilamiz |
| --------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 🔴 Yuqori | 15–25 | Formal texnikalar (decision table, state transition, BVA), peer review, API + E2E avtomatlashtirish, exploratory sessiya, performance va security tekshiruvlari |
| 🟡 O'rta | 8–14 | Asosiy texnikalar, API avtomatlashtirish, smoke E2E, checklist |
| 🟢 Past | 1–7 | Checklist, qisqa exploratory spot-check, boshqa testlar "yo'l-yo'lakay" qamraydi |
ISTQB bo'yicha risk tahlili natijasi quyidagilarni aniqlashga xizmat qiladi: test qamrovi, test darajalari va turlari, texnikalar va qamrov darajasi, har vazifa uchun kuch (effort), ustuvorlik va testdan tashqari qo'shimcha choralar.
### Riskka javob variantlari
Risk aniqlangach, testlash yagona javob emas. CTFL v4.0.1 to'rt xil javobni sanaydi:
1. **Testlash orqali kamaytirish (mitigation)** — yuqoridagi jadval;
2. **Qabul qilish (acceptance)** — "kosmetik, keyingi relizda tuzatamiz";
3. **O'tkazish (transfer)** — masalan, sertifikatlangan to'lov provayderiga topshirish;
4. **Zaxira reja (contingency plan)** — feature flag bilan o'chirib qo'yish, rollback rejasi.
Risk nazorati ikki qismdan iborat: **mitigation** (choralarni bajarish) va **monitoring** (choralar ishlayaptimi, yangi risklar paydo bo'ldimi — kuzatish).
> **⚠️ Diqqat:** Risk matritsasi bir marta tuzilib, tortmaga tashlab qo'yiladigan hujjat emas. Har bir production incident'dan keyin unga qayting: incident yuz bergan joyning ehtimolligini oshiring.
---
## 4. DemoBozor uchun 1 sahifali test strategiyasi {#namuna}
Quyida — haqiqiy jamoada ishlatsa bo'ladigan ixcham strategiya namunasi. Uni Confluence, Notion yoki repo'dagi `docs/test-strategy.md` faylida saqlang.
**DemoBozor — Test strategiyasi (v1.3, 2026-yil oktabr)**
**1. Kontekst.** Onlayn do'kon: Web (React), iOS (Swift), Android (Kotlin), REST API (Node.js), PostgreSQL. Tillar: o'zbek (lotin/kirill), rus, ingliz. Ikki haftalik sprint, har sprint oxirida reliz. Jamoa: 6 dasturchi, 2 QA, 1 PO.
**2. Sifat maqsadlari.**
- To'lov va buyurtma oqimida pul bilan bog'liq xato production'ga chiqmasligi;
- Mobil ilovada crash-free users ko'rsatkichi jamoa belgilagan maqsaddan pastga tushmasligi;
- Har reliz kritik yo'llar (ro'yxatdan o'tish → katalog → savatcha → to'lov) bo'yicha avtomatik smoke'dan o'tishi.
**3. Qamrov.** Testlanadi: barcha mijoz funksiyalari, admin panelning buyurtma va foydalanuvchi bo'limlari, API kontraktlari. Testlanmaydi: to'lov provayderining ichki logikasi (faqat integratsiya va xato javoblari), uchinchi tomon analitika SDK'larining ichki ishi.
**4. Risklar.** Risk register — `docs/risk-register.md`; har sprint boshida yangilanadi (3-bo'limdagi jadval).
**5. Test darajalari.**
| Daraja | Kim yozadi | Nimani qamraydi | Qachon ishlaydi |
| ------------------ | ----------------- | --------------------------------------------- | -------------------------------- |
| Unit | Dasturchilar | Hisob-kitoblar (chegirma, yetkazish narxi) | Har commit/PR |
| API (integratsiya) | QA + dasturchilar | Barcha endpoint'lar, biznes qoidalar, xatolar | Har PR (smoke), kechasi (to'liq) |
| E2E (UI) | QA | 10–15 ta kritik foydalanuvchi yo'li | PR'da smoke, kechasi to'liq |
| Manual/exploratory | QA | Yangi funksiyalar, UX, mobil o'ziga xosliklar | Har sprint, relizdan oldin |
| Non-functional | QA + DevOps | k6 smoke, axe a11y, xavfsizlik checklisti | Relizdan oldin |
**6. Texnikalar.** Chegirmalar — decision table; summalar va limitlar — EP + BVA; buyurtma holatlari — state transition; to'lov usullari × platformalar — pairwise; yangi funksiyalar — exploratory charter'lar.
**7. Muhitlar.** `dev` (dasturchilar), `staging` — `staging.demobozor.example` (QA, prod'ga yaqin konfiguratsiya), `prod`. Mobil: TestFlight va Firebase App Distribution build'lari.
**8. Mezonlar.** 6-bo'limdagi entry/exit criteria.
**9. Hisobot.** Har reliz uchun test summary; haftalik sifat dashboard'i (7-bo'lim).
**10. Vositalar.** Jira (bug'lar), Qase (test case'lar), Playwright + TypeScript (web va API), Maestro (mobil smoke), Proxyman (trafik tahlili), k6 (yuk), GitHub Actions (CI).
> **💡 Maslahat:** Strategiya qisqa bo'lgani yaxshi — 1–2 sahifadan oshsa, uni hech kim o'qimaydi. Tafsilotlar alohida hujjatlarda (risk register, test plan, checklist) bo'lsin, strategiya ularga havola bersin.
---
## 5. Muhitlar, test ma'lumotlari va avtomatlashtirish strategiyasi {#muhit-data-avto}
### Muhitlar
| Muhit | Kim ishlatadi | Qanday testlar | Ma'lumot |
| ---------- | ------------------------ | -------------------------------------- | ----------------------------- |
| local | Dasturchi | Unit, komponent | Mock / seed |
| dev | Dasturchilar, QA (erta) | Yangi feature'ni erta ko'rish | Sintetik |
| staging | QA | Regression, E2E, API, exploratory | Sintetik + anonimlashtirilgan |
| pre-prod | QA, DevOps (agar bo'lsa) | Reliz nomzodi, migratsiya, yuk testi | Prod'ga yaqin hajm |
| production | Hamma | Smoke (test akkaunt bilan), monitoring | Haqiqiy |
### Test ma'lumotlari strategiyasi
- **Sintetik ma'lumot** — asosiy usul: faker yoki seed skriptlar bilan yaratiladi ([QA 17](/ios-lessons/qa-typescript)).
- **Testlar o'z ma'lumotini o'zi yaratadi va tozalaydi** — API orqali (setup/teardown), boshqa testga bog'liq bo'lmaydi.
- **Prod ma'lumotidan nusxa** — faqat anonimlashtirilgan holda (ism, telefon, karta raqamlari maskalangan). Shaxsga doir ma'lumotlar qonunchilikda himoyalangan; prod nusxasini xom holda staging'ga ko'chirish — xavfsizlik va huquqiy risk.
- **Maxsus test akkauntlar** — production smoke uchun (buyurtmalari avtomatik bekor qilinadi, analitikadan chiqarib tashlanadi).
> **🇺🇿 Mahalliy kontekst:** O'zbekistonda ham "Shaxsga doir ma'lumotlar to'g'risida"gi qonun amal qiladi. Test muhitida haqiqiy telefon raqamlari va pasport ma'lumotlari bilan ishlash — kompaniya uchun real risk. Yuristingiz va xavfsizlik mutaxassisingiz bilan siyosatni kelishib oling.
### Avtomatlashtirish strategiyasi
| Qatlam | Ulush (taxminiy) | Qachon ishga tushadi | Kim ega |
| ---------------- | ------------------- | ----------------------------------- | ------------ |
| Unit | Eng ko'p | Har PR | Dasturchilar |
| API | Ko'p | PR'da smoke, kechasi to'liq | QA (SDET) |
| E2E UI | Kam, faqat kritik | PR'da `@smoke`, kechasi to'liq | QA |
| Visual / a11y | Tanlangan sahifalar | Kechasi | QA |
| Performance (k6) | Smoke yuk | Relizdan oldin, kechasi (ixtiyoriy) | QA + DevOps |
Bu — test piramidasining amaliy ko'rinishi ([QA 4](/ios-lessons/qa-levels-types), [QA 16](/ios-lessons/qa-automation-intro)). CI'dagi ishga tushirish tafsilotlari — [QA 21](/ios-lessons/qa-ci-cd).
**Flaky test siyosati** (strategiyada yozilgan bo'lsin):
1. Flaky test aniqlansa — darhol ticket ochiladi va egasi tayinlanadi;
2. Test "karantin" tegiga (`@quarantine`) o'tkaziladi — CI'ni bloklamaydi, lekin ishlashda davom etadi;
3. Karantinda maksimal muddat (masalan, 2 sprint) — tuzatiladi yoki o'chiriladi;
4. Retry soni cheklangan (masalan, CI'da 1–2) — retry muammoni yashirish uchun emas.
---
## 6. Kirish va chiqish mezonlari {#mezonlar}
**Entry criteria** — testlashni boshlash uchun nima tayyor bo'lishi kerak. **Exit criteria** — testlashni tugatib, "tayyor" deyish uchun nima bajarilishi kerak. Ikkalasi ham **o'lchanadigan** bo'lishi shart.
### DemoBozor relizi uchun entry criteria (namuna)
- Reliz nomzodi (RC) build'i staging'ga deploy qilingan, versiya va build raqami reliz ticket'iga yozilgan;
- Avtomatik smoke testlar o'tgan;
- Yangi funksiyalar uchun qabul mezonlari (acceptance criteria) PO tomonidan tasdiqlangan;
- Test ma'lumotlari va test akkauntlari tayyor;
- Ma'lum Blocker bug'lar yo'q (aks holda testlash ma'nosiz).
### Exit criteria (namuna)
| Mezon | Maqsad (jamoa kelishgan qiymat) |
| ------------------------------------------------ | -------------------------------------------------------- |
| Rejalashtirilgan kritik test case'lar bajarilgan | 100% |
| Ochiq Blocker / Critical bug'lar | 0 |
| Ochiq Major bug'lar | Har biri uchun PO qarori va workaround yozilgan |
| Qizil zonadagi risklar qamrovi | 100% |
| Avtomatik regression natijasi | Barcha yiqilishlar tahlil qilingan; flaky'lar ajratilgan |
| Performance smoke (k6) | p95 kelishilgan SLO ichida |
| Release notes | QA tomonidan tekshirilgan |
> **⚠️ Diqqat:** "Pass rate ≥ 95%" kabi mezonni ehtiyotkorlik bilan ishlating: qolgan 5% ichida to'lov testi bo'lsa-chi? Foiz emas, **qaysi** testlar yiqilgani muhim. Shuning uchun risk qamrovi va ochiq bug'lar severity'si asosiy mezon bo'lsin.
---
## 7. Sifat metrikalari: formulalar va tuzoqlar {#metrikalar}
ISTQB CTFL v4.0.1 test metrikalarini guruhlarga ajratadi: loyiha progressi, test progressi, mahsulot sifati, defekt metrikalari (masalan, defect density, defect detection percentage), risk metrikalari (masalan, qolgan risk darajasi), qamrov va xarajat metrikalari.
Eng ko'p ishlatiladigan metrikalar:
| Metrika | Formula | Nimani ko'rsatadi | Tuzoq |
| ----------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------ | ------------------------------------------------------------------------ |
| **Defect density** | defektlar soni ÷ hajm (KLOC, modul yoki story point) | Qaysi modul "kasalroq" | KLOC kod uslubiga bog'liq; faqat bir xil o'lchovda solishtiring |
| **DRE** (Defect Removal Efficiency) | relizdan oldin topilgan ÷ (oldin + keyin topilgan) × 100 | Testlash qanchalik samarali | Prod defektlari kech ma'lum bo'ladi — oynani belgilang (masalan, 30 kun) |
| **Escape rate** (defect leakage) | production'da topilgan ÷ (oldin + keyin topilgan) × 100 | Qancha bug "qochib" chiqdi | Ba'zi jamoalar boshqa formula ishlatadi — bittasiga kelishing |
| **Test execution progress** | bajarilgan ÷ rejalashtirilgan × 100 | Testlash qayerda | Oson testlar avval bajarilsa, raqam aldaydi |
| **Pass rate** | o'tgan ÷ bajarilgan × 100 | Joriy holat | Past pass rate yaxshi testlar belgisi bo'lishi ham mumkin |
| **Requirements coverage** | kamida 1 testi bor talablar ÷ jami talablar × 100 | Talablar qamrovi (RTM, [QA 7](/ios-lessons/qa-test-documentation)) | "1 ta test bor" ≠ "yaxshi testlangan" |
| **Automation coverage** | avtomatlashtirilgan regression case'lar ÷ jami regression case'lar × 100 | Qo'lda ishning qancha qismi avtomat | Oson case'lar avtomatlashtiriladi, riskli'lari qoladi |
| **Flaky rate** | beqaror natija bergan run'lar ÷ jami run'lar × 100 | Test to'plamiga ishonch | Retry'lar muammoni yashiradi |
| **MTTD / MTTR** | muammoni aniqlash / tiklash uchun o'rtacha vaqt | Reaksiya tezligi | "R" — repair, recover yoki resolve? Ta'rifni yozib qo'ying |
| **Reopen rate** | qayta ochilgan bug'lar ÷ yopilgan bug'lar × 100 | Fix sifati, bug report aniqligi | Bitta murakkab bug butun raqamni buzadi |
| **Crash-free users / sessions** | Crashlytics hisoblaydi (pastda) | Mobil ilova barqarorligi | Faqat fatal crash'lar hisoblanadi, ANR'lar emas |
### Ishlangan misol: DemoBozor v2.0
Relizdan oldin QA **120** ta defekt topdi. Relizdan keyingi 30 kunda production'da yana **8** ta defekt topildi.
```text
DRE = 120 / (120 + 8) × 100 = 93.75%
Escape rate = 8 / (120 + 8) × 100 = 6.25%
```
Modullar bo'yicha defect density:
| Modul | Defektlar | Hajm (KLOC) | Density (defekt/KLOC) |
| ------- | --------- | ----------- | --------------------- |
| To'lov | 18 | 6 | **3.0** |
| Katalog | 30 | 20 | 1.5 |
| Profil | 4 | 5 | 0.8 |
Katalogda defektlar soni ko'p, lekin **zichlik** bo'yicha eng muammoli modul — To'lov. Xulosa: keyingi relizda To'lov riskining ehtimolligini oshiramiz va unga ko'proq vaqt ajratamiz.
### Crash-free metrikalar (Firebase Crashlytics ta'rifi)
- **Crash-free users** — tanlangan davrda ilovadan foydalangan va birorta ham crash ko'rmagan foydalanuvchilar foizi;
- **Crash-free sessions** — tanlangan davrdagi sessiyalardan crash bilan tugamaganlari foizi;
- Yangi sessiya ilova cold start bo'lganda yoki kamida 30 daqiqa fonda turib, qayta ochilganda boshlanadi;
- Faqat **fatal** hodisalar hisoblanadi.
Bu metrikalar mobil reliz qarorlarida juda muhim: bosqichma-bosqich chiqarish (9-bo'lim) vaqtida aynan shularni kuzatasiz.
### Goodhart qonuni: o'lchov maqsadga aylansa, buziladi
Goodhart qonunining mashhur ifodasi: _"o'lchov maqsadga aylanganda, u yaxshi o'lchov bo'lishdan to'xtaydi"_. QA'da bu shunday ko'rinadi:
| "Maqsad" qilib qo'yilgan metrika | Nima bo'ladi | Yaxshiroq alternativ |
| ----------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------- |
| "Har tester oyiga 50 ta bug topsin" | Bug'lar maydalanadi, dublikatlar ko'payadi, dasturchi bilan nizo | Escape rate trendi + topilgan bug'lar severity'si |
| "Pass rate 100% bo'lsin" | Yiqilayotgan testlar `skip` qilinadi yoki o'chiriladi | Yiqilishlar tahlil qilinganmi — shuni o'lchang |
| "Automation coverage 80% bo'lsin" | Assertion'siz yoki eng oson testlar avtomatlashtiriladi | Qizil zonadagi risklarning avtomat qamrovi |
| "Bug'lar soni kamaysin" | Bug'lar chatda "jimgina" hal qilinadi, ticket ochilmaydi | Production incident'lar va mijoz shikoyatlari trendi |
> **🧠 Esda tuting:** Metrika — savolga javob. Avval savolni yozing ("mijozlarga yetib borayotgan bug'lar kamayyaptimi?"), keyin unga mos metrikani tanlang. Bitta nuqtadan ko'ra **trend** muhim, shaxsni emas — **jarayonni** baholang.
---
## 8. DORA metrikalari va QA'ning ta'siri {#dora}
DORA (DevOps Research and Assessment) dasturiy ta'minotni yetkazib berish samaradorligini o'lchaydigan metrikalar bilan mashhur. Uzoq yillar "four keys" (to'rtta kalit metrika) deb atalgan to'plam hozir **beshta** metrikaga aylangan:
- **2023** — "mean time to recover (MTTR)" o'rniga **failed deployment recovery time** kiritildi: endi faqat deploy sabab bo'lgan nosozlikdan tiklanish o'lchanadi;
- **2024** — beshinchi metrika **deployment rework rate** qo'shildi.
| Guruh | Metrika | DORA ta'rifi (qisqacha) | QA qanday ta'sir qiladi |
| ---------------------------- | ----------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------- |
| Throughput (o'tkazuvchanlik) | **Change lead time** | O'zgarish commit qilingandan production'ga deploy qilingungacha vaqt | Tez va ishonchli avtomatik testlar kutishni qisqartiradi |
| Throughput | **Deployment frequency** | Ma'lum davrdagi deploy'lar soni yoki deploy'lar orasidagi vaqt | Barqaror CI va kichik relizlar |
| Throughput | **Failed deployment recovery time** | Darhol aralashuv talab qilgan muvaffaqiyatsiz deploy'dan tiklanish vaqti | Production smoke, monitoring, tez hotfix regressiyasi |
| Instability (beqarorlik) | **Change fail rate** | Deploy'dan keyin darhol aralashuv talab qilganlar ulushi | Quality gate'lar, risk-based regressiya |
| Instability | **Deployment rework rate** | Production'dagi incident sabab qilingan rejasiz deploy'lar ulushi | Kam "qochgan" bug — kam rejasiz hotfix |
> **💡 Maslahat:** DORA metrikalari jamoa jarayonini yaxshilash uchun. Ularni jamoalarni bir-biri bilan solishtirish yoki odamlarni baholash uchun ishlatsangiz, Goodhart qonuni darhol ishga tushadi.
QA nuqtai nazaridan eng muhim saboq: **tezlik va barqarorlik bir-biriga qarshi emas.** Yaxshi avtomatlashtirilgan, tez test to'plami lead time'ni ham, change fail rate'ni ham yaxshilaydi.
---
## 9. Reliz boshqaruvi: go/no-go, bosqichma-bosqich chiqarish, rollback {#reliz}
### Reliz oqimi
```text
feature freeze
→ release branch (release/2.1.0)
→ RC build (2.1.0 build 45)
→ regression: avtomat + manual + exploratory
→ go/no-go yig'ilishi
→ bosqichma-bosqich chiqarish (phased / staged / canary)
→ monitoring (24–72 soat)
→ 100% foydalanuvchiga
```
### Reliz checklisti (QA nuqtai nazaridan)
- [ ] RC build versiyasi va build raqami reliz ticket'idagi bilan mos
- [ ] Regression natijalari tahlil qilingan, yiqilgan testlarning har biriga izoh bor
- [ ] Ochiq bug'lar ro'yxati severity bo'yicha ko'rib chiqilgan
- [ ] Release notes haqiqatga mos (yo'q funksiya va'da qilinmagan)
- [ ] Ma'lumotlar bazasi migratsiyalari eski va yangi versiya bilan tekshirilgan
- [ ] Feature flag'lar to'g'ri sozlangan (nima yoqiladi, nima o'chiq qoladi)
- [ ] Monitoring dashboard'lari va alert'lar tayyor
- [ ] Rollback yoki hotfix rejasi yozilgan
- [ ] Support jamoasi yangi funksiyalar va ma'lum muammolar haqida xabardor
- [ ] Mobil: do'kon metadata va skrinshotlar tekshirilgan ([App Store submission](/ios-lessons/app-store))
### Go/no-go yig'ilishi
**Ishtirokchilar:** PO/PM, QA Lead, Tech Lead, DevOps yoki reliz menejeri, kerak bo'lsa support.
**QA olib keladigan ma'lumot:**
1. Test summary: nima testlandi, nima testlanmadi va nega;
2. Ochiq bug'lar severity bo'yicha, har biriga ta'sir va workaround;
3. Risk register'dagi qolgan (residual) risklar;
4. Metrikalar: regression natijasi, flaky'lar, performance smoke.
**Mumkin bo'lgan qarorlar:**
| Qaror | Qachon |
| --------------------------- | -------------------------------------------------------------------------------------------------- |
| ✅ **Go** | Exit criteria bajarilgan |
| ⚠️ **Go with known issues** | Qolgan bug'lar hujjatlashtirilgan, workaround bor, PO riskni qabul qildi |
| ⛔ **No-go** | Blocker/Critical bor yoki qizil zonadagi risk qamralmagan; qayta ko'rib chiqish sanasi belgilanadi |
> **🧠 Esda tuting:** Yakuniy reliz qarorini odatda biznes (PO/stakeholder'lar) qabul qiladi. QA'ning vazifasi — qaror **ma'lumotli** bo'lishini ta'minlash va qarorni hujjatlashtirish.
### Mobil reliz: binary'ni "qaytarib bo'lmaydi"
Web yoki backend'da rollback — bir necha daqiqalik ish. Mobil ilovada esa foydalanuvchi yangilab bo'lgan versiyani qaytarib olib bo'lmaydi. Shuning uchun do'konlarning bosqichma-bosqich chiqarish vositalari muhim.
**Apple App Store — phased release** (avtomatik yangilanish yoqilgan foydalanuvchilar uchun, 7 kun):
| Kun | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| ----------------------- | --- | --- | --- | --- | --- | --- | ---- |
| Foydalanuvchilar ulushi | 1% | 2% | 5% | 10% | 20% | 50% | 100% |
- Phased release'ni jami 30 kungacha to'xtatib (pause) turish mumkin, pauzalar soni cheklanmagan;
- Diqqat: bu jadval faqat **avtomatik** yangilanishlarga tegishli — App Store'dan ilovani qo'lda yangilamoqchi bo'lgan har kim istalgan vaqtda yangi versiyani yuklab oladi.
**Google Play — staged rollout:**
- Foizni dasturchi o'zi tanlaydi va keyin qo'lda oshiradi (avtomatik oshmaydi);
- Muammo topilsa, rollout'ni **to'xtatish (halt)** mumkin — yangi foydalanuvchilar olmaydi, lekin olganlar o'sha versiyada qoladi;
- Muammo tuzatilgan bo'lsa — yangi tuzatilgan build bilan yangi reliz chiqariladi.
Shuning uchun mobil jamoalarda server tomonidagi **feature flag** (kill switch) va remote config — rollback'ning o'rnini bosuvchi asosiy vosita. Juda jiddiy holatda Apple'dan **expedited review** (tezlashtirilgan ko'rib chiqish) so'rash mumkin — lekin bunga tayanib reja qurmang.
### Web va backend: canary va feature flag'lar
- **Canary reliz** — yangi versiya avval trafikning kichik qismiga beriladi, metrikalar (xatolar, kechikish) eski versiya bilan solishtiriladi, keyin asta-sekin kengaytiriladi (Google SRE Workbook'da batafsil);
- **Feature flag (feature toggle)** — kodni deploy qilish va funksiyani foydalanuvchiga yoqishni ajratadi; muammo bo'lsa, funksiya qayta deploy'siz o'chiriladi (Martin Fowler'ning "Feature Toggles" maqolasi — klassik manba);
- **QA uchun:** har bir flag uchun ikkala holat (yoqilgan/o'chirilgan) testlanishi kerak — bu ko'pincha unutiladi.
### Relizdan keyingi monitoring (birinchi 24–72 soat)
| Nimani kuzatamiz | Qayerda |
| ------------------------------------------- | --------------------------------- |
| Crash-free users/sessions | Firebase Crashlytics |
| 5xx xatolar ulushi, p95 kechikish | APM / Grafana |
| To'lov muvaffaqiyati, checkout konversiyasi | Biznes dashboard |
| Support murojaatlari, do'kondagi sharhlar | Helpdesk, App Store / Google Play |
| Production smoke (test akkaunt bilan) | Avtomatik job |
### Hotfix jarayoni
1. Severity Blocker/Critical production muammosi → hotfix qarori;
2. Reliz tag'idan `hotfix/2.1.1` branch;
3. Minimal o'zgarish (faqat tuzatish);
4. Maqsadli regressiya: tuzatilgan joy + unga yaqin kritik yo'llar + smoke;
5. Bosqichma-bosqich chiqarish va kuchaytirilgan monitoring;
6. Post-mortem: nega qochib chiqdi? Risk register va regression to'plamiga yangi test qo'shiladi.
---
## 10. Shift-right: production'dagi sifat {#shift-right}
Shift-left — testlashni erta boshlash ([QA 3](/ios-lessons/qa-sdlc-stlc-agile)). **Shift-right** esa production'dan sifat haqida ma'lumot olish. Hero darajasidagi QA ikkalasini ham boshqaradi.
| Amaliyot | Mohiyati | Batafsil |
| ---------------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------- |
| Observability | Loglar, metrikalar, trace'lar — muammoni foydalanuvchidan oldin ko'rish | [DevOps: Observability](/ios-lessons/devops-observability) |
| Synthetic monitoring | Har N daqiqada prod'da skript (masalan, login + katalog) ishlaydi | [QA 21](/ios-lessons/qa-ci-cd) |
| A/B tajribalar | Yangi variantni foydalanuvchilarning bir qismiga ko'rsatib, o'lchash | [Growth: A/B testlash](/ios-lessons/growth-experimentation-ab) |
| Beta dasturlar | TestFlight external testing, Google Play yopiq test trekkari | [QA 14](/ios-lessons/qa-mobile-testing) |
| Dogfooding | Jamoa a'zolari mahsulotdan har kuni o'zlari foydalanadi | — |
| Feature flag + bosqichli chiqarish | Riskni kichik auditoriyada sinash | [DevOps: Release](/ios-lessons/devops-release) |
**Teskari aloqa halqasi** — shift-right'ning eng qimmatli qismi:
```text
production incident
→ root cause tahlili (post-mortem)
→ yangi regression test (avtomat)
→ risk register yangilanadi (ehtimollik ↑)
→ test strategiyasi va checklist'lar yangilanadi
```
> **⚠️ Diqqat:** "Production'da testlaymiz" degani foydalanuvchilarni tester'ga aylantirish emas. Shift-right faqat yaxshi shift-left ustiga quriladi.
---
## 11. QA jarayonini qurish va QA Lead roli {#qa-lead}
### Jamoa modellari
| Model | Qanday | Afzalligi | Kamchiligi |
| ------------------------ | ------------------------------------------------------------------------ | --------------------------------------- | -------------------------------------------- |
| **Embedded** | Har squad ichida QA bor | Kontekstni chuqur biladi, tez feedback | Squad'lar orasida standartlar farq qiladi |
| **Markazlashgan** | Alohida QA bo'limi, loyihalarga "beriladi" | Yagona standart, resurslarni taqsimlash | Kontekst yo'qoladi, "devor ortidan tashlash" |
| **Gibrid (guild / CoE)** | QA squad'larda, lekin QA guild umumiy standart va vositalarni boshqaradi | Ikkalasining afzalligi | Koordinatsiyaga vaqt kerak |
Ko'p zamonaviy jamoalar **gibrid** modelni tanlaydi.
### Whole-team quality va quality coaching
Sifat — faqat QA'ning ishi emas. Zamonaviy QA Lead "hamma narsani o'zim testlayman" o'rniga butun jamoaning testlash qobiliyatini oshiradi:
- dasturchilar unit va komponent testlarini yozadi, QA ularni ko'rib chiqadi;
- har yangi story uchun Three Amigos (PO + dev + QA) — qabul mezonlarini birga yozish ([QA 3](/ios-lessons/qa-sdlc-stlc-agile));
- **testability review** — dizayn bosqichida "buni qanday testlaymiz?" savoli (`data-testid`, test rejimi, log'lar, feature flag'lar);
- juftlikda testlash (dev + QA), bug bash'lar, ichki mini-trening'lar.
### Bug triage jarayoni
| Element | Namuna |
| -------------- | ---------------------------------------------------------------------------------------- |
| Davriylik | Haftasiga 2 marta, 30 daqiqa; relizdan oldin har kuni |
| Ishtirokchilar | QA Lead, Tech Lead, PO |
| Kirish | Yangi va qayta ochilgan bug'lar ([QA 8](/ios-lessons/qa-bug-reports)) |
| Natija | Severity/priority tasdiqlangan, egasi va fix version belgilangan yoki Rejected/Duplicate |
Jamoa kelishgan **javob muddati** (SLA) namunasi — sizning jamoangizda boshqacha bo'lishi mumkin:
| Severity | Reaksiya | Tuzatish |
| -------- | ------------ | --------------------------- |
| Blocker | Darhol | Hotfix |
| Critical | Shu ish kuni | Joriy reliz |
| Major | Triage'da | Joriy yoki keyingi sprint |
| Minor | Triage'da | Backlog, ustuvorlikka qarab |
### Test case review
Test case'lar ham kod kabi ko'rib chiqiladi. Reviewer checklisti:
- [ ] Sarlavha nimani tekshirishini aniq aytadi
- [ ] Qadamlar takrorlanadigan, test ma'lumotlari ko'rsatilgan
- [ ] Kutilgan natija o'lchanadigan ("to'g'ri ishlaydi" emas)
- [ ] Negative va chegaraviy holatlar bor
- [ ] Talabga bog'langan (traceability)
- [ ] Dublikat emas
### Yangi QA'ni onboarding qilish (birinchi hafta)
| Kun | Vazifa |
| --- | --------------------------------------------------------------------------- |
| 1 | Kirish huquqlari (Jira, repo, staging, TestFlight), mahsulot bilan tanishuv |
| 2 | Test strategiyasi, risk register va checklist'larni o'qish |
| 3 | Tajribali QA bilan regressiyada "soya" bo'lib ishlash (shadowing) |
| 4 | Birinchi kichik ticket'ni mustaqil testlash, bug report yozish |
| 5 | Feedback suhbati, 30 kunlik maqsadlar |
### QA yollash (hiring loop)
Intervyu "trivia" (yodlangan ta'riflar) emas, **fikrlashni** tekshirsin: skrining → amaliy topshiriq (test dizayn yoki bug report) → texnik suhbat (API/SQL/avtomatlashtirish) → jamoa bilan suhbat. Nomzod tomonidan qanday ko'rinishini [QA 28](/ios-lessons/qa-career-interview)'da batafsil ko'ramiz.
### QA ishini baholash (estimation)
QA ishini faoliyatlar bo'yicha bo'ling: talab tahlili, test dizayn, test ma'lumotlarini tayyorlash, bajarish, regression, avtomatlashtirish, hisobot. Har biriga uch nuqtali baho bering — optimistik (O), ehtimoliy (M), pessimistik (P):
```text
PERT bahosi = (O + 4M + P) / 6
Misol: promo-kod funksiyasini testlash
O = 2 kun, M = 3 kun, P = 7 kun
(2 + 4×3 + 7) / 6 = 21 / 6 = 3.5 kun
```
Bug tuzatish sikllari (retest + regression) uchun alohida vaqt qo'shishni unutmang. Baholash usullari haqida ko'proq: [PM 3](/ios-lessons/pm-estimation-planning).
### Rahbariyat uchun sifat dashboard'i
5–7 ta ko'rsatkich, trend va qisqa xulosa — bundan ortig'ini hech kim o'qimaydi. Namuna (raqamlar xayoliy, DemoBozor uchun):
| Ko'rsatkich | Joriy | Oldingi | Holat |
| ----------------------------- | ----- | ------- | ----- |
| Escape rate (30 kun) | 6.3% | 9.1% | 🟢 |
| Ochiq Critical/Major bug'lar | 0 / 4 | 1 / 6 | 🟢 |
| Crash-free users (iOS) | 99.6% | 99.7% | 🟡 |
| Flaky rate (CI) | 2.3% | 1.1% | 🔴 |
| Qizil risklar avtomat qamrovi | 7 / 9 | 6 / 9 | 🟡 |
Har bir 🔴 yonida bitta jumla: nima bo'ldi va nima qilyapmiz ("flaky rate oshdi — staging'dagi sekin to'lov mock'i; tuzatish shu sprintda").
> **🎯 Intervyuda:** "Rahbariyatga sifatni qanday ko'rsatasiz?" — Bir nechta trend metrikasi (escape rate, crash-free, ochiq kritik bug'lar), qizil-sariq-yashil holat va har bir muammoga aniq harakat rejasi; vanity metrikalar (masalan, faqat test case'lar soni) emas.
---
## 12. Bosim ostida qaror: "Juma kuni baribir chiqaramiz" {#bosim}
**Vaziyat:** Payshanba kechqurun. PM: "Ertaga reliz, marketing kampaniyasi boshlanadi. 3 ta Major bug'ni keyingi relizda tuzatamiz."
Hero darajasidagi QA hissiyot bilan "yo'q" demaydi va jimgina "ha" ham demaydi. U **riskni biznes tilida ko'rsatadi**:
1. **Faktlar:** har bir bug — kimga, qanchalik tez-tez, qanday oqibat bilan ta'sir qiladi; workaround bormi;
2. **Variantlar:** tuzatib, relizni 1 kunga surish; muammoli funksiyani feature flag bilan o'chirib chiqarish; "known issues" bilan chiqarish va monitoring kuchaytirish; relizni ko'chirish;
3. **Tavsiya:** sizning asoslangan fikringiz;
4. **Qarorni hujjatlashtirish:** kim, qachon, qaysi risk qabul qilindi.
Xabar namunasi:
```text
Mavzu: 2.1.0 reliz — 3 ta Major bug bo'yicha risk xulosasi
1) DB-412: Humo kartasi bilan to'lovda SMS tasdiqlash oynasi ba'zan 2 marta ochiladi.
Ta'sir: Humo to'lovlarining bir qismi; pul ikki marta yechilmaydi (tekshirildi).
Workaround: foydalanuvchi oynani yopib, qayta urinadi.
Tavsiya: known issue sifatida chiqarish mumkin; support'ga skript beramiz.
2) DB-418: BAHOR15 promo-kodi va "yangi mijoz" chegirmasi birga qo'llanib, ikkalasi qo'shiladi (25%).
Ta'sir: to'g'ridan-to'g'ri pul yo'qotish; kampaniya paytida keng tarqaladi.
Tavsiya: NO-GO yoki promo-kod funksiyasini flag bilan o'chirib chiqarish.
3) DB-421: iPad'da landshaft rejimida filtr paneli yarim qirqiladi.
Ta'sir: iPad foydalanuvchilarining kichik qismi, filtr baribir ishlaydi.
Tavsiya: known issue, keyingi relizda.
Umumiy tavsiya: 2-bandni hal qilmasdan chiqmaslik (flag yoki fix). Qolganlari — qabul qilsa bo'ladi.
Qaror egasi: PO. Qaror va qabul qilingan risklar reliz ticket'iga yoziladi.
```
> **💡 Maslahat:** Bitta bug'ni "pul yo'qotishi mumkin" deb aytish yetarli emas — iloji bo'lsa, ta'sirni o'lchang: nechta foydalanuvchi, qaysi oqim, qancha summa. Raqam bilan kelgan QA'ni hamma eshitadi.
> **🧠 Esda tuting:** Risk qabul qilinib, reliz chiqdi va keyin o'sha bug muammo keltirdi — bu QA'ning "mag'lubiyati" emas, agar risk aniq ko'rsatilgan va hujjatlashtirilgan bo'lsa. Bu — ongli biznes qarori edi.
---
## 13. Etuklik modellari: TMMi {#tmmi}
**TMMi (Test Maturity Model integration)** — tashkilotdagi test jarayonining etukligini baholash va yaxshilash uchun model. U TMMi Foundation tomonidan boshqariladi va 5 ta darajadan iborat:
| Daraja | Nomi | Qisqacha mazmuni |
| ------ | ---------------- | --------------------------------------------------------------------------------- |
| 1 | **Initial** | Testlash tartibsiz, ko'pincha debugging bilan aralash |
| 2 | **Managed** | Test siyosati va strategiyasi, rejalashtirish, monitoring va nazorat bor |
| 3 | **Defined** | Testlash butun hayot sikliga integratsiya qilingan, tashkilot darajasida standart |
| 4 | **Measured** | Test jarayoni metrikalar bilan o'lchanadi va boshqariladi |
| 5 | **Optimization** | Defektlarning oldini olish, jarayonni doimiy yaxshilash |
Daraja faqat oldingi darajaning barcha maqsadlari bajarilgandan keyin hisoblanadi — bosqichlarni "sakrab o'tib" bo'lmaydi.
Amaliy foydasi: jamoangiz qayerda turganini tushunish va **keyingi qadamni** tanlash. Masalan, agar risk register ham, test strategiyasi ham yo'q bo'lsa — siz hali 2-darajaga ham yetmagansiz va metrikalar bilan "4-daraja" o'ynashga hojat yo'q.
> **⚠️ Diqqat:** Etuklik modeli — o'z-o'zidan maqsad emas. Sertifikat uchun "qog'oz jarayon" yaratish Goodhart qonunining yana bir ko'rinishi. Wikipedia ma'lumotiga ko'ra modelning 2.0 versiyasi 2026-yil iyunida taqdim etilgan — rasmiy tafsilotlarni tmmi.org'da tekshiring.
---
## 14. Amaliy mashqlar {#mashqlar}
### Mashq 1: Risk darajasini hisoblang (🟢)
DemoBozor'ning yangi relizida quyidagi o'zgarishlar bor. Risk darajasini hisoblang, zonani aniqlang va test chuqurligini tanlang.
| Funksiya | Ehtimollik | Ta'sir |
| -------------------------------------- | ---------- | ------ |
| A. Yangi to'lov provayderi (Humo) | 5 | 5 |
| B. Qidiruvga "so'nggi qidiruvlar" | 2 | 2 |
| C. Muddatli to'lovda 24 oylik variant | 3 | 4 |
| D. Footer'dagi havolalar yangilandi | 1 | 1 |
| E. Savatchada miqdor limitini 99 → 199 | 3 | 3 |
💡 Javobni ko'rish
| Funksiya | Daraja | Zona | Test chuqurligi |
| -------- | ------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| A | 25 | 🔴 Yuqori | Decision table (karta turlari × natijalar), API + E2E avtomatlashtirish, xato javoblari, idempotentlik, exploratory, security tekshiruvi |
| B | 4 | 🟢 Past | Checklist, qisqa exploratory |
| C | 12 | 🟡 O'rta | EP + BVA (muddat variantlari, summa chegaralari), API testlar; qoidalar biznes bilan qayta tasdiqlanadi |
| D | 1 | 🟢 Past | Havolalarni avtomatik tekshirish (link checker) yoki tez ko'z yugurtirish |
| E | 9 | 🟡 O'rta | BVA (2 qiymatli): 0, 1, 199, 200; savatcha summasi va yetkazish narxi qayta hisoblanishi |
Qo'shimcha: C uchun muhim savol — 24 oy biznes qoidasi rasman tasdiqlanganmi? Kontraktdagi qoida hozircha 3, 6 yoki 12 oy. Talab o'zgarganini PO bilan aniqlashtirish — QA'ning birinchi ishi.
### Mashq 2: DRE va escape rate (🟢)
v2.1 relizidan oldin 85 ta defekt topildi. Relizdan keyingi 30 kunda production'da 15 ta defekt topildi. Oldingi relizda DRE 92% edi. Hisoblang va xulosa qiling.
💡 Javobni ko'rish
```text
DRE = 85 / (85 + 15) × 100 = 85%
Escape rate = 15 / 100 × 100 = 15%
```
DRE 92% → 85% ga tushdi: testlash samaradorligi pasaygan. Keyingi qadamlar:
1. 15 ta production defektini tahlil qiling: qaysi modul, qaysi severity, nega testda topilmadi (qamrov yo'q, muhit farqi, ma'lumot farqi, vaqt yetmadi?);
2. Har bir "qochgan" kritik defekt uchun regression testi qo'shing;
3. Risk register'ni yangilang (qaysi joyning ehtimolligi oshdi);
4. Muhit farqi sabab bo'lgan bo'lsa — staging'ni prod'ga yaqinlashtirish bo'yicha DevOps bilan gaplashing.
### Mashq 3: Qaysi modulga e'tibor beramiz? (🟡)
| Modul | Defektlar (oxirgi 3 reliz) | Hajm (KLOC) |
| -------- | -------------------------- | ----------- |
| Savatcha | 24 | 8 |
| Katalog | 36 | 24 |
| Buyurtma | 15 | 3 |
| Profil | 6 | 6 |
Defect density'ni hisoblang. Keyingi sprintda qaysi modulga ko'proq test kuchi ajratasiz va nega?
💡 Javobni ko'rish
| Modul | Density (defekt/KLOC) |
| -------- | --------------------- |
| Savatcha | 24 / 8 = **3.0** |
| Katalog | 36 / 24 = 1.5 |
| Buyurtma | 15 / 3 = **5.0** |
| Profil | 6 / 6 = 1.0 |
Eng yuqori zichlik — **Buyurtma** (5.0), keyin Savatcha (3.0). Defektlar soni bo'yicha Katalog birinchi bo'lsa ham, zichlik past. Xulosa: Buyurtma moduliga regression va exploratory vaqtini oshirish, kod review'ni kuchaytirish va state transition testlarini avtomatlashtirish. Lekin faqat raqamga qaramang: ta'sirni ham hisobga oling — Buyurtma pul bilan bog'liq, ya'ni risk ham yuqori.
### Mashq 4: Exit criteria yozing (🟡)
DemoBozor v2.2 relizida "Muddatli to'lov" funksiyasi qo'shilmoqda. Shu reliz uchun 6 ta **o'lchanadigan** exit criteria yozing.
💡 Javobni ko'rish
Namuna (raqamlar jamoa bilan kelishiladi):
1. Muddatli to'lov bo'yicha barcha test case'lar (EP + BVA: yosh 17/18/65/66, summa 499 999 / 500 000 / 30 000 000 / 30 000 001, muddat 3/6/12 va noto'g'ri qiymatlar) bajarilgan — 100%;
2. Ochiq Blocker va Critical bug'lar — 0;
3. Har bir ochiq Major bug uchun PO qarori va workaround yozilgan;
4. To'lov va buyurtma oqimining avtomatik regressiyasi yashil; yiqilishlarning har biri tahlil qilingan;
5. Feature flag yoqilgan va o'chirilgan holatlarda ham asosiy checkout ishlashi tekshirilgan;
6. Release notes va foydalanuvchiga ko'rinadigan matnlar uch tilda (o'zbek, rus, ingliz) tekshirilgan.
Yomon misol: "funksiya yaxshi testlangan bo'lishi kerak" — o'lchab bo'lmaydi.
### Mashq 5: "3 ta Major bilan chiqamizmi?" (🔴)
Reliz ertaga. Ochiq bug'lar:
1. Rus tilida "Корзина" sahifasi sarlavhasi inglizcha "Cart" bo'lib qolgan;
2. Android 12'da push bildirishnomani bosganda ilova bosh sahifani ochadi (buyurtma sahifasini emas);
3. Promo-kodni ikki brauzer tab'ida bir vaqtda qo'llasa, u ikki marta ishlatiladi.
Har biri uchun ta'sirni baholang va reliz bo'yicha tavsiya bering.
💡 Javobni ko'rish
| Bug | Ta'sir | Workaround | Tavsiya |
| --- | ------------------------------------------------------------ | ----------------------------------- | --------------------------------------------------------------------------------------------------------- |
| 1 | Kosmetik l10n xatosi, funksiya ishlaydi | Kerak emas | Known issue, keyingi reliz |
| 2 | Navigatsiya noqulay, buyurtmani qo'lda topish mumkin | "Buyurtmalarim" bo'limi | Known issue, support'ga eslatma |
| 3 | Race condition → pul yo'qotish, suiiste'mol qilinishi mumkin | Yo'q (foydalanuvchi foydasiga xato) | **Hal qilmasdan chiqmaslik**: server tomonida tuzatish yoki promo-kodlarni vaqtincha flag bilan o'chirish |
Umumiy tavsiya: 3-bug hal qilinmaguncha — NO-GO (yoki promo-kod funksiyasini o'chirib GO). Qaror PO'da, QA riskni raqam va oqibatlar bilan ko'rsatadi va qarorni reliz ticket'iga yozadi. Bundan tashqari: 3-bug uchun parallel so'rovlar bilan API testi yozing — u regression to'plamida qolsin.
### Mashq 6: Goodhart tuzog'ini toping (🟡)
Yangi rahbar QA jamoasi uchun quyidagi KPI'larni taklif qildi. Qaysilari zararli va ularni nima bilan almashtirasiz?
1. Har bir QA haftasiga kamida 15 ta bug topsin;
2. Production'dagi Critical incident'lar soni chorakdan-chorakka kamaysin;
3. Avtomatik testlar soni har oy 10% oshsin;
4. Relizdan keyingi 30 kunda escape rate 8% dan oshmasin.
💡 Javobni ko'rish
| KPI | Baho | Nega | Alternativ |
| --- | ------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------- |
| 1 | ❌ Zararli | Bug'lar maydalanadi, sifatli ish emas — son quvladi | Topilgan bug'lar severity'si va escape rate trendi |
| 2 | ✅ Yaxshi (ehtiyot bilan) | Mijozga ta'sirni o'lchaydi; incident yashirilmasligi kerak | Incident'lar + post-mortem'lardagi harakatlar bajarilishi |
| 3 | ❌ Zararli | Testlar soni ≠ qiymat; foydasiz yoki flaky testlar ko'payadi | Qizil zonadagi risklarning avtomat qamrovi, flaky rate |
| 4 | ✅ Yaxshi | Testlash samaradorligi; jamoa darajasida, trend sifatida kuzatiladi | DRE bilan birga |
### Mashq 7: Phased release'ning 3-kuni (🟡)
iOS 2.3.0 phased release'ning 3-kuni. Crashlytics'da crash-free users 99.7% dan 97.9% ga tushdi; crash'larning ko'pi yangi "Sevimlilar" ekranida. Nima qilasiz? Hozir yangi versiyani kimlar olgan bo'lishi mumkin?
💡 Javobni ko'rish
1. **Phased release'ni pause qiling** (App Store Connect'da) — avtomatik yangilanish orqali yangi foydalanuvchilar olishi to'xtaydi. Jami pauza 30 kungacha bo'lishi mumkin.
2. Agar "Sevimlilar" feature flag ortida bo'lsa — **flag'ni o'chiring**: crash olgan foydalanuvchilarni ham darhol himoya qiladi.
3. Crash'ni qayta hosil qiling (stack trace, qurilma/OS taqsimoti), hotfix branch, maqsadli regressiya, yangi build (zarurat bo'lsa expedited review so'rash mumkin).
4. Kimlar olgan: 3-kunda jadval bo'yicha avtomatik yangilanish yoqilgan foydalanuvchilarning 5% gacha qismi **va** App Store'dan qo'lda yangilagan har qanday foydalanuvchi.
5. Post-mortem: nega testda topilmadi? Masalan, eski iOS versiyasi yoki katta ma'lumotli akkaunt — device matrix va test ma'lumotlariga qo'shing.
---
## 15. O'zingizni tekshiring {#checklist}
- [ ] Test strategiyasi va test plan farqini misol bilan tushuntira olaman
- [ ] Risk register tuzib, ehtimollik × ta'sir bo'yicha zonalarga ajrata olaman
- [ ] Risk darajasiga qarab test chuqurligini asoslab bera olaman
- [ ] DRE, escape rate, defect density va flaky rate'ni hisoblay olaman
- [ ] Goodhart qonunini va zararli KPI'larni taniy olaman
- [ ] DORA'ning 5 ta metrikasini va QA'ning ularga ta'sirini bilaman
- [ ] Go/no-go yig'ilishiga nima olib borishni bilaman
- [ ] Apple phased release va Google Play staged rollout farqini tushuntira olaman
- [ ] "Shunchaki chiqaramiz" bosimiga risk tilida javob bera olaman
---
## Xulosa {#xulosa}
- Hero darajasidagi QA'ning ishi — sifat riskini ko'rinadigan qilish va to'g'ri qarorga yordam berish; u gatekeeper emas, ma'lumotli maslahatchi.
- Test strategiyasi qisqa bo'lsin: kontekst, risklar, darajalar, texnikalar, muhitlar, avtomatlashtirish, mezonlar, metrikalar.
- Risk = ehtimollik × ta'sir; test chuqurligi risk zonasiga qarab taqsimlanadi, risk register har relizdan keyin yangilanadi.
- Exit criteria o'lchanadigan bo'lsin; foizlardan ko'ra **qaysi** testlar yiqilgani va qolgan risk muhim.
- Metrikalar savolga javob beradi; Goodhart qonunini unutmang — trendlarga qarang, odamlarni emas, jarayonni baholang.
- DORA hozir 5 ta metrika bilan ishlaydi (2024-yildan rework rate qo'shilgan); yaxshi testlar tezlik va barqarorlikni birga yaxshilaydi.
- Mobil relizni qaytarib bo'lmaydi: phased release / staged rollout, feature flag va monitoring — asosiy himoya.
- Bosim ostida faktlar, variantlar, tavsiya va hujjatlashtirilgan qaror bilan ishlang.
- **Keyingi dars:** [QA 28: Karyera — CV, portfolio, ISTQB sertifikati, 60+ intervyu savoli va birinchi ish](/ios-lessons/qa-career-interview)
## Manbalar {#manbalar}
1. [ISTQB — Certified Tester Foundation Level Syllabus v4.0.1 (PDF, 2024)](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf)
2. [ISTQB — Expert Level Test Management Syllabus (PDF, 2011)](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB-CTEL-TM_Syllabus_v1.0_2011.pdf)
3. [DORA — Software delivery performance metrics](https://dora.dev/guides/dora-metrics/)
4. [DORA — A history of DORA's software delivery metrics](https://dora.dev/insights/dora-metrics-history/)
5. [Apple — Release a version update in phases](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases)
6. [Google Play Console Help — Release app updates with staged rollouts](https://support.google.com/googleplay/android-developer/answer/6346149)
7. [Firebase — Understand crash-free metrics](https://firebase.google.com/docs/crashlytics/crash-free-metrics)
8. [Apple — App Review: expedited review so'rovi](https://developer.apple.com/contact/app-store/?topic=expedite)
9. [Martin Fowler — Feature Toggles (aka Feature Flags)](https://martinfowler.com/articles/feature-toggles.html)
10. [Google SRE Workbook — Canarying Releases](https://sre.google/workbook/canarying-releases/)
11. [Wikipedia — Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s_law)
12. [TMMi Foundation](https://www.tmmi.org/)
13. [Wikipedia — Testing Maturity Model (TMMi haqida)](https://en.wikipedia.org/wiki/Testing_Maturity_Model)