QA 6: Test dizayn texnikalari (2) — State Transition, Pairwise, Use Case, White-box va Exploratory

🧪 QA Engineer — Zero to Hero

QA 6: Test dizayn texnikalari (2) — State Transition, Pairwise, Use Case, White-box va Exploratory

Holat: 2026-yil oktabr. Dars ISTQB CTFL v4.0.1 syllabus'ining 4.2.4 (state transition), 4.3 (white-box), 4.4 (experience-based) va 4.5 (collaboration-based) bo'limlariga tayanadi. Pairwise va use case testing joriy Foundation (v4.0) dasturiga kirmaydi, lekin amaliyotda juda ko'p ishlatiladi — ular ham shu yerda. Coverage misollari Node.js 24 va nyc 18 bilan ishga tushirib tekshirilgan.

Bu darsdan keyin siz: holat, kombinatsiya, ssenariy, kod tuzilishi va tajribaga asoslangan texnikalarni bir-biridan ajratib, vaziyatga mosini tanlay olasiz.

• buyurtma holatlari uchun state diagram va state table chizib, uchta coverage mezoni bo'yicha test yozasiz;
• yuzlab konfiguratsiyani pairwise bilan bir necha o'nta testga qisqartirasiz;
• use case'dan asosiy, muqobil va istisno ssenariylarni chiqarasiz;
• statement va branch coverage farqini real vosita natijasida ko'rasiz;
• charter, session va SFDIPOT bilan exploratory testingni tartibli o'tkazasiz.

Mundarija

1. State Transition testing
2. Pairwise va combinatorial testing
3. Use case va ssenariy testing
4. White-box: statement va branch coverage
5. Experience-based texnikalar
6. Collaboration-based yondashuvlar
7. Qaysi texnikani qachon tanlash kerak
8. Amaliy mashqlar
9. Xulosa
10. Manbalar

1. State Transition testing {#state-transition}

1.1. Qachon kerak?

Ba'zi tizimlarda natija faqat kiritishga emas, hozirgi holatga ham bog'liq. "Bekor qilish" tugmasi yangi buyurtmada ishlaydi, yo'ldagi buyurtmada esa ishlamasligi kerak. Bunday mantiqni EP yoki decision table yaxshi ko'rsatmaydi — unga state transition testing kerak.

Asosiy tushunchalar:

Syllabus'dagi yozuv formati: **event [guard] / action**. Guard va action bo'lmasa, tushirib qoldiriladi.

1.2. DemoBozor buyurtmasi: state diagram

Hodisalar ro'yxati:

DemoBozor buyurtmasining holatlar diagrammasi: 8 holat va 11 ta valid o'tish

Jami 8 ta holat va 11 ta valid o'tish: CREATED→PENDING_PAYMENT, CREATED→PACKING, PENDING_PAYMENT→PAID, PAID→PACKING, PACKING→SHIPPED, SHIPPED→DELIVERED, DELIVERED→RETURNED va to'rtta holatdan CANCELLED'ga.

1.3. State table — invalid o'tishlarni ko'rsatadigan ko'zgu

Diagramma faqat ruxsat etilgan o'tishlarni ko'rsatadi. State table esa hamma kombinatsiyani: qatorlar — holatlar, ustunlar — hodisalar. Bo'sh katak (bu yerda —) — invalid o'tish.

8 × 8 = 64 katak: 11 valid, 53 invalid. Har bir — — bitta potensial negativ test.

1.4. Uchta coverage mezoni

Syllabus xulosasi: all states — eng kuchsiz; valid transitions — eng ko'p ishlatiladigani; all transitions — mission va safety-critical tizimlar uchun minimal talab. To'liq valid transitions coverage all states coverage'ni kafolatlaydi.

1.5. Valid transitions coverage uchun test case'lar

Har bir test — hodisalar ketma-ketligi. Bitta test odatda bir nechta o'tishni qamraydi:

5 ta test → 11/11 valid o'tish (100%). Qiziq fakt: faqat TC-S1 va TC-S2 ning o'zi 8/8 holatni qamraydi — ya'ni all states coverage 2 ta test bilan to'ladi, lekin valid o'tishlarning faqat 8 tasini bajaradi. All states nega kuchsiz ekani shundan ko'rinib turibdi.

💡 Maslahat: Har bir o'tishda faqat holatni emas, action'ni ham tekshiring. TC-S5 da CANCELLED holatining o'zi yetarli emas — pul haqiqatan qaytdimi (to'lovlar jadvalida REFUNDED yozuvi bormi — QA 12)?

