QA 27: Test strategiyasi, metrikalar va QA Lead — risk-based testing, release va jarayon qurish

🧪 QA Engineer — Zero to Hero

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
2. Test strategiyasi nima va nimadan iborat
3. Risk-based testing: risk = ehtimollik × ta'sir
4. DemoBozor uchun 1 sahifali test strategiyasi
5. Muhitlar, test ma'lumotlari va avtomatlashtirish strategiyasi
6. Kirish va chiqish mezonlari
7. Sifat metrikalari: formulalar va tuzoqlar
8. DORA metrikalari va QA'ning ta'siri
9. Reliz boshqaruvi: go/no-go, bosqichma-bosqich chiqarish, rollback
10. Shift-right: production'dagi sifat
11. QA jarayonini qurish va QA Lead roli
12. Bosim ostida qaror: "Juma kuni baribir chiqaramiz"
13. Etuklik modellari: TMMi
14. Amaliy mashqlar
15. O'zingizni tekshiring
16. Xulosa
17. 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:

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). 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).

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:

Strategiya yondashuvlari

Amalda strategiya bir nechta yondashuvning aralashmasi bo'ladi. ISTQB'ning Expert Level Test Management syllabus'ida (2011) ular quyidagicha guruhlangan:

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

Testlash asosan mahsulot riskiga 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:

💡 Maslahat: Ehtimollikni baholashda tarixdan foydalaning: oldingi relizlarda qaysi modulda ko'p bug chiqqan? "Defektlar to'planadi" printsipi (QA 2) bu yerda ishlaydi.

Risk matritsasi: DemoBozor funksiyalari ehtimollik va ta'sir bo'yicha

Risk register (risklar reyestri)

Risklar jadvalda yuritiladi va har relizdan keyin yangilanadi:

Test chuqurligini risk bo'yicha taqsimlash

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.

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

Test ma'lumotlari strategiyasi

• Sintetik ma'lumot — asosiy usul: faker yoki seed skriptlar bilan yaratiladi (QA 17).
• 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

Bu — test piramidasining amaliy ko'rinishi (QA 4, QA 16). CI'dagi ishga tushirish tafsilotlari — QA 21.

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)

⚠️ 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:

Ishlangan misol: DemoBozor v2.0

Relizdan oldin QA 120 ta defekt topdi. Relizdan keyingi 30 kunda production'da yana 8 ta defekt topildi.

DRE         = 120 / (120 + 8) × 100 = 93.75%
Escape rate =   8 / (120 + 8) × 100 =  6.25%

Modullar bo'yicha defect density:

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:

🧠 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.

💡 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

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)

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:

🧠 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):

• 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)

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). Shift-right esa production'dan sifat haqida ma'lumot olish. Hero darajasidagi QA ikkalasini ham boshqaradi.

Teskari aloqa halqasi — shift-right'ning eng qimmatli qismi:

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

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);
• 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

Jamoa kelishgan javob muddati (SLA) namunasi — sizning jamoangizda boshqacha bo'lishi mumkin:

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)

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'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):

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.

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):

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:

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 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.

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

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.

</details>

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.

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

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.

</details>

Mashq 3: Qaysi modulga e'tibor beramiz? (🟡)

Defect density'ni hisoblang. Keyingi sprintda qaysi modulga ko'proq test kuchi ajratasiz va nega?

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

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.

</details>

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.

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

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.

</details>

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.

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

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.

</details>

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.

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

</details>

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?

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

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.

</details>

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}