QA 4: Testlash darajalari va turlari — Unit'dan UAT'gacha, Smoke, Sanity, Regression va Test Pyramid

🧪 QA Engineer — Zero to Hero

QA 4: Testlash darajalari va turlari — Unit'dan UAT'gacha, Smoke, Sanity, Regression va Test Pyramid

Holat: 2026-yil oktabr. Bu darsda ISTQB v4.0'dagi 5 ta test darajasi, test turlari (funksional, nofunksional, black-box, white-box), ISO/IEC 25010 sifat xususiyatlari, statik va dinamik testlash, review turlari, confirmation va regression testing, smoke/sanity farqi, maintenance testing hamda Test Pyramid va uning muqobillarini o'rganamiz. Kod misoli Vitest 5 bilan tekshirilgan.

Bu darsdan keyin siz: har qanday test haqida "bu qaysi darajada va qaysi turdagi test?" degan savolga aniq javob berasiz va testlarni to'g'ri qatlamga joylashtirasiz.

• Component, component integration, system, system integration va acceptance darajalarini farqlaysiz.
• Funksional va nofunksional testlashni, ISO/IEC 25010 xususiyatlarini misollar bilan tushuntirasiz.
• Smoke, sanity, regression va retesting farqini intervyu darajasida bilasiz.
• Review turlarini va statik testlash qaysi defektlarni yaxshi topishini bilasiz.
• Test pyramid, testing trophy va "muzqaymoq" anti-pattern'ini tushunasiz.

Mundarija

1. Daraja va tur: farqi nima
2. 5 ta test darajasi
3. Funksional va nofunksional testlash
4. Black-box, white-box va grey-box
5. Statik va dinamik testlash, review turlari
6. Confirmation va regression testing
7. Smoke, Sanity, Regression va Retesting
8. Boshqa muhim test turlari
9. Maintenance testing
10. Test Pyramid, Testing Trophy va "muzqaymoq"
11. Amaliy mashqlar
12. O'zingizni tekshiring
13. Xulosa
14. Manbalar