1.6. Invalid o'tishlar: qaysi birini tanlaymiz?

53 ta invalid o'tishning hammasini tekshirish ko'pincha qimmat. Risk bo'yicha eng xavflilarini tanlaymiz:

TC-N5 — state table'ning eng katta foydasi: to'lov provayderi javobi buyurtma bekor qilingandan keyin kelishi mumkin. Pul yechildi, buyurtma bekor. Avtomatik qaytariladimi? Talabda javob yo'q — demak PO bilan gaplashish kerak.

⚠️ Diqqat: Syllabus maslahati: bitta testda faqat bitta invalid o'tishni sinang. Aks holda birinchi xato ikkinchisini yashiradi (defect masking).

UI ko'pincha invalid o'tishlarni yashiradi: yo'ldagi buyurtmada "Bekor qilish" tugmasi ko'rinmaydi. Lekin API ochiq: xayoliy POST /api/v1/orders/{id}/cancel so'rovini SHIPPED buyurtmaga yuborib ko'ring. Kutilgan javob — xato kodi (masalan, 409 Conflict; aniq kodni API kontrakti belgilaydi) va holat o'zgarmasligi. Batafsil — QA 11.

E8 dagi guard [≤ 10 kun] — aslida chegara. Unga BVA'ni qo'llang: 10-kun (ruxsat), 11-kun (rad). Texnikalar yana birga ishlaydi.

