QA 28: Karyera — CV, portfolio, ISTQB sertifikati, 60+ intervyu savoli va birinchi ish

🧪 QA Engineer — Zero to Hero

QA 28: Karyera — CV, portfolio, ISTQB sertifikati, 60+ intervyu savoli va birinchi ish

Holat: 2026-yil oktabr. Bu dars kursning karyera qismi: QA karyera zinapoyasi, darajalar bo'yicha kutilmalar, 16 haftalik o'quv rejasi, portfolio va CV, O'zbekistonda va remote ish qidirish, ISTQB sertifikatlari (CTFL v4.0 imtihon faktlari ISTQB'ning rasmiy sahifalaridan) va javoblari bilan 66 ta intervyu savoli. Maosh raqamlari ataylab berilmagan — ular tez o'zgaradi, joriy vakansiyalardan o'zingiz solishtiring.

Bu darsdan keyin siz: birinchi QA ishiga tayyorgarlikni aniq reja bilan boshqarasiz va intervyuda bilimingizni tartibli, ishonchli ko'rsata olasiz.

• QA karyera yo'llari va har bir daraja kutadigan ko'nikmalarni bilasiz;
• tajriba bo'lmasa ham ishonchli portfolio va ATS'dan o'tadigan CV tayyorlaysiz;
• ISTQB sertifikati sizga kerakmi-yo'qmi, asosli qaror qilasiz;
• 66 ta eng ko'p beriladigan savolga qisqa va to'g'ri javob berishni mashq qilasiz;
• yangi ishdagi birinchi 90 kunni rejalashtirasiz.

Mundarija

1. Karyera xaritasi: Intern'dan Lead'gacha
2. Har bir daraja nimani kutadi
3. 16 haftalik o'quv rejasi
4. Portfolio: tajribasiz tajribani ko'rsatish
5. QA uchun CV
6. Ish qidirish: O'zbekiston va remote
7. ISTQB va boshqa sertifikatlar
8. Intervyu jarayoni qanday o'tadi
9. 66 ta intervyu savoli va javoblar
10. Amaliy topshiriq (take-home) qanday bajariladi
11. Yangi ishdagi birinchi 90 kun
12. Hamjamiyatlar va doimiy o'sish
13. Amaliy mashqlar
14. O'zingizni tekshiring
15. Xulosa
16. Manbalar