1. Daraja va tur: farqi nima {#daraja-va-tur}

Yangi QA'lar ko'pincha "unit test" va "performance test" ni bir qatorga qo'yadi. Aslida ular turli o'qlarda yotadi:

• Test darajasi (test level) — test faoliyatlarining birga tashkil qilinadigan va boshqariladigan guruhi. Har bir daraja — dasturning ma'lum bir ishlab chiqish bosqichiga bog'langan test jarayonining nusxasi: alohida komponentdan to butun tizimgacha. Oddiy qilib aytganda — "qaysi ko'lamda?"
• Test turi (test type) — ma'lum sifat xususiyatiga bog'langan test faoliyatlari guruhi. Ko'pchilik test turlarini har qanday darajada bajarish mumkin. Oddiy qilib — "nimani tekshiramiz?"

🧠 Esda tuting: Daraja — "qayerda/qaysi ko'lamda", tur — "nimani". Bitta test ham darajaga, ham turga ega: "system darajasidagi performance testi".

2. 5 ta test darajasi {#darajalar}

ISTQB v4.0 beshta test darajasini tasvirlaydi. Ular bir-biridan test obyekti, test maqsadlari, test asosi, topiladigan defekt va failure'lar, yondashuv va mas'uliyat bilan farqlanadi.

Component testing

Komponentni boshqa qismlardan ajratib tekshiradi; ko'pincha maxsus vositalar — test harness yoki unit test framework kerak bo'ladi. DemoBozor'ning yetkazib berish narxini hisoblovchi funksiyasi uchun Vitest testi:

// pricing.js — DemoBozor qoidasi:
// mahsulotlar summasi >= 300 000 so'm bo'lsa yetkazib berish bepul, aks holda 20 000 so'm
export const FREE_DELIVERY_THRESHOLD = 300_000;
export const DELIVERY_FEE = 20_000;

export function deliveryFee(subtotal) {
  return subtotal >= FREE_DELIVERY_THRESHOLD ? 0 : DELIVERY_FEE;
}

// pricing.test.js — `npx vitest run` bilan ishga tushiriladi
import { describe, test, expect } from "vitest";
import { deliveryFee } from "./pricing.js";

describe("deliveryFee — component (unit) test", () => {
  test("299 999 so'm — yetkazib berish 20 000 so'm", () => {
    expect(deliveryFee(299_999)).toBe(20_000);
  });

  test("300 000 so'm — chegara, yetkazib berish bepul", () => {
    expect(deliveryFee(300_000)).toBe(0);
  });

  test("300 001 so'm — yetkazib berish bepul", () => {
    expect(deliveryFee(300_001)).toBe(0);
  });
});

QA 2 darsidagi > xatosi kodda bo'lganida, aynan ikkinchi test yiqilardi. Component testlar odatda dasturchilar tomonidan yoziladi, lekin qaysi chegaralarni tekshirish kerakligini QA ko'pincha yaxshiroq biladi — shuning uchun ular haqida birga gaplashing. iOS'da bu XCTest yoki Swift Testing bo'ladi: Testing — XCTest.

Component integration testing

Komponentlar orasidagi interfeys va o'zaro ta'sirni tekshiradi. ISTQB bo'yicha u integratsiya strategiyasiga kuchli bog'liq: bottom-up (pastdan yuqoriga), top-down (yuqoridan pastga) yoki big-bang (hammasini birdaniga ulash). DemoBozor misoli: savatcha xizmati narx modulidan deliveryFee ni so'raydi va bazaga to'g'ri summani yozadimi?

System testing

Butun tizimning xatti-harakatini tekshiradi: ko'pincha end-to-end vazifalarning funksional testi va nofunksional xususiyatlar (masalan, usability ba'zan faqat to'liq tizimda, vakillik qiladigan muhitda yaxshi baholanadi). Quyi tizimlarning simulyatsiyalari ham ishlatilishi mumkin. Odatda mustaqil test jamoasi bajaradi va tizim spetsifikatsiyasiga tayanadi.

System integration testing

Test qilinayotgan tizim bilan boshqa tizimlar va tashqi xizmatlar orasidagi interfeyslarni tekshiradi. Operatsion muhitga o'xshash test muhiti kerak. DemoBozor uchun bu: to'lov provayderining test (sandbox) muhiti, SMS shlyuzi, yetkazib berish xizmati API'si.

⚠️ Diqqat: Tashqi xizmatlar sandbox'i ko'pincha production'dan farq qiladi: boshqa vaqt chegaralari, cheklangan test kartalari, boshqa xato kodlari. Integratsiya testlarida bu farqlarni hujjatlashtiring va production'dagi birinchi to'lovlarni kuzatib boring.

Acceptance testing

Validatsiya va deploy'ga tayyorlikni ko'rsatishga qaratilgan: tizim foydalanuvchining biznes ehtiyojlarini qondiradimi? Ideal holatda uni mo'ljallangan foydalanuvchilar bajaradi. ISTQB acceptance testingning asosiy shakllarini sanaydi:

3. Funksional va nofunksional testlash {#funksional-nofunksional}

Funksional testlash

Komponent yoki tizim bajarishi kerak bo'lgan funksiyalarni baholaydi — "tizim nima qiladi?". ISTQB bo'yicha asosiy maqsad: funksional to'liqlik (completeness), funksional to'g'rilik (correctness) va funksional maqsadga muvofiqlik (appropriateness) ni tekshirish.

Nofunksional testlash

Funksional bo'lmagan xususiyatlarni baholaydi — "tizim qanchalik yaxshi ishlaydi?". ISTQB v4.0.1 ISO/IEC 25010 standartidagi tasnifga tayanadi:

ISO/IEC 25010 standartining yangi (2023) tahririda "usability" o'rniga interaction capability, "portability" o'rniga flexibility nomlari ishlatiladi va safety alohida xususiyat sifatida berilgan. ISTQB v4.0.1 eski va yangi nomlarni birga keltiradi — intervyuda ikkalasini ham bilish foydali.

ISTQB nofunksional testlash haqida yana uch muhim narsani aytadi:

• Nofunksional testlashni ba'zan erta boshlash maqsadga muvofiq (review'lar yoki component testlar orqali).
• Ko'p nofunksional testlar funksional testlardan kelib chiqadi: o'sha funksiya bajariladi, lekin qo'shimcha cheklov tekshiriladi (masalan, "promo-kod 1 soniyadan tez qo'llanadimi?").
• Nofunksional defektning kech topilishi loyiha uchun jiddiy xavf; ba'zi testlar maxsus muhit talab qiladi (masalan, usability laboratoriyasi).

4. Black-box, white-box va grey-box {#black-white-grey}

ISTQB'da asosiy test turlari to'rtta: funksional, nofunksional, black-box va white-box. Ularning hammasini barcha darajalarda qo'llash mumkin, faqat fokus farq qiladi. "Grey-box" — sanoatda keng ishlatiladigan amaliy atama: QA'larning ko'pchiligi aynan shunday ishlaydi — UI orqali harakat qiladi, lekin natijani API, loglar yoki baza orqali ham tasdiqlaydi (QA 12).

Black-box texnikalari (EP, BVA, decision table, state transition) — QA 5 va QA 6; white-box (statement va branch coverage) — QA 6.

5. Statik va dinamik testlash, review turlari {#statik-dinamik}

Dinamik testlash — dasturni ishga tushirib tekshirish. Statik testlash — ish mahsulotini ishga tushirmasdan tekshirish: odamlar tomonidan review yoki asboblar tomonidan static analysis.

Statik testlash deyarli har qanday ish mahsulotiga qo'llanadi: talablar, kod, test plan, test case, backlog elementlari, test charter'lar, hujjatlar, shartnomalar va modellar. ISTQB statik va dinamik testlash farqlarini shunday sanaydi:

Statik testlash bilan osonroq va arzonroq topiladigan defektlar (ISTQB):

• Talablardagi defektlar: ziddiyatlar, noaniqliklar, qarama-qarshiliklar, tushib qolgan narsalar, noaniq ma'lumotlar, takrorlanishlar.
• Dizayn defektlari: samarasiz baza tuzilmasi, yomon modullashtirish.
• Kodlash defektlarining ayrim turlari: qiymatsiz yoki e'lon qilinmagan o'zgaruvchilar, erishib bo'lmaydigan yoki takrorlangan kod, haddan tashqari murakkablik.
• Standartlardan chetga chiqish (nomlash qoidalari).
• Noto'g'ri interfeys spetsifikatsiyalari (parametrlar soni, turi yoki tartibi mos emas).
• Ayrim xavfsizlik zaifliklari (masalan, buffer overflow).
• Test asosini qamrashdagi bo'shliqlar (masalan, acceptance criterion uchun test yo'q).

Review turlari

Inspection'da muallif review leader yoki kotib (scribe) bo'la olmaydi. Static analysis asboblari: JavaScript/TypeScript uchun ESLint, Swift uchun SwiftLint, Kotlin uchun detekt yoki ktlint, ko'p tillar uchun SonarQube kabi platformalar.

🎯 Intervyuda: "Statik testlash nima va unga misol keltiring." — "Dasturni ishga tushirmasdan tekshirish: talablar va kod review'i, static analysis. Masalan, talab review'ida '300 000 so'mdan ortiq' iborasidagi chegara noaniqligini topish — bu defektni hech qanday kod yozilmasdan tuzatadi."

6. Confirmation va regression testing {#retest-regression}

Dastur o'zgarganda (yangi funksiya yoki bug tuzatish) ikki xil test kerak:

• Confirmation testing (retesting) — asl defekt muvaffaqiyatli tuzatilganini tasdiqlaydi. Avval yiqilgan testlarni qayta bajarish va/yoki tuzatish uchun kiritilgan o'zgarishlarni qamraydigan yangi testlar qo'shish. Vaqt kam bo'lsa — kamida bug report'dagi qadamlar bajarilib, failure takrorlanmasligi tekshiriladi.
• Regression testing — o'zgarish (shu jumladan, tasdiqlangan tuzatish) boshqa joyda salbiy oqibat keltirmaganini tasdiqlaydi. Oqibatlar o'sha komponentda, tizimning boshqa komponentlarida yoki hatto bog'langan tizimlarda bo'lishi mumkin. Regression muhitga ham tegishli bo'lishi mumkin.

Regression ko'lamini aniqlash uchun avval impact analysis (ta'sir tahlili) qilinadi: dasturning qaysi qismlari o'zgarishdan ta'sirlanishi mumkin?

DemoBozor misoli. Bug: Humo kartalar bilan to'lov rad etilyapti. Dasturchi karta turini aniqlash funksiyasini tuzatdi.

ISTQB'ning muhim kuzatuvi: regression to'plamlari ko'p marta bajariladi va har iteratsiyada o'sib boradi — shuning uchun regression avtomatlashtirish uchun eng kuchli nomzod. Avtomatlashtirishni loyihaning boshidan boshlash va CI'ga regression testlarni kiritish yaxshi amaliyot (QA 16, QA 21).

7. Smoke, Sanity, Regression va Retesting {#smoke-sanity}

Bu to'rtta atama intervyularda eng ko'p chalkashtiriladi. Kompaniyalarda ularning ma'nosi biroz farq qilishi mumkin — quyida eng keng tarqalgan talqin:

Smoke test ko'pincha build verification test (BVT) deb ham ataladi: agar u yiqilsa, chuqur testlashni boshlashning ma'nosi yo'q — build qaytariladi. ISTQB testing quadrants modelida smoke testlar Q4 ga kiritilgan (QA 3).

🎯 Intervyuda: "Smoke va sanity farqi?" — "Smoke — yangi build'ning asosiy funksiyalari umuman ishlashini tekshiradigan keng va yuzaki test: yiqilsa, build test uchun qabul qilinmaydi. Sanity — o'zgargan yoki tuzatilgan joyni tor va chuqurroq tekshirish, odatda to'liq regression'dan oldin. Ba'zi manbalar bu atamalarni sinonim sifatida ishlatadi, shuning uchun jamoada qaysi ma'noda ishlatilishini aniqlashtiraman."

8. Boshqa muhim test turlari {#boshqa-turlar}

9. Maintenance testing {#maintenance}

Mahsulot foydalanishga chiqqandan keyin ham o'zgaradi. ISTQB bo'yicha maintenance (texnik xizmat) tuzatuvchi (corrective), muhitga moslashtiruvchi (adaptive) yoki performance/maintainability'ni yaxshilovchi bo'lishi mumkin; rejalashtirilgan relizlar va rejalashtirilmagan tezkor tuzatishlar (hotfix) bilan amalga oshadi.

Maintenance testing ikkita narsani tekshiradi: o'zgarish muvaffaqiyatli joriy qilinganmi va tizimning o'zgarmagan qismlarida (odatda tizimning katta qismi) regressiya bormi. Ko'lami quyidagilarga bog'liq: o'zgarish riski, mavjud tizim hajmi, o'zgarish hajmi.

💡 Maslahat: Hotfix — eng xavfli reliz turi: vaqt kam, bosim katta. Hotfix uchun oldindan tayyorlangan minimal regression to'plami (smoke + o'zgargan sohaga yaqin testlar) jamoani panikadan saqlaydi.

10. Test Pyramid, Testing Trophy va "muzqaymoq" {#pyramid}

ISTQB bo'yicha test pyramid — turli testlarning turli granularlikka ega ekanini ko'rsatuvchi model. U avtomatlashtirish va test kuchini taqsimlashda yordam beradi: qatlam qanchalik yuqori bo'lsa, granularlik va izolyatsiya shunchalik past, bajarish vaqti esa shunchalik ko'p. Pastki qatlam testlari kichik, izolyatsiyalangan va tez — ular ko'p bo'ladi. Yuqori qatlamda murakkab end-to-end testlar — sekinroq, shuning uchun kam bo'ladi.

Test Pyramid, Testing Trophy va muzqaymoq anti-pattern'i yonma-yon

Qatlamlar soni va nomlari har xil bo'lishi mumkin: Cohn'ning asl modelida "unit", "service" va "UI"; boshqa mashhur variantda "unit (component)", "integration (component integration)" va "end-to-end". Ham Vocke'ning martinfowler.com'dagi maqolasi ikkita asosiy xulosani beradi: turli granularlikdagi testlar yozing va qatlam qanchalik yuqori bo'lsa, testlar shunchalik kam bo'lsin. U shuningdek "test ice-cream cone" haqida ogohlantiradi: bunday to'plamni qo'llab-quvvatlash og'ir va u juda uzoq ishlaydi.

Har tekshiruvni eng arzon qatlamga joylang

⚠️ Diqqat: Pyramid — dogma emas, nisbat haqidagi g'oya. Aniq foizlar yo'q. Agar jamoangizda 600 ta qo'lda UI test case va 40 ta unit test bo'lsa, siz "muzqaymoq"dasiz: har reliz qo'lda regression'ga kunlar ketadi va E2E testlar tez-tez sababsiz yiqiladi. QA'ning vazifasi — dasturchilar bilan birga qaysi tekshiruvni qaysi qatlamga ko'chirish mumkinligini kelishish.

11. Amaliy mashqlar {#mashqlar}

Mashq 1: Daraja va turni aniqlang

Har bir testning darajasi (component, component integration, system, system integration, acceptance) va turi (funksional, nofunksional; kerak bo'lsa black/white-box) ni yozing.

1. Dasturchi isValidPromoCode("BAHOR15") funksiyasi true qaytarishini tekshiradi.
2. QA staging'da ro'yxatdan o'tishdan buyurtma "DELIVERED" holatigacha butun oqimni sinaydi.
3. DemoBozor to'lov provayderining sandbox'iga 50 ta test to'lov yuboradi.
4. 300 ta virtual foydalanuvchi bir vaqtda katalogni ochadi, javob vaqti o'lchanadi.
5. Do'kon operatorlari yangi admin panelda bir kunlik buyurtmalarni qayta ishlaydi.
6. Savatcha xizmati narx moduliga to'g'ri parametrlar yuborishini tekshiruvchi test.
7. deliveryFee() funksiyasining ikkala if tarmog'i ham kamida bir marta bajarilganini o'lchash.
8. Ilova iPhone va Android'ning eng kichik ekranlarida to'g'ri ko'rinishini tekshirish.

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

</details>

Mashq 2: 10 ta smoke test

DemoBozor'ning yangi build'i staging'ga chiqdi. Uni chuqur testlashga qabul qilish uchun 10 ta smoke tekshiruvini tanlang (har biri 1–2 daqiqadan oshmasin).

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

Namunaviy to'plam:

1. Ilova/sayt ochiladi, bosh sahifa xatosiz yuklanadi.
2. Telefon raqami bilan SMS kod so'rash va kirish ishlaydi.
3. Katalog sahifasi va mahsulot kartochkalari yuklanadi.
4. Qidiruv natija qaytaradi (masalan, "choynak").
5. Mahsulot sahifasi ochiladi, narx ko'rinadi.
6. Mahsulot savatchaga qo'shiladi, savatcha soni yangilanadi.
7. Savatchada summa va yetkazib berish narxi ko'rsatiladi.
8. Checkout sahifasi ochiladi, to'lov usullari ro'yxati chiqadi.
9. Test karta bilan to'lov yakunlanadi va buyurtma yaratiladi.
10. "Mening buyurtmalarim" sahifasida yangi buyurtma ko'rinadi.

Tamoyil: keng, yuzaki, tez — har asosiy oqimdan bitta "tirikmi?" tekshiruvi. Chegara qiymatlar, xato xabarlari va murakkab ssenariylar smoke'ga kirmaydi.

</details>

Mashq 3: Promo-kod mantiqi o'zgardi — regression ko'lami

Dasturchi promo-kod qo'llash funksiyasini qayta yozdi: endi chegirma "yangi mijoz chegirmasi bilan solishtirilib, kattasi qo'llanadi" qoidasini hisoblash uchun umumiy calculateDiscount() funksiyasi ishlatiladi. Impact analysis qiling: qaysi sohalarni regression qilasiz?

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

To'g'ridan-to'g'ri ta'sir:

• Promo-kod qo'llash: format, muddat, minimal summa, bir martalik ishlatish.
• Yangi mijoz 10% va promo 15% — kattasi qo'llanishi; promo 10% dan kichik bo'lgan holat.
• Premium a'zo: bepul yetkazib berish chegirma bilan birga ishlashi.

**Bilvosita ta'sir (calculateDiscount() umumiy funksiya!):**

• Yetkazib berish narxi: chegirma summa 300 000 chegarasidan pastga tushirganda nima bo'ladi? (Talab aniqmi: chegara chegirmagacha yoki keyingi summaga qo'llanadimi?)
• Muddatli to'lov chegaralari (500 000 – 30 000 000 so'm) chegirmadan keyingi summa bilan to'g'ri tekshiriladimi?
• Buyurtma tafsilotlari, chek, email/SMS'dagi summalar.
• Admin panel hisobotlari (chegirmalar statistikasi).
• Pul qaytarish (RETURNED) — chegirmali buyurtmada qaytariladigan summa.

Qaysi qatlamda: hisob-kitob kombinatsiyalarini unit/API darajasida; 1–2 ta E2E ssenariyni UI'da.

Asosiy saboq: umumiy funksiya o'zgarsa, regression ko'lami kengayadi — impact analysis'da kodni kim chaqirishini dasturchidan so'rang.

</details>

Mashq 4: Retesting yoki regression?

1. DB-210 ("300 000 so'mda yetkazib berish haqi olinadi") tuzatildi — QA aynan shu qadamlarni bajaradi.
2. Shu tuzatishdan keyin Premium a'zolar uchun yetkazib berish ham tekshiriladi.
3. Har tun CI'da 400 ta avtomatik test ishga tushadi.
4. Humo bug'i tuzatildi — QA Humo bilan to'lovni qayta sinaydi.

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

1. Retesting (confirmation).
2. Regression — tuzatish boshqa joyni buzmaganini tekshirish.
3. Regression (avtomatlashtirilgan).
4. Retesting (confirmation).

</details>

Mashq 5: Qaysi review turi?

1. Muallif o'z dizayn hujjatini jamoaga tushuntirib beradi, maqsad — hamma bir xil tushunishi.
2. Moderator boshchiligida arxitektorlar ikki xil kesh yondashuvidan birini tanlaydi.
3. To'lov moduli talablari rasmiy jarayon bilan, rollar, tayyorgarlik va metrikalar bilan tekshiriladi.
4. QA story'ni o'qib, izohlarda savollar qoldiradi.

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

1. Walkthrough — muallif boshqaradi; o'qitish va kelishuv.
2. Technical review — texnik muammo bo'yicha qaror.
3. Inspection — eng rasmiy, metrikalar bilan.
4. Informal review.

</details>

Mashq 6: Jamoangiz qaysi shaklda?

Xayoliy DemoBozor jamoasining hozirgi test to'plami: 600 ta qo'lda bajariladigan UI test case, 120 ta avtomatik UI (E2E) test, 0 ta API test, 40 ta unit test. Regression har relizda 4 kun oladi, E2E testlarning 15 foizi sababsiz yiqiladi. (a) Bu qaysi shakl? (b) 3 ta yaxshilash qadamini taklif qiling.

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

(a) Muzqaymoq (ice-cream cone) anti-pattern'i: tepada ko'p qo'lda test, katta UI qatlam, pastda juda kam unit test, API qatlami umuman yo'q.

(b) Namunaviy reja:

1. Biznes qoidalarini pastga tushirish: chegirma, yetkazib berish va promo-kod qoidalarini UI orqali emas, unit va API testlar bilan qamrash (QA 20). Bu yuzlab qo'lda case'larni almashtiradi.
2. E2E to'plamini qisqartirish va barqarorlashtirish: faqat asosiy foydalanuvchi oqimlari qolsin; beqaror testlarning sababini topish yoki karantinga olish (QA 21).
3. Qo'lda regression'ni risk asosida qayta ko'rib chiqish: takroriy case'larni avtomatlashtirish yoki o'chirish; qo'lda vaqtni exploratory testlashga yo'naltirish.

Natijani metrikalar bilan kuzating: regression vaqti, beqaror testlar foizi, production'ga o'tib ketgan bug'lar soni (QA 27).

</details>

O'zingizni tekshiring {#checklist}

• [ ] Test darajasi va test turi farqini misol bilan tushuntira olaman.
• [ ] 5 ta test darajasini va acceptance testingning shakllarini sanay olaman.
• [ ] ISO/IEC 25010 nofunksional xususiyatlarini (eski va yangi nomlari bilan) bilaman.
• [ ] Black-box, white-box va grey-box farqini ayta olaman.
• [ ] 4 ta review turini rasmiylik darajasi bo'yicha tartiblay olaman.
• [ ] Smoke, sanity, regression va retesting farqini jadvalsiz tushuntira olaman.
• [ ] Test pyramid, testing trophy va muzqaymoq anti-pattern'ini chizib bera olaman.

Xulosa {#xulosa}

• Daraja — "qaysi ko'lamda" (component → acceptance), tur — "nimani" tekshiramiz (funksional, nofunksional, black-box, white-box). Ko'p turlar har darajada qo'llanadi.
• 5 daraja: component, component integration, system, system integration, acceptance. Acceptance — validatsiya: UAT, operational, contractual, regulatory, alpha va beta.
• Nofunksional xususiyatlar ISO/IEC 25010'ga tayanadi: performance efficiency, compatibility, interaction capability (usability), reliability, security, maintainability, flexibility (portability), safety.
• Statik testlash defektni to'g'ridan-to'g'ri topadi va erta, arzon; review turlari — informal, walkthrough, technical review, inspection.
• Retesting — "shu bug tuzaldimi?", regression — "boshqa joy buzilmadimi?". Regression — avtomatlashtirishning birinchi nomzodi; ko'lamni impact analysis belgilaydi.
• Smoke keng va yuzaki, sanity tor va chuqurroq; atamalar ma'nosini jamoada aniqlashtiring.
• Testlarni eng arzon qatlamga joylang: ko'p unit, kamroq API, kam E2E — muzqaymoq anti-pattern'idan qoching.
• Keyingi dars: QA 5: Test dizayn texnikalari (1) — Equivalence Partitioning, Boundary Value Analysis va Decision Table

Manbalar {#manbalar}

1. ISTQB CTFL Syllabus v4.0.1 (PDF, 2024-09-15)
2. ISO 25000 portali — ISO/IEC 25010 mahsulot sifati modeli
3. Martin Fowler — Test Pyramid
4. Ham Vocke (martinfowler.com) — The Practical Test Pyramid
5. Kent C. Dodds — The Testing Trophy and Testing Classifications
6. Lisa Crispin — Using the Agile Testing Quadrants
7. Vitest — rasmiy hujjatlar