🎯 Intervyuda: "State table diagrammadan nimasi bilan foydali?" — State table invalid o'tishlarni ham aniq ko'rsatadi (bo'sh kataklar). Shuning uchun negativ testlar va talabdagi bo'shliqlar (masalan, bekor qilingan buyurtmaga kelgan to'lov) aynan jadvalda ko'rinadi.

2. Pairwise va combinatorial testing {#pairwise}

2.1. Muammo: kombinatsiyalar portlashi

DemoBozor web-versiyasi uchun konfiguratsiyalar:

Hammasi: 4 × 4 × 4 × 5 = 320 kombinatsiya. Safari faqat macOS va iOS'da ishlaydi desak, 40 tasi o'chadi — baribir 280 ta. Har birini qo'lda tekshirish — haftalar.

2.2. G'oya va dalil

Pairwise (all-pairs) testing har bir juft parametrning har bir juft qiymati kamida bir marta uchrashishini kafolatlaydi. Masalan, "Firefox + kirill tili", "iOS + Humo", "rus tili + naqd" — har biri qaysidir testda bor.

Nega juftlar yetarli? NIST (AQSh Milliy standartlar va texnologiyalar instituti) tadqiqotlariga ko'ra, dasturiy bug va nosozliklarning ko'pchiligi bitta yoki ikkita parametr sababli yuzaga keladi, uch va undan ko'p parametr ishtirokidagilari borgan sari kamayadi; kuzatilgan nosozliklar 1 dan 6 tagacha o'zgaruvchining o'zaro ta'siri bilan qo'zg'algan. Shuning uchun pairwise — arzon va samarali kompromis, 3-wise esa kuchliroq variant.

🧠 Esda tuting: Pairwise ISTQB CTFL v4.0 Foundation dasturiga kirmaydi. Lekin intervyu va real loyihalarda u haqida albatta so'rashadi.

2.3. Qo'lda pairwise: 4 parametr × 3 qiymat = 9 ta test

Kichik holatda pairwise jadvalni orthogonal array (L9) bilan qo'lda tuzish mumkin. 3 × 3 × 3 × 3 = 81 kombinatsiya o'rniga 9 ta:

Tekshiruv: 6 juft parametr × 9 juft qiymat = 54 juftlik, hammasi jadvalda bor. Ishonmasangiz, ixtiyoriy juftni tanlang — masalan, "Safari + Naqd" (5-qator) yoki "Telefon + O'zbek" (7-qator).

💡 Maslahat: Pairwise jadvalni tuzgandan keyin uni kichik skript bilan tekshiring: barcha juftliklarni sanab, har birini qatorlar ichidan qidiradi. Qo'lda tuzilgan jadvaldagi bitta xato bir nechta juftlikni yo'qotadi.

2.4. PICT bilan avtomatik generatsiya

Kattaroq modellar uchun Microsoft'ning ochiq kodli PICT vositasi bor. Model fayl — oddiy matn: har qatorda Parametr: qiymat1, qiymat2, ..., keyin cheklovlar (constraints):

Brauzer: Chrome, Safari, Firefox, Edge
OT:      Windows, macOS, Android, iOS
Til:     uz_Latn, uz_Cyrl, ru, en
Tolov:   Uzcard, Humo, Visa, Mastercard, Naqd

IF [OT] IN {"Windows", "Android"} THEN [Brauzer] <> "Safari";

Ishga tushirish (PICT hujjatidagi sintaksis: pict model [options]):

pict demobozor.txt > checkout-configs.tsv   # standart: pairwise (/o:2)
pict demobozor.txt /o:3                     # 3-wise — kuchliroq, testlar ko'proq

Natija — birinchi qatorida parametr nomlari, keyingi qatorlarda tab bilan ajratilgan qiymatlar. Model va parametrlar o'zgarmasa, har ishga tushirishda natija bir xil chiqadi; /r opsiyasi tasodifiylashtiradi.

Nechta qator bo'ladi? Pastki chegarani o'zingiz hisoblay olasiz: eng katta ikki parametr — To'lov (5) va boshqa 4 qiymatli parametr. Ularning har bir jufti (5 × 4 = 20) kamida bitta qatorda bo'lishi kerak, demak 20 tadan kam bo'lishi mumkin emas. Bu 280 ga nisbatan juda kichik.

2.5. Pairwise'ning chegaralari

• Uch parametr birga bo'lgandagina chiqadigan bug'ni kafolatlab topmaydi.
• Qiymatlarni to'g'ri tanlash sizning ishingiz: avval EP bilan partition'lar, keyin pairwise.
• Cheklovlarni unutsangiz, mumkin bo'lmagan kombinatsiyalar (Windows'da Safari) chiqadi.
• Xavfli kombinatsiyalar (masalan, "iOS + Humo + kirill") bo'lsa, ularni pairwise to'plamga qo'lda qo'shing.

🎯 Intervyuda: "Pairwise nima va qachon ishlatasiz?" — Ko'p parametrli konfiguratsiyalarda har bir juft qiymatni kamida bir marta qamraydigan kichik to'plam. Asosi — bug'larning ko'pchiligi bitta yoki ikkita parametr o'zaro ta'siridan chiqishi. Kamchiligi — 3+ parametrli interaksiyalarni kafolatlamaydi.

3. Use case va ssenariy testing {#use-case}

Use case — aktor (foydalanuvchi yoki tizim) va tizim o'rtasidagi o'zaro ta'sir ssenariysi. CTFL v4.0 uni alohida texnika sifatida olib tashlagan, lekin end-to-end ssenariylarni tuzishda u hamon eng tushunarli asbob.

Use case: "Buyurtma berish (checkout)"

Har bir oqim — kamida bitta test ssenariysi. Asosiy oqim + 3 muqobil + 4 istisno = 8 ta ssenariy. E4 kabi istisnolar ko'pincha talabda yo'q bo'ladi va eng og'ir bug'lar aynan shu yerda yashaydi (ikki marta yechilgan pul).

💡 Maslahat: Use case'dagi har bir istisno oqimni "Nima bo'ladi, agar ...?" savoli bilan qidiring: internet uzilsa, ikkinchi tab ochilsa, "Orqaga" bosilsa, to'lov sahifasi yangilansa?

4. White-box: statement va branch coverage {#white-box}

4.1. Ta'riflar

White-box texnikalar kodning ichki tuzilishiga qaraydi. CTFL v4.0 ikkitasini o'rgatadi:

Muhim qoida: branch coverage statement coverage'ni o'z ichiga oladi. 100% branch → 100% statement, lekin teskarisi to'g'ri emas.

4.2. Real misol: deliveryFee()

// DemoBozor: yetkazib berish narxi (so'm)
function deliveryFee(subtotal, isPremium) {
  let fee = 20000;
  if (isPremium) {
    fee = 0;
  }
  if (subtotal >= 300000) {
    fee = 0;
  }
  return fee;
}

module.exports = { deliveryFee };

Bitta test yozamiz — Premium mijoz, 300 000 so'm:

const test = require("node:test");
const assert = require("node:assert");
const { deliveryFee } = require("./deliveryFee.js");

test("premium + 300 000", () => {
  assert.strictEqual(deliveryFee(300000, true), 0);
});

Coverage'ni Istanbul asosidagi nyc bilan o'lchaymiz:

npm i -D nyc
npx nyc --reporter=text node --test one.test.js

Haqiqiy natija:

----------------|---------|----------|---------|---------|-------------------
File            | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------------|---------|----------|---------|---------|-------------------
 deliveryFee.js |     100 |       50 |     100 |     100 | 4-7
----------------|---------|----------|---------|---------|-------------------

Statement 100%, branch 50%. Ikkala if ham faqat "true" tomonga ketdi. "False" tomonlar — isPremium = false va subtotal < 300000 — umuman sinalmadi. Ikkinchi testni qo'shamiz:

test("oddiy mijoz + 100 000", () => {
  assert.strictEqual(deliveryFee(100000, false), 20000);
});

Endi nyc natijasi: statement 100%, branch 100%.

🧠 Esda tuting: Vositalar branch'ni turlicha sanaydi. Xuddi shu bitta test uchun Node.js'ning o'rnatilgan coverage'i (node --test --experimental-test-coverage, V8 asosida) branch'ni 100% deb ko'rsatdi — u elsesiz ifning "yashirin" false tomonini alohida sanamaydi. Raqamga qarashdan oldin vosita nimani sanashini biling.

4.3. 100% coverage — sifat kafolati emas

Endi dasturchi xato qildi: >= o'rniga > yozdi (subtotal > 300000). Quyidagi ikki test bilan:

test("premium, 100 000", () => {
  assert.strictEqual(deliveryFee(100000, true), 0);
});

test("oddiy mijoz, 400 000", () => {
  assert.strictEqual(deliveryFee(400000, false), 0);
});

nyc natijasi bug'li kodda: statement 100%, branch 100%, ikkala test ham o'tdi. Bug esa joyida: aynan 300 000 so'mlik buyurtmaga 20 000 so'm yetkazish narxi qo'yiladi. Uni faqat BVA testi topadi:

test("BVA: oddiy mijoz, aynan 300 000", () => {
  assert.strictEqual(deliveryFee(300000, false), 0); // haqiqiy: 20000 — test yiqiladi
});

Xulosa: coverage "qaysi kod umuman ishga tushmagan"ini ko'rsatadi (va bu juda foydali), lekin "kod to'g'ri ishlaydi" demaydi. Syllabus ham shuni aytadi: statement coverage ma'lumotga bog'liq defektlarni (masalan, faqat maxraj nol bo'lganda chiqadigan bo'lish xatosini) topmasligi mumkin; white-box esa umuman yozilmagan talabni (defect of omission) ko'rmaydi.

4.4. QA uchun amaliy foydasi

• Dasturchilarning unit test coverage hisobotini o'qib, qamralmagan joylarni topish va o'sha joylarga black-box testlar qo'shish.
• Kod review'da "bu else qachon ishlaydi?" degan savollar berish.
• API va integratsiya darajasida coverage'ni CI'da kuzatish (QA 21).

🎯 Intervyuda: "100% statement coverage 100% branch coverage'ni bildiradimi?" — Yo'q. Teskarisi to'g'ri: 100% branch → 100% statement. Misol: elsesiz if — true tomoni hamma statement'larni bajaradi, false tomoni esa sinalmay qoladi.

5. Experience-based texnikalar {#experience-based}

Syllabus bu guruhga uchta texnikani kiritadi: error guessing, exploratory testing va checklist-based testing. Ular formal texnikalar o'tkazib yuborgan bug'larni topadi — lekin samaradorligi tester tajribasiga bog'liq.

5.1. Error guessing va fault attack

Error guessing — dasturchilar odatda qayerda xato qilishini, tizim ilgari qanday buzilganini va o'xshash ilovalarda qanday nosozliklar bo'lganini bilib, shu joylarga "hujum" qilish. Syllabus xato manbalarini sanaydi: kiritish, chiqish, mantiq, hisob-kitob, interfeys va ma'lumotlar. Fault attack — oldindan tuzilgan xatolar ro'yxati bo'yicha tizimli hujum.

DemoBozor uchun "hujum" ro'yxati:

5.2. Exploratory testing

Syllabus ta'rifi: exploratory testing'da testlar test obyektini o'rganish jarayonida bir vaqtda loyihalanadi, bajariladi va baholanadi. U spetsifikatsiya kam bo'lganda, vaqt bosimi kuchli bo'lganda va formal texnikalarni to'ldirish uchun ayniqsa foydali.

Bu "tasodifiy bosish" emas. Uni tartibga solish uchun charter ishlatiladi. Elisabeth Hendrickson "Explore It!" (2013) kitobidagi mashhur shablon:

Explore  <nimani: maqsad hudud>
with     <nima bilan: resurslar, vositalar, ma'lumotlar>
to discover <nimani bilish uchun: qidirayotgan ma'lumot>

DemoBozor uchun charter'lar:

Explore  promo-kod maydonini
with     turli registr, kirill harflar va nusxalangan matnlar bilan
to discover qaysi kiritishlar noto'g'ri qabul yoki rad etilishini

Explore  checkout'dagi to'lov qadamini
with     sekin tarmoq, "Orqaga" tugmasi va ikkita tab bilan
to discover pul ikki marta yechiladigan yoki buyurtma "osilib" qoladigan holatlarni

Explore  buyurtmalar tarixini
with     uch tilda (lotin, kirill, rus) va uzun mahsulot nomlari bilan
to discover matn kesilishi va tarjima kamchiliklarini

5.3. Session-based test management (SBTM)

Session-based yondashuvni 2000-yilda Jonathan va James Bach ishlab chiqqan. Uning qismlari:

Oddiy session sheet shabloni:

SESSIYA: DB-EXP-014        SANA: 2026-10-12      TESTER: QA muhandisi
CHARTER: Explore checkout'dagi to'lov qadamini sekin tarmoq va ikkita tab
         bilan, to discover pul ikki marta yechiladigan holatlarni
DAVOMIYLIK: 90 daqiqa      MUHIT: staging, iOS 26 simulator, build 2.0.0 (412)

ESLATMALAR:
- 3G profil bilan to'lov 14 soniya davom etdi, spinner bor
- Ikkinchi tabda "To'lash" bosildi -> server 409 qaytardi, xabar inglizcha (!)
BUG'LAR:   DB-2231 (xabar tarjima qilinmagan)
SAVOLLAR:  To'lov 30 soniyadan oshsa nima bo'ladi? Talabda timeout yo'q
VAQT:      test 70% · bug yozish 20% · sozlash 10%

5.4. Checklist-based testing

Tester checklist'dagi test condition'larni qamraydi. Syllabus qoidalari: band'lar ko'pincha savol shaklida; har birini alohida va bevosita tekshirish mumkin bo'lsin; avtomatik tekshiriladigan, juda umumiy yoki entry/exit criteria'ga xos band'lar kiritilmasin; checklist defektlar tahlili asosida muntazam yangilanib turilsin, lekin haddan tashqari uzayib ketmasin. Misol — Nielsen'ning 10 ta usability heuristikasi. Checklist yozish amaliyoti — QA 7.

5.5. SFDIPOT — test g'oyalari generatori

James Bach'ning Heuristic Test Strategy Model'idagi mahsulot elementlari ko'pincha SFDIPOT ("San Francisco Depot") mnemonikasi bilan eslab qolinadi. Turli manbalarda qisqaroq SFDPO yoki SFDPOT variantlari ham uchraydi.

🎯 Intervyuda: "Exploratory testing ad-hoc testingdan nimasi bilan farq qiladi?" — Exploratory testing maqsadli: charter, vaqt chegarasi, eslatmalar va debrief bor; o'rganish, dizayn va bajarish bir vaqtda bo'ladi. Ad-hoc esa rejasiz, hujjatsiz tekshiruv.

6. Collaboration-based yondashuvlar {#collaboration}

Bu guruhning maqsadi bug'ni topish emas, oldini olish. CTFL v4.0 uchta yondashuvni ko'rsatadi:

Amalda bu "Three Amigos" uchrashuvi va Gherkin ssenariylari ko'rinishida bo'ladi — batafsil QA 3 va QA 7 darslarida.

7. Qaysi texnikani qachon tanlash kerak {#tanlash}

Texnikalar raqobatchi emas. Kuchli tester bitta funksiya uchun 3–4 tasini birga ishlatadi.

8. Amaliy mashqlar {#mashqlar}

Mashq 1: qaytarish oqimi

Qoida: yetkazilgan buyurtmani 10 kun ichida qaytarish mumkin, pul qaytariladi. Qaytarish bilan bog'liq state transition testlarini yozing: valid o'tish, guard chegarasi va kamida ikkita invalid o'tish. Kutilgan natijalarni ko'rsating.

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

R2 va R3 — guard'ga qo'llangan BVA. PO'ga savol: "10 kun" kalendar kunimi yoki 240 soatmi, va Asia/Tashkent vaqti bo'yicha hisoblanadimi? R4 da to'lovlar jadvalida ikkinchi REFUNDED yozuvi paydo bo'lmasligini ham tekshiring.

</details>

Mashq 2: yangi qoida qo'shildi

Biznes yangi qoida qo'shdi: SHIPPED holatidan ham bekor qilish mumkin (kuryer tovarni omborga qaytaradi, pul qaytariladi). Valid va invalid o'tishlar soni qanday o'zgaradi? Valid transitions coverage'ni saqlash uchun qanday test qo'shasiz?

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

• Valid o'tishlar: 11 → 12 (SHIPPED →E7→ CANCELLED qo'shildi).
• Invalid o'tishlar: 53 → 52 (jadval 64 katakligicha qoladi).
• Yangi test: CREATED →E1→ PENDING_PAYMENT →E3→ PAID →E4→ PACKING →E5→ SHIPPED →E7→ CANCELLED. Action: pul qaytarilganini tekshiring.
• Eski TC-N1 ("SHIPPED + bekor qilish → rad") endi noto'g'ri — uni o'chiring yoki yangilang. Talab o'zgarsa, testlar ham o'zgaradi: traceability shuning uchun kerak (QA 7).

</details>

Mashq 3: 4 parametr uchun pairwise

DemoBozor mobil ilovasi uchun parametrlar: OT versiyasi (eng yangi, oldingi, eskiroq), Til (lotin, kirill, rus), Tarmoq (Wi-Fi, 4G, sekin 3G), Mavzu (yorug', qorong'i, tizim bo'yicha). To'liq kombinatsiyalar soni nechta? 9 qatorli pairwise jadval tuzing.

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

To'liq: 3 × 3 × 3 × 3 = 81. L9 orthogonal array bo'yicha 9 ta qator:

Bu darsdagi Brauzer/Til/To'lov/Qurilma jadvali bilan bir xil tuzilma (har ustunda har qiymat 3 marta, har juft ustunda har juftlik aynan bir marta) — demak 54 juftlikning hammasi qamralgan.

</details>

Mashq 4: statement va branch coverage

function finalDiscountPct(isNew, promoPct) {
  let pct = 0;
  if (isNew) {
    pct = 10;
  }
  if (promoPct > pct) {
    pct = promoPct;
  }
  return pct;
}

a) 100% statement coverage uchun minimal nechta test kerak? b) 100% branch coverage uchun-chi? Test ma'lumotlarini yozing.

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

a) 1 ta test: finalDiscountPct(true, 15) → 15. Ikkala if ham true, barcha statement'lar bajariladi. nyc natijasi: statement 100%, branch 50%.

b) 2 ta test: yuqoridagi + finalDiscountPct(false, 0) → 0. Ikkinchi testda ikkala if ham false tomonga ketadi. nyc: statement 100%, branch 100%.

Qo'shimcha (black-box nuqtai nazardan): finalDiscountPct(true, 5) → 10 ("kattasi qo'llanadi" qoidasi) va finalDiscountPct(true, 10) → 10 (teng holat — BVA). Coverage bularni talab qilmaydi, lekin biznes qoida talab qiladi.

</details>

Mashq 5: charter yozing

DemoBozor'ning muddatli to'lov (foizsiz) arizasi uchun 60 daqiqalik exploratory sessiyaga 2 ta charter yozing.

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

Explore  muddatli to'lov arizasidagi yosh va summa maydonlarini
with     chegara qiymatlari, formatlangan summalar (1 000 000, 1,000,000)
         va nusxalangan matnlar bilan
to discover noto'g'ri qabul qilinadigan yoki rad etiladigan qiymatlarni

Explore  3/6/12 oylik to'lov grafigini
with     turli summalar (bo'linmaydiganlari ham: 1 000 001) va tillar bilan
to discover oylik to'lovlar yig'indisi umumiy summaga teng bo'lmagan holatlarni

Yaxshi charter — tor, aniq maqsadli va vaqt ichida bajariladigan. "Ilovani testla" — charter emas.

</details>

Mashq 6: SFDIPOT bilan g'oyalar

"Buyurtmangiz yo'lda" push-bildirishnomasi uchun SFDIPOT'ning har bir harfiga kamida bitta test g'oyasi yozing.

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

</details>

Mashq 7: use case istisnolari

"Sharh qoldirish" use case'i: faqat DELIVERED buyurtma egasi, 1–5 yulduz, matn 10–1000 belgi. Kamida 4 ta istisno (exception) oqimini yozing.

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

</details>

Xulosa {#xulosa}

• State transition: holatga bog'liq tizimlar uchun. State table invalid o'tishlarni ko'rsatadi; valid transitions coverage — eng ko'p ishlatiladigan mezon; bitta testda bitta invalid o'tish.
• Pairwise: har bir juft qiymatni kamida bir marta qamraydi; NIST ma'lumotlariga ko'ra nosozliklarning ko'pchiligi 1–2 parametrdan chiqadi. Katta modellar uchun PICT.
• Use case: asosiy, muqobil va istisno oqimlar; eng og'ir bug'lar ko'pincha istisnolarda.
• White-box: 100% branch → 100% statement, teskarisi emas. 100% coverage ham bug yo'qligini kafolatlamaydi — > va >= bug'ini faqat BVA topdi.
• Experience-based: error guessing, charter va session bilan tartiblangan exploratory testing, checklist'lar va SFDIPOT.
• Collaboration-based: maqsad — bug'ning oldini olish: 3C, INVEST, acceptance criteria, ATDD.
• Keyingi dars: QA 7: Test hujjatlari — Test Plan, Strategy, Checklist, Test Case va Traceability Matrix

Manbalar {#manbalar}

1. ISTQB — Certified Tester Foundation Level Syllabus v4.0.1 (PDF)
2. NIST CSRC — Combinatorial Methods for Trust and Assurance (ACTS)
3. Microsoft PICT — GitHub
4. Microsoft PICT — hujjat (doc/pict.md)
5. Pairwise.org — pairwise testing haqida
6. Elisabeth Hendrickson — Explore It! (Pragmatic Bookshelf, 2013)
7. Wikipedia — Session-based testing
8. Ministry of Testing — San Francisco Depot
9. Istanbul / nyc — GitHub
10. Nielsen Norman Group — 10 Usability Heuristics