QA 2: Testlashning 7 printsipi va ISTQB tili — Error, Defect, Failure va test jarayoni

🧪 QA Engineer — Zero to Hero

QA 2: Testlashning 7 printsipi va ISTQB tili — Error, Defect, Failure va test jarayoni

Holat: 2026-yil oktabr. Bu dars testlashning "grammatikasi": testlash maqsadlari, error → defect → failure zanjiri, testing va debugging farqi, ISTQB'ning 7 printsipi, test jarayoni va testware, asosiy atamalar lug'ati, verification va validation, testlash psixologiyasi. Manba — ISTQB CTFL v4.0.1 syllabus'i (2024-09-15), CTFL v4.0 imtihoni hamon amalda.

Bu darsdan keyin siz: jamoada va intervyuda QA atamalarini to'g'ri ishlatasiz va har bir test faoliyati nima uchun kerakligini tushuntira olasiz.

• Error, defect, failure va root cause'ni misolda farqlaysiz.
• Testlashning 7 printsipini DemoBozor misolida tushuntira olasiz.
• Test jarayonining faoliyatlarini va ular beradigan testware'ni bilasiz.
• 20 dan ortiq asosiy atamani ingliz va o'zbek tilida to'g'ri ishlatasiz.
• Topilgan xatoni konstruktiv yetkazish va mustaqillik darajalarini tanlashni bilasiz.

Mundarija

1. Testlash nima uchun kerak va uning maqsadlari
2. Error → Defect → Failure va root cause
3. Testing va debugging farqi
4. Testlashning 7 printsipi
5. Test jarayoni: faoliyatlar va testware
6. Traceability: talab ↔ test ↔ bug
7. Asosiy atamalar lug'ati
8. Verification va Validation
9. Testlash psixologiyasi va mustaqillik
10. ISTQB va CTFL v4.0 imtihoni
11. Amaliy mashqlar
12. O'zingizni tekshiring
13. Xulosa
14. Manbalar

1. Testlash nima uchun kerak va uning maqsadlari {#maqsadlar}

Testlash — bu nafaqat "xato topish". ISTQB syllabus'i odatiy test maqsadlarini shunday sanaydi:

1. Ish mahsulotlarini baholash: talablar, user story'lar, dizayn va kod.
2. Failure'larni yuzaga chiqarish va defektlarni topish.
3. Test obyektining kerakli qamrovini (coverage) ta'minlash.
4. Sifat yetarli bo'lmasligi riskini kamaytirish.
5. Belgilangan talablar bajarilganini tekshirish.
6. Shartnoma, qonun va regulyator talablariga mosligini tekshirish.
7. Stakeholder'larga ongli qaror qabul qilishi uchun ma'lumot berish.
8. Test obyektining sifatiga ishonch hosil qilish.
9. Test obyekti to'liq va stakeholder'lar kutganidek ishlashini tasdiqlash.

Maqsadlar kontekstga qarab o'zgaradi: qaysi ish mahsuloti test qilinyapti, qaysi test darajasi, qanday risklar bor, qaysi SDLC ishlatilyapti, biznes holati qanday (masalan, raqobat yoki bozorga chiqish muddati).

🇺🇿 Mahalliy kontekst: Tasavvur qiling, DemoBozor Navro'z aksiyasini ikki hafta qoldirib e'lon qildi. Bu reliz uchun asosiy maqsad — "noto'g'ri chegirma hisoblanishi riskini kamaytirish" va "yuklama ostida checkout ishlashiga ishonch hosil qilish". Ayni paytda profil sahifasidagi avatar yuklash funksiyasi ikkinchi darajali. Maqsad aniq bo'lsa, vaqt to'g'ri taqsimlanadi.

ISTQB testlashning loyihaga qo'shadigan hissasini ham alohida ta'kidlaydi:

• Defektlarni arzon usulda topadi (tuzatish esa — debugging, alohida faoliyat).
• Sifatni turli bosqichlarda o'lchab, reliz qarori uchun ma'lumot beradi.
• Foydalanuvchilarning "vakili" bo'ladi: tester foydalanuvchi ehtiyojlarini jamoa ichida eslatib turadi.
• Shartnoma, qonun yoki standart talablarini bajarishga yordam beradi.

2. Error → Defect → Failure va root cause {#error-defect-failure}

ISTQB'ning asosiy formulasi: inson xato qiladi (error/mistake) → bu kodda yoki hujjatda defekt (defect, fault, bug) hosil qiladi → defekt ishga tushganda nosozlik (failure) yuz beradi.

Root cause → Error → Defect → Failure zanjiri DemoBozor misolida

Kodda bu shunday ko'rinadi:

// Talab (noaniq yozilgan): "300 000 so'mdan ortiq buyurtmada yetkazib berish bepul"
// Biznes aslida nazarda tutgan: "300 000 so'm va undan ko'p"
function deliveryFee(subtotal) {
  if (subtotal > 300000) {
    // DEFEKT: >= bo'lishi kerak edi
    return 0;
  }
  return 20000;
}

console.log(deliveryFee(299999)); // 20000 — to'g'ri
console.log(deliveryFee(300000)); // 20000 — FAILURE: kutilgan 0
console.log(deliveryFee(300001)); // 0 — to'g'ri

Muhim nuanslar (ISTQB'dan):

• Insonlar nega xato qiladi: vaqt bosimi, ish mahsuloti yoki infratuzilmaning murakkabligi, charchoq, yetarli tayyorgarlik yo'qligi.
• Defekt faqat kodda emas: talablar spetsifikatsiyasida, test skriptida, build faylida ham bo'ladi. Erta bosqichdagi aniqlanmagan defekt keyingi bosqichlarga "yuqadi".
• Har defekt failure bermaydi: ba'zilari har safar, ba'zilari faqat ma'lum sharoitda, ba'zilari esa umuman namoyon bo'lmaydi. Yuqoridagi defekt faqat roppa-rosa 300 000 so'mda ko'rinadi — tasodifiy test uni deyarli topmaydi.
• Failure'ni muhit ham keltirib chiqarishi mumkin: masalan, radiatsiya yoki elektromagnit maydon firmware'da nuqson hosil qilishi.

Root cause analysis: "5 marta Nega?"

Defektni tuzatish — yarim ish. Xuddi shunday xatolar takrorlanmasligi uchun ildiz sababni topish kerak. Oddiy usul — ketma-ket "Nega?" deb so'rash:

1. Nega mijoz yetkazib berish uchun to'ladi? — Kod 300 000 so'mda 20 000 qaytardi.
2. Nega? — Shartda >= o'rniga > yozilgan.
3. **Nega dasturchi > yozdi?** — Talabda "300 000 so'mdan ortiq" deb yozilgan edi.
4. Nega talab shunday yozildi? — Biznes "dan ortiq" ni "dan boshlab" ma'nosida ishlatgan; talab review'da chegara haqida savol berilmagan.
5. Nega review'da so'ralmadi? — Review checklist'ida "chegaralar aniq yozilganmi?" degan band yo'q.

Ildiz sabab: talab review jarayonida chegaralarni aniqlashtirish odati yo'qligi. Choralar: kodni tuzatish (debugging), talab matnini "≥ 300 000 so'm" ga o'zgartirish va review checklist'iga yangi band qo'shish. Oxirgisi — sof QA faoliyati: jarayon yaxshilandi.

🎯 Intervyuda: "Error, defect va failure farqi nima?" — "Error — insonning xatosi, defect — uning ish mahsulotidagi izi (masalan, koddagi noto'g'ri shart), failure — defekt ishga tushganda tashqaridan ko'rinadigan nosozlik. Har defekt failure bermaydi, failure esa muhit sababli ham yuz berishi mumkin."

3. Testing va debugging farqi {#testing-debugging}

Bular alohida faoliyatlar. ISTQB bo'yicha:

• Testing — dinamik testda failure'ni yuzaga chiqaradi yoki statik testda defektni to'g'ridan-to'g'ri topadi.
• Debugging — failure sababini (defektni) topish, tahlil qilish va bartaraf etish. Odatiy jarayon: qayta hosil qilish (reproduction) → tashxis (diagnosis) → tuzatish (fix).

Tuzatishdan keyin ikki muhim test bajariladi:

1. Confirmation testing (retesting): tuzatish haqiqatan ishladimi? ISTQB tavsiyasi — iloji bo'lsa, buni xatoni birinchi topgan odam bajaradi.
2. Regression testing: tuzatish boshqa joyni buzmadimi? (Masalan, promo-kod va Premium bepul yetkazib berish hisob-kitobi.)

💡 Maslahat: Statik testlashda (masalan, talab review'ida) defekt to'g'ridan-to'g'ri topiladi — failure'ni qayta hosil qilish yoki tashxis qo'yish shart emas, faqat defektni olib tashlash kerak. Shuning uchun erta topilgan defektlar arzonroq.

4. Testlashning 7 printsipi {#printsiplar}

Bu printsiplar ko'p yillik tajribadan kelib chiqqan umumiy qoidalar. ISTQB v4.0 ularni manbalari bilan keltiradi. Har birida: inglizcha nomi, ma'nosi, DemoBozor misoli va amalda nima qilamiz.

Printsip 1. Testing shows the presence, not the absence of defects

Testlash defektlar borligini ko'rsatadi, yo'qligini isbotlay olmaydi (Buxton, 1970). Testlash qolib ketgan defektlar ehtimolini kamaytiradi, lekin hech qanday defekt topilmasa ham, dastur to'g'riligini isbotlamaydi.

• DemoBozor: 200 ta test case o'tdi — bu "checkout'da xato yo'q" degani emas. Bu "biz tekshirgan holatlarda xato topilmadi" degani.
• Amalda: hisobotda "xato yo'q" demang. "Rejadagi 200 testdan 200 tasi o'tdi; ochiq risklar: ..." deb yozing.

Printsip 2. Exhaustive testing is impossible

Hamma narsani test qilib bo'lmaydi (Manna, 1978), arzimas holatlardan tashqari. Buning o'rniga test texnikalari, test case'larni prioritetlash va risk-based testing ishlatiladi.

• DemoBozor: promo-kod 6–12 belgidan iborat, har belgi 36 xil (A–Z, 0–9). Mumkin bo'lgan kodlar soni: 36⁶ + 36⁷ + ... + 36¹² ≈ 4,87 × 10¹⁸. Soniyasiga 1000 ta tekshiruv bilan bu taxminan 154 million yil davom etadi.
• Amalda: hamma qiymatlarni emas, ekvivalent sinflar va chegara qiymatlarni test qilamiz: 5 belgi (rad), 6 belgi (qabul), 12 belgi (qabul), 13 belgi (rad), kichik harf, maxsus belgi... Bu texnikalarni QA 5 darsida o'rganamiz.

Printsip 3. Early testing saves time and money

Erta testlash vaqt va pulni tejaydi (Boehm, 1981). Erta olib tashlangan defekt keyingi ish mahsulotlarida yangi defektlar keltirib chiqarmaydi. Statik va dinamik testlashni imkon qadar erta boshlash kerak.

• DemoBozor: "300 000 so'mdan ortiq" iborasini talab review'ida 5 daqiqada aniqlashtirish mumkin edi. Relizdan keyin esa: shikoyatlar, pul qaytarish, kodni tuzatish, qayta test, qayta reliz, buxgalteriya bilan hisob-kitob.
• Amalda: user story yozilayotganda qatnashing, savol bering, misol so'rang (shift-left, QA 3).

Printsip 4. Defects cluster together

Defektlar to'planib yashaydi (Enders, 1975). Odatda kam sonli komponentlar topilgan defektlarning ko'pchiligini o'z ichiga oladi yoki ko'p operatsion nosozliklarga sababchi bo'ladi — bu Pareto printsipining ko'rinishi. Kutilgan va kuzatilgan "klaster"lar risk-based testing uchun muhim kirish ma'lumoti.

• DemoBozor (xayoliy statistika): oxirgi 3 oyda Jira'dagi 120 ta bug'ning 58 tasi to'lov va promo-kod modullarida.
• Amalda: keyingi relizda shu modullarga ko'proq test vaqti ajratamiz, ular uchun regression to'plamini kuchaytiramiz (QA 27).

Printsip 5. Tests wear out

Testlar eskiradi (Beizer, 1990). Bir xil testlar ko'p marta takrorlansa, yangi defektlarni topishda tobora samarasiz bo'ladi. Avval bu printsip "pesticide paradox" (pestitsid paradoksi) deb atalgan: zararkunandalar bir xil zaharga ko'nikkani kabi, kod ham bir xil testlarga "moslashadi".

• DemoBozor: checkout testlari bir yildan beri o'sha 3 ta mahsulot va o'sha karta bilan bajariladi — yangi to'lov usuli (Humo) qo'shilganda ham ular yashil.
• Amalda: test ma'lumotlarini o'zgartiring, yangi testlar qo'shing, exploratory sessiyalar o'tkazing. Lekin e'tibor bering: avtomatlashtirilgan regression testlarni takrorlash foydali — ularning vazifasi aynan "eski narsa buzilmadimi?" ni tekshirish.

Printsip 6. Testing is context dependent

Testlash kontekstga bog'liq (Kaner, 2011). Hamma joyga mos yagona yondashuv yo'q.

• Amalda: boshqa kompaniyadagi "eng yaxshi amaliyot"ni ko'r-ko'rona ko'chirmang — avval kontekstni (risk, soha, jamoa, muddat) tahlil qiling.

Printsip 7. Absence-of-defects fallacy

"Defekt yo'q — demak, muvaffaqiyat" — bu xato fikr. Barcha belgilangan talablarni puxta test qilib, topilgan barcha defektlarni tuzatsangiz ham, tizim foydalanuvchi ehtiyojini qondirmasligi, biznes maqsadiga yordam bermasligi yoki raqobatchilardan yomonroq bo'lishi mumkin. Shuning uchun verifikatsiyadan tashqari validatsiya ham kerak (Boehm, 1981).

• DemoBozor: "Tez buyurtma" funksiyasi spetsifikatsiyaga 100% mos: barcha testlar yashil. Lekin to'lovni tasdiqlash uchun 5 ta ekran o'tish kerak va foydalanuvchilar uni ishlatmaydi.
• Amalda: foydalanuvchi nuqtai nazaridan ham test qiling (usability, UAT, beta), analitika ma'lumotlariga qarang.

🎯 Intervyuda: "7 printsipdan birini misol bilan tushuntiring." — Eng yaxshi javob: printsip nomi + o'z misolingiz + amaliy xulosa. Masalan: "Exhaustive testing is impossible: 6 xonali SMS kodda 1 000 000 kombinatsiya bor, hammasini sinamaymiz — ekvivalent sinflar va chegaralarni olamiz, bloklash mantiqini alohida tekshiramiz."

5. Test jarayoni: faoliyatlar va testware {#test-jarayoni}

ISTQB testlashni bir nechta faoliyat guruhidan iborat jarayon sifatida tasvirlaydi. Ular mantiqiy ketma-ketlikda ko'rinsa ham, amalda ko'pincha iterativ yoki parallel bajariladi va loyihaga moslashtiriladi. Test jarayonlari haqida batafsil ma'lumot ISO/IEC/IEEE 29119-2 standartida.

ISTQB test jarayoni: 6 ta asosiy faoliyat va butun jarayon bo'ylab monitoring va control

Test jarayoni kontekstga bog'liq. ISTQB quyidagi omillarni sanaydi: stakeholder'lar, jamoa a'zolari (ko'nikma, tajriba), biznes sohasi (kritiklik, risklar, qonunlar), texnik omillar (dastur turi, arxitektura), loyiha cheklovlari (scope, vaqt, byudjet), tashkilot omillari, SDLC va asboblar. Bular test strategiyasi, texnikalar, avtomatlashtirish darajasi va hujjatlar batafsilligiga ta'sir qiladi.

Testlashdagi ikki asosiy rol

ISTQB ikki rolni ajratadi:

• Test management role — test jarayoni, jamoa va yetakchilik uchun javobgar: asosan planning, monitoring, control va completion.
• Testing role — texnik qism: analysis, design, implementation va execution.

Bir kishi ikkala rolni ham bajarishi mumkin. Agile jamoada test boshqaruvining bir qismini jamoaning o'zi bajaradi.

🧠 Esda tuting: Analysis — "nimani?", design — "qanday?". Bu farq ISTQB imtihonida juda ko'p so'raladi.

6. Traceability: talab ↔ test ↔ bug {#traceability}

Traceability (kuzatuvchanlik) — talablar, test condition'lar, test case'lar, natijalar va defektlar o'rtasidagi bog'lanish. U nima uchun kerak:

• Qamrovni baholash: har bir talabni kamida bitta test qamrab olganmi?
• Qolgan riskni ko'rish: qaysi risklar test natijalari bilan yopildi?
• O'zgarish ta'sirini aniqlash: talab o'zgarsa, qaysi testlarni yangilash kerak?
• Audit va hisobot: natijalarni stakeholder'larga tushunarli ko'rsatish.

DemoBozor misoli (qisqa traceability matritsasi):

To'liq Requirements Traceability Matrix (RTM) yasashni QA 7 darsida o'rganamiz.

7. Asosiy atamalar lug'ati {#lugat}

Bu atamalarni jamoada va intervyuda doim eshitasiz. Ta'riflar ISTQB ma'nosiga mos, sodda tilda berilgan:

⚠️ Diqqat: False negative — eng xavflisi: jamoa "testlar yashil" deb xotirjam, lekin bug foydalanuvchiga yetib boradi. CrowdStrike hodisasida (QA 1) wildcard ishlatilgan testlar aynan shunday "yashil" ko'rinish bergan.

8. Verification va Validation {#verification-validation}

Barry Boehm'ning mashhur formulasi bu ikkisini bir jumlada ajratadi:

• Verification: "Are we building the product right?" — mahsulotni to'g'ri qurayapmizmi? Ya'ni spetsifikatsiyaga mosmi?
• Validation: "Are we building the right product?" — to'g'ri mahsulotni qurayapmizmi? Ya'ni foydalanuvchi ehtiyojini qondiradimi?

7-printsip shuni aytadi: faqat verifikatsiya yetarli emas — validatsiya ham kerak.

9. Testlash psixologiyasi va mustaqillik {#psixologiya}

Confirmation bias va "yomon xabar"

Inson o'z fikrini tasdiqlovchi ma'lumotni ko'rishga moyil (confirmation bias). Dasturchi "kodim ishlaydi" deb ishonadi va shunga mos ssenariylarni sinaydi. Tester ham bu xavfdan holi emas: "bu modul doim buziladi" degan fikr boshqa joylarni e'tibordan chetda qoldirishi mumkin.

ISTQB ta'kidlaganidek, tester ko'pincha yomon xabar olib keluvchi bo'ladi va odamlarda xabar olib keluvchini ayblash odati bor. Shuning uchun defekt haqidagi ma'lumot konstruktiv yetkazilishi kerak:

• Hamkorlikdan boshlang: "Birgalikda sifatli mahsulot qilyapmiz" ohangida.
• Shaxsni emas, faktni ayting: "kodingiz buzuq" emas, "300 000 so'mda yetkazib berish haqi olinyapti".
• Ta'sirni tushuntiring: "Bu aksiya kunida minglab buyurtmaga tegishli bo'lishi mumkin."
• Taxminni fakt sifatida bermang: "Sabab bu qatorda" emas, "Ehtimol, shu shart sabab bo'lishi mumkin — tekshirib ko'rasizmi?"
• Yaxshi ishni ham ayting: ishonch muhiti keyingi qiyin xabarlarni yengillashtiradi.

Mustaqillik darajalari

ISTQB bo'yicha mustaqillik testerni defekt topishda samaraliroq qiladi, chunki muallif va testerning "ko'r nuqtalari" har xil. Lekin mustaqillik tanishlikning o'rnini bosmaydi: dasturchilar o'z kodidagi ko'p defektlarni samarali topadi.

Afzalliklari: mustaqil tester boshqa turdagi failure'larni ko'radi, stakeholder'larning taxminlarini tekshira oladi. Kamchiliklari: jamoadan uzilib qolish, muloqot muammolari, "biz va ular" munosabati; dasturchilar sifat uchun javobgarlik hissini yo'qotishi; testerlar "reliz to'sig'i" deb ayblanishi.

Ko'p loyihalar uchun eng yaxshisi — bir nechta daraja birga: dasturchilar component testlarni, test jamoasi system testlarni, biznes vakillari acceptance testlarni bajaradi.

💡 Maslahat: ISTQB "whole team approach" ni ham tavsiya qiladi: sifat — butun jamoaning ishi, tester esa dasturchilar bilan test strategiyasi va avtomatlashtirishni birga kelishadi. Lekin xavfsizlik uchun juda muhim tizimlarda (masalan, tibbiy) yuqori mustaqillik talab qilinishi mumkin.

10. ISTQB va CTFL v4.0 imtihoni {#istqb}

ISTQB (International Software Testing Qualifications Board) — dasturiy testlash bo'yicha xalqaro sertifikatlash tashkiloti. Uning boshlang'ich sertifikati — CTFL (Certified Tester Foundation Level). Joriy syllabus — v4.0 (v4.0.1 — 2024-09-15 dagi tuzatilgan nashr); imtihon hamon CTFL v4.0 bo'yicha o'tkaziladi.

Bu kursning 1–8 va 27-darslari CTFL mavzularini qamraydi, lekin kurs undan ancha kengroq (API, SQL, avtomatlashtirish). Imtihonga tayyorgarlik, narxlar va sertifikatning ish bozoridagi qiymati haqida QA 28 darsida gaplashamiz.

💡 Maslahat: Syllabus istqb.org saytida bepul yuklab olinadi. Imtihon formulirovkalari aynan syllabus tilida bo'ladi, shuning uchun inglizcha atamalarni (test basis, test condition, testware...) yod olishingiz foydali.

11. Amaliy mashqlar {#mashqlar}

Mashq 1: Qaysi printsip?

Har bir vaziyat qaysi printsipga mos keladi?

1. "Biz 3 yildan beri bir xil 50 ta regression testni qo'lda bajaramiz, oxirgi yarim yilda ular bitta ham bug topmadi, lekin foydalanuvchilar bug'lar haqida yozishda davom etyapti."
2. "Menejer: 'Barcha testlar o'tdi, demak bug yo'q, reliz qilamiz!'"
3. "Bug'larning yarmidan ko'pi to'lov modulidan chiqyapti."
4. "Tibbiy qurilma jamoasi va startap jamoasi bir xil test hujjatlarini yuritishi kerakmi?"
5. "Ilova barcha talablarga javob beradi, lekin foydalanuvchilar uni o'chirib tashlayapti."
6. "Barcha telefon raqamlarini (+998 dan keyin 9 raqam) bitta-bitta sinab chiqamiz."
7. "Talablar hali yozilyapti, test qilishga narsa yo'q — QA keyinroq qo'shilsin."

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

1. Tests wear out — testlar va test ma'lumotlarini yangilash, yangi testlar qo'shish kerak.
2. Testing shows the presence, not the absence of defects — testlar o'tishi xato yo'qligini isbotlamaydi.
3. Defects cluster together — shu modulga ko'proq test kuchi ajratiladi.
4. Testing is context dependent — yo'q, kontekstga qarab har xil.
5. Absence-of-defects fallacy — validatsiya kerak.
6. Exhaustive testing is impossible — 10⁹ ta raqam; ekvivalent sinflar va chegaralar bilan ishlaymiz.
7. Early testing saves time and money — talablar review'i ham test faoliyati.

</details>

Mashq 2: Error, defect, failure va root cause

Har bir hikoyada error, defect, failure va (iloji bo'lsa) root cause'ni ajrating.

1. Dasturchi muddat bosimi ostida ishlab, Humo kartalar uchun BIN tekshiruvini nusxa ko'chirishda unutdi. Natijada Humo karta bilan to'lov qilganda "Karta qo'llab-quvvatlanmaydi" xatosi chiqyapti.
2. Talablar hujjatida "SMS kod 60 soniya amal qiladi" deb yozilgan, biznes esa 120 soniyani nazarda tutgan. Dastur 60 soniyadan keyin kodni rad etyapti va mijozlar shikoyat qilyapti.
3. Test skriptida kutilgan natija noto'g'ri yozilgan: "chegirma 10%" o'rniga "chegirma 15%". Test har safar yiqiladi, dastur esa to'g'ri ishlaydi.

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

1. Error: dasturchining unutishi. Defect: kodda Humo uchun tekshiruv yo'q. Failure: Humo bilan to'lov rad etiladi. Root cause (ehtimoliy): vaqt bosimi va nusxa ko'chirishga tayangan yondashuv; code review'da to'lov usullari ro'yxati tekshirilmagan.
2. Error: talab yozuvchining xatosi (120 o'rniga 60). Defect: talablar hujjatida (keyin kodda ham). Failure: 60–120 soniya orasida kiritilgan to'g'ri kod rad etiladi. Root cause: talab biznes bilan tasdiqlanmagan — bu defektni statik testlash (review) bosqichida topish mumkin edi.
3. Error: test yozuvchining xatosi. Defect: test skriptida (testware ham ish mahsuloti!). Failure: test yiqiladi, lekin dasturda nosozlik yo'q — bu false positive. Saboq: yiqilgan testni darhol "bug" deb ochmang — avval test o'zini tekshiring.

</details>

Mashq 3: Testing yoki debugging?

Har bir faoliyat testingmi yoki debugging? Odatda kim bajaradi?

1. Failure'ni lokal muhitda qayta hosil qilish va stack trace'ni o'qish.
2. Talablar hujjatidagi qarama-qarshilikni topish.
3. Tuzatilgan bug'ni o'sha qadamlar bilan qayta tekshirish.
4. Kod qatorida > ni >= ga almashtirish.
5. Tuzatishdan keyin savatcha va promo-kod oqimini qayta tekshirish.
6. Bug'ning qaysi commit'da paydo bo'lganini git bisect bilan aniqlash.

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

1. Debugging (reproduction + diagnosis) — odatda dasturchi; QA ham qayta hosil qilishda yordam beradi.
2. Testing (statik) — tester, analitik, jamoa.
3. Testing (confirmation testing) — iloji bo'lsa bug'ni topgan tester.
4. Debugging (fix) — dasturchi.
5. Testing (regression) — tester yoki avtomatik testlar.
6. Debugging (diagnosis) — ko'pincha dasturchi, lekin tajribali QA ham bajaradi (QA 13).

</details>

Mashq 4: Lug'at bo'yicha moslashtirish

Ta'rifga mos atamani toping: test basis, test condition, test oracle, testware, coverage, false negative, test suite, traceability.

1. Kutilgan natijani aniqlash manbai.
2. Testlar tayanadigan hujjat yoki manba.
3. Talab, test va bug o'rtasidagi bog'lanish.
4. Testlashning barcha ish mahsulotlari.
5. Tekshiriladigan aniq jihat.
6. Test o'tdi, lekin dasturda defekt bor.
7. Birga bajariladigan testlar guruhi.
8. Qamrov elementlarining qancha qismi test qilinganini ko'rsatuvchi o'lchov.

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

1. Test oracle
2. Test basis
3. Traceability
4. Testware
5. Test condition
6. False negative
7. Test suite
8. Coverage

</details>

Mashq 5: Verification yoki validation?

1. Tester promo-kod uzunligi 6–12 belgi ekanini test case bo'yicha tekshiradi.
2. 20 ta haqiqiy mijoz yangi checkout ekranini sinab ko'radi va fikr bildiradi.
3. Dizayn hujjati talablarga mosligi review qilinadi.
4. Analitika ko'rsatadiki, foydalanuvchilarning 40 foizi to'lov ekranida chiqib ketyapti — sababini o'rganish.
5. API javobidagi total maydoni hisoblash formulasiga mosligi tekshiriladi.
6. Do'kon operatorlari reliz oldidan yangi admin panelni o'z kundalik vazifalarida sinab ko'radi.

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

1. Verification — spetsifikatsiyaga moslik.
2. Validation — foydalanuvchi ehtiyoji va qulayligi.
3. Verification — hujjat talabga mos qurilganmi.
4. Validation — mahsulot foydalanuvchi uchun ishlayaptimi (4-banddagi 40% — mashq uchun xayoliy raqam).
5. Verification — formula (spetsifikatsiya) bo'yicha.
6. Validation — UAT: haqiqiy foydalanuvchilar o'z ishida.

</details>

Mashq 6: SMS kodni "hammasini" test qilish mumkinmi?

DemoBozor SMS kodi — 6 raqam. (a) Nechta kombinatsiya bor? (b) Hammasini qo'lda yoki avtomatik sinash maqsadga muvofiqmi? (c) Uning o'rniga qaysi testlarni tanlaysiz?

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

(a) 10⁶ = 1 000 000 kombinatsiya (000000 dan 999999 gacha).

(b) Yo'q. Bundan tashqari, DemoBozor qoidasi 3 marta noto'g'ri urinishdan keyin raqamni 15 daqiqaga bloklaydi — demak, "hammasini sinash" xatti-harakatining o'zi xavfsizlik himoyasi bilan to'qnashadi. (Agar blok ishlamasa — bu jiddiy xavfsizlik bug'i!)

(c) Taxminiy to'plam:

• To'g'ri kod 120 soniya ichida → kirish muvaffaqiyatli.
• To'g'ri kod 120 soniyadan keyin → rad etiladi (vaqt chegarasi: 119/120/121 soniya atrofida).
• 5 raqam, 7 raqam, harf, bo'sh maydon → format xatosi.
• 1-, 2-, 3-noto'g'ri urinish → xabarlar; 3-dan keyin 15 daqiqalik blok.
• Blok vaqtida to'g'ri kod ham rad etiladi; 15 daqiqadan keyin yana urinish mumkin.
• Qayta yuborish 60 soniyadan oldin mumkin emas; yangi kod kelgach eski kod ishlamaydi.

Bu — ekvivalent sinflar, chegara qiymatlar va holatlar o'tishi texnikalari (QA 5, QA 6).

</details>

Mashq 7: Mustaqillik darajasini tanlang

DemoBozor uchun quyidagi testlarni kim bajargani ma'qul va bu qaysi mustaqillik darajasi?

1. calculateDiscount() funksiyasining unit testlari.
2. Yangi to'lov provayderi bilan integratsiyani reliz oldidan tekshirish.
3. Yangi admin panelning do'kon operatorlari ishiga mosligini tekshirish.

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

1. Dasturchining o'zi (mustaqillik yo'q) — component test uchun eng samarali; code review'da hamkasb ko'rib chiqadi (bir oz mustaqillik).
2. Test jamoasi (yuqori mustaqillik) va zarur bo'lsa to'lov provayderining sertifikatlash jarayoni (juda yuqori mustaqillik).
3. Biznes vakillari, do'kon operatorlari — acceptance testing; ular boshqa jamoadan, demak yuqori mustaqillik, lekin eng muhimi — real foydalanuvchi nuqtai nazari (validatsiya).

</details>

O'zingizni tekshiring {#checklist}

• [ ] ISTQB'dagi kamida 5 ta test maqsadini sanay olaman.
• [ ] Error, defect, failure va root cause'ni o'z misolim bilan tushuntira olaman.
• [ ] Testing va debugging farqini, confirmation va regression testing'ni ajrata olaman.
• [ ] 7 printsipni inglizcha nomi bilan ayta olaman va har biriga misol keltira olaman.
• [ ] Test analysis "nima?" ga, test design "qanday?" ga javob berishini bilaman.
• [ ] Verification va validation farqini misolda ko'rsata olaman.
• [ ] CTFL imtihonining asosiy parametrlarini bilaman.

Xulosa {#xulosa}

• Testlashning maqsadi faqat bug topish emas: risklarni kamaytirish, qamrovni ta'minlash, qaror uchun ma'lumot berish va sifatga ishonch hosil qilish.
• Error → defect → failure: inson xatosi ish mahsulotida defekt hosil qiladi, defekt ishga tushganda failure ko'rinadi. Root cause'ni topib, jarayonni ham tuzatamiz.
• Testing va debugging — alohida faoliyatlar. Tuzatishdan keyin confirmation va regression testing majburiy.
• 7 printsip: defektlar borligini ko'rsatadi; to'liq testlash mumkin emas; erta test tejaydi; defektlar to'planadi; testlar eskiradi; kontekstga bog'liq; "defekt yo'q" — muvaffaqiyat degani emas.
• Test jarayoni: planning, monitoring va control, analysis, design, implementation, execution, completion — har biri o'z testware'ini beradi.
• Verification — "to'g'ri qurayapmizmi?", validation — "to'g'ri narsani qurayapmizmi?". Ikkalasi ham kerak.
• Topilgan muammoni konstruktiv yetkazish va to'g'ri mustaqillik darajasini tanlash — testerning muhim ko'nikmalari.
• Keyingi dars: QA 3: SDLC, STLC va Agile — Waterfall, V-Model, Scrum va QA'ning har bosqichdagi o'rni

Manbalar {#manbalar}

1. ISTQB CTFL Syllabus v4.0.1 (PDF, 2024-09-15)
2. ISTQB — Certified Tester Foundation Level (CTFL) v4.0
3. ISTQB Exam Structure and Rules Tables v1.18 (PDF, 2026)
4. ISTQB Glossary
5. CrowdStrike — External Technical Root Cause Analysis: Channel File 291 (PDF)