# 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](#karyera-xaritasi) 2. [Har bir daraja nimani kutadi](#darajalar) 3. [16 haftalik o'quv rejasi](#oquv-rejasi) 4. [Portfolio: tajribasiz tajribani ko'rsatish](#portfolio) 5. [QA uchun CV](#cv) 6. [Ish qidirish: O'zbekiston va remote](#ish-qidirish) 7. [ISTQB va boshqa sertifikatlar](#istqb) 8. [Intervyu jarayoni qanday o'tadi](#intervyu-jarayoni) 9. [66 ta intervyu savoli va javoblar](#savollar) 10. [Amaliy topshiriq (take-home) qanday bajariladi](#take-home) 11. [Yangi ishdagi birinchi 90 kun](#90-kun) 12. [Hamjamiyatlar va doimiy o'sish](#osish) 13. [Amaliy mashqlar](#mashqlar) 14. [O'zingizni tekshiring](#checklist) 15. [Xulosa](#xulosa) 16. [Manbalar](#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](/lessons/images/qa/qa_28_career_ladder.svg) Senior darajasidan keyin yo'l tarmoqlanadi: | Yo'l | Asosiy ish | Kim uchun mos | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | | **QA Lead / QA Manager** | Jamoa, jarayon, reliz qarorlari, hiring ([QA 27](/ios-lessons/qa-strategy-metrics)) | Odamlar bilan ishlashni yoqtiradiganlar | | **SDET / Test Architect** | Test infratuzilmasi, framework'lar, CI, test strategiyasining texnik qismi | Kod yozishni yoqtiradiganlar | | **Quality Coach** | Butun jamoaning testlash madaniyatini oshirish, o'qitish | Ustozlikni yoqtiradiganlar | | **Mutaxassis** (performance, security, a11y) | Tor sohada chuqur ekspertiza ([QA 23](/ios-lessons/qa-performance-k6), [QA 24](/ios-lessons/qa-security), [QA 25](/ios-lessons/qa-a11y-l10n-visual)) | Bitta sohaga "sho'ng'ishni" yoqtiradiganlar | **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](/ios-lessons/devops-cicd)); - **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. | Daraja | Taxminiy tajriba | Mustaqillik | Asosiy ko'nikmalar | Natijasi (output) | | -------------------- | ------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | **Intern / Trainee** | 0 | Doimiy yo'l-yo'riq bilan | Terminlar, test case va bug report yozish | Belgilangan test case'larni bajaradi | | **Junior QA** | ~0–2 yil | Aniq vazifani mustaqil, murakkabida yordam bilan | Test dizayn texnikalari, Jira, DevTools, API asoslari, SQL asoslari | Feature'ni checklist/test case bilan testlaydi, sifatli bug report | | **Middle QA / AQA** | ~2–4 yil | Feature yoki modulni to'liq o'zi | API testlash, avtomatlashtirish (Playwright), CI, mobil, Proxyman | Feature uchun test strategiyasi, avtomatlashtirilgan regression | | **Senior QA / SDET** | ~4+ yil | Mahsulot yoki bir nechta jamoa darajasida | Framework arxitekturasi, risk-based strategiya, performance/security asoslari, mentorlik | Test infratuzilmasi, standartlar, jamoaning o'sishi | | **Lead / Manager** | Kompaniyaga bog'liq | Jarayon va odamlar uchun javobgar | Strategiya, metrikalar, reliz qarorlari, hiring, kommunikatsiya | Sifat jarayoni, jamoa, rahbariyat bilan aloqa | ### Manual QA, AQA va SDET farqi | Rol | Asosiy fokus | Kod yozish | | ----------------------- | --------------------------------------------------------------------------------- | -------------------------- | | **Manual QA** | Test dizayn, exploratory, talablar, bug'lar | Kam yoki umuman yo'q | | **AQA** (Automation QA) | Mavjud test case'larni avtomatlashtirish, framework'ni qo'llab-quvvatlash | O'rtacha–ko'p | | **SDET** | Test infratuzilmasi, framework dizayni, testability, ba'zan prod kodiga ham hissa | Ko'p, dasturchi darajasida | > **🎯 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. | Hafta | Darslar | Haftaning natijasi | | ----- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | | 1–2 | [QA 1](/ios-lessons/qa-intro-career)–[QA 4](/ios-lessons/qa-levels-types) | Terminlar lug'ati; SDLC/STLC sxemasi; ISTQB syllabus'ni o'qishni boshlash | | 3–4 | [QA 5](/ios-lessons/qa-test-design-1)–[QA 8](/ios-lessons/qa-bug-reports) | Toolshop uchun 30 ta test case va 5 ta bug report | | 5–6 | [QA 9](/ios-lessons/qa-web-http-devtools)–[QA 11](/ios-lessons/qa-api-advanced) | Restful-booker uchun Postman/Bruno kolleksiyasi (chaining + testlar) | | 7 | [QA 12](/ios-lessons/qa-sql), [QA 13](/ios-lessons/qa-terminal-git-logs) | 15 ta SQL so'rov; git bilan ishlash, log tahlili | | 8 | [QA 14](/ios-lessons/qa-mobile-testing), [QA 15](/ios-lessons/qa-proxyman) | Mobil checklist; Proxyman bilan 3 ta stsenariy (Map Local, Breakpoint, Network Conditions) | | 9–10 | [QA 16](/ios-lessons/qa-automation-intro)–[QA 18](/ios-lessons/qa-playwright-basics) | TypeScript asoslari; saucedemo uchun birinchi Playwright testlar | | 11–12 | [QA 19](/ios-lessons/qa-playwright-advanced)–[QA 21](/ios-lessons/qa-ci-cd) | POM + fixtures + API testlar + GitHub Actions | | 13 | [QA 22](/ios-lessons/qa-mobile-automation), [QA 23](/ios-lessons/qa-performance-k6) | Maestro flow; k6 skript (thresholds bilan) | | 14 | [QA 24](/ios-lessons/qa-security)–[QA 26](/ios-lessons/qa-ai-testing) | Security checklist; axe a11y testi; AI bilan test g'oyalari (tekshirilgan) | | 15 | [QA 27](/ios-lessons/qa-strategy-metrics), QA 28 | Test strategiya + risk matritsa; CV va LinkedIn tayyor | | 16 | [QA 29](/ios-lessons/qa-capstone-challenges) | Capstone yakunlandi; arizalar yuborila boshlandi | > **💡 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 | Element | Qayerda | Nima ko'rsatadi | | ------------------------------- | ---------------------------------- | ----------------------------------------------------- | | Capstone avtomatlashtirish repo | GitHub | Playwright, TypeScript, POM, API testlar, CI | | Test hujjatlari | Repo'dagi `docs/` yoki Notion | Strategiya, risk matritsa, checklist, test case'lar | | Bug report'lar | Repo'dagi `docs/bugs/` | Aniq, takrorlanadigan, yaxshi formatlangan report'lar | | API kolleksiya | Repo'dagi `postman/` yoki `bruno/` | API testlash, chaining, assertion'lar | | 2–3 daqiqalik demo video | README'da havola | Muloqot qobiliyati, natijani taqdim etish | | Maqola yoki post | LinkedIn, blog | Fikrlash va yozish madaniyati | ### Qayerda "haqiqiy" mashq qilish mumkin - **Toolshop** (practicesoftwaretesting.com) va uning ataylab bug'li versiyasi — bug hunting uchun ideal ([QA 29](/ios-lessons/qa-capstone-challenges)); - **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 ```text 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 ```text # Toolshop QA Portfolio ![Playwright tests](https://github.com//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 | ❌ Yomon | ✅ Yaxshi | | ----------------------- | ----------------------------------------------------------------------------------------------------- | | Responsible for testing | Designed 30 test cases for an e-commerce checkout using EP, BVA and decision tables | | Used Postman | Built a Postman collection with 12 chained API tests for Restful-Booker (auth, CRUD, negative cases) | | Found bugs | Found and documented 10 reproducible bugs in Toolshop "with-bugs" build, incl. a broken price sort | | Know automation | Automated 14 UI and 8 API scenarios with Playwright + TypeScript; runs on every PR via GitHub Actions | ### Ingliz tilidagi namuna (xayoliy nomzod) ```text AZIZ KARIMOV — Junior QA Engineer Tashkent, Uzbekistan · · github.com/ · linkedin.com/in/ 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//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 | Kanal | Izoh | | --------------------------------------- | --------------------------------------------------------------------------------------------- | | **hh.uz** | O'zbekistondagi asosiy ish qidirish saytlaridan biri; filtrlar: "QA", "тестировщик", "tester" | | **LinkedIn Jobs** | Xalqaro va remote vakansiyalar; profil inglizcha bo'lsin | | **Kompaniyalarning karyera sahifalari** | Mahsulot kompaniyalari va outsourcing kompaniyalari | | **IT Park ekotizimi** | IT Park rezidenti bo'lgan kompaniyalar — potentsial ish beruvchilar ro'yxati | | **Telegram vakansiya kanallari** | Ko'p vakansiyalar shu yerda; kanal ishonchliligini tekshiring | | **Tanishlar va hamjamiyat** | Meetup'lar, onlayn guruhlar — tavsiya (referral) eng kuchli kanal | > **🇺🇿 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 | Parametr | Qiymat | | ---------------------- | ----------------------------------------------------------------- | | Joriy syllabus | CTFL v4.0 (yuklab olinadigan fayl: v4.0.1, 2024-09-15) | | Savollar soni | 40 | | Vaqt | 60 daqiqa (ona tili bo'lmagan tilda topshirilsa +25% → 75 daqiqa) | | O'tish bali | 26 / 40 (65%) | | K-darajalar taqsimoti | 8 ta K1 (eslash), 24 ta K2 (tushunish), 8 ta K3 (qo'llash) | | Oldingi shart | Yo'q; CTFL boshqa ko'p ISTQB sertifikatlari uchun shart | | Tayyorgarlik materiali | Syllabus, glossary va A–D namunaviy imtihonlari istqb.org'da | 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) | Daraja | Sertifikat | Kim uchun | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Advanced | **CTAL-TA** v4.0 — Test Analyst | Test dizayn va tahlilda chuqurlashish | | Advanced | **CTAL-TAE** v2.0 — Test Automation Engineering | AQA / SDET | | Advanced | **CTAL-TM** v3.0 — Test Management | QA Lead / Manager | | Advanced | **CTAL-TTA** — Technical Test Analyst | Texnik testlash (white-box, non-functional) | | Advanced | **CTAL-AT** v2.0 — Agile Tester | Agile jamoalarda ishlovchilar | | Specialist | **CT-AI** v2.0 — AI Testing | AI tizimlarini testlash | | Specialist | **CT-GenAI** — Testing with Generative AI | GenAI'ni testlashda ishlatish ([QA 26](/ios-lessons/qa-ai-testing)) | | Specialist | **CT-MAT** (mobil), **CT-PT** (performance), **CT-SEC** (security), **CT-UT** (usability), **CT-TAS** (automation strategy), **CT-AcT** (acceptance) | Tor mutaxassislik | 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? | ✅ Foydasi | ⚠️ Cheklovi | | ------------------------------------------------------------------ | ---------------------------------------------------- | | Umumiy professional lug'at — intervyuda terminlar aniq | Amaliy ko'nikmani isbotlamaydi | | Ba'zi ish beruvchilar (outsourcing, xalqaro, korporativ) qadrlaydi | Pullik; narx provayderga bog'liq | | HR saralashida qo'shimcha signal | Juniorlar uchun portfolio odatda kuchliroq dalil | | Tizimli o'qish uchun yaxshi reja | Faqat "test topshirish uchun" yodlash foyda bermaydi | **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} | Bosqich | Nima tekshiriladi | Qanday tayyorlanish | | ---------------------- | -------------------------------------------------------------------------- | --------------------------------------------------- | | HR skrining | Motivatsiya, til, kutilmalar, mos kelish | 2 daqiqalik "o'zim haqimda", kompaniya haqida bilim | | Texnik intervyu | Nazariya, test dizayn, web/API/SQL, avtomatlashtirish | 9-bo'limdagi savollar | | Jonli amaliy topshiriq | "Buni testlang", test case yozish, sahifadagi bug'larni topish, SQL so'rov | Ovoz chiqarib fikrlash, savol berish | | Take-home | Test case'lar, bug report'lar, avtomatlashtirish | 10-bo'lim | | Jamoa/menejer suhbati | Muloqot, jamoaga mos kelish, xulq-atvor | STAR javoblar | | Taklif (offer) | Shartlar | Savollaringiz ro'yxati | ### 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?**
💡 Javobni ko'rish 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](/ios-lessons/qa-intro-career).
**2. Error, defect va failure farqi?**
💡 Javobni ko'rish **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.
**3. Verification va validation farqi?**
💡 Javobni ko'rish Verification — "mahsulotni **to'g'ri** qurayapmizmi?" (spetsifikatsiyaga moslik: review, testlar). Validation — "**to'g'ri mahsulotni** qurayapmizmi?" (foydalanuvchi ehtiyojiga moslik: UAT, beta testlash).
**4. Testlashning 7 printsipini sanang.**
💡 Javobni ko'rish 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](/ios-lessons/qa-principles-istqb).
**5. SDLC va STLC farqi?**
💡 Javobni ko'rish 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](/ios-lessons/qa-sdlc-stlc-agile).
**6. Test darajalarini sanang.**
💡 Javobni ko'rish 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.
**7. Smoke, sanity va regression farqi?**
💡 Javobni ko'rish | Tur | Maqsad | Kenglik / chuqurlik | | ---------- | ------------------------------------------------------------------ | ----------------------------------- | | Smoke | Build asosiy funksiyalar bo'yicha testlashga yaroqlimi | Keng, sayoz, tez | | Sanity | Kichik o'zgarish/fix'dan keyin aynan shu joy mantiqan ishlayaptimi | Tor, chuqurroq | | Regression | O'zgarish mavjud funksiyalarni buzmadimi | Keng, ko'pincha avtomatlashtirilgan |
**8. Retesting va regression testing farqi?**
💡 Javobni ko'rish 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.
**9. Severity va priority farqi? Misol keltiring.**
💡 Javobni ko'rish 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](/ios-lessons/qa-bug-reports).
**10. Bug life cycle'ni tushuntiring.**
💡 Javobni ko'rish 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.
**11. Test plan nimalardan iborat?**
💡 Javobni ko'rish 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](/ios-lessons/qa-test-documentation).
**12. Test case, test scenario va checklist farqi?**
💡 Javobni ko'rish **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.
**13. Black-box, white-box va grey-box testing?**
💡 Javobni ko'rish 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.
**14. Entry va exit criteria nima?**
💡 Javobni ko'rish 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](/ios-lessons/qa-strategy-metrics).
**15. Exploratory testing nima va qachon kerak?**
💡 Javobni ko'rish 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.
**16. Shift-left va shift-right nima?**
💡 Javobni ko'rish **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.
### 9.2. Test dizayn va "buni testlang" (17–26) **17. EP va BVA'ni misol bilan tushuntiring: yosh 18–65.**
💡 Javobni ko'rish **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](/ios-lessons/qa-test-design-1)). Qo'shimcha nozik joy: yosh tug'ilgan sanadan hisoblansa — "bugun 18 yoshga to'lgan" holati va vaqt zonasi (Asia/Tashkent). Batafsil: [QA 5](/ios-lessons/qa-test-design-1).
**18. Decision table qachon ishlatiladi?**
💡 Javobni ko'rish 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.
**19. State transition testing qachon kerak?**
💡 Javobni ko'rish 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](/ios-lessons/qa-test-design-2).
**20. Pairwise testing nima uchun kerak?**
💡 Javobni ko'rish 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](/ios-lessons/qa-test-design-2)). 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.
**21. "Qalamni testlang."**
💡 Javobni ko'rish 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.
**22. "Liftni testlang."**
💡 Javobni ko'rish 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.
**23. "Login formasini testlang."**
💡 Javobni ko'rish - **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](/ios-lessons/qa-security)); - **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.
**24. "Karta bilan to'lov formasini testlang."**
💡 Javobni ko'rish - 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.
**25. Talablar yo'q bo'lsa nima qilasiz?**
💡 Javobni ko'rish 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.
**26. Testlashni qachon to'xtatasiz?**
💡 Javobni ko'rish 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.
### 9.3. Web, API va SQL (27–40) **27. Brauzerga URL yozilganda nima sodir bo'ladi (qisqacha)?**
💡 Javobni ko'rish 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](/ios-lessons/qa-web-http-devtools).
**28. Cookie, localStorage va sessionStorage farqi?**
💡 Javobni ko'rish | Xususiyat | Cookie | localStorage | sessionStorage | | -------------------- | -------------------------------- | -------------- | --------------- | | Serverga yuboriladi | Ha, har so'rov bilan | Yo'q | Yo'q | | Muddati | `Expires`/`Max-Age` yoki sessiya | O'chirilguncha | Tab yopilguncha | | JS o'qiy oladimi | `HttpOnly` bo'lmasa | Ha | Ha | | Xavfsizlik flag'lari | `HttpOnly`, `Secure`, `SameSite` | Yo'q | Yo'q | QA nuqtai nazari: token'ni localStorage'da saqlash XSS hujumida o'g'irlanish xavfini oshiradi.
**29. GET va POST farqi? PUT va PATCH farqi?**
💡 Javobni ko'rish 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](/ios-lessons/qa-api-postman).
**30. Idempotentlik nima va QA uchun nega muhim?**
💡 Javobni ko'rish 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).
**31. 401 va 403; 400 va 422; 500 va 503 farqi?**
💡 Javobni ko'rish - **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).
**32. REST API'da nimalarni tekshirasiz?**
💡 Javobni ko'rish 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](/ios-lessons/qa-sql)); xato formati izchilligi; autentifikatsiya va avtorizatsiya; negative holatlar (yo'q maydon, noto'g'ri tip, chegaralar); idempotentlik; pagination va filtrlar. Batafsil: [QA 11](/ios-lessons/qa-api-advanced).
**33. Bug front-end'dami yoki back-end'mi — qanday aniqlaysiz?**
💡 Javobni ko'rish 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.
**34. CORS xatosi nima?**
💡 Javobni ko'rish 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.
**35. JWT nima va QA unda nimani tekshiradi?**
💡 Javobni ko'rish 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.
**36. INNER JOIN va LEFT JOIN farqi?**
💡 Javobni ko'rish 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`).
**37. WHERE va HAVING farqi?**
💡 Javobni ko'rish 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.
**38. Dublikat yozuvlarni SQL bilan qanday topasiz?**
💡 Javobni ko'rish 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): ```sql 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.
**39. DELETE, TRUNCATE va DROP farqi?**
💡 Javobni ko'rish - `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.
**40. Contract testing nima?**
💡 Javobni ko'rish 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.
### 9.4. Avtomatlashtirish, Playwright va CI (41–52) **41. Nimani avtomatlashtirish kerak, nimani yo'q?**
💡 Javobni ko'rish **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](/ios-lessons/qa-automation-intro).
**42. Test piramidasi nima?**
💡 Javobni ko'rish 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).
**43. Flaky test nima, sabablari va qanday tuzatasiz?**
💡 Javobni ko'rish 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](/ios-lessons/qa-ci-cd).
**44. Playwright'ning Selenium'dan asosiy farqlari qanday?**
💡 Javobni ko'rish 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.
**45. Auto-waiting nima va nega `waitForTimeout` yomon?**
💡 Javobni ko'rish 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](/ios-lessons/qa-capstone-challenges)'dagi topshiriqda real ko'ramiz.
**46. Locator strategiyangiz qanday?**
💡 Javobni ko'rish 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](/ios-lessons/qa-playwright-basics).
**47. Page Object Model nima va nega kerak?**
💡 Javobni ko'rish 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](/ios-lessons/qa-playwright-advanced).
**48. Playwright'da fixture nima?**
💡 Javobni ko'rish 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.
**49. `storageState` nima uchun ishlatiladi?**
💡 Javobni ko'rish 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 `.gitignore`da bo'lishi kerak).
**50. Testlarni parallel ishlatishda nimalarga e'tibor berasiz?**
💡 Javobni ko'rish 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.
**51. CI'da testlar qanday tashkil qilinadi?**
💡 Javobni ko'rish 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](/ios-lessons/qa-ci-cd).
**52. API va UI testlarni qanday birlashtirasiz?**
💡 Javobni ko'rish 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](/ios-lessons/qa-api-automation).
### 9.5. Mobil va Proxyman (53–58) **53. Mobil testlashning web'dan asosiy farqlari?**
💡 Javobni ko'rish 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](/ios-lessons/qa-mobile-testing).
**54. Interruption testlari nima?**
💡 Javobni ko'rish 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.
**55. Simulator/emulator va real qurilma farqi?**
💡 Javobni ko'rish 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.
**56. Deep link'ni qanday testlaysiz?**
💡 Javobni ko'rish 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 ""`, Android'da `adb shell am start -a android.intent.action.VIEW -d ""`.
**57. Proxyman (yoki Charles) nima uchun kerak, SSL proxying qanday ishlaydi?**
💡 Javobni ko'rish 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](/ios-lessons/qa-proxyman).
**58. Proxyman'da Map Local va Breakpoint farqi?**
💡 Javobni ko'rish **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 `userId`ni o'zgartirib, server validatsiyasi va avtorizatsiyasini tekshirish.
### 9.6. Xulq-atvor savollari — STAR (59–66) STAR: **S**ituation (vaziyat) → **T**ask (vazifa) → **A**ction (nima qildingiz) → **R**esult (natija, iloji bo'lsa raqam bilan). Batafsil: [Behavioral intervyu](/ios-lessons/behavioral-interview). **59. Eng qiziq topgan bug'ingiz haqida aytib bering.**
💡 Javobni ko'rish 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.
**60. Dasturchi bug'ingizni "bu bug emas" deb rad etdi. Nima qilasiz?**
💡 Javobni ko'rish 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.
**61. Muddat yaqin, hammasini testlashga vaqt yo'q. Nima qilasiz?**
💡 Javobni ko'rish 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](/ios-lessons/qa-strategy-metrics).
**62. Production'ga bug o'tib ketdi. Nima qildingiz?**
💡 Javobni ko'rish 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).
**63. Talablar noaniq bo'lgan holatni qanday hal qilgansiz?**
💡 Javobni ko'rish Savollar ro'yxatini tuzib, Three Amigos uchrashuvini taklif qilganman; noaniq joylarni Given/When/Then misollari bilan yozib, PO'ga tasdiqlatganman. Natija — dasturchilar va QA bir xil tushunchada ishladi, keyinroq "bug yoki feature" bahslari kamaydi.
**64. Jamoadosh bilan kelishmovchilik bo'lganda nima qilasiz?**
💡 Javobni ko'rish Avval tinglayman va uning nuqtai nazarini tushunishga harakat qilaman; muhokamani faktlar va umumiy maqsad (foydalanuvchi, sifat, muddat) atrofida olib boraman. Kelisha olmasak — hurmat bilan qarorni tegishli odamga (Tech Lead, PO) olib chiqaman. Muhimi — kelishmovchilik ish munosabatini buzmasligi.
**65. Yangi vositani qanchalik tez o'rgana olasiz? Misol keltiring.**
💡 Javobni ko'rish Namuna: "Playwright'ni 2 haftada o'rgandim: rasmiy hujjatdagi 'Getting started' bo'limi, keyin saucedemo uchun kichik loyiha, keyin POM va CI. Natijada 20 dan ortiq test GitHub Actions'da ishlayapti." Konkret natija va o'rganish usulini ayting.
**66. Nega QA? Nega aynan bizning kompaniya?**
💡 Javobni ko'rish Samimiy motivatsiya: "mahsulotni foydalanuvchi ko'zi bilan ko'rish va muammoni u sezmasidan oldin topish menga yoqadi". Kompaniya haqida: ularning mahsulotini oldindan ishlatib ko'ring va unda nimani qiziq topganingizni yoki qanday yaxshilash mumkinligini ayting — bu sizni boshqa nomzodlardan darhol ajratadi.
--- ## 10. Amaliy topshiriq (take-home) qanday bajariladi {#take-home} Odatiy take-home topshiriqlar: - Berilgan funksiya (masalan, ro'yxatdan o'tish) uchun checklist va test case'lar; - Demo ilovada topilgan bug'lar uchun report'lar; - 3–5 ta stsenariyni avtomatlashtirish (UI yoki API); - API uchun testlar va qisqa hisobot. ### Qanday topshirish kerak | Qiling | Qilmang | | ------------------------------------------------------------------- | ------------------------------------------------------- | | README: qanday ishga tushiriladi, taxminlar, nima qilinmadi va nega | Hech qanday izohsiz zip fayl | | Avval kritik yo'llar, keyin qolganlari | 100 ta sayoz test case | | Toza tuzilma (POM, nomlash), bir xil uslub | Talab qilinmagan murakkab framework | | Topilgan bug'larni alohida ro'yxat qilish | Bug'larni test natijalari orasida yashirish | | Ajratilgan vaqtni halol ko'rsatish | Boshqa birovning kodini o'zingizniki deb topshirish | | CI (bonus) — agar vaqt bo'lsa | Yiqilayotgan testlarni o'chirib "hammasi yashil" qilish | > **💡 Maslahat:** Topshiriqni tekshiruvchi odatda 15–20 daqiqa vaqt ajratadi. README'ning birinchi 10 qatorida eng muhim natijalarni ko'rsating: nechta test, nima qamraldi, qanday bug'lar topildi. --- ## 11. Yangi ishdagi birinchi 90 kun {#90-kun} | Davr | Maqsad | Nima qilasiz | | --------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | | 1–30 kun | O'rganish | Mahsulot va domen, muhitlar, hujjatlar (strategiya, risk register), jamoa a'zolari; birinchi kichik ticket'lar va bug report'lar | | 31–60 kun | Hissa qo'shish | Bitta funksional sohaga "egalik"; checklist'ni yaxshilash; avtomatlashtirishga birinchi PR'lar | | 61–90 kun | Mustaqillik va tashabbus | Sohani mustaqil boshqarish; bitta jarayon yaxshilanishini taklif qilish va amalga oshirish | Foydali odatlar: - **Savol bering**, lekin avval 15 daqiqa o'zingiz izlang va nimani sinaganingizni ayting; - **"Yutuqlar daftari"** yuriting: topgan muhim bug'laringiz, yozgan testlaringiz, yaxshilagan jarayonlaringiz — performance review'da juda asqotadi; - Har oy rahbaringizdan **feedback** so'rang; - Birinchi kunlardan "hamma narsani o'zgartirish" taklifi bilan chiqmang — avval nima uchun shunday qilinganini tushuning. --- ## 12. Hamjamiyatlar va doimiy o'sish {#osish} - **Ministry of Testing** — testerlar uchun yirik xalqaro hamjamiyat: maqolalar, kurslar, muhokamalar; - **ISTQB** — syllabus va glossary — professional lug'atingizni boyitadi; - **Playwright community** — rasmiy hamjamiyat sahifasida ko'rsatilgan kanallar (savol-javob, yangiliklar, misollar); - **Test Automation University** — avtomatlashtirish bo'yicha bepul onlayn kurslar; - **Mahalliy hamjamiyatlar** — Telegram guruhlari, meetup'lar, konferensiyalar: tajriba almashish va tavsiya (referral) olishning eng yaxshi yo'li. O'sish uchun oddiy qoida: har chorakda **bitta yangi ko'nikma** (masalan, k6 yoki security testlash) va **bitta ochiq natija** (maqola, ichki taqdimot, open source PR). > **🧠 Esda tuting:** QA — marafon. Barqaror sur'at (kuniga 1–2 soat o'qish va amaliyot) yonib ketishdan (burnout) yaxshiroq natija beradi. --- ## 13. Amaliy mashqlar {#mashqlar} ### Mashq 1: CV bullet'larini qayta yozing (🟢) Quyidagi bullet'larni "Harakat + Nima + Qanday + Natija" formulasi bo'yicha qayta yozing (ingliz tilida): 1. "Tested the website" 2. "Worked with Jira" 3. "Did API testing"
💡 Javobni ko'rish Namuna (raqamlarni o'z haqiqiy natijangizga moslang): 1. "Tested checkout and cart flows of a demo e-commerce site using EP and BVA; executed 45 test cases and reported 9 reproducible bugs." 2. "Logged and tracked 25 bugs in Jira with clear steps, environment details and evidence; 0 rejected as unclear." 3. "Built a Postman collection of 12 chained API tests (auth, CRUD, negative cases) for Restful-Booker and ran it with Newman."
### Mashq 2: 2 daqiqalik "o'zim haqimda" (🟢) "Tell me about yourself" savoliga 2 daqiqalik javob tuzing: hozirgi holat → nimani o'rgandingiz va qildingiz → nega aynan QA va shu kompaniya.
💡 Javobni ko'rish Tuzilma va namuna: 1. **Hozir:** "Men Junior QA'man, so'nggi 4 oy davomida manual va API testlash hamda Playwright avtomatlashtirishni o'rgandim." 2. **Dalil:** "Toolshop uchun to'liq QA loyihasi qildim: strategiya, 30 ta test case, bug'li versiyada 10 ta bug va Playwright testlari GitHub Actions'da ishlaydi." 3. **Motivatsiya:** "Menga muammoni foydalanuvchi sezmasidan oldin topish yoqadi. Sizning mahsulotingizni ishlatib ko'rdim va to'lov oqimingiz qiziq tuyuldi — aynan shunday sohada o'smoqchiman." Uzoq biografiya va ish bilan bog'liq bo'lmagan tafsilotlardan qoching.
### Mashq 3: Vakansiyani tahlil qiling (🟡) Vakansiya talablari: "Manual testing experience; API testing (Postman); SQL basics; understanding of HTTP; Jira; English B1+; nice to have: Playwright/Cypress". Har bir talabni kurs darslari bilan bog'lang va o'zingizdagi bo'shliqlarni aniqlang.
💡 Javobni ko'rish | Talab | Kurs darsi | Qanday dalil ko'rsatasiz | | ------------------------- | ---------- | ----------------------------------------------- | | Manual testing | QA 4–8 | Test case'lar va bug report'lar portfolio'da | | API testing (Postman) | QA 10–11 | Postman kolleksiyasi (newman bilan ishlaydi) | | SQL basics | QA 12 | SQL so'rovlar fayli, capstone'dagi topshiriqlar | | HTTP | QA 9 | Intervyuda status kodlar va DevTools tahlili | | Jira | QA 8 | Bug report namunalari | | English B1+ | — | Ingliz tilidagi README va CV | | Playwright (nice to have) | QA 18–21 | GitHub repo + CI badge | Bo'shliq topilsa — intervyugacha qolgan vaqtga aniq reja yozing (masalan, "SQL: 3 kun, har kuni 10 ta so'rov").
### Mashq 4: "DemoBozor qidiruvini testlang" (🟡) Intervyuda shu topshiriq berildi. 3 daqiqalik javob konturini tuzing.
💡 Javobni ko'rish 1. **Savollar:** qaysi maydonlar bo'yicha qidiradi? Til va yozuv (lotin/kirill)? Natijalar tartibi? Pagination? 2. **Funksional:** aniq nom, qisman so'z, katta-kichik harf, lotin va kirill ("choynak" / "чойнак"), xato yozilgan so'z, natija yo'q holati; 3. **Chegaralar:** so'rov 2–100 belgi → 1, 2, 100, 101 belgi; faqat probellar; 4. **Maxsus belgilar:** apostrof ("ko'ylak", "koʻylak"), emoji, `%`, `_`, SQL/XSS probe'lar (xavfsiz qayta ishlanadi); 5. **Natijalar:** saralash, filtr bilan birga, pagination, mahsulot sonining to'g'riligi (API/DB bilan solishtirish); 6. **Non-functional:** javob vaqti, mobil ko'rinish, a11y (label, klaviatura bilan ishlatish); 7. **Ustuvorlik:** qaysilarini avval testlashimni va nega aytaman (risk).
### Mashq 5: STAR javob (🟡) "Dasturchi siz yozgan bug'ni Cannot Reproduce deb yopdi" vaziyatiga STAR formatida javob yozing.
💡 Javobni ko'rish **S:** Mobil ilovada savatchadagi mahsulot soni ba'zan noto'g'ri ko'rsatilardi; dasturchi "Cannot Reproduce" deb yopdi. **T:** Bug haqiqiy ekanini isbotlash va uni tuzatishga yordam berish. **A:** Qaysi sharoitda chiqishini aniqlash uchun Proxyman bilan trafikni yozdim va muammo faqat sekin tarmoqda, ikki so'rov ketma-ket kelganda chiqishini topdim; Network Conditions bilan qayta hosil qildim, video va so'rovlar tartibini report'ga qo'shib, ticket'ni qayta ochdim va dasturchi bilan birga ko'rib chiqdik. **R:** Race condition topildi va tuzatildi; men shu holat uchun regression testi qo'shdim. Shundan keyin intermittent bug'larga har doim tarmoq sharoitini ham yozadigan bo'ldim.
### Mashq 6: Shaxsiy 12 haftalik reja (🟢) 3-bo'limdagi jadval asosida o'zingizning 12 haftalik rejangizni tuzing: har hafta uchun darslar, amaliy natija va tekshirish usuli.
💡 Javobni ko'rish Yaxshi rejaning belgilari: - har haftada **ko'rinadigan natija** bor (fayl, repo, kolleksiya), shunchaki "o'qish" emas; - haftalik vaqt real (masalan, 12–15 soat), dam olish kuni rejalashtirilgan; - 6–8-haftadan boshlab ariza yuborish va mock-intervyular rejaga kiritilgan; - har 4 haftada "nazorat nuqtasi": o'zingizni tekshiring bo'limlari bo'yicha qayta ko'rib chiqish.
--- ## 14. O'zingizni tekshiring {#checklist} - [ ] QA karyera yo'llari va yondosh kasblarni tushuntira olaman - [ ] Portfolio repo'mda README, CI badge va hujjatlar bor - [ ] CV 1 sahifa, natijalarga asoslangan va vakansiyaga moslashtirilgan - [ ] CTFL imtihon faktlarini va sertifikat foydasi/cheklovlarini bilaman - [ ] 66 ta savolning kamida 50 tasiga ochmasdan javob bera olaman - [ ] STAR formatida kamida 3 ta haqiqiy hikoyam tayyor - [ ] Take-home topshiriqni qanday topshirishni bilaman - [ ] Birinchi 90 kun uchun reja tuzdim --- ## Xulosa {#xulosa} - QA karyerasi Manual QA'dan boshlanib, Lead, SDET/Architect, Quality Coach yoki mutaxassislik sari tarmoqlanadi; yondosh yo'llar ham ochiq. - Juniorlar uchun eng kuchli dalil — **portfolio**: capstone repo, hujjatlar, bug report'lar va CI. - CV qisqa, natijaga asoslangan va har vakansiyaga moslashtirilgan bo'lsin; to'qib chiqarilgan tajriba intervyuda tez ochiladi. - Maosh raqamlarini joriy vakansiyalardan o'zingiz solishtiring; muzokarada umumiy paketni baholang. - CTFL v4.0: 40 savol, 60 daqiqa (+25% non-native), o'tish 26/40 — foydali, lekin portfolio'ning o'rnini bosmaydi. - Intervyuda tuzilmali fikrlash, savol berish va STAR — bilim kabi muhim. - Birinchi 90 kun: o'rganish → hissa → tashabbus. - **Keyingi dars:** [QA 29: Amaliyot — Capstone loyiha va 30 ta topshiriq (Zero to Hero Challenge)](/ios-lessons/qa-capstone-challenges) ## Manbalar {#manbalar} 1. [ISTQB — Certified Tester Foundation Level (CTFL) v4.0](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/) 2. [ISTQB — Certifications (to'liq ro'yxat)](https://istqb.org/certifications/) 3. [ISTQB — Exam Structure and Rules Tables v1.18 (PDF, 2026)](https://istqb.org/wp-content/uploads/2026/05/ISTQB_Exam-Structure-and-Rules-Tables_v1.18.pdf) 4. [ISTQB — CTFL Syllabus v4.0.1 (PDF)](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf) 5. [GitHub Docs — Adding a workflow status badge](https://docs.github.com/en/actions/how-tos/monitor-workflows/add-a-status-badge) 6. [GitHub Docs — Creating a GitHub Pages site](https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-github-pages-site) 7. [Practice Software Testing (Toolshop) — GitHub](https://github.com/testsmith-io/practice-software-testing) 8. [hh.uz](https://hh.uz) 9. [IT Park Uzbekistan](https://it-park.uz) 10. [LinkedIn Jobs](https://www.linkedin.com/jobs/) 11. [uTest](https://www.utest.com/) 12. [Testlio](https://testlio.com/) 13. [Ministry of Testing](https://www.ministryoftesting.com/) 14. [Playwright — Community](https://playwright.dev/community/welcome) 15. [Test Automation University](https://testautomationu.applitools.com/) 16. [Wikipedia — STAR method](https://en.wikipedia.org/wiki/Situation,_task,_action,_result)