1. Karyera xaritasi: Intern'dan Lead'gacha {#karyera-xaritasi}

QA karyerasi — bitta to'g'ri chiziq emas. Har pog'onada asosiy savol o'zgaradi: Junior "qanday testlayman?" deb so'rasa, Lead "sifatni qanday boshqaramiz?" deb so'raydi.

QA karyera zinapoyasi: Intern, Junior, Middle, Senior, Lead va yondosh yo'llar

Senior darajasidan keyin yo'l tarmoqlanadi:

Yondosh yo'llar — QA tajribasi juda qadrlanadigan boshqa kasblar:

• Business Analyst — talablarni tahlil qilish (QA buni har kuni qiladi);
• Product Manager — foydalanuvchi va sifat nuqtai nazari;
• DevOps / SRE — CI/CD, monitoring, reliz (DevOps CI/CD);
• Security — xavfsizlik testlash va AppSec.

🧠 Esda tuting: Manual QA'dan boshlash "past daraja" emas. Test dizayn, talablarni tahlil qilish va bug report yozish — barcha keyingi yo'llarning poydevori. Kuchli avtomatlashtiruvchi avvalo kuchli tester bo'ladi.

2. Har bir daraja nimani kutadi {#darajalar}

Quyidagi jadval — sanoatda keng tarqalgan, lekin taxminiy tasavvur. Yillar soni kompaniyaga qarab juda farq qiladi; muhimi — mustaqillik va mas'uliyat darajasi.

Manual QA, AQA va SDET farqi

🎯 Intervyuda: "5 yildan keyin o'zingizni qayerda ko'rasiz?" — Aniq yo'nalish ayting va uni hozirgi harakatlaringiz bilan bog'lang: "API va avtomatlashtirishda chuqurlashib, SDET bo'lmoqchiman; hozir Playwright bilan capstone loyiha qildim va CI'ga ulayapman."

3. 16 haftalik o'quv rejasi {#oquv-rejasi}

Bu kursni noldan boshlagan odam uchun realistik reja: kuniga 2–3 soat, haftasiga bir kun — faqat amaliyot. Har hafta oxirida natija GitHub'da yoki hujjatda ko'rinsin.

💡 Maslahat: 16 haftani kutmang — 8-haftadan keyin (manual + API + SQL tayyor bo'lganda) Junior Manual QA vakansiyalariga ariza berishni boshlasangiz bo'ladi. Intervyular ham mashq.

4. Portfolio: tajribasiz tajribani ko'rsatish {#portfolio}

Junior uchun eng katta muammo: "tajriba yo'q — ish yo'q, ish yo'q — tajriba yo'q". Portfolio bu doirani buzadi: siz qila olishingizni ko'rsatasiz, faqat aytmaysiz.

Portfolio'ga nimalar kiradi

Qayerda "haqiqiy" mashq qilish mumkin

• Toolshop (practicesoftwaretesting.com) va uning ataylab bug'li versiyasi — bug hunting uchun ideal (QA 29);
• saucedemo, restful-booker va kursda ishlatilgan boshqa amaliyot saytlari;
• Crowdtesting platformalari — masalan, uTest yoki Testlio: haqiqiy mahsulotlarni pullik loyihalarda testlash imkoniyati. Qabul shartlari va to'lov qoidalari o'zgarib turadi — saytlarida tekshiring;
• Open source — loyihalarga aniq bug report yozish yoki testlarini yaxshilash (PR) — juda kuchli signal.

⚠️ Diqqat: Haqiqiy kompaniyalarning production tizimlarini ruxsatsiz "testlamang", ayniqsa xavfsizlik va yuklama testlarini. Bu noqonuniy bo'lishi mumkin. Portfolio uchun faqat amaliyot uchun ochiq saytlar, o'z loyihalaringiz va rasmiy bug bounty/crowdtesting dasturlaridan foydalaning.

Repo tuzilmasi

toolshop-qa-portfolio/
├── README.md                 # loyiha haqida, qanday ishga tushiriladi, natijalar
├── docs/
│   ├── test-strategy.md      # 1 sahifali strategiya
│   ├── risk-matrix.md
│   ├── checklist.md
│   ├── test-cases.csv        # yoki test management tool eksporti
│   └── bugs/                 # BUG-001.md ... BUG-010.md
├── postman/                  # yoki bruno/
├── pages/                    # Page Object'lar
├── fixtures/
├── tests/
│   ├── ui/
│   ├── api/
│   └── a11y/
├── playwright.config.ts
└── .github/workflows/playwright.yml

README namunasi

# Toolshop QA Portfolio

![Playwright tests](https://github.com/<user>/toolshop-qa-portfolio/actions/workflows/playwright.yml/badge.svg)

Practice Software Testing "Toolshop" ilovasi uchun to'liq QA loyihasi:
strategiya, risk matritsa, 30 ta test case, 10 ta bug report, API kolleksiya
va Playwright + TypeScript avtomatlashtirish (UI, API, a11y), GitHub Actions CI.

## Ishga tushirish
npm ci
npx playwright install --with-deps chromium
npx playwright test

## Natijalar
- 24 ta avtomatik test (UI 14, API 8, a11y 2)
- with-bugs versiyasida 10 ta hujjatlashtirilgan bug (docs/bugs)
- CI: har PR'da smoke, har kecha to'liq regression

## Nima qilinmadi va nega
- Yuklama testi: ommaviy demo saytga yuk berish noto'g'ri

CI badge URL formati GitHub hujjatida: https://github.com/OWNER/REPOSITORY/actions/workflows/WORKFLOW-FILE/badge.svg. README'dagi raqamlar sizning haqiqiy natijangiz bo'lsin.

5. QA uchun CV {#cv}

QA vakansiyalari ko'p ariza oladi; ko'pincha birinchi saralashni HR yoki ATS (Applicant Tracking System) qiladi. Maqsad — 6–10 soniyada "bu odam nima qila oladi" degan savolga javob berish.

Tuzilma (1 sahifa, juniorlar uchun)

1. Sarlavha — ism, shahar, aloqa, GitHub, LinkedIn;
2. Summary — 2–3 jumla: kimsiz, nimani yaxshi bilasiz, nimani qidiryapsiz;
3. Skills — guruhlangan: Testing, API, Automation, Tools, Languages;
4. Projects / Experience — eng muhim bo'lim, natijalar bilan;
5. Education, Certifications, Languages (ingliz tili darajasi).

ATS qoidalari

• Oddiy format: standart sarlavhalar, jadval va rasm ichida matn yo'q, PDF;
• Vakansiyadagi kalit so'zlar sizda haqiqatan bo'lsa — aynan o'sha shaklda yozing (API testing, Postman, SQL, Playwright, TypeScript, Jira, CI/CD, Agile/Scrum, test design);
• Fayl nomi: Aziz_Karimov_QA_CV.pdf.

Bullet formulasi: Harakat + Nima + Qanday + Natija

Ingliz tilidagi namuna (xayoliy nomzod)

AZIZ KARIMOV — Junior QA Engineer
Tashkent, Uzbekistan · <email> · github.com/<user> · linkedin.com/in/<user>

SUMMARY
Junior QA engineer with hands-on practice in manual and API testing and
Playwright automation. Built an end-to-end QA portfolio for a public demo
e-commerce app. Looking for a Junior QA / Junior AQA role.

SKILLS
Testing: test design (EP, BVA, decision tables, state transition),
  test cases, checklists, bug reports, exploratory testing
API: REST, Postman/Newman, JSON Schema; SQL: SELECT, JOIN, GROUP BY
Automation: Playwright, TypeScript, Page Object Model, GitHub Actions
Tools: Jira, Chrome DevTools, Proxyman, Git

PROJECTS
Toolshop QA Portfolio (github.com/<user>/toolshop-qa-portfolio)
- Wrote a 1-page test strategy and a risk matrix for 9 features
- Designed 30 test cases; found and documented 10 bugs in the buggy build
- Automated 22 scenarios (UI + API + a11y) with Playwright; CI on GitHub Actions

EDUCATION / CERTIFICATIONS / LANGUAGES
...

Ko'p uchraydigan xatolar

• QA CV'sida imlo xatolari — "detalga e'tibor" degan da'voni darhol yo'qqa chiqaradi;
• Har bir eshitgan vositani "skills"ga yozish (keyin intervyuda savol bo'ladi);
• Mas'uliyatlarni sanash, natijalarni emas;
• To'qib chiqarilgan tajriba yoki raqamlar — texnik intervyuda tez ochiladi.

💡 Maslahat: Har bir vakansiya uchun Summary va Skills bo'limini 5 daqiqada moslashtiring. Bitta "universal" CV bilan 100 ta arizadan ko'ra, moslashtirilgan 20 ta ariza yaxshiroq natija beradi.

6. Ish qidirish: O'zbekiston va remote {#ish-qidirish}

Qayerdan qidirish

🇺🇿 Mahalliy kontekst: Vakansiyalar ko'pincha rus yoki ingliz tilida bo'ladi va kalit so'zlar ham shunday: "QA инженер", "тестировщик", "Manual QA", "AQA". Qidiruvda uchala tildagi variantlarni ishlating.

Remote ish uchun

• Ingliz tili — yozma (bug report, Slack) va og'zaki (daily stand-up) — ko'pincha hal qiluvchi omil;
• Vaqt zonasi — Toshkent UTC+5; jamoa bilan qancha soat kesishishini oldindan aniqlang;
• Shartnoma va to'lov — rasmiylashtirish shakli va soliq masalalarini ariza berishdan oldin o'rganing; kerak bo'lsa mutaxassisdan maslahat oling;
• Sinov topshiriqlari — remote'da deyarli har doim bo'ladi (10-bo'lim).

Maosh haqida

Bu darsda maosh raqamlari ataylab berilmagan: ular shahar, til, kompaniya turi va yilga qarab tez o'zgaradi. To'g'ri yo'l:

1. hh.uz va LinkedIn'dagi o'xshash vakansiyalarda ko'rsatilgan oraliqlarni yig'ing;
2. Hamjamiyatdagi tajribali QA'lardan so'rang;
3. Umumiy paketni baholang: maosh, o'qish imkoniyati, mentor, masofaviy ish, sug'urta;
4. Muzokarada: o'zingizning minimal chegarangizni biling, iloji bo'lsa oraliqni birinchi bo'lib ular aytsin, yolg'on gapirmang.

Ariza taktikasi

• Arizalarni jadvalda kuzating: kompaniya, sana, holat, keyingi qadam;
• Har arizaga 3–5 jumlali qisqa xat: nega aynan shu kompaniya va qaysi ko'nikmangiz mos;
• Rad javobi — normal holat; har intervyudan keyin "nimani yaxshilayman" deb yozib qo'ying.

7. ISTQB va boshqa sertifikatlar {#istqb}

ISTQB (International Software Testing Qualifications Board) — dasturiy ta'minotni testlash bo'yicha xalqaro sertifikatlash tashkiloti. Uning asosiy boshlang'ich sertifikati — CTFL (Certified Tester Foundation Level).

CTFL v4.0 — imtihon faktlari

Imtihon ISTQB'ning a'zo board'lari va ular akkreditlagan exam provider'lar orqali topshiriladi, ko'pincha onlayn (proctoring bilan). O'zbekistondan topshirish shartlari va narxini tanlagan provayderning saytida tekshiring.

Keyingi sertifikatlar (istqb.org ro'yxatidan)

istqb.org'da ba'zi eski sertifikatlar "Retiring" deb belgilangan (masalan, Foundation Level Agile Tester — CT-AT). Ro'yxat o'zgarib turadi — imtihonga yozilishdan oldin rasmiy sahifani tekshiring.

Sertifikat kerakmi?

Tavsiya: Syllabus'ni o'qing (bepul) — u bu kursning 1–8-darslari bilan kuchli kesishadi. Byudjet bo'lsa yoki ish beruvchi talab qilsa — imtihon topshiring. Lekin portfolio'ni sertifikatdan oldin qo'ying.

💡 Maslahat: Imtihonda ISTQB terminlariga e'tibor bering: masalan, v4.0'da beshinchi printsip "Tests wear out" deb nomlanadi (oldingi versiyalarda "pesticide paradox"). Namunaviy imtihonlarni vaqt bilan ishlang.

8. Intervyu jarayoni qanday o'tadi {#intervyu-jarayoni}

Intervyuda o'zingizni qanday tutish

• Ovoz chiqarib fikrlang — intervyuer natijani emas, fikrlash yo'lini baholaydi;
• Aniqlashtiruvchi savollar bering — "qalamni testlang" topshirig'ida birinchi qadam — talablarni so'rash;
• Javobni tuzilmali bering — "funksional, negative, chegaraviy, non-functional" kabi guruhlar bilan;
• Bilmasangiz — tan oling va qanday aniqlashingizni ayting ("hujjatdan tekshirardim", "kichik prototip yozib ko'rardim");
• Xulq-atvor savollarida STAR: Situation (vaziyat), Task (vazifa), Action (nima qildingiz), Result (natija).

Siz beradigan savollar (har doim 2–3 ta tayyorlang)

• Jamoada QA va dasturchilar nisbati qanday? QA qaysi bosqichda jalb qilinadi?
• Avtomatlashtirish hozir qanday holatda, qaysi vositalar ishlatiladi?
• Reliz jarayoni qanday: qanchalik tez-tez va qanday qaror qabul qilinadi?
• Birinchi 3 oyda mendan nima kutiladi? Mentor bo'ladimi?

9. 66 ta intervyu savoli va javoblar {#savollar}

Javoblarni avval o'zingiz ovoz chiqarib aytib ko'ring, keyin ochib solishtiring. Har javob — qisqa, intervyuda aytish mumkin bo'lgan shaklda.

9.1. Nazariya va asoslar (1–16)

1. QA, QC va testing farqi nima?

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

QA (Quality Assurance) — jarayonga qaratilgan va xatolarning oldini olishga yo'naltirilgan: standartlar, review'lar, jarayonni yaxshilash. QC (Quality Control) — mahsulotga qaratilgan, tayyor mahsulotda nuqsonlarni aniqlash. Testing — QC'ning asosiy faoliyati: tizimni tekshirib nuqsonlarni topish va sifat haqida ma'lumot berish. Batafsil: QA 1.

</details>

2. Error, defect va failure farqi?

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

Error (mistake) — inson xatosi: dasturchi bepul yetkazish shartiga >= o'rniga > yozdi. Defect (bug, fault) — shu xato natijasida koddagi nuqson. Failure — defekt ishga tushganda tizimning kutilgandan farqli xatti-harakati: aynan 300 000 so'mlik buyurtmaga yetkazish haqi olinadi. Har bir defekt failure'ga olib kelmaydi — u joylashgan kod hech qachon bajarilmasligi mumkin.

</details>

3. Verification va validation farqi?

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

Verification — "mahsulotni to'g'ri qurayapmizmi?" (spetsifikatsiyaga moslik: review, testlar). Validation — "to'g'ri mahsulotni qurayapmizmi?" (foydalanuvchi ehtiyojiga moslik: UAT, beta testlash).

</details>

4. Testlashning 7 printsipini sanang.

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

ISTQB CTFL v4.0 bo'yicha:

1. Testlash defektlar borligini ko'rsatadi, yo'qligini isbotlamaydi;
2. To'liq testlash imkonsiz;
3. Erta testlash vaqt va pulni tejaydi;
4. Defektlar to'planadi (kichik qism ko'p defektni o'z ichiga oladi);
5. Testlar eskiradi (tests wear out) — bir xil testlar vaqt o'tib yangi defekt topmay qo'yadi;
6. Testlash kontekstga bog'liq;
7. "Defekt yo'q" xatosi (absence-of-defects fallacy) — defektsiz, lekin foydalanuvchiga keraksiz tizim ham muvaffaqiyatsiz.

Har biriga bitta misol aytsangiz — kuchli javob. Batafsil: QA 2.

</details>

5. SDLC va STLC farqi?

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

SDLC — dasturiy ta'minotning butun hayot sikli: talablar → dizayn → ishlab chiqish → testlash → deploy → qo'llab-quvvatlash. STLC — uning ichidagi testlash sikli: talablar tahlili → test rejalash → test case'lar → muhit tayyorlash → bajarish → yakunlash. Agile'da bu bosqichlar har sprint ichida qisqa sikllarda takrorlanadi. Batafsil: QA 3.

</details>

6. Test darajalarini sanang.

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

ISTQB CTFL v4.0: komponent (unit), komponent integratsiya, tizim (system), tizim integratsiyasi (tashqi tizimlar va servislar bilan) va qabul (acceptance) testlash. Qabul testlashning shakllari: UAT, operational acceptance, contractual va regulatory acceptance, alpha va beta testlash.

</details>

7. Smoke, sanity va regression farqi?

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

</details>

8. Retesting va regression testing farqi?

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

Retesting (confirmation testing) — tuzatilgan bug aynan tuzatilganini o'sha qadamlar bilan tekshirish. Regression testing — tuzatish yoki boshqa o'zgarish boshqa joylarni buzmaganini tekshirish. Odatda ikkalasi ketma-ket bajariladi.

</details>

9. Severity va priority farqi? Misol keltiring.

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

Severity — bug'ning tizimga texnik ta'siri; priority — uni tuzatish shoshilinchligi (biznes qarori).

• Yuqori severity, past priority: oyiga ikki marta ishlatiladigan eski admin hisobot eksportida crash;
• Past severity, yuqori priority: bosh sahifada kompaniya nomi xato yozilgan yoki to'lov sahifasida noto'g'ri logotip.

Batafsil: QA 8.

</details>

10. Bug life cycle'ni tushuntiring.

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

New → Open/Triaged → Assigned → In Progress → Fixed → Ready for QA → Verified → Closed. Yon tarmoqlar: Rejected (bug emas / works as designed), Duplicate, Cannot Reproduce, Deferred / Won't Fix, Reopened (tekshiruvda muammo qayta chiqsa). Aniq status nomlari jamoaning Jira workflow'iga bog'liq.

</details>

11. Test plan nimalardan iborat?

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

Maqsad va qamrov (nima testlanadi va nima testlanmaydi), yondashuv (darajalar, turlar, texnikalar), muhitlar va ma'lumotlar, rollar, jadval, entry/exit criteria, risklar va ularni kamaytirish, deliverable'lar, vositalar. Shablon sifatida ISO/IEC/IEEE 29119-3 ishlatiladi. Batafsil: QA 7.

</details>

12. Test case, test scenario va checklist farqi?

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

Checklist — tekshiriladigan punktlar ro'yxati (qisqa, tajribali tester uchun). Test scenario — yuqori darajadagi "nimani tekshiramiz" ("promo-kod bilan buyurtma berish"). Test case — oldingi shartlar, aniq qadamlar, test ma'lumotlari va kutilgan natija bilan batafsil hujjat.

</details>

13. Black-box, white-box va grey-box testing?

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

Black-box — ichki kodni bilmasdan, talab va xatti-harakat bo'yicha (EP, BVA, decision table). White-box — kod tuzilmasi asosida (statement va branch coverage). Grey-box — qisman ichki bilim bilan: masalan, API va DB sxemasini bilib turib UI'ni testlash.

</details>

14. Entry va exit criteria nima?

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

Entry criteria — testlashni boshlash shartlari (build staging'da, smoke o'tgan, test ma'lumotlari tayyor). Exit criteria — testlashni tugatish shartlari (kritik case'lar bajarilgan, ochiq Blocker/Critical yo'q, yuqori risklar qamralgan). Ikkalasi ham o'lchanadigan bo'lishi kerak. Batafsil: QA 27.

</details>

15. Exploratory testing nima va qachon kerak?

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

Bir vaqtning o'zida o'rganish, test dizayn va bajarish. Tartibli bo'lishi uchun charter (maqsad) va timebox (masalan, 60 daqiqalik sessiya) ishlatiladi. Qachon kerak: talablar kam, yangi funksiya, scripted testlar topa olmaydigan bug'larni izlash, vaqt qisqa. U scripted testlashni almashtirmaydi — to'ldiradi.

</details>

16. Shift-left va shift-right nima?

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

Shift-left — testlash faoliyatini erta boshlash: talablarni review qilish, Three Amigos, unit va API testlar, PR'dagi avtomatik tekshiruvlar. Shift-right — production'dan sifat haqida ma'lumot olish: monitoring, canary reliz, feature flag'lar, A/B testlar, crash analitikasi.

</details>

9.2. Test dizayn va "buni testlang" (17–26)

17. EP va BVA'ni misol bilan tushuntiring: yosh 18–65.

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

Equivalence Partitioning: < 18 (invalid), 18–65 (valid), > 65 (invalid) va format bo'yicha invalid bo'laklar (bo'sh, harf, kasr son). Har bo'lakdan bitta vakil yetarli.

BVA: chegaralar 17 | 18 va 65 | 66 — har birida ikkita chegaraviy qiymat bor. 2 qiymatli BVA — 17, 18, 65, 66; 3 qiymatli BVA (har chegaraviy qiymat va uning ikkala qo'shnisi) — 16, 17, 18, 19, 64, 65, 66, 67. Ko'p uchraydigan xato javob — "17, 18, 19, 64, 65, 66": u faqat valid bo'lak chegaralarini oladi (QA 5).

Qo'shimcha nozik joy: yosh tug'ilgan sanadan hisoblansa — "bugun 18 yoshga to'lgan" holati va vaqt zonasi (Asia/Tashkent). Batafsil: QA 5.

</details>

18. Decision table qachon ishlatiladi?

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

Natija bir nechta shartning kombinatsiyasiga bog'liq bo'lganda — biznes qoidalari uchun. Masalan, DemoBozor chegirmasi: yangi mijoz × promo-kod × premium a'zo. Har bir qoida (ustun) — bitta test; natijaga ta'sir qilmaydigan shartlar "–" bilan qisqartiriladi.

</details>

19. State transition testing qachon kerak?

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

Tizim holatlarga ega bo'lib, hodisalarga qarab holat o'zgarganda: buyurtma statuslari, login bloklash (3 marta noto'g'ri SMS kod → 15 daqiqa blok), obuna. Faqat ruxsat etilgan o'tishlarni emas, ruxsat etilmaganlarini ham testlaymiz (masalan, SHIPPED → CANCELLED mumkin emas). Batafsil: QA 6.

</details>

20. Pairwise testing nima uchun kerak?

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

Ko'p parametrli kombinatsiyalarni qisqartirish uchun: 3 brauzer × 3 til × 3 to'lov usuli × 2 qurilma = 54 kombinatsiya, lekin har bir juftlik kamida bir marta uchraydigan to'plam 9 ta testdan iborat bo'lishi mumkin. Asos: ko'p nosozliklar bir yoki ikki parametrning o'zaro ta'siridan kelib chiqadi (NIST'ning kombinatorial testlash tadqiqotlari — QA 6). Vosita: Microsoft PICT. Eslatma: pairwise va use case testing CTFL v4.0 syllabus'iga kirmaydi (v4.0'dagi black-box texnikalar: EP, BVA, decision table, state transition), lekin amalda keng qo'llanadi.

</details>

21. "Qalamni testlang."

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

Avval savollar: qanday qalam (sharikli, gelli, qo'rg'oshin)? Kim uchun (maktab o'quvchisi, ofis)? Talablar bormi?

Keyin guruhlab:

• Funksional: yozadimi, rangi va chiziq qalinligi, qopqoq/tugma mexanizmi;
• Chegaraviy va chidamlilik: necha metr yozadi, siyoh oxirida qanday yozadi, tushib ketsa;
• Muhit: sovuqda/issiqda, turli qog'ozda, vertikal holatda (devorga) yozish;
• Ergonomika: ushlash qulayligi, chap qo'l uchun siyoh surtilishi;
• Xavfsizlik: zaharsiz materiallar, bolalar uchun qopqoqni yutib yuborish xavfi;
• Negative: suvga tushsa, bosim bilan yozilsa;
• Qadoq, narx, yorliq.

Intervyuer javobning to'liqligini emas, tuzilmasini va savol berishingizni baholaydi.

</details>

22. "Liftni testlang."

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

Savollar: nechta qavat, yuk ko'tarish limiti, odamlar soni, tezlik talablari?

• Funksional: chaqirish tugmasi, qavat tanlash, eshik ochilishi/yopilishi, displey va ovozli e'lon;
• Chegaralar: 1-qavat va oxirgi qavat, maksimal yuk (limitga teng va limitdan ozgina ortiq);
• Bir vaqtdagi chaqiruvlar: bir nechta qavatdan chaqirilganda navbat mantiqi;
• Xavfsizlik: eshik orasidagi to'siq, tok o'chishi, favqulodda tugma va aloqa, yong'in rejimi;
• Usability va a11y: tugmalar balandligi, Brayl yozuvi, ovozli e'lonlar;
• Performance: kutish vaqti, "tirbandlik" soatlarida.

</details>

23. "Login formasini testlang."

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

• Positive: to'g'ri login va parol; "eslab qolish";
• Negative: noto'g'ri parol, mavjud bo'lmagan foydalanuvchi, bo'sh maydonlar, boshida/oxirida probel, katta-kichik harf;
• Chegaralar: parol uzunligi (DemoBozor: 8–64 belgi) — 2 qiymatli BVA: 7, 8, 64, 65;
• Xavfsizlik: parol maskalangan; bir necha noto'g'ri urinishdan keyin bloklash; xato xabari qaysi maydon noto'g'riligini aytmaydi; HTTPS; SQLi/XSS probe'lar xavfsiz qayta ishlanadi; logout'dan keyin sessiya yaroqsiz (QA 24);
• UX: Enter bilan yuborish, autofill, "parolni ko'rsatish", fokus tartibi;
• A11y: label'lar, xato xabarlari screen reader'ga o'qiladi;
• Boshqa: parolni tiklash oqimi, bir vaqtning o'zida ikki qurilmadan kirish.

</details>

24. "Karta bilan to'lov formasini testlang."

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

• Karta raqami: har bir to'lov tizimining (Uzcard, Humo, Visa, Mastercard) formati va uzunligi; probel bilan kiritish; xalqaro kartalar uchun Luhn tekshiruvi;
• Amal qilish muddati: o'tgan oy, joriy oy, kelajak; CVV — hech qachon saqlanmaydi va log'larga tushmaydi;
• Summa: 0, manfiy, juda katta, kasr qiymatlar;
• Tasdiqlash: SMS/OTP oqimi, noto'g'ri kod, kodning muddati tugashi;
• Ishonchlilik: double-click → pul ikki marta yechilmasligi (idempotentlik); to'lov paytida tarmoq uzilishi; timeout; brauzerda "orqaga";
• Xato javoblari: mablag' yetarli emas, karta bloklangan, provayder ishlamayapti;
• Qaytarish (refund) va buyurtma holati bilan moslik;
• Xavfsizlik: HTTPS, karta ma'lumotlari maskalangan, PCI DSS talablari.

</details>

25. Talablar yo'q bo'lsa nima qilasiz?

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

1. Ma'lumot manbalarini qidiraman: PO, dizayn maketlari, eski versiya, foydalanuvchi qo'llanmasi, raqobatchilar;
2. Savollar ro'yxatini tuzib, PO bilan aniqlashtiraman;
3. O'z taxminlarimni yozib, tasdiqlatib olaman (masalan, Gherkin misollari bilan);
4. Charter bilan exploratory testing o'tkazaman;
5. Noaniqliklarni bug emas, savol sifatida qayd qilaman.

</details>

26. Testlashni qachon to'xtatasiz?

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

To'liq testlash imkonsiz, shuning uchun qaror exit criteria asosida: kritik case'lar bajarilgan, yuqori risklar qamralgan, ochiq Blocker/Critical yo'q, yangi topilayotgan bug'lar soni kamaygan. Agar vaqt yoki byudjet tugasa — testlanmagan qismlar va qolgan risk haqida aniq hisobot beriladi; qarorni stakeholder'lar shu ma'lumot bilan qabul qiladi.

</details>

9.3. Web, API va SQL (27–40)

27. Brauzerga URL yozilganda nima sodir bo'ladi (qisqacha)?

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

DNS domenni IP manzilga aylantiradi → TCP ulanish (HTTPS bo'lsa TLS handshake) → HTTP so'rov → server javobi (status, header'lar, body) → brauzer HTML'ni o'qib, CSS/JS/rasmlarni yuklaydi va sahifani chizadi. QA uchun: har bosqichda muammo bo'lishi mumkin (DNS, sertifikat, 5xx, CORS, JS xatosi) — barchasi DevTools'da ko'rinadi. Batafsil: QA 9.

</details>

28. Cookie, localStorage va sessionStorage farqi?

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

QA nuqtai nazari: token'ni localStorage'da saqlash XSS hujumida o'g'irlanish xavfini oshiradi.

</details>

29. GET va POST farqi? PUT va PATCH farqi?

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

GET — ma'lumot o'qish; body odatda yo'q, xavfsiz (safe) va idempotent, keshlanishi mumkin. POST — yangi resurs yaratish yoki amal bajarish; idempotent emas. PUT — resursni to'liq almashtirish (idempotent). PATCH — qisman o'zgartirish (idempotent bo'lishi shart emas). Batafsil: QA 10.

</details>

30. Idempotentlik nima va QA uchun nega muhim?

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

Bir xil so'rovni N marta yuborish natijasi 1 marta yuborish bilan bir xil bo'lsa — so'rov idempotent. GET, PUT, DELETE — idempotent; POST — yo'q. QA double-click, tarmoq retry'i yoki sahifani yangilash natijasida ikki marta buyurtma yoki to'lov bo'lmasligini tekshiradi (server odatda idempotency key ishlatadi).

</details>

31. 401 va 403; 400 va 422; 500 va 503 farqi?

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

• 401 Unauthorized — autentifikatsiya yo'q yoki noto'g'ri (kimligingiz noma'lum); 403 Forbidden — kimligingiz ma'lum, lekin ruxsat yo'q;
• 400 Bad Request — so'rov noto'g'ri tuzilgan (sintaksis/format); 422 Unprocessable Content — format to'g'ri, lekin mazmun qoidaga zid (validatsiya);
• 500 Internal Server Error — serverdagi kutilmagan xato; 503 Service Unavailable — server vaqtincha ishlamayapti (yuklama yoki texnik ishlar).

Real hayotdagi misol: restful-booker noto'g'ri parolga 200 va {"reason":"Bad credentials"} qaytaradi — bu REST nuqtai nazaridan bug muhokamasi uchun yaxshi material (to'g'risi 401 bo'lardi).

</details>

32. REST API'da nimalarni tekshirasiz?

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

Status kod; javob body'sidagi qiymatlar; sxema va tiplar; header'lar (Content-Type, keshlash, xavfsizlik); javob vaqti; biznes qoidalar; yon ta'sirlar (DB'dagi yozuv — QA 12); xato formati izchilligi; autentifikatsiya va avtorizatsiya; negative holatlar (yo'q maydon, noto'g'ri tip, chegaralar); idempotentlik; pagination va filtrlar. Batafsil: QA 11.

</details>

33. Bug front-end'dami yoki back-end'mi — qanday aniqlaysiz?

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

DevTools → Network:

1. So'rov umuman yuborildimi? Yo'q bo'lsa va Console'da JS xato bo'lsa — front-end;
2. So'rov to'g'ri parametrlar bilan yuborildimi? Noto'g'ri bo'lsa — front-end;
3. Javob statusi va ma'lumoti to'g'rimi? Javob noto'g'ri yoki 5xx — back-end;
4. Javob to'g'ri, lekin UI noto'g'ri ko'rsatyapti — front-end.

Bug report'ga so'rov/javobni (yoki HAR'ni) biriktiring — dasturchi vaqtini tejaysiz.

</details>

34. CORS xatosi nima?

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

Brauzerning xavfsizlik mexanizmi: bir origin'dagi sahifa boshqa origin'ga so'rov yuborganda, server Access-Control-Allow-Origin kabi header'lar bilan ruxsat bermasa, brauzer javobni JavaScript'ga bermaydi. Bu odatda server konfiguratsiyasi masalasi. Postman yoki curl'da ko'rinmaydi, chunki ular brauzer emas — shuning uchun "Postman'da ishlayapti-ku" argumenti CORS'ga taalluqli emas.

</details>

35. JWT nima va QA unda nimani tekshiradi?

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

JSON Web Token — header.payload.signature ko'rinishidagi imzolangan token (base64url bilan kodlangan, shifrlanmagan). QA tekshiradi: muddati o'tgan token rad etiladi (401); imzosi buzilgan yoki payload o'zgartirilgan token rad etiladi; payload'da maxfiy ma'lumot yo'q; logout'dan keyin refresh token yaroqsiz; payload'dagi rolni o'zgartirib ruxsat olib bo'lmaydi. Haqiqiy token'larni onlayn decoder'larga joylamang.

</details>

36. INNER JOIN va LEFT JOIN farqi?

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

INNER JOIN — faqat ikkala jadvalda ham mos keladigan qatorlar. LEFT JOIN — chap jadvalning barcha qatorlari; o'ngda mosi bo'lmasa, ustunlar NULL. QA'da LEFT JOIN ... WHERE o.id IS NULL — "yetim" yozuvlarni topishning klassik usuli (masalan, buyurtmasi yo'q order_items).

</details>

37. WHERE va HAVING farqi?

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

WHERE — guruhlashdan oldin qatorlarni filtrlaydi; HAVING — GROUP BY'dan keyin guruhlarni agregat qiymat bo'yicha filtrlaydi. Misol: GROUP BY user_id HAVING COUNT(*) > 5 — 5 tadan ko'p buyurtma bergan foydalanuvchilar.

</details>

38. Dublikat yozuvlarni SQL bilan qanday topasiz?

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

Umumiy shablon — GROUP BY + HAVING COUNT(*) > 1. QA uchun foydali misol: double-click natijasida bir daqiqa ichida bir xil summali ikki buyurtma yaratilganmi (SQLite sintaksisi):

SELECT user_id, total, substr(created_at, 1, 16) AS minute, COUNT(*) AS cnt
FROM orders
GROUP BY user_id, total, minute
HAVING COUNT(*) > 1;

Agar ustunda UNIQUE cheklov bo'lsa (masalan, users.phone), DB dublikatga yo'l qo'ymaydi — cheklov borligini ham tekshirish QA ishi.

</details>

39. DELETE, TRUNCATE va DROP farqi?

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

• DELETE — qatorlarni o'chiradi (WHERE bilan tanlab); tranzaksiya ichida qaytarish mumkin;
• TRUNCATE — jadvaldagi barcha qatorlarni tez o'chiradi, jadval tuzilmasi qoladi; tranzaksiyaviy xatti-harakati DBMS'ga bog'liq (SQLite'da TRUNCATE yo'q — WHERE'siz DELETE ishlatiladi);
• DROP — jadvalni tuzilmasi bilan butunlay o'chiradi.

⚠️ Production'da bularni hech qachon ruxsatsiz va zaxirasiz ishlatmang.

</details>

40. Contract testing nima?

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

Consumer (masalan, mobil ilova) va provider (API) o'rtasidagi kelishuv — so'rov va javob formati — avtomatik tekshiriladi. Consumer-driven contract testing'da (masalan, Pact) consumer kutgan format provider'ning CI'sida tekshiriladi. E2E'dan tez va integratsiya buzilishini erta ushlaydi. OpenAPI sxemasiga qarshi validatsiya — yengilroq variant.

</details>

9.4. Avtomatlashtirish, Playwright va CI (41–52)

41. Nimani avtomatlashtirish kerak, nimani yo'q?

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

Ha: barqaror va tez-tez takrorlanadigan regression, smoke, data-driven testlar, API, kritik foydalanuvchi yo'llari. Yo'q (yoki keyinroq): tez o'zgaruvchan UI, bir martalik tekshiruvlar, exploratory, UX/vizual "his", kam ishlatiladigan murakkab qismlar. Mezon — ROI va risk. Batafsil: QA 16.

</details>

42. Test piramidasi nima?

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

Pastda ko'p, tez va arzon unit testlar; o'rtada integratsiya/API testlar; tepada oz sonli E2E UI testlar. Sabab: pastki qatlam testlari tez, barqaror va muammoni aniq ko'rsatadi; E2E testlar sekin va mo'rt. Teskari shakl — "muzqaymoq" anti-pattern (ko'p qo'lda va UI testlar).

</details>

43. Flaky test nima, sabablari va qanday tuzatasiz?

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

Kod o'zgarmasa ham ba'zan o'tib, ba'zan yiqiladigan test. Sabablar: qattiq kutishlar (sleep), testlar orasida umumiy holat yoki ma'lumot, test tartibiga bog'liqlik, tashqi servislar, animatsiyalar, parallel ishga tushirishda ma'lumot to'qnashuvi, muhit beqarorligi. Tuzatish: web-first assertion'lar va auto-wait, har test o'z ma'lumotini yaratadi, izolyatsiya, tashqi servislarni mock qilish, trace tahlili, karantin siyosati. Batafsil: QA 21.

</details>

44. Playwright'ning Selenium'dan asosiy farqlari qanday?

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

Playwright: auto-waiting va web-first assertion'lar, bitta API bilan Chromium/Firefox/WebKit, browser context'lar orqali tez izolyatsiya, o'rnatilgan test runner (parallel, retries, reporter'lar), trace viewer, codegen, network mocking va API testing. Selenium: W3C WebDriver standarti, juda ko'p dasturlash tili, katta ekotizim va Grid; kutishlarni ko'proq o'zingiz boshqarasiz. Tanlov kontekstga bog'liq: jamoa tili, mavjud infratuzilma, brauzer talablari.

</details>

**45. Auto-waiting nima va nega waitForTimeout yomon?**

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

Playwright action'dan oldin elementning tayyorligini (ko'rinadi, barqaror, yoqilgan, boshqa element to'smagan) avtomatik kutadi; expect(locator) assertion'lari shart bajarilguncha qayta urinadi. waitForTimeout(3000) — qattiq kutish: sekin muhitda yetmaydi (flaky), tez muhitda vaqtni behuda sarflaydi.

Nozik joy: allTextContents() kabi "bir martalik" metodlar kutmaydi — ulardan oldin auto-waiting assertion yoki locator.waitFor() ishlating. Bu xatoni QA 29'dagi topshiriqda real ko'ramiz.

</details>

46. Locator strategiyangiz qanday?

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

Foydalanuvchiga ko'rinadigan atributlar ustun: getByRole (nomi bilan), getByLabel, getByPlaceholder, getByText. Barqaror test atributlari: getByTestId (data-testid yoki loyihada sozlangan atribut — saucedemo'da data-test). CSS — ehtiyotkorlik bilan; XPath — oxirgi chora. Dinamik class nomlari va DOM tuzilmasiga bog'lanmaslik. Batafsil: QA 18.

</details>

47. Page Object Model nima va nega kerak?

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

Har sahifa yoki komponent uchun class: locator'lar va harakatlar (login(), addToCart()) bir joyda. Testlar biznes tilida o'qiladi, UI o'zgarsa faqat bitta joy tuzatiladi. Assertion'larni odatda testning o'zida qoldirish tavsiya etiladi. Batafsil: QA 19.

</details>

48. Playwright'da fixture nima?

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

Test uchun muhit yoki obyekt tayyorlab beradigan mexanizm. Built-in fixture'lar: page, context, browser, request. test.extend bilan o'zingiznikini qo'shasiz (masalan, loginPage yoki autentifikatsiyalangan API client): setup va teardown bir joyda, faqat kerak bo'lganda va har test uchun izolyatsiya bilan.

</details>

**49. storageState nima uchun ishlatiladi?**

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

Login holatini (cookie'lar, localStorage) faylga saqlab, keyingi testlarda qayta ishlatish uchun — har testda UI orqali login qilmaslik. Odatda alohida setup project'da bir marta login qilinadi, boshqa project'lar dependencies va use.storageState orqali shu holatdan foydalanadi. Saucedemo'da login holati session-username cookie'sida saqlanadi; QA 19'da u playwright/.auth/standard_user.json fayliga yoziladi (bu papka .gitignoreda bo'lishi kerak).

</details>

50. Testlarni parallel ishlatishda nimalarga e'tibor berasiz?

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

Izolyatsiya: har test o'z ma'lumotini yaratadi, umumiy akkaunt holatini o'zgartirmaydi, boshqa testlar tartibiga bog'liq emas. Unikal ma'lumotlar (timestamp, faker). Worker soni va muhit resurslari. serial rejim — faqat haqiqiy zarurat bo'lganda.

</details>

51. CI'da testlar qanday tashkil qilinadi?

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

PR'da tez smoke (--grep @smoke); merge'dan keyin yoki har kecha to'liq regression (cron); relizdan oldin to'liq to'plam + non-functional. Katta to'plam sharding (--shard=1/4) bilan bir nechta mashinada; natijalar birlashtiriladi; HTML report va trace'lar artifact sifatida saqlanadi. Required status check'lar — quality gate. Batafsil: QA 21.

</details>

52. API va UI testlarni qanday birlashtirasiz?

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

API orqali holat tayyorlash (foydalanuvchi, buyurtma) → UI'da faqat tekshirilayotgan qismni bajarish → API orqali tozalash. UI test tezlashadi va barqarorlashadi. Teskari yo'nalish ham foydali: UI'dagi natijani API yoki DB bilan solishtirish. Batafsil: QA 20.

</details>

9.5. Mobil va Proxyman (53–58)

53. Mobil testlashning web'dan asosiy farqlari?

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

Qurilma va OS fragmentatsiyasi; ekran o'lchamlari; interruption'lar (qo'ng'iroq, push); ruxsatlar (permissions); tarmoq o'zgarishi va offline; ilova hayot sikli (fon, OS tomonidan yopilishi, holatni tiklash); batareya va xotira; o'rnatish va yangilash; do'kon qoidalari; gesture'lar; Dynamic Type; real qurilma sensorlari. Batafsil: QA 14.

</details>

54. Interruption testlari nima?

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

Ilova ishlayotganda tashqi hodisalar: kiruvchi qo'ng'iroq, SMS, push, budilnik, quvvat kamligi, ekran qulflanishi, boshqa ilovaga o'tish, Wi-Fi ↔ mobil internet almashuvi. Kutilgan natija: crash yo'q, holat va kiritilgan ma'lumot saqlanadi, to'lov yoki buyurtma ikki marta yuborilmaydi.

</details>

55. Simulator/emulator va real qurilma farqi?

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

Simulator/emulator — tez, arzon, avtomatlashtirish va ko'p OS versiyasini tekshirish uchun qulay. Real qurilma — haqiqiy performance, batareya, kamera, sensorlar, tarmoq sharoiti va ishlab chiqaruvchi (OEM) o'zgarishlari. Strategiya: ikkalasi ham; relizdan oldin eng ommabop real qurilmalarda smoke.

</details>

56. Deep link'ni qanday testlaysiz?

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

Ilova o'rnatilgan va o'rnatilmagan, ochiq, yopiq va fonda bo'lgan holatlarda; login talab qiladigan ekranga (avval login, keyin aynan kerakli ekran); noto'g'ri yoki eskirgan parametrlar bilan; universal/app link va custom scheme. Ishga tushirish: iOS simulyatorda xcrun simctl openurl booted "<url>", Android'da adb shell am start -a android.intent.action.VIEW -d "<url>".

</details>

57. Proxyman (yoki Charles) nima uchun kerak, SSL proxying qanday ishlaydi?

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

Ilova va server orasidagi HTTP(S) trafikni ko'rish va boshqarish uchun — mobil ilovada DevTools yo'q. SSL proxying: qurilmaga proxy'ning root CA sertifikati o'rnatiladi va ishonchli deb belgilanadi; proxy har bir domen uchun o'z sertifikatini yaratib, trafikni ochib ko'rsatadi (MITM). Faqat o'z test qurilmalaringizda; certificate pinning bunga (to'g'ri ravishda) to'sqinlik qiladi. Batafsil: QA 15.

</details>

58. Proxyman'da Map Local va Breakpoint farqi?

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

Map Local — server javobini siz tayyorlagan lokal fayl bilan almashtiradi: bo'sh savatcha, 99 ta mahsulot yoki 500 xato kabi chegaraviy UI holatlarini backend'siz ko'rish. Breakpoint — so'rov yoki javobni to'xtatib, qo'lda tahrirlab, keyin davom ettirish: masalan, so'rovdagi narx yoki userIdni o'zgartirib, server validatsiyasi va avtorizatsiyasini tekshirish.

</details>

9.6. Xulq-atvor savollari — STAR (59–66)

STAR: Situation (vaziyat) → Task (vazifa) → Action (nima qildingiz) → Result (natija, iloji bo'lsa raqam bilan). Batafsil: Behavioral intervyu.

59. Eng qiziq topgan bug'ingiz haqida aytib bering.

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

Namuna (capstone tajribasidan): "S: Toolshop'ning bug'li versiyasini testlayotgandim. T: Katalog funksiyalarini tekshirish. A: 'Price (High - Low)' saralashini tanlaganimda narxlar o'sish tartibida chiqdi; option qiymatlarini DevTools'da ko'rib, label va qiymat almashib qolganini aniqladim; boshqa saralash variantlarini ham tekshirib, aniq qadamlar va skrinshot bilan report yozdim. R: Bug birinchi urinishda qayta hosil qilindi, saralash uchun avtomatik test qo'shdim." Haqiqiy tajribangizdan gapiring — o'ylab topilgan voqea tez ochiladi.

</details>

60. Dasturchi bug'ingizni "bu bug emas" deb rad etdi. Nima qilasiz?

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

Shaxsiy qabul qilmayman. Avval talab yoki dizaynni qayta tekshiraman — balki men xato tushungandirman. Agar talab men aytgandek bo'lsa, dasturchiga aniq qadamlar, dalillar (video, log) bilan ko'rsataman va birga qayta hosil qilamiz. Kelisha olmasak — qarorni PO'ga olib chiqaman: bu "kim haq" emas, "mahsulot qanday bo'lishi kerak" masalasi. Qaror ticket'da qayd qilinadi.

</details>

61. Muddat yaqin, hammasini testlashga vaqt yo'q. Nima qilasiz?

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

Risk asosida ustuvorlik beraman: avval pul, ma'lumot va asosiy oqimlar (login, checkout), keyin o'zgargan qismlar va ularga yaqin joylar. Testlanmay qoladigan qismlarni PO va jamoaga ochiq aytaman, qolgan riskni yozib qo'yaman. Mumkin bo'lsa — avtomatik regressiyani kuchaytiraman yoki dasturchilar bilan juftlikda testlayman. Batafsil: QA 27.

</details>

62. Production'ga bug o'tib ketdi. Nima qildingiz?

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

Ayb qidirish emas, harakat: muammoni tezda qayta hosil qilish va ta'sirini baholashga yordam berish, hotfix'ni tekshirish. Keyin post-mortem: nega testda topilmadi (qamrov, ma'lumot, muhit farqi?). Natija — regression to'plamiga yangi test va jarayonga aniq o'zgarish (masalan, checklist'ga yangi punkt).

</details>

63. Talablar noaniq bo'lgan holatni qanday hal qilgansiz?

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