# 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](#sdlc) 2. [Waterfall: ketma-ket model](#waterfall) 3. [V-Model: har bosqichning test juftligi](#v-model) 4. [Iterativ, inkremental, Agile va DevOps](#iterative-agile-devops) 5. [Scrum'da QA](#scrum) 6. [User story, INVEST va acceptance criteria](#user-story) 7. [Gherkin: Given/When/Then](#gherkin) 8. [Agile Testing Quadrants](#quadrants) 9. [STLC: test hayot sikli](#stlc) 10. [Shift-left va shift-right](#shift-left-right) 11. [Talablarni testlash: noaniqlik checklisti](#talablarni-testlash) 12. [Amaliy mashqlar](#mashqlar) 13. [O'zingizni tekshiring](#checklist) 14. [Xulosa](#xulosa) 15. [Manbalar](#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: | Faoliyat | Nima qilinadi | QA'ning hissasi | | ------------------------ | ----------------------------------- | -------------------------------------------------------------- | | Talablar | Nima qurilishi kerakligi aniqlanadi | Talablarni review qilish, savol berish, acceptance criteria | | Dizayn va arxitektura | Qanday qurilishi rejalashtiriladi | Testability, integratsiya risklari, test strategiyasi | | Ishlab chiqish (kodlash) | Kod yoziladi | Unit testlar bo'yicha hamkorlik, test data va muhit tayyorlash | | Testlash | Mahsulot tekshiriladi | Test dizayn, bajarish, bug report, regression | | Joylashtirish (release) | Foydalanuvchiga chiqariladi | Smoke, reliz checklisti, monitoring | | Qo'llab-quvvatlash | Tuzatish va yaxshilash | Maintenance testing, production bug tahlili | 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**. | Afzallik | Kamchilik | | --------------------------------------- | -------------------------------------------- | | Aniq rejalar, hujjatlar va muddatlar | Talab o'zgarsa — qimmat | | Shartnoma va regulyator talablariga mos | Defektlar kech topiladi | | Kichik, barqaror loyihalarda tushunarli | Foydalanuvchi natijani faqat oxirida ko'radi | **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](/lessons/images/qa/qa_03_v_model.svg) | Chap qanot (ishlab chiqish) | O'ng qanot (test darajasi) | Test asosi | DemoBozor misoli | | --------------------------- | -------------------------- | ----------------------------- | ----------------------------------------------- | | Talablar | Acceptance testing | Biznes talablari, user story | Do'kon operatorlari aksiya oqimini qabul qiladi | | Tizim spetsifikatsiyasi | System testing | Tizim spetsifikatsiyasi | Checkout'ni to'liq E2E sinash | | Arxitektura dizayni | Integration testing | Arxitektura, API kontraktlari | Savatcha xizmati ↔ narx hisoblash moduli | | Modul dizayni | Component (unit) testing | Modul dizayni, kod | `deliveryFee()` funksiyasining unit testlari | 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](/ios-lessons/qa-levels-types) 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 | Model | Qachon mos | QA'ning roli | Asosiy xavf | | --------------------- | ------------------------------------------------------ | -------------------------------------------- | ----------------------------------------------- | | Waterfall | Barqaror talablar, qat'iy shartnoma | Erta review va test dizayn, oxirida bajarish | Defektlar kech topiladi | | V-Model | Hujjat va kuzatuvchanlik muhim (masalan, regulyatsiya) | Har bosqichga mos test darajasi | O'zgarishlarga sekin moslashadi | | Iterativ/inkremental | Katta tizim qismlarga bo'linadi | Har iteratsiyada test + regression | Regression hajmi tez o'sadi | | Agile (Scrum, Kanban) | Talablar o'zgaruvchan, tez fikr-mulohaza kerak | Jamoa a'zosi sifatida har sprintda | Hujjat juda kam bo'lib ketishi | | DevOps | Tez-tez reliz, CI/CD | Avtomatlashtirish, quality gate, monitoring | Avtomatlashtirishni qo'llab-quvvatlash xarajati | **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](/ios-lessons/pm-methodologies). --- ## 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 | Event | Timebox (1 oylik sprint uchun) | QA nima qiladi | | ------------------------ | ------------------------------ | ------------------------------------------------------------------------------------------------- | | **Sprint** | 1 oy yoki kamroq | Story'lar tayyor bo'lishi bilan test qiladi; "test sprinti" degan narsa yo'q — test sprint ichida | | **Sprint Planning** | 8 soatgacha | Test hajmini baholaydi, testability va risk savollarini beradi, test vazifalarini rejaga qo'shadi | | **Daily Scrum** | 15 daqiqa | To'siqlarni aytadi: muhit ishlamayapti, acceptance criteria noaniq, bloklovchi bug | | **Sprint Review** | 4 soatgacha | Increment'ning sifat holatini, ma'lum muammolarni shaffof ko'rsatadi | | **Sprint Retrospective** | 3 soatgacha | Jarayonni yaxshilashni taklif qiladi: beqaror testlar, kech topshiriqlar, sifat metrikalari | **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" | Artefakt | Majburiyat (commitment) | | --------------- | ----------------------- | | Product Backlog | Product Goal | | Sprint Backlog | Sprint Goal | | Increment | **Definition of 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: ```text 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): **I**ndependent (mustaqil), **N**egotiable (muhokama qilinadigan), **V**aluable (qimmatli), **E**stimable (baholanadigan), **S**mall (kichik), **T**estable (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): | Kalit so'z | Vazifasi | | ------------------------------- | ---------------------------------------------------------------- | | `Feature` | Funksiya nomi va qisqa tavsifi | | `Background` | Har bir ssenariydan oldin bajariladigan umumiy `Given` qadamlari | | `Scenario` (yoki `Example`) | Bitta aniq misol | | `Given` | Boshlang'ich holat (kontekst) | | `When` | Harakat yoki hodisa | | `Then` | Kutilgan natija | | `And`, `But` | Oldingi qadamni davom ettirish | | `Scenario Outline` + `Examples` | Bitta shablonni jadvaldagi har qator bilan qayta ishlatish | 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: ```gherkin 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 "" 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](/ios-lessons/qa-test-design-1)). > **⚠️ 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: | | Jamoani qo'llab-quvvatlaydi | Mahsulotni tanqid qiladi | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Biznesga qaragan** | **Q2:** funksional testlar, misollar, user story testlari, UX prototiplari, API testlash, simulyatsiyalar. Acceptance criteria'ni tekshiradi; qo'lda yoki avtomatik | **Q3:** exploratory testing, usability testing, user acceptance testing. Foydalanuvchiga yo'naltirilgan, ko'pincha qo'lda | | **Texnologiyaga qaragan** | **Q1:** component va component integration testlari. Avtomatik va CI'ga kiritilgan | **Q4:** smoke testlar va nofunksional testlar (usability'dan tashqari): performance, security... Ko'pincha avtomatik | > **🧠 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](/ios-lessons/qa-principles-istqb)) 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](/lessons/images/qa/qa_03_stlc.svg) | Bosqich | Entry mezonlari | Asosiy ishlar | Exit mezonlari / natija | | ------------------------- | --------------------------------------------------------------- | -------------------------------------------------------------- | ---------------------------------------------------- | | **1. Talablar tahlili** | Talablar (user story) mavjud | Talablarni o'qish, savollar, testlanadigan narsalarni aniqlash | Savollar ro'yxati javoblangan, RTM qoralamasi | | **2. Test rejalash** | Talablar tahlil qilingan | Scope, yondashuv, resurs, jadval, risklar, baholash | Tasdiqlangan test plan | | **3. Test dizayni** | Test plan tasdiqlangan | Checklist, test case, test data yozish | Review'dan o'tgan test case'lar, test data | | **4. Muhit tayyorlash** | Muhit talablari ma'lum | Staging, test akkauntlari, ma'lumotlar, integratsiyalar | Tayyor muhit, smoke testlar o'tgan | | **5. Testlarni bajarish** | Build deploy qilingan, smoke o'tgan, test data tayyor | Test run, bug report, retest, regression | Rejadagi testlar bajarilgan, kritik bug'lar yopilgan | | **6. Siklni yopish** | Exit mezonlari bajarilgan yoki stakeholder risk'ni qabul qilgan | Hisobot, metrikalar, retrospektiva | Test completion report, saboqlar | 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: | Amaliyot | Ma'nosi | DemoBozor misoli | | -------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------- | | **Monitoring va alerting** | Xatolar, sekinlik va crash'larni real vaqtda kuzatish | To'lov xatolari foizi oshsa — signal | | **Canary release** | Yangi versiyani avval foydalanuvchilarning kichik qismiga chiqarish | Yangi checkout avval 5% xaridorga | | **Feature flags** | Funksiyani kod deploy'idan alohida yoqish/o'chirish | Muammo bo'lsa "Tez buyurtma" bitta flag bilan o'chiriladi | | **A/B test** | Ikki variantni haqiqiy foydalanuvchilarda solishtirish | Ikki xil "bepul yetkazib berish" banneri | | **Synthetic monitoring** | Production'da avtomatik ssenariylarni muntazam ishga tushirish | Har 5 daqiqada qidiruv va savatcha tekshiruvi | > **⚠️ 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](/ios-lessons/devops-release), [DevOps: Observability](/ios-lessons/devops-observability), [Growth 3: A/B testlash](/ios-lessons/growth-experimentation-ab). --- ## 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 | Belgi | Savol | | ------------------------- | ---------------------------------------------- | | Aniq (unambiguous) | Ikki kishi uni bir xil tushunadimi? | | Testlanadigan (testable) | Uni "o'tdi/o'tmadi" bilan tekshirib bo'ladimi? | | To'liq (complete) | Xato holatlari ham yozilganmi? | | Izchil (consistent) | Boshqa talablarga zid emasmi? | | Atomar (atomic) | Bitta talabda bitta g'oya bormi? | | Kuzatiladigan (traceable) | Manbasi va ID'si bormi? | ### Noaniq → testlanadigan | Noaniq talab | Savollar | Testlanadigan variant | | ------------------------------------------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | "Katalog tez yuklanishi kerak." | Qancha tez? Qaysi tarmoqda? Qaysi qurilmada? Qanday o'lchanadi? | "Katalogning birinchi sahifasi staging'da, 4G tarmoq emulyatsiyasida, 95% so'rovlarda 2 soniyadan tez to'liq ko'rsatiladi." | | "300 000 so'mdan ortiq buyurtmada yetkazib berish bepul." | 300 000 ning o'zi kiradimi? Chegirmadan oldingi yoki keyingi summa? | "Chegirmagacha bo'lgan mahsulotlar summasi ≥ 300 000 so'm bo'lsa, yetkazib berish narxi 0 so'm." | | "Foydalanuvchi bir necha marta xato kod kiritsa, bloklanadi." | Necha marta? Qancha vaqtga? Nima bloklanadi? | "Ketma-ket 3 ta noto'g'ri SMS kod kiritilsa, telefon raqami 15 daqiqaga bloklanadi va bu haqda xabar ko'rsatiladi." | | "Parol xavfsiz bo'lishi kerak." | Uzunligi? Belgilar turi? | "Parol 8–64 belgi, kamida 1 harf va 1 raqam." | > **🧠 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](/ios-lessons/pm-requirements-tz). --- ## 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."
💡 Javobni ko'rish 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."
### 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."
💡 Javobni ko'rish 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.
### 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).
💡 Javobni ko'rish ```gherkin 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 "" 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.
### 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.
💡 Javobni ko'rish 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).
### 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.
💡 Javobni ko'rish 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.
### 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.
💡 Javobni ko'rish **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.
--- ## 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](/ios-lessons/qa-levels-types) ## Manbalar {#manbalar} 1. [ISTQB CTFL Syllabus v4.0.1 (PDF, 2024-09-15)](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf) 2. [The Scrum Guide (2020)](https://scrumguides.org/scrum-guide.html) 3. [Manifesto for Agile Software Development (2001)](https://agilemanifesto.org/) 4. [Cucumber — Gherkin Reference](https://cucumber.io/docs/gherkin/reference/) 5. [Lisa Crispin — Using the Agile Testing Quadrants](https://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/) 6. [Wikipedia — V-model (software development)]() 7. [Martin Fowler — Canary Release](https://martinfowler.com/bliki/CanaryRelease.html) 8. [Pete Hodgson (martinfowler.com) — Feature Toggles](https://martinfowler.com/articles/feature-toggles.html) 9. [Atlassian — Definition of Done](https://www.atlassian.com/agile/project-management/definition-of-done)