QA 3: SDLC, STLC va Agile — Waterfall, V-Model, Scrum va QA'ning har bosqichdagi o'rni

🧪 QA Engineer — Zero to Hero

QA 3: SDLC, STLC va Agile — Waterfall, V-Model, Scrum va QA'ning har bosqichdagi o'rni

Holat: 2026-yil oktabr. Bu darsda dasturiy ta'minot hayot sikli (SDLC) modellari, V-Model, Agile va Scrum'da QA'ning roli, user story va acceptance criteria, Gherkin (Given/When/Then), Agile Testing Quadrants, test hayot sikli (STLC), shift-left/shift-right va talablarni testlashni o'rganamiz. Manbalar: ISTQB CTFL v4.0.1, Scrum Guide (2020-yil noyabr), Cucumber Gherkin Reference.

Bu darsdan keyin siz: qaysi jarayon modelida ishlashingizdan qat'i nazar, QA qayerda va qachon qo'shilishi kerakligini bilasiz.

• Waterfall, V-Model, iterativ, Agile va DevOps modellarini va ularning testlashga ta'sirini farqlaysiz.
• Scrum event'larida QA nima qilishini aniq bilasiz.
• User story uchun testlanadigan acceptance criteria va Gherkin ssenariylarini yoza olasiz.
• STLC bosqichlarini entry/exit mezonlari bilan tushuntira olasiz.
• Noaniq talabni testlanadigan talabga aylantira olasiz.

Mundarija

1. SDLC nima
2. Waterfall: ketma-ket model
3. V-Model: har bosqichning test juftligi
4. Iterativ, inkremental, Agile va DevOps
5. Scrum'da QA
6. User story, INVEST va acceptance criteria
7. Gherkin: Given/When/Then
8. Agile Testing Quadrants
9. STLC: test hayot sikli
10. Shift-left va shift-right
11. Talablarni testlash: noaniqlik checklisti
12. Amaliy mashqlar
13. O'zingizni tekshiring
14. Xulosa
15. Manbalar

1. SDLC nima {#sdlc}

SDLC (Software Development Lifecycle) — dasturiy ta'minot g'oyadan to foydalanishdan chiqarilguncha o'tadigan bosqichlar. Model qanday bo'lishidan qat'i nazar, odatda quyidagi faoliyatlar bor:

ISTQB bo'yicha tanlangan SDLC modeli testlashga ta'sir qiladi:

• test faoliyatlarining ko'lami va vaqti (qaysi test darajalari va turlari, qachon);
• test hujjatlarining batafsilligi;
• test texnikalari va yondashuv tanlovi;
• avtomatlashtirish darajasi;
• testerning roli va mas'uliyati.

🧠 Esda tuting: Har qanday modelda ishlaydigan yaxshi amaliyotlar (ISTQB): har bir ishlab chiqish faoliyatiga mos test faoliyati bo'lishi; har test darajasining o'z maqsadi bo'lishi; test analysis va design mos ishlab chiqish bosqichida boshlanishi; testerlar ish mahsulotlarining qoralamalarini ham review qilishi.

2. Waterfall: ketma-ket model {#waterfall}

Waterfall (sharshara) — bosqichlar qat'iy ketma-ketlikda bajariladigan model: talablar to'liq yozib bo'linadi, keyin dizayn, keyin kod, keyin test, keyin reliz. Orqaga qaytish qimmat.

Testlashga ta'siri (ISTQB): ketma-ket modellarda dastlabki bosqichlarda testerlar talab review'i, test analysis va test design bilan shug'ullanadi. Bajariladigan kod keyinroq paydo bo'lgani uchun dinamik testlash erta boshlana olmaydi.

Qachon mos: talablar barqaror, o'zgarish ehtimoli past, shartnoma qat'iy (fixed price), regulyator hujjatlarni talab qiladi.

⚠️ Diqqat: Waterfall'da QA eng katta xatoni "kod tayyor bo'lguncha kutish" bilan qiladi. Kod bo'lmasa ham ish bor: talablarni review qiling, test case'larni oldindan yozing, test muhitini tayyorlang.

3. V-Model: har bosqichning test juftligi {#v-model}

V-Model — Waterfall'ning testlashga urg'u bergan ko'rinishi. Chap qanot — ishlab chiqish bosqichlari (yuqoridan pastga), o'ng qanot — ularga mos test darajalari (pastdan yuqoriga). Har bir chap bosqichda yozilgan hujjat o'ng tomondagi test darajasining test asosi bo'ladi.

V-Model: chap qanotda ishlab chiqish bosqichlari, o'ng qanotda ularga mos test darajalari

V-Model'ning asosiy g'oyasi: test dizayni chap qanotda boshlanadi. Talablar tayyor bo'lishi bilan acceptance test'lar loyihalanadi, arxitektura tayyor bo'lishi bilan integration test'lar. Chap qanotdagi review'lar — statik testlash, o'ng qanot — dinamik testlash. Test darajalarini batafsil QA 4 darsida ko'ramiz.

4. Iterativ, inkremental, Agile va DevOps {#iterative-agile-devops}

Iterativ va inkremental modellar

Mahsulot qismlarga bo'lib quriladi: har iteratsiya ishlaydigan prototip yoki mahsulot qismini (increment) beradi. ISTQB bo'yicha bu degani — har iteratsiyada barcha test darajalarida statik va dinamik testlash bo'lishi mumkin, tez-tez yetkazib berish esa tez fikr-mulohaza va keng regression testlashni talab qiladi.

Agile

2001-yilda e'lon qilingan Agile Manifesto to'rtta qadriyatni ilgari suradi:

• Individuals and interactions over processes and tools — jarayon va asboblardan ko'ra odamlar va muloqot;
• Working software over comprehensive documentation — keng hujjatlardan ko'ra ishlaydigan dastur;
• Customer collaboration over contract negotiation — shartnoma muhokamasidan ko'ra mijoz bilan hamkorlik;
• Responding to change over following a plan — rejaga qat'iy amal qilishdan ko'ra o'zgarishga moslashish.

Manifest aniq aytadi: o'ngdagilar ham qadrli, lekin chapdagilar ko'proq qadrlanadi. ISTQB bo'yicha Agile loyihalarda yengil hujjatlar va regression'ni osonlashtiradigan keng avtomatlashtirish afzal ko'riladi; qo'lda testlash asosan tajribaga asoslangan texnikalar (masalan, exploratory) bilan bajariladi.

DevOps

DevOps — ishlab chiqish (testlash bilan birga) va operatsiyalarni umumiy maqsadlar atrofida birlashtiradigan tashkiliy yondashuv. U jamoa avtonomiyasi, tez fikr-mulohaza, integratsiyalangan asboblar va CI/CD (continuous integration / continuous delivery) kabi amaliyotlarni rivojlantiradi. ISTQB DevOps'ning testlash uchun foydalarini sanaydi: kod sifati haqida tez fikr-mulohaza, CI orqali shift-left, barqaror test muhitlari, nofunksional sifatning ko'rinishi, takroriy qo'lda testlashning kamayishi. Shu bilan birga: foydalanuvchi nuqtai nazaridan qo'lda testlash baribir kerak bo'ladi.

Modellarni solishtirish

Kanban haqida qisqacha: ish oqim (flow) sifatida boshqariladi, doskada "jarayondagi ishlar" soni cheklanadi (WIP limit) va sprintlar majburiy emas. QA uchun bu degani — "Testing" ustunidagi ishlar to'planib qolsa, butun oqim sekinlashadi. Metodologiyalar haqida batafsil: PM 2.

5. Scrum'da QA {#scrum}

Scrum Guide (2020-yil noyabr versiyasi) Scrum Team'da uchta mas'uliyatni (accountability) belgilaydi: Product Owner, Scrum Master va Developers. Developers — har sprintda foydalanishga yaroqli increment'ning istalgan jihatini yaratishga sodiq odamlar. Guide'da "tester" yoki "QA" degan alohida rol yo'q — demak, QA jamoada Developers'ning bir qismi, sifat esa butun jamoaning ishi.

Scrum event'lari va QA faoliyati

Product Backlog refinement — Scrum Guide'da alohida event emas, doimiy faoliyat. Lekin QA uchun eng qimmatli vaqt aynan shu: story'larga misollar, chegara holatlar va acceptance criteria qo'shiladi.

Artefaktlar va "Done"

Scrum Guide Definition of Done'ni "increment mahsulot uchun talab qilinadigan sifat o'lchovlariga javob bergandagi holatining rasmiy tavsifi" deb ta'riflaydi. DemoBozor jamoasi uchun namunaviy DoD:

• [ ] Acceptance criteria bajarilgan va QA tomonidan tekshirilgan.
• [ ] Unit testlar yozilgan va CI'da o'tgan.
• [ ] Code review'dan o'tgan.
• [ ] Ochiq Blocker/Critical bug yo'q.
• [ ] Avtomatik regression testlar yashil.
• [ ] O'zbek (lotin/kirill), rus va ingliz matnlari qo'shilgan.
• [ ] Release notes yangilangan.

Definition of Ready (DoR) Scrum Guide'da yo'q, lekin ko'p jamoalarda ishlatiladi. ISTQB ham buni qayd etadi: Agile'da exit criteria ko'pincha Definition of Done, user story ishlab chiqish yoki testlashga olinishi uchun entry criteria esa Definition of Ready deb ataladi. Namunaviy DoR:

• [ ] Story INVEST talablariga mos.
• [ ] Acceptance criteria yozilgan (pozitiv va negativ misollar bilan).
• [ ] Dizayn maketi biriktirilgan.
• [ ] Bog'liqliklar (API, boshqa jamoa) aniq.
• [ ] Test data talablari ma'lum.

🎯 Intervyuda: "Scrum'da tester nima qiladi, agar Scrum Guide'da tester roli bo'lmasa?" — "Tester Developers'ning bir qismi: refinement'da acceptance criteria va misollarni shakllantiradi, sprint davomida story'larni test qiladi va avtomatlashtiradi, Definition of Done'ning sifat qismini ta'minlaydi, retrospektivada jarayonni yaxshilashni taklif qiladi."

6. User story, INVEST va acceptance criteria {#user-story}

User story — foydalanuvchi yoki xaridor uchun qimmatli funksiyaning qisqa tavsifi. ISTQB bo'yicha uning uchta muhim jihati bor — "3C" (Jeffries, 2000):

• Card — story yozilgan joy (karta yoki Jira'dagi yozuv);
• Conversation — dastur qanday ishlatilishi haqidagi suhbat (yozma yoki og'zaki);
• Confirmation — acceptance criteria.

Eng keng tarqalgan format:

As a [rol], I want [maqsad], so that [qiymat].

Xaridor sifatida, men promo-kod kiritmoqchiman,
shunda buyurtmam arzonroq tushadi.

Yaxshi story INVEST bo'ladi (Wake, 2003): Independent (mustaqil), Negotiable (muhokama qilinadigan), Valuable (qimmatli), Estimable (baholanadigan), Small (kichik), Testable (testlanadigan). ISTQB muhim fikrni qo'shadi: agar stakeholder story'ni qanday test qilishni bilmasa, demak story yetarlicha aniq emas yoki undan qiymat yo'q.

Acceptance criteria

Acceptance criteria — story qabul qilinishi uchun bajarilishi kerak bo'lgan shartlar. ISTQB ularni test condition'lar deb qarashni tavsiya qiladi. Ular scope'ni belgilaydi, kelishuvga yordam beradi, pozitiv va negativ ssenariylarni tasvirlaydi va baholashni aniqroq qiladi. Ikki keng tarqalgan format:

1. Qoidaga asoslangan (rule-oriented) — ro'yxat yoki jadval.
2. Ssenariyga asoslangan (scenario-oriented) — Given/When/Then (keyingi bo'lim).

DemoBozor promo-kod story'si uchun rule-oriented acceptance criteria:

1. Promo-kod 6–12 belgidan iborat, faqat A–Z va 0–9.
2. Bitta buyurtmaga bitta promo-kod qo'llanadi.
3. Savatcha summasi promo uchun minimal summadan kam bo'lsa — "Minimal summa: X so'm" xabari.
4. Muddati o'tgan kod — "Promo-kod muddati tugagan" xabari.
5. Har foydalanuvchi bitta promo-kodni bir marta ishlatadi.
6. Yangi mijoz chegirmasi (10%) va promo-kod chegirmasi qo'shilmaydi — kattasi qo'llanadi.

Three Amigos

Story'ni uch nuqtai nazardan birga muhokama qilish amaliyoti — biznes (Product Owner yoki analitik), ishlab chiqish (dasturchi) va testlash (QA). ISTQB ham hamkorlikda story yozishda aynan shu uch nuqtai nazarni tilga oladi. ATDD (Acceptance Test-Driven Development)da bu "specification workshop" deb ataladi: story va acceptance criteria tahlil qilinadi, noaniqliklar yechiladi, keyin test case'lar (misollar) yoziladi.

💡 Maslahat: Three Amigos'da QA'ning eng kuchli quroli — "Agar ... bo'lsa-chi?" savoli. "Agar mijoz promo-kodni kichik harflarda yozsa-chi? Avtomatik katta harfga o'tkazamizmi yoki rad etamizmi?" Bu savol talabda yo'q — demak, uni hozir hal qilish kerak, kod yozilgandan keyin emas.

7. Gherkin: Given/When/Then {#gherkin}

BDD (Behavior-Driven Development) dastur xatti-harakatini stakeholder'lar tushunadigan sodda tilda yozilgan misollar orqali tasvirlaydi — odatda Given/When/Then formatida. Bu misollar keyinchalik avtomatik testlarga aylantirilishi mumkin (masalan, Cucumber yoki playwright-bdd bilan).

Gherkin'ning asosiy kalit so'zlari (Cucumber Reference):

Gherkin 70 dan ortiq tilga tarjima qilingan va fayl boshidagi # language: sarlavhasi bilan til tanlanadi. Amalda ko'p jamoalar kalit so'zlarni inglizcha qoldirib, qadam matnini o'z tilida yozadi — biz ham shunday qilamiz:

Feature: Promo-kod qo'llash
  Xaridor sifatida men promo-kod kiritib chegirma olmoqchiman,
  shunda buyurtmam arzonroq tushadi.

  Background:
    Given tizimga kirgan xaridorning avvalgi buyurtmalari bor
    And savatchada 400 000 so'mlik mahsulotlar bor

  Scenario: Amal qiladigan promo-kod 15% chegirma beradi
    Given "BAHOR15" promo-kodi faol va minimal summasi 200 000 so'm
    When xaridor "BAHOR15" promo-kodini qo'llaydi
    Then chegirma 60 000 so'm bo'ladi
    And to'lanadigan summa 340 000 so'm bo'ladi

  Scenario: Muddati o'tgan promo-kod rad etiladi
    Given "QISH10" promo-kodining muddati kecha tugagan
    When xaridor "QISH10" promo-kodini qo'llaydi
    Then "Promo-kod muddati tugagan" xabari ko'rsatiladi
    And to'lanadigan summa 400 000 so'm bo'lib qoladi

  Scenario Outline: Formati noto'g'ri promo-kod rad etiladi
    When xaridor "<kod>" promo-kodini qo'llaydi
    Then "Promo-kod formati noto'g'ri" xabari ko'rsatiladi

    Examples:
      | kod            | izoh                 |
      | BAH15          | 5 belgi — juda qisqa |
      | BAHOR15BAHOR15 | 14 belgi — juda uzun |
      | BAHOR-15       | defis — ruxsat yo'q  |
      | BAHOR 15       | probel — ruxsat yo'q |

Bu misolda e'tibor bering:

• Background'dagi birinchi qator bejiz emas. Agar xaridor yangi mijoz bo'lsa, unga 10% chegirma tushardi va "muddati o'tgan promo-kod" ssenariysida summa 400 000 emas, 360 000 bo'lardi. Kontekst aniq yozilmasa, kutilgan natija ham noaniq bo'ladi.
• Yetkazib berish narxi ko'rsatilmagan, chunki 400 000 ≥ 300 000 — yetkazib berish bepul. Agar summa kichikroq bo'lsa, Then qadamida uni ham hisobga olish kerak edi.
• Scenario Outline bitta qoidani 4 ta chegaraviy misol bilan tekshiradi — bu ekvivalent sinflar va chegara qiymatlarining Gherkin'dagi ko'rinishi (QA 5).

⚠️ Diqqat: Gherkin — UI skripti emas. "When foydalanuvchi #promo-input maydoniga bosadi" kabi texnik qadamlardan qoching. Gherkin biznes xatti-harakatini tasvirlaydi; qaysi tugma bosilishi — avtomatlashtirish kodining ishi.

8. Agile Testing Quadrants {#quadrants}

Testing quadrants modelini Brian Marick taklif qilgan (2003), Lisa Crispin va Janet Gregory uni "Agile Testing" kitobida ommalashtirgan. Model testlarni ikki o'q bo'yicha ajratadi: biznesga qaragan yoki texnologiyaga qaragan va jamoani qo'llab-quvvatlovchi (ishlab chiqishni yo'naltiruvchi) yoki mahsulotni tanqid qiluvchi (kutilmalar bilan solishtiruvchi). ISTQB v4.0'dagi tavsif:

🧠 Esda tuting: Kvadrant raqamlari tartibni bildirmaydi. Lisa Crispin buni alohida ta'kidlaydi: Q1 dan Q4 gacha "sharshara" kabi ketma-ket yurish shart emas. Model — hech bir test turi unutilmaganini tekshirish uchun xarita.

9. STLC: test hayot sikli {#stlc}

STLC (Software Testing Life Cycle) — sanoatda keng ishlatiladigan atama: testlashning o'z hayot sikli. U ISTQB'dagi test jarayoniga (QA 2) juda o'xshaydi, faqat bosqichlar boshqacha guruhlangan. Har bosqichning entry (kirish) va exit (chiqish) mezonlari bor.

STLC: 6 bosqich, ular orasidagi darvozalar va 5-bosqich uchun entry/exit misoli

ISTQB entry va exit mezonlari haqida muhim narsalarni aytadi:

• Odatiy entry mezonlari: resurslar (odamlar, asboblar, muhit, test data, byudjet, vaqt), testware (test asosi, testlanadigan talablar, test case'lar) va test obyektining boshlang'ich sifati (masalan, barcha smoke testlar o'tgan).
• Odatiy exit mezonlari: puxtalik o'lchovlari (erishilgan qamrov, ochiq defektlar soni, defekt zichligi, yiqilgan testlar soni) va "ha/yo'q" mezonlari (rejadagi testlar bajarildimi, statik testlash o'tkazildimi, barcha defektlar report qilindimi).
• Vaqt yoki byudjet tugashi ham exit mezoni bo'lishi mumkin — agar stakeholder'lar qo'shimcha testsiz reliz qilish riskini ko'rib chiqib, qabul qilgan bo'lsa.

💡 Maslahat: Agile'da STLC har sprint ichida qisqa va ko'p marta takrorlanadi: bitta story uchun tahlil, dizayn, bajarish va yopish bir necha kunda o'tadi. Shuning uchun STLC'ni "bir martalik katta jarayon" emas, har bir ish bo'lagiga qo'llanadigan fikrlash tartibi deb tushuning.

10. Shift-left va shift-right {#shift-left-right}

Shift-left

ISTQB bo'yicha erta testlash printsipi ba'zan shift-left deb ataladi: testlash SDLC'da oldinroq bajariladi. Lekin bu keyingi bosqichlardagi testlashdan voz kechish degani emas. Yaxshi amaliyotlar:

• spetsifikatsiyani tester nuqtai nazaridan review qilish (noaniqlik, to'liqsizlik, ziddiyatlarni topish);
• kod yozilishidan oldin test case'lar yozish va kodni yozish jarayonida ularni ishga tushirish;
• CI va undan ham yaxshisi CD — tez fikr-mulohaza va kod bilan birga keladigan avtomatik component testlar;
• dinamik testdan oldin static analysis;
• nofunksional testlarni imkon qadar component darajasidan boshlash.

Shift-left avvaliga qo'shimcha o'qitish va xarajat talab qilishi mumkin, lekin keyinchalik vaqt va xarajatni tejaydi. Buning uchun stakeholder'lar g'oyani qo'llab-quvvatlashi muhim.

Shift-right

Shift-right — testlash va sifat nazoratini reliz va production'ga ham kengaytirish. Asosiy amaliyotlar:

⚠️ Diqqat: Shift-right — "foydalanuvchilar biz uchun test qilsin" degani emas. U shift-left'ni to'ldiradi: reliz oldidan qilingan testlar + production'dagi kuzatuv. Batafsil: DevOps 3: Release engineering, DevOps: Observability, Growth 3: A/B testlash.

11. Talablarni testlash: noaniqlik checklisti {#talablarni-testlash}

Talablar review'i — eng arzon test. ISTQB statik testlash bilan oson topiladigan talab defektlarini sanaydi: ziddiyatlar, noaniqliklar, qarama-qarshiliklar, tushib qolgan narsalar, noaniq ma'lumotlar va takrorlanishlar.

"Xavfli so'zlar" ro'yxati

Quyidagi so'zlarni ko'rsangiz, darhol savol bering: tez, sekin, qulay, oson, intuitiv, zamonaviy, ko'p, kam, yetarli, optimal, xavfsiz, odatda, ba'zan, iloji boricha, va hokazo (h.k.), kerak bo'lsa, ...dan ortiq/kam (chegara kiradimi?).

Har biriga to'rt savol: Qancha? Qachon? Kim uchun? Qanday o'lchanadi?

Yaxshi talab belgilari

Noaniq → testlanadigan

🧠 Esda tuting: Ikkinchi qatordagi savol ("chegirmadan oldingi yoki keyingi summa?") — QA ning qiymati shunda. Agar uni hech kim so'ramasa, dasturchi qandaydir variantni tanlaydi va bu bug yoki biznes yo'qotishi bo'lib chiqishi mumkin. Talab yozish san'ati haqida: PM 4.

12. Amaliy mashqlar {#mashqlar}

Mashq 1: Talablarni testlanadigan qiling

Har bir talab uchun savollar yozing va testlanadigan variantini taklif qiling (raqamlarni DemoBozor qoidalaridan oling yoki oqilona taxmin qiling va "taxmin" deb belgilang).

1. "Qidiruv qulay bo'lishi kerak."
2. "Savatchaga ko'p mahsulot qo'shish mumkin."
3. "Sharh yozish faqat haqiqiy xaridorlar uchun."
4. "Ilova internet bo'lmaganda ham ishlashi kerak."

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

1. Savollar: "Qulay" — nima? Minimal/maksimal uzunlik? Natija bo'lmasa nima bo'ladi? Variant: "Qidiruv so'rovi 2–100 belgi; 2 belgidan kam bo'lsa 'Kamida 2 ta belgi kiriting' xabari; natija topilmasa 'Hech narsa topilmadi' va mashhur kategoriyalar ko'rsatiladi."
2. Savollar: "Ko'p" — nechta? Bitta mahsulotdan nechta? Variant: "Bitta mahsulot soni 1–99; savatchada ko'pi bilan 50 xil mahsulot; 51-mahsulot qo'shilganda 'Savatcha to'ldi' xabari."
3. Savollar: "Haqiqiy xaridor" kim? Buyurtma qaysi holatda bo'lishi kerak? Variant: "Sharhni faqat shu mahsulot bo'yicha DELIVERED holatidagi buyurtmasi bor foydalanuvchi yoza oladi; reyting 1–5, matn 10–1000 belgi."
4. Savollar: Qaysi funksiyalar oflayn? Ma'lumot qachon sinxronlanadi? Oflayn buyurtma mumkinmi? Variant (taxmin): "Internet yo'q bo'lsa, oxirgi ochilgan katalog va savatcha keshdan ko'rsatiladi; buyurtma berish tugmasi faol emas va 'Internetga ulaning' xabari chiqadi; ulanish tiklangach savatcha server bilan sinxronlanadi."

</details>

Mashq 2: QA vazifasini Scrum event'iga joylang

Har bir vazifa qaysi event yoki faoliyatda bajariladi: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Backlog refinement yoki sprint davomida?

1. "Promo-kod story'siga kichik harf bilan kiritish misolini qo'shish."
2. "Staging serveri ikki kundan beri ishlamayotganini aytish."
3. "Beqaror E2E testlar tufayli CI har kuni qizarayotganini muhokama qilish."
4. "Yangi story uchun test hajmini baholash."
5. "Stakeholder'larga increment'dagi ma'lum ikkita minor bug haqida aytish."
6. "Tayyor bo'lgan story'ni staging'da test qilish."

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

1. Backlog refinement (Three Amigos) — misollar va acceptance criteria.
2. Daily Scrum — to'siq.
3. Sprint Retrospective — jarayonni yaxshilash.
4. Sprint Planning — baholash.
5. Sprint Review — shaffoflik.
6. Sprint davomida — story tayyor bo'lishi bilan, sprint oxirini kutmasdan.

</details>

Mashq 3: SMS kod qoidalari uchun Gherkin

DemoBozor qoidasi: SMS kod 6 raqam; 120 soniya amal qiladi; qayta yuborish 60 soniyadan keyin; 3 marta noto'g'ri → raqam 15 daqiqaga bloklanadi. Ushbu qoidalar uchun Feature, Background va kamida 5 ta ssenariy yozing (bittasi Scenario Outline bo'lsin).

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

Feature: SMS kod orqali kirish
  Qoidalar: kod 6 raqam, 120 soniya amal qiladi, qayta yuborish 60 soniyadan keyin,
  3 marta noto'g'ri kiritilsa raqam 15 daqiqaga bloklanadi.

  Background:
    Given xaridor "+998901234567" raqamiga SMS kod so'ragan

  Scenario: To'g'ri kod amal qilish muddati ichida kiritiladi
    When xaridor 119-soniyada to'g'ri kodni kiritadi
    Then xaridor tizimga kiradi

  Scenario: Kodning muddati tugagan
    When xaridor 121-soniyada to'g'ri kodni kiritadi
    Then "Kod muddati tugagan" xabari ko'rsatiladi
    And xaridor tizimga kirmaydi

  Scenario: Qayta yuborish 60 soniyadan oldin mumkin emas
    When 59 soniya o'tadi
    Then "Kodni qayta yuborish" tugmasi faol emas

  Scenario: Qayta yuborish 60 soniyadan keyin ochiladi
    When 60 soniya o'tadi
    Then "Kodni qayta yuborish" tugmasi faol bo'ladi

  Scenario Outline: Format noto'g'ri kod qabul qilinmaydi
    When xaridor "<kod>" kodini kiritadi
    Then "Kod 6 ta raqamdan iborat bo'lishi kerak" xabari ko'rsatiladi

    Examples:
      | kod     |
      | 12345   |
      | 1234567 |
      | 12a456  |

  Scenario: 3 marta noto'g'ri kod raqamni bloklaydi
    When xaridor ketma-ket 3 marta noto'g'ri kod kiritadi
    Then raqam 15 daqiqaga bloklanadi
    And to'g'ri kod kiritilsa ham kirish rad etiladi

  Scenario: Blok 15 daqiqadan keyin ochiladi
    Given raqam 3 marta noto'g'ri urinish sababli bloklangan
    When 15 daqiqa o'tadi
    And xaridor yangi SMS kod so'raydi
    Then yangi kod yuboriladi

Yaxshi javob belgilari: chegaralar (119/121 soniya, 59/60 soniya) bor; har ssenariy bitta xatti-harakatni tekshiradi; qadamlar biznes tilida (UI elementlari tilga olinmagan). Amaliy eslatma: vaqtga bog'liq ssenariylarni avtomatlashtirish uchun test muhitida "soatni boshqarish" imkoni (masalan, test rejimida OTP muddatini sozlash) kerak bo'ladi — buni Three Amigos'da oldindan kelishib oling.

</details>

Mashq 4: Modelni tanlang

Qaysi SDLC modeli (yoki yondashuv) mos va QA qanday ishlaydi?

1. Davlat buyurtmasi: soliq hisobotini topshirish tizimi, talablar qonun bilan belgilangan, qat'iy shartnoma va audit.
2. DemoBozor'ning yangi "Sevimlilar" funksiyasi: foydalanuvchi fikriga qarab tez o'zgaradi.
3. Kuniga bir necha marta deploy qilinadigan DemoBozor backend xizmatlari.

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

1. V-Model (yoki Waterfall) — talablar barqaror, hujjat va kuzatuvchanlik muhim. QA: talablar review'i, har darajaga test dizayni oldindan, RTM, rasmiy hisobotlar.
2. Agile (Scrum) — tez fikr-mulohaza. QA: refinement'da misollar, sprint ichida test, exploratory sessiyalar, regression avtomatlashtirish.
3. DevOps (CI/CD) — QA: pipeline'dagi avtomatik testlar va quality gate'lar, contract/API testlar, canary va monitoring (shift-right).

</details>

Mashq 5: Testni kvadrantga joylang

Q1, Q2, Q3 yoki Q4?

1. deliveryFee() unit testlari.
2. 10 ta do'kon operatori yangi admin panelni sinab ko'radi.
3. 1000 ta virtual foydalanuvchi bilan checkout yuklama testi.
4. Promo-kod story'si uchun Gherkin misollari asosidagi avtomatik testlar.
5. "Yangi to'lov ekrani" bo'yicha 90 daqiqalik exploratory sessiya.
6. API kontrakt testi: savatcha xizmati javobi kutilgan formatda.
7. Har deploy'dan keyin asosiy sahifalar ochilishini tekshiruvchi smoke test.
8. Ekran o'quvchi (VoiceOver) bilan foydalanish qulayligini sinash.

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

1. Q1 — texnologiyaga qaragan, jamoani qo'llab-quvvatlaydi.
2. Q3 — user acceptance testing.
3. Q4 — nofunksional (performance).
4. Q2 — misollar va user story testlari.
5. Q3 — exploratory testing.
6. Q2 — ISTQB API testlashni Q2'ga qo'yadi (biznes qoidalarini qo'llab-quvvatlovchi testlar). Agar u faqat ichki komponentlar o'rtasidagi texnik shartnomani tekshirsa, Q1 deb ham qarash mumkin — muhimi, test nimaga xizmat qilishini tushunish.
7. Q4 — ISTQB smoke testlarni Q4'ga kiritadi.
8. Q3 — usability (ISTQB usability testlarni Q4'dan chiqarib, Q3'ga qo'yadi); accessibility'ni avtomatik tekshirish esa Q4 bo'lishi mumkin.

</details>

Mashq 6: Sprint relizi uchun entry/exit mezonlari

DemoBozor jamoasi 2 haftalik sprint oxirida "Promo-kod v2" funksiyasini chiqarmoqchi. 5-bosqich (testlarni bajarish) uchun 3 ta entry va 4 ta exit mezonini yozing.

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

Entry:

1. Build staging'ga deploy qilingan va versiya raqami ma'lum.
2. Smoke testlar (login, katalog, savatcha, checkout) o'tgan.
3. Test data tayyor: faol, muddati o'tgan va minimal summasi har xil promo-kodlar; yangi va eski mijoz akkauntlari.

Exit:

1. Rejadagi test case'larning 100% bajarilgan (o'tgan yoki sababli bloklangan).
2. Ochiq Blocker/Critical bug yo'q; Major bug'lar uchun PO qarori yozilgan.
3. Promo-kod bilan bog'liq avtomatik regression testlar yashil.
4. Test summary report PO'ga yuborilgan.

Esda tuting: agar vaqt tugab, exit mezonlari to'liq bajarilmasa, reliz faqat stakeholder'lar riskni ko'rib chiqib, qabul qilsa amalga oshadi — va bu qaror yozib qo'yiladi.

</details>

O'zingizni tekshiring {#checklist}

• [ ] SDLC modeli testlashning qaysi jihatlariga ta'sir qilishini sanay olaman.
• [ ] V-Model'da har bir ishlab chiqish bosqichiga mos test darajasini ayta olaman.
• [ ] Scrum event'larida QA nima qilishini bilaman va DoD/DoR farqini tushuntira olaman.
• [ ] User story uchun rule-oriented va Gherkin formatida acceptance criteria yoza olaman.
• [ ] Testing quadrants'dagi Q1–Q4 ni misollar bilan ayta olaman.
• [ ] STLC bosqichlari va entry/exit mezonlarini bilaman.
• [ ] Noaniq talabni testlanadigan talabga aylantira olaman.

Xulosa {#xulosa}

• SDLC modeli test faoliyatlarining vaqti, hujjat hajmi, texnikalar, avtomatlashtirish va tester roliga ta'sir qiladi.
• Waterfall va V-Model'da dinamik test kech, lekin QA ishi talab review'i va test dizayni bilan erta boshlanadi. V-Model'da har ishlab chiqish bosqichining test juftligi bor.
• Agile va DevOps'da test sprint yoki pipeline ichida: yengil hujjatlar, keng avtomatlashtirish, tez fikr-mulohaza — va baribir qo'lda, foydalanuvchi nuqtai nazaridan testlash.
• Scrum'da QA — Developers'ning bir qismi; eng qimmatli vaqt — backlog refinement va Three Amigos.
• Acceptance criteria'ni qoida yoki Given/When/Then shaklida yozamiz; kontekst (Background) aniq bo'lmasa, kutilgan natija ham noaniq bo'ladi.
• STLC — talablar tahlilidan siklni yopishgacha 6 bosqich; entry/exit mezonlari sifat darvozalari vazifasini bajaradi.
• Shift-left — testni ertaroq boshlash, shift-right — production'da kuzatish; ular bir-birini to'ldiradi.
• Keyingi dars: QA 4: Testlash darajalari va turlari — Unit'dan UAT'gacha, Smoke, Sanity, Regression va Test Pyramid

Manbalar {#manbalar}

1. ISTQB CTFL Syllabus v4.0.1 (PDF, 2024-09-15)
2. The Scrum Guide (2020)
3. Manifesto for Agile Software Development (2001)
4. Cucumber — Gherkin Reference
5. Lisa Crispin — Using the Agile Testing Quadrants
6. [Wikipedia — V-model (software development)](<https://en.wikipedia.org/wiki/V-model_(software_development)>)
7. Martin Fowler — Canary Release
8. Pete Hodgson (martinfowler.com) — Feature Toggles
9. Atlassian — Definition of Done