# QA 1: QA Engineer kim — Testing, QC va QA farqi, rollar va 2026-yil kasb xaritasi
> **Holat:** 2026-yil oktabr. Kursning birinchi darsi: dasturiy sifat nega muhimligi (4 ta haqiqiy hodisa), Testing, Quality Control va Quality Assurance farqi, QA muhandisining kundalik ishi, sohadagi rollar va 29 darslik "Zero to Hero" yo'l xaritasi. Atamalar ISTQB CTFL v4.0.1 syllabus'iga (2024-09-15) tayanadi.
> **Bu darsdan keyin siz:** QA kasbi nima ekanini va bu kursda qayerdan qayerga borishingizni aniq bilasiz.
- Dasturiy xatolar qanchalik qimmatga tushishini real misollarda tushuntira olasiz.
- Testing, Quality Control (QC) va Quality Assurance (QA) farqini bir gapda ayta olasiz.
- QA muhandisining bir kuni, u yaratadigan hujjatlar va natijalarni bilasiz.
- Manual QA, AQA, SDET, Performance, Security va QA Lead rollarini farqlaysiz.
- Kurs davomida ishlatadigan "DemoBozor" namunaviy mahsuloti va asboblar bilan tanishasiz.
## Mundarija
1. [Nega sifat muhim: 4 ta haqiqiy hodisa](#nega-sifat)
2. [Testing, Quality Control va Quality Assurance](#testing-qc-qa)
3. [QA muhandisi aslida nima qiladi](#qa-nima-qiladi)
4. [QA sohasidagi rollar](#rollar)
5. [Ko'nikmalar xaritasi](#konikmalar)
6. [QA haqidagi 6 ta afsona](#afsonalar)
7. [Kurs yo'l xaritasi: Zero → Hero](#yol-xaritasi)
8. [Kursning yo'ldoshi: DemoBozor](#demobozor)
9. [Kurs davomida kerak bo'ladigan asboblar](#asboblar)
10. [Amaliy mashqlar](#mashqlar)
11. [O'zingizni tekshiring](#checklist)
12. [Xulosa](#xulosa)
13. [Manbalar](#manbalar)
---
## 1. Nega sifat muhim: 4 ta haqiqiy hodisa {#nega-sifat}
Dasturiy ta'minotdagi xato ba'zan shunchaki "tugma ishlamadi" bilan tugaydi. Ba'zan esa raketa portlaydi, bemor jarohat oladi, kompaniya 45 daqiqada yuz millionlab dollar yo'qotadi yoki dunyo bo'ylab millionlab kompyuter bir kunda ishdan chiqadi. Quyidagi to'rt hodisa — testlash darsliklarida eng ko'p o'rganiladigan haqiqiy misollar. Har birining rasmiy tergov hujjati bor (Manbalar bo'limida).
| Hodisa | Sana | Nima bo'ldi | Texnik sabab (qisqa) |
| ------------------------ | ----------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Ariane 5, Flight 501** | 1996-yil 4-iyun | Raketa parvoz boshlanganidan taxminan 40 soniya o'tib yo'nalishdan chiqdi va parchalanib ketdi | 64-bit float qiymat 16-bit butun songa o'girilganda sig'madi; kod Ariane 4'dan qayta ishlatilgan |
| **Therac-25** | 1985–1987 | Nurlanish terapiyasi apparati kamida 6 holatda bemorlarga haddan tashqari katta doza berdi; o'lim va og'ir jarohatlar | Race condition, apparat himoya qulflari olib tashlanib xavfsizlik to'liq dasturga ishonilgan |
| **Knight Capital** | 2012-yil 1-avgust | Taxminan 45 daqiqada 212 ta mijoz buyurtmasi uchun 4 milliondan ortiq bitim; 460 mln dollardan ortiq zarar | Yangi kod 8 serverdan bittasiga ko'chirilmagan; qayta ishlatilgan "flag" eski o'lik kodni uyg'otgan |
| **CrowdStrike Falcon** | 2024-yil 19-iyul | Xavfsizlik dasturining kontent yangilanishi Windows kompyuterlarni ishdan chiqardi; Microsoft hisobicha 8,5 mln qurilma | Shablon 21 ta maydonni kutgan, kod 20 ta qiymat bergan; testlarda 21-maydon uchun "wildcard" ishlatilgan |
### Ariane 5: qayta ishlatilgan kod — yangi xavf
Ariane 5 raketasining birinchi parvozida inersial navigatsiya tizimi (SRI) dasturi gorizontal tezlikka bog'liq `BH` (Horizontal Bias) qiymatini 64-bitli kasr sondan 16-bitli butun songa o'girdi. Ariane 5'ning trayektoriyasida bu qiymat Ariane 4'dagidan ancha tez o'sgan, son 16-bitga sig'magan va "Operand Error" yuz bergan. Eng achinarlisi — bu funksiya parvoz paytida umuman kerak emas edi: u Ariane 4'dan "umumiylik uchun" (commonality reasons) qoldirilgan.
Tergov komissiyasi testlash haqida aniq xulosa yozgan: SRI'ni Ariane 5 trayektoriyasi bilan real sharoitda sinagan test bo'lmagan va "agar tizim testga qo'shilganida, xato aniqlangan bo'lardi". Tavsiyalar orasida: imkon qadar real uskunalar bilan to'liq tizim testi, trayektoriya ma'lumotlarini test talablariga kiritish, ichki o'zgaruvchilarning qiymat oralig'ini tekshirish.
> **🧠 Esda tuting:** "Bu kod oldin ishlagan" degani "yangi muhitda ham ishlaydi" degani emas. Qayta ishlatilgan kod yangi kontekstda **yangi test** talab qiladi. Chegara qiymatlarni tekshirish texnikasi (Boundary Value Analysis) aynan shunday xatolarni ushlaydi — uni [QA 5](/ios-lessons/qa-test-design-1) darsida o'rganamiz.
### Therac-25: xavfsizlikni bitta qatlamga ishonib bo'lmaydi
Therac-25 — AECL kompaniyasining nurlanish terapiyasi apparati. Nancy Leveson va Clark Turner'ning 1993-yilgi tergov maqolasiga ko'ra, 1985-yil iyunidan 1987-yil yanvarigacha oltita ma'lum hodisada apparat bemorlarga haddan tashqari katta doza bergan, natijada o'lim va og'ir jarohatlar bo'lgan. Asosiy sabablar:
- Oldingi modellardagi dastur qayta ishlatilgan, lekin u modellarda xatolarni **apparat himoya qulflari** (hardware interlocks) yashirib turgan. Therac-25'da qulflar olib tashlangan va xavfsizlik to'liq dasturga topshirilgan.
- Parallel jarayonlar o'rtasidagi **race condition**: operator ma'lumotni tez tahrirlasa, tizim noto'g'ri holatga tushib qolgan.
- Tushunarsiz xato xabarlari (`MALFUNCTION 54` kabi faqat raqam), operator ularni jiddiy deb qabul qilmagan.
- Dastur mustaqil review'dan o'tmagan, apparat va dastur birga kasalxonaga yetib borguncha to'liq sinalmagan.
> **💡 Maslahat:** Xato xabari ham mahsulot sifatining bir qismi. "Xatolik 54" emas, "Doza sozlamasi tasdiqlanmadi — qayta kiriting" kabi aniq xabar foydalanuvchini to'g'ri harakatga yo'naltiradi. Test qilayotganda xato xabarlarini ham tekshiring.
### Knight Capital: deploy ham test qilinishi kerak
AQSh Qimmatli qog'ozlar komissiyasi (SEC) hujjatiga ko'ra, Knight Capital birja buyurtmalarini yo'naltiruvchi tizimiga yangi kod joylashtirdi. Texnik xodim yangi kodni sakkizta serverdan bittasiga ko'chirmagan, buni ikkinchi xodim tekshirmagan va bunday tekshiruvni talab qiladigan yozma tartib ham bo'lmagan. Yangi kod eski "Power Peg" funksiyasini yoqadigan **flag'ni qayta ishlatgan** edi — sakkizinchi serverda esa o'sha eski, yillar davomida ishlatilmagan kod hali turgan.
Natija: 2012-yil 1-avgustda taxminan 45 daqiqa ichida 212 ta mijoz buyurtmasi uchun 154 ta aksiya bo'yicha 4 milliondan ortiq bitim, 397 million aksiyadan ortiq savdo amalga oshdi. Kompaniya 460 million dollardan ortiq zarar ko'rdi.
> **⚠️ Diqqat:** Bu yerda "dasturchi xato kod yozdi" deyish yetarli emas. Muammo zanjiri: o'chirilmagan o'lik kod (dead code) + qayta ishlatilgan flag + qo'lda deploy + ikkinchi tekshiruvning yo'qligi + monitoring kech sezgani. QA'ning vazifasi — faqat funksiyani emas, **reliz jarayonini ham** savol ostiga qo'yish: "Barcha serverlarda bir xil versiya turganini qanday tekshiramiz?"
### CrowdStrike: test ma'lumoti ham "haqiqiy" bo'lishi kerak
2024-yil 19-iyulda CrowdStrike Falcon sensori uchun "Channel File 291" kontent yangilanishi chiqdi. Kompaniyaning ildiz sabab tahliliga (Root Cause Analysis) ko'ra, yangi shablon turi 21 ta kirish maydonini e'lon qilgan, sensor kodi esa faqat 20 ta qiymat uzatgan. Testlarda va dastlabki yangilanishlarda 21-maydon uchun "istalgan qiymat" (wildcard) mezoni ishlatilgani sababli bu nomuvofiqlik ko'p bosqichli testlardan o'tib ketgan. 19-iyulda 21-maydonni haqiqatan tekshiradigan qoida chiqqanda, sensor massiv chegarasidan tashqarida o'qishga urindi (out-of-bounds read) va tizim qulab tushdi. Microsoft hisobicha zarar ko'rgan Windows qurilmalari soni 8,5 million (barcha Windows kompyuterlarining 1 foizidan kami).
Hisobotdagi tavsiyalardan biri — yangilanishlarni **bosqichma-bosqich** (staged deployment, canary) tarqatish: avval kichik guruhda sinab, keyin kengaytirish.
> **🎯 Intervyuda:** "Qaysi mashhur dasturiy xatoni bilasiz va undan qanday saboq olgansiz?" — Hodisa nomi + texnik sabab + qaysi test yoki jarayon uni ushlab qolishi mumkin edi. Masalan: "CrowdStrike'da test ma'lumoti 21-maydonni wildcard bilan qamragan; har bir maydonni haqiqiy qiymat bilan tekshiradigan test va canary reliz zararni keskin kamaytirgan bo'lardi."
To'rt hodisaning umumiy saboqlari keyingi darslarimizning mavzulari:
| Saboq | Qaysi darsda o'rganamiz |
| ------------------------------------ | ----------------------------------------- |
| Chegara qiymatlarni tekshirish | [QA 5](/ios-lessons/qa-test-design-1) |
| Integratsion va to'liq tizim testi | [QA 4](/ios-lessons/qa-levels-types) |
| Talab va hujjatlarni erta tekshirish | [QA 3](/ios-lessons/qa-sdlc-stlc-agile) |
| Reliz jarayoni, canary va monitoring | [QA 27](/ios-lessons/qa-strategy-metrics) |
| CI/CD'dagi avtomatik tekshiruvlar | [QA 21](/ios-lessons/qa-ci-cd) |
---
## 2. Testing, Quality Control va Quality Assurance {#testing-qc-qa}
Kundalik nutqda "testlash" va "QA" so'zlari ko'pincha bir ma'noda ishlatiladi. ISTQB syllabus'i esa ularni aniq ajratadi:
- **Testing** — mahsulotga yo'naltirilgan, **tuzatuvchi** (corrective) yondashuv: test obyektini tekshirib, undagi defektlarni topishga yordam beradi. Testing — **Quality Control (QC)** ning asosiy shakli. QC'ning boshqa shakllari ham bor: formal usullar (model checking, to'g'rilikni isbotlash), simulyatsiya va prototiplash.
- **Quality Assurance (QA)** — jarayonga yo'naltirilgan, **oldini oluvchi** (preventive) yondashuv. U "agar yaxshi jarayon to'g'ri bajarilsa, yaxshi mahsulot chiqadi" degan g'oyaga tayanadi. QA ham ishlab chiqish, ham testlash jarayonlariga tegishli va **loyihadagi har bir kishining mas'uliyati**.
Test natijalaridan ikkalasi ham foydalanadi: testlashda — defektlarni tuzatish uchun, QA'da — jarayonlar qanchalik yaxshi ishlayotgani haqida fikr-mulohaza (feedback) olish uchun.
| | Quality Assurance | Quality Control | Testing |
| -------------------- | ----------------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------ |
| **Nimaga qaraydi** | Jarayonga | Mahsulotga | Aniq test obyektiga |
| **Yondashuv** | Oldini olish | Aniqlash va tuzatish | QC'ning asosiy usuli: statik va dinamik tekshiruv |
| **Asosiy savol** | Ish jarayonimiz sifatli natija beradimi? | Mahsulot talab va kutilmalarga javob beradimi? | Qayerda xato bor va qanday risk qoldi? |
| **Kim** | Butun jamoa | Tekshiruvchi rollar | Tester va dasturchilar |
| **DemoBozor misoli** | "Har PR kamida bitta review va unit testdan o'tadi" qoidasi | Reliz oldidan savatcha va to'lov oqimini tekshirish | `deliveryFee()` funksiyasini 299 999 / 300 000 so'mda sinash |
### Unda nega lavozim "QA Engineer" deb ataladi?
Ko'p kompaniyalarda "QA Engineer" vakansiyasining asosiy vazifalari — testlash (QC). Bu tarixiy nom. Lekin yaxshi QA muhandisi shu bilan to'xtamaydi: u bug'lar qayerda to'planayotganini ko'radi va **jarayonni** yaxshilashni taklif qiladi ("bu modulga code review majburiy bo'lsin", "talablarga misollar qo'shamiz"). Ana shu payt u haqiqiy ma'noda QA bilan shug'ullanadi.
> **🎯 Intervyuda:** "QA va testing farqi nima?" — "Testing mahsulotdagi defektlarni topadi va QC'ning bir shakli. QA esa jarayonga qaratilgan: defektlar umuman paydo bo'lmasligi uchun qoidalar va amaliyotlarni yaxshilaydi. Testing — 'topish', QA — 'oldini olish'."
---
## 3. QA muhandisi aslida nima qiladi {#qa-nima-qiladi}
QA ishi "tayyor dasturni oxirida bosib ko'rish" emas. U talab yozilgan kundan boshlanadi va mahsulot foydalanuvchiga chiqqandan keyin ham davom etadi. Agile jamoadagi oddiy kun taxminan shunday o'tadi (kompaniya va reliz kuniga qarab o'zgaradi):
| Vaqt | Faoliyat | Natija (artefakt) |
| ----- | --------------------------------------------------------------------------- | ------------------------------------ |
| 09:30 | Daily stand-up: kecha nima test qilindi, nima to'sib turibdi | Bloklovchi muammolar ro'yxati |
| 10:00 | Yangi user story'larni o'qish, savollar berish (talablarni statik testlash) | Aniqlashtirilgan acceptance criteria |
| 11:00 | Test dizayn: checklist va test case yozish | Checklist, test case'lar |
| 13:30 | "Ready for QA" holatidagi vazifalarni staging muhitida tekshirish | Test natijalari |
| 15:00 | Topilgan bug'larni yozish, dasturchi bilan qayta hosil qilish | Bug report'lar |
| 16:00 | Avtomatlashtirilgan regression testlar natijasini tahlil qilish | Yiqilgan testlar tahlili |
| 17:00 | Ertangi reliz uchun smoke tekshiruvi, hisobot | Test summary |
QA yaratadigan asosiy artefaktlar (ISTQB ularni **testware** deb ataydi):
- **Test plan** — nimani, qanday, kim va qachon test qilamiz ([QA 7](/ios-lessons/qa-test-documentation)).
- **Checklist** va **test case** — tekshiruvlar ro'yxati va batafsil qadamlar ([QA 7](/ios-lessons/qa-test-documentation)).
- **Bug report** — topilgan defekt haqida aniq hujjat ([QA 8](/ios-lessons/qa-bug-reports)).
- **Avtomatlashtirilgan testlar** — kod ko'rinishidagi testlar ([QA 16–22](/ios-lessons/qa-automation-intro)).
- **Test hisobotlari va metrikalar** — reliz qarori uchun ma'lumot ([QA 27](/ios-lessons/qa-strategy-metrics)).
> **⚠️ Diqqat:** QA — "darvozabon" (gatekeeper) emas. Relizni chiqarish qarorini odatda product owner yoki menejment qabul qiladi. QA'ning vazifasi — qaror uchun **aniq ma'lumot berish**: qaysi risklar tekshirildi, qaysilari ochiq qoldi, qaysi bug'lar ma'lum. ISTQB ham buni "whole team approach" deb ataydi: sifat uchun butun jamoa javobgar.
---
## 4. QA sohasidagi rollar {#rollar}
Lavozim nomlari kompaniyadan kompaniyaga farq qiladi, shuning uchun vakansiyada **nomga emas, vazifalar ro'yxatiga** qarang. Eng ko'p uchraydigan rollar:
| Rol | Asosiy fokus | Asosiy asboblar | Kursdagi darslar |
| ------------------------------------------------ | ------------------------------------------------------------------ | ----------------------------------------------------------- | ---------------- |
| **Manual QA Engineer** | Funksional testlash, test dizayn, bug report | Jira, TestRail/Qase, Chrome DevTools | 1–9 |
| **QA Analyst** | Talablarni tahlil qilish, acceptance criteria, test strategiya | Confluence/Notion, Jira | 3, 5–7 |
| **Automation QA (AQA)** | Regression testlarni avtomatlashtirish | Playwright, Postman/Newman, CI | 16–21 |
| **SDET** (Software Development Engineer in Test) | Test infratuzilmasi, framework, CI/CD — dasturchi darajasida kod | Playwright, Docker, GitHub Actions | 13, 16–22 |
| **Mobile QA** | iOS/Android ilovalarni testlash va avtomatlashtirish | Xcode Simulator, Android Emulator, Proxyman, Maestro/Appium | 14, 15, 22 |
| **Performance QA** | Yuklama, stress va barqarorlik testlari | k6, JMeter, Grafana | 23 |
| **Security tester (QA darajasida)** | OWASP bo'yicha asosiy xavfsizlik tekshiruvlari | Burp Suite, ZAP, Proxyman | 24 |
| **QA Lead / QA Manager** | Strategiya, jamoa, metrikalar, reliz uchun ma'lumot | Jira dashboard'lari, test management | 27 |
| **Test Architect** | Bir nechta jamoa uchun test strategiyasi va asboblar arxitekturasi | Framework'lar, CI, observability | 16, 21, 27 |
So'nggi yillarda ba'zi kompaniyalarda **"Quality Engineer" (QE)** nomi ham uchraydi: bu rol faqat test yozish bilan emas, butun jamoaning sifat amaliyotlari (testability, monitoring, jarayon) bilan shug'ullanadi. Mohiyatan bu — yuqorida aytilgan "haqiqiy QA" yo'nalishi.
> **💡 Maslahat:** Pentest (professional xavfsizlik sinovi) — alohida kasb va alohida ruxsatlar talab qiladi. QA darajasidagi xavfsizlik testlari faqat **o'z ilovangiz va test muhitingizda** bajariladi ([QA 24](/ios-lessons/qa-security)).
---
## 5. Ko'nikmalar xaritasi {#konikmalar}
ISTQB syllabus'i tester uchun muhim umumiy ko'nikmalarni sanab o'tadi: testlash bilimi; puxtalik, ehtiyotkorlik, qiziquvchanlik, detallarga e'tibor, tizimlilik; muloqot, faol tinglash va jamoada ishlash; analitik, tanqidiy va ijodiy fikrlash; texnik bilim; domen (soha) bilimi.
### Hard skills — kursda qayerda o'rganamiz
| Ko'nikma | Nega kerak | Dars |
| ------------------------------------- | ------------------------------------------------ | --------- |
| Test dizayn texnikalari | Kam test bilan ko'p xato topish | 5–6 |
| Test hujjatlari va bug report | Natijani boshqalarga tushunarli yetkazish | 7–8 |
| Web, HTTP, DevTools | Bug front-end'dami yoki back-end'dami — ajratish | 9 |
| API testing | Interfeyssiz qatlamni tekshirish | 10–11, 20 |
| SQL | Ma'lumotlar bazasidagi natijani tasdiqlash | 12 |
| Terminal, Git, loglar | Muhitni tushunish, dalil yig'ish | 13 |
| Mobil testlash va Proxyman | iOS/Android va tarmoq trafigini tekshirish | 14–15, 22 |
| Dasturlash (TypeScript) va Playwright | Avtomatlashtirish | 16–21 |
| Performance, security, a11y | Nofunksional sifat | 23–25 |
### Soft skills — eng ko'p baholanadigan sifatlar
- **Qiziquvchanlik:** "Agar foydalanuvchi bu yerda ortga qaytsa-chi?", "Internet uzilsa-chi?" deb so'rash odati.
- **Detallarga e'tibor:** 299 999 va 300 000 so'm orasidagi farqni ko'ra bilish.
- **Muloqot:** ISTQB to'g'ri ta'kidlaydi — tester ko'pincha "yomon xabar" olib keladi. Shuning uchun xabar **konstruktiv** bo'lishi kerak: shaxsga emas, faktga qaratilgan.
- **"Konstruktiv buzish" fikrlashi:** dastur qanday ishlashi kerakligini bilib turib, uni qanday buzish mumkinligini o'ylash — va topganingizni jamoaga foyda bo'ladigan tarzda yetkazish.
- **Biznesni tushunish:** qaysi xato foydalanuvchi va kompaniya uchun qimmatroq ekanini ajrata bilish.
> **🧠 Esda tuting:** Yaxshi QA "T-shaklidagi" mutaxassis: keng doirada (web, API, mobil, SQL, jarayon) yetarli bilim va bir-ikki yo'nalishda (masalan, avtomatlashtirish yoki mobil) chuqur tajriba.
---
## 6. QA haqidagi 6 ta afsona {#afsonalar}
| Afsona | Haqiqat |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "QA — shunchaki tugma bosish" | Asosiy ish — tahlil: talablarni tushunish, test dizayn, sabablarni izlash, risklarni baholash. Tugma bosish — faqat ijro qismi. |
| "Tester — dasturchi bo'la olmaganlar kasbi" | Bu boshqa fikrlash turi. SDET'lar dasturchi darajasida kod yozadi; manual QA esa domen va foydalanuvchi tajribasini chuqur biladi. |
| "Avtomatlashtirish qo'lda testlashni butunlay almashtiradi" | ISTQB ham DevOps haqida yozganda ta'kidlaydi: avtomatlashtirish ko'p bo'lsa ham, foydalanuvchi nuqtai nazaridan qo'lda testlash baribir kerak. Exploratory va usability testlar — inson ishi. |
| "AI testerlarni almashtiradi" | AI test g'oyalari va kod qoralamasini tezlashtiradi, lekin risk bahosi, biznes konteksti va natija uchun javobgarlik insonda qoladi. AI javoblarini doim tekshirish kerak ([QA 26](/ios-lessons/qa-ai-testing)). |
| "Yaxshi test qilingan dastur — xatosiz dastur" | Testlash xato **borligini** ko'rsatadi, yo'qligini isbotlay olmaydi — bu birinchi printsip ([QA 2](/ios-lessons/qa-principles-istqb)). |
| "QA faqat oxirida kerak" | Eng arzon bug — talab bosqichida topilgani. Erta testlash (shift-left) haqida [QA 3](/ios-lessons/qa-sdlc-stlc-agile) darsida. |
---
## 7. Kurs yo'l xaritasi: Zero → Hero {#yol-xaritasi}
Kurs 5 moduldan iborat. Har modul oxirida siz yangi darajaga chiqasiz. Darajalar taxminiy: haqiqiy darajani amaliyot va real loyihalardagi tajriba belgilaydi.
### Modul 1 — Poydevor
| № | Dars |
| --- | ------------------------------------------------------------------------------------------------------------------------------------ |
| 1 | [QA 1: QA Engineer kim — Testing, QC va QA farqi, rollar va 2026-yil kasb xaritasi](/ios-lessons/qa-intro-career) |
| 2 | [QA 2: Testlashning 7 printsipi va ISTQB tili — Error, Defect, Failure va test jarayoni](/ios-lessons/qa-principles-istqb) |
| 3 | [QA 3: SDLC, STLC va Agile — Waterfall, V-Model, Scrum va QA'ning har bosqichdagi o'rni](/ios-lessons/qa-sdlc-stlc-agile) |
| 4 | [QA 4: Testlash darajalari va turlari — Unit'dan UAT'gacha, Smoke, Sanity, Regression va Test Pyramid](/ios-lessons/qa-levels-types) |
### Modul 2 — Manual QA yadrosi
| № | Dars |
| --- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| 5 | [QA 5: Test dizayn texnikalari (1) — Equivalence Partitioning, Boundary Value Analysis va Decision Table](/ios-lessons/qa-test-design-1) |
| 6 | [QA 6: Test dizayn texnikalari (2) — State Transition, Pairwise, Use Case, White-box va Exploratory](/ios-lessons/qa-test-design-2) |
| 7 | [QA 7: Test hujjatlari — Test Plan, Strategy, Checklist, Test Case va Traceability Matrix](/ios-lessons/qa-test-documentation) |
| 8 | [QA 8: Bug report va Bug Life Cycle — Severity vs Priority, Jira va yaxshi bug yozish san'ati](/ios-lessons/qa-bug-reports) |
### Modul 3 — Texnik ko'nikmalar
| № | Dars |
| --- | ------------------------------------------------------------------------------------------------------------------------------------- |
| 9 | [QA 9: Web qanday ishlaydi — Client-Server, HTTP, DNS, Cookie, Cache va Chrome DevTools](/ios-lessons/qa-web-http-devtools) |
| 10 | [QA 10: API testing (1) — REST, JSON, status kodlar va Postman amaliyoti](/ios-lessons/qa-api-postman) |
| 11 | [QA 11: API testing (2) — Test dizayn, negative testlar, JSON Schema, Auth, Mock va Contract testing](/ios-lessons/qa-api-advanced) |
| 12 | [QA 12: SQL va ma'lumotlar bazasi — QA uchun SELECT, JOIN, GROUP BY va data tekshiruvi](/ios-lessons/qa-sql) |
| 13 | [QA 13: Terminal, Git, Docker va Loglar — QA'ning muhandislik asboblari](/ios-lessons/qa-terminal-git-logs) |
| 14 | [QA 14: Mobil ilovalarni testlash — iOS va Android farqlari, Simulator, ADB, TestFlight va checklist](/ios-lessons/qa-mobile-testing) |
| 15 | [QA 15: Proxyman — HTTPS trafikni ushlash, Map Local, Breakpoint, Scripting va Network Conditions](/ios-lessons/qa-proxyman) |
### Modul 4 — Avtomatlashtirish
| № | Dars |
| --- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| 16 | [QA 16: Test avtomatlashtirishga kirish — nimani avtomatlashtirish kerak, ROI va 2026 asboblar xaritasi](/ios-lessons/qa-automation-intro) |
| 17 | [QA 17: QA uchun TypeScript — o'zgaruvchilar, funksiyalar, async/await, class'lar va npm](/ios-lessons/qa-typescript) |
| 18 | [QA 18: Playwright (1) — o'rnatish, locator'lar, action'lar, assertion'lar va auto-waiting](/ios-lessons/qa-playwright-basics) |
| 19 | [QA 19: Playwright (2) — Page Object Model, fixtures, auth state, network mocking va visual testlar](/ios-lessons/qa-playwright-advanced) |
| 20 | [QA 20: API avtomatlashtirish — Playwright request, Zod schema va API+UI gibrid testlar](/ios-lessons/qa-api-automation) |
| 21 | [QA 21: CI/CD'da testlar — GitHub Actions, hisobotlar, sharding, flaky testlar va quality gate](/ios-lessons/qa-ci-cd) |
| 22 | [QA 22: Mobil avtomatlashtirish — Maestro, Appium 3, XCUITest va Espresso](/ios-lessons/qa-mobile-automation) |
### Modul 5 — Hero darajasi
| № | Dars |
| --- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| 23 | [QA 23: Performance testing — Load, Stress, Spike, Soak va k6 bilan amaliyot](/ios-lessons/qa-performance-k6) |
| 24 | [QA 24: Security testing asoslari — OWASP Top 10:2025, IDOR, injection va QA xavfsizlik checklisti](/ios-lessons/qa-security) |
| 25 | [QA 25: Accessibility, Localization va Visual testing — WCAG 2.2, axe-core va o'zbek tili nozikliklari](/ios-lessons/qa-a11y-l10n-visual) |
| 26 | [QA 26: AI va QA (2026) — LLM bilan test dizayn, Playwright Agents, MCP va AI tizimlarini testlash](/ios-lessons/qa-ai-testing) |
| 27 | [QA 27: Test strategiyasi, metrikalar va QA Lead — risk-based testing, release va jarayon qurish](/ios-lessons/qa-strategy-metrics) |
| 28 | [QA 28: Karyera — CV, portfolio, ISTQB sertifikati, 60+ intervyu savoli va birinchi ish](/ios-lessons/qa-career-interview) |
| 29 | [QA 29: Amaliyot — Capstone loyiha va 30 ta topshiriq (Zero to Hero Challenge)](/ios-lessons/qa-capstone-challenges) |
### Kursni qanday o'qish kerak
1. **Ketma-ket o'qing.** Har dars oldingisiga tayanadi: masalan, Playwright darsi TypeScript va test dizayn bilimlarini talab qiladi.
2. **Mashqlarni tashlab ketmang.** Har dars oxiridagi topshiriqlarni avval o'zingiz bajaring, keyin javobni oching.
3. **Amaliyot qiling.** Darslarda real amaliyot saytlari ishlatiladi (saucedemo, restful-booker va boshqalar) — ular aynan test o'rganish uchun yaratilgan.
4. **Portfolio yig'ing.** Yozgan test case, bug report va avtomatik testlaringizni saqlang — [QA 29](/ios-lessons/qa-capstone-challenges) darsidagi capstone loyihada ularni bitta GitHub portfolio'ga jamlaysiz.
> **🇺🇿 Mahalliy kontekst:** Kurs o'zbek tilida, lekin atamalar inglizcha qoldirilgan. Sababi oddiy: vakansiyalar, Jira, rasmiy hujjatlar va intervyu savollarining katta qismi aynan shu atamalar bilan ishlaydi. "Test case", "bug report", "regression" so'zlarini tarjima qilmasdan bilish — ishda tezroq moslashishingizga yordam beradi.
---
## 8. Kursning yo'ldoshi: DemoBozor {#demobozor}
Butun kurs davomida misollar uchun bitta **xayoliy** mahsulotdan foydalanamiz — **DemoBozor**. Bu O'zbekistondagi onlayn do'kon: Web (React), iOS (Swift), Android (Kotlin) ilovalari, REST API (Node.js) va PostgreSQL bazasi. Tillar: o'zbek (lotin va kirill), rus, ingliz. Vaqt zonasi — Asia/Tashkent (UTC+5). Rollar: xaridor, sotuvchi, admin.
DemoBozor'ning biznes qoidalari — bizning "talablar hujjatimiz". Keyingi darslarda test case, chegara qiymatlar va bug report'larni aynan shu qoidalarga qarab yozamiz:
| Soha | Qoida |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Telefon raqami | `+998` + 9 raqam (masalan `+998 90 123 45 67`) |
| SMS kod (OTP) | 6 raqam; 120 soniya amal qiladi; qayta yuborish 60 soniyadan keyin; 3 marta noto'g'ri → raqam 15 daqiqaga bloklanadi |
| Ism | 2–50 belgi; harflar (lotin/kirill), probel, apostrof, defis |
| Parol (sotuvchi/admin web paneli) | 8–64 belgi; kamida 1 harf va 1 raqam |
| Savatcha | bitta mahsulot soni 1–99; savatchada ko'pi bilan 50 xil mahsulot |
| Yetkazib berish | mahsulotlar summasi ≥ 300 000 so'm → bepul; aks holda 20 000 so'm. Toshkent 1 kun, viloyatlar 2–4 kun |
| Promo-kod | 6–12 belgi, faqat A–Z va 0–9 (katta harf); bitta buyurtmaga bitta; har promo uchun minimal summa va amal qilish muddati; har foydalanuvchi bir marta |
| Chegirmalar | Yangi mijoz (birinchi buyurtma) 10%; promo-kod odatda 15%; chegirmalar qo'shilmaydi — kattasi qo'llanadi; Premium a'zo: har doim bepul yetkazib berish |
| Muddatli to'lov (foizsiz) | yosh 18–65 (shu jumladan); buyurtma 500 000 – 30 000 000 so'm; 3, 6 yoki 12 oy |
| To'lov usullari | Uzcard, Humo, Visa, Mastercard, naqd (yetkazib berganda) |
| Sharh | 1–5 yulduz; matn 10–1000 belgi; faqat yetkazilgan buyurtma egasi yozadi |
| Qidiruv | so'rov 2–100 belgi |
Buyurtma holatlari: `CREATED` (Yaratildi) → `PENDING_PAYMENT` (To'lov kutilmoqda) → `PAID` (To'landi) → `PACKING` (Yig'ilmoqda) → `SHIPPED` (Yo'lda) → `DELIVERED` (Yetkazildi). Bekor qilish (`CANCELLED`) va qaytarish (`RETURNED`) qoidalarini [QA 6](/ios-lessons/qa-test-design-2) darsida State Transition texnikasi bilan batafsil ko'ramiz.
> **💡 Maslahat:** Bu jadvalni saqlab qo'ying yoki xatcho'p qiling. Keyingi darslardagi ko'p mashqlar "DemoBozor qoidasiga ko'ra..." deb boshlanadi.
---
## 9. Kurs davomida kerak bo'ladigan asboblar {#asboblar}
Hozir hech narsani o'rnatish shart emas — har bir asbobni kerakli darsda qadam-baqadam ko'rsatamiz. Bu ro'yxat — oldindan tasavvur uchun:
| Asbob | Nima uchun | Dars | Rasmiy sayt |
| ------------------------------------ | ------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------- |
| Google Chrome (DevTools) | Web ilovani tekshirish, Network, Console | 9 | [google.com/chrome](https://www.google.com/chrome/) |
| Visual Studio Code | Kod va test yozish | 13, 17–22 | [code.visualstudio.com](https://code.visualstudio.com/) |
| Node.js 24 LTS | TypeScript va Playwright'ni ishga tushirish | 17–21 | [nodejs.org](https://nodejs.org/) |
| Git | Kod versiyalari, branch'larni test qilish | 13 | [git-scm.com](https://git-scm.com/) |
| Postman yoki Bruno | API so'rovlarini yuborish va test yozish | 10–11 | [postman.com](https://www.postman.com/), [usebruno.com](https://www.usebruno.com/) |
| Proxyman | Mobil va web trafikni ushlash, mock qilish | 15 | [proxyman.com](https://proxyman.com/) |
| `sqlite3` yoki DB Browser for SQLite | SQL so'rovlarini mashq qilish | 12 | [sqlitebrowser.org](https://sqlitebrowser.org/) |
| Jira yoki Linear | Bug va vazifalarni yuritish | 8 | [atlassian.com/software/jira](https://www.atlassian.com/software/jira), [linear.app](https://linear.app/) |
> **⚠️ Diqqat:** Postman'ning bepul (Free) rejasi 2026-yil martidan boshlab faqat bitta foydalanuvchiga mo'ljallangan. Yolg'iz o'rganish uchun bu yetarli. Jamoa bilan bepul ishlash kerak bo'lsa — Bruno, Hoppscotch yoki Insomnia kabi muqobillar bor; tushunchalar bir xil ([QA 10](/ios-lessons/qa-api-postman)).
> **💡 Maslahat:** iOS ilovalarni test qilish uchun macOS va Xcode kerak; Android uchun Android Studio (emulator) yetarli va u Windows/Linux'da ham ishlaydi. Proxyman macOS, Windows va Linux uchun mavjud. Bu tafsilotlar [QA 14](/ios-lessons/qa-mobile-testing) va [QA 15](/ios-lessons/qa-proxyman) darslarida.
---
## 10. Amaliy mashqlar {#mashqlar}
### Mashq 1: QA, QC yoki Testing?
Har bir faoliyatni **QA** (jarayon, oldini olish), **QC** (mahsulotni tekshirish) yoki **Testing** (QC'ning test orqali shakli) ga ajrating. Ba'zilarida ikkita javob mumkin — sababini yozing.
1. Retrospektivada bug'lar ko'pligi muhokama qilinib, Definition of Done'ga "har PR'da unit test" qoidasi qo'shildi.
2. Tester `POST /api/v1/orders` endpoint'ini 10 xil ma'lumot bilan sinadi.
3. Jamoa yangi dasturchilar uchun kod yozish standartini tasdiqladi.
4. Tester talablar hujjatini o'qib, ikki qoida bir-biriga zid ekanini topdi.
5. Dizayner yangi to'lov ekranining interaktiv prototipini 5 ta foydalanuvchida sinadi.
6. CI'da linter (static analysis) har commit'ni tekshiradi.
7. QA Lead bug statistikasiga qarab, to'lov moduli uchun majburiy ikki kishilik code review'ni taklif qildi.
8. Reliz oldidan savatcha va checkout oqimi qo'lda tekshirildi.
💡 Javobni ko'rish
| № | Javob | Izoh |
| --- | ----------------- | --------------------------------------------------------------------------------- |
| 1 | QA | Jarayon o'zgardi — kelajakdagi defektlarning oldi olinadi |
| 2 | Testing (QC) | Dinamik test: dastur ishga tushirilib tekshiriladi |
| 3 | QA | Standart — jarayon qoidasi |
| 4 | Testing (QC) | Statik testlash: talab hujjati review qilindi, defekt to'g'ridan-to'g'ri topildi |
| 5 | QC | Prototiplash — QC'ning testdan tashqari shakli |
| 6 | Testing (QC) + QA | Static analysis — statik test; uni CI'ga majburiy qo'yish esa jarayon qarori (QA) |
| 7 | QA | Test natijalari jarayonni yaxshilash uchun ishlatildi |
| 8 | Testing (QC) | Mahsulot reliz oldidan tekshirildi |
Asosiy qoida: **natija — o'zgargan jarayon** bo'lsa QA, **natija — mahsulot haqidagi ma'lumot** bo'lsa QC/Testing.
### Mashq 2: Elektr choynakni test qiling
Intervyularda tez-tez beriladigan savol: "Mana bu narsani qanday test qilasiz?" Oddiy elektr choynak uchun kamida 15 ta test g'oyasini yozing va ularni kategoriyalarga ajrating (funksional, xavfsizlik, ishonchlilik, foydalanish qulayligi, moslik va h.k.).
💡 Javobni ko'rish
Namunaviy javob (to'liq ro'yxat emas — muhimi, kategoriyalab fikrlash):
**Funksional**
- To'liq choynak suvni qaynatadimi? Necha daqiqada?
- Minimal belgigacha quyilgan suv ham qaynaydimi?
- Qaynagandan keyin avtomatik o'chadimi?
- Indikator chirog'i yoqilganda yonib, o'chganda o'chadimi?
**Xavfsizlik**
- Suvsiz yoqilsa nima bo'ladi (quruq qaynatishdan himoya)?
- Tutqich qizib ketadimi?
- Qopqoq yopilmagan bo'lsa ham o'chadimi?
- Elektr shnur va vilka izolyatsiyasi; nam qo'l bilan ushlaganda xavf.
**Chegaraviy holatlar**
- "MAX" belgisidan ortiq quyilsa — suv toshib ketadimi?
- Tarmoqdagi kuchlanish pasayib-ko'tarilganda xavfsiz ishlaydimi?
**Ishonchlilik (chidamlilik)**
- 1000 marta yoqib-o'chirilganda tugma ishlashda davom etadimi?
- Ketma-ket 10 marta qaynatilganda qizib ketish himoyasi ishlaydimi?
**Foydalanish qulayligi**
- Suv sathini ko'rish oson mi?
- Chap qo'l bilan ham ushlash qulaymi?
- Quyishda suv tomchilab ketadimi?
**Moslik va muhit**
- Turli rozetkalarga mos keladimi?
- Qattiq suvda (ohak) qancha vaqtda ifloslanadi, tozalash osonmi?
Intervyuda eng muhimi — ro'yxat uzunligi emas, **tuzilmasi**: avval talablarni so'rang ("Choynak kim uchun? Qaysi standartlarga mos bo'lishi kerak?"), keyin kategoriyalar bo'yicha fikrlang, oxirida eng xavfli testlarni birinchi o'ringa qo'ying.
### Mashq 3: DemoBozor login ekranidagi muammolar
DemoBozor iOS ilovasining yangi build'ida (v2.0.0, build 145) login ekranini tekshirdingiz va quyidagilarni kuzatdingiz. [DemoBozor qoidalari](#demobozor) asosida qaysi kuzatuvlar **muammo** ekanini toping (kamida 8 ta) va har biri qaysi qoida yoki kutilmani buzayotganini yozing.
1. Telefon maydoni `+998` prefiksi bilan boshlanadi va o'chirib bo'lmaydi.
2. Telefon maydoniga harflarni ham yozish mumkin: `+998 90 abc`.
3. 8 ta raqam kiritilganda ham "Kod olish" tugmasi faol; bosilganda hech qanday xabar chiqmaydi.
4. SMS kod uchun 4 ta katak ko'rsatiladi.
5. "Kodni qayta yuborish" tugmasi 30 soniyadan keyin faollashadi.
6. Noto'g'ri kod kiritilganda "Invalid code" yozuvi chiqadi (ilova tili — o'zbekcha).
7. Ketma-ket 4 marta noto'g'ri kod kiritildi — ilova 5-urinishga ham ruxsat berdi.
8. To'g'ri kod kiritilgach, bosh sahifa ochiladi.
9. To'g'ri kod kiritilgandan keyin 5–6 soniya ekran "qotadi", yuklanish belgisi yo'q.
10. Qorong'i rejimda telefon raqami matni fon bilan deyarli bir xil rangda.
11. iPhone SE'da klaviatura ochilganda "Kirish" tugmasi klaviatura ostida qolib ketadi.
12. "Foydalanish shartlari" havolasi 404 sahifasini ochadi.
💡 Javobni ko'rish
To'g'ri ishlayotganlar: **1** va **8**. Qolgan 10 tasi — muammo:
| № | Muammo | Buzilgan qoida / kutilma | Kategoriya |
| --- | --------------------------------- | --------------------------------------------------------------------------------------- | ----------------- |
| 2 | Harf yozish mumkin | Telefon faqat raqamlardan iborat (`+998` + 9 raqam) | Validatsiya |
| 3 | 8 raqamda tugma faol, xabar yo'q | Telefon to'liq 9 raqam bo'lishi kerak; foydalanuvchiga sabab ko'rsatilishi kerak | Validatsiya, UX |
| 4 | 4 ta katak | SMS kod — 6 raqam | Talabga mos emas |
| 5 | 30 soniya | Qayta yuborish — 60 soniyadan keyin | Talabga mos emas |
| 6 | "Invalid code" | Interfeys tili o'zbekcha — matn tarjima qilinmagan | Lokalizatsiya |
| 7 | 5-urinishga ruxsat | 3 marta noto'g'ri → 15 daqiqa blok | Xavfsizlik, talab |
| 9 | 5–6 s "qotish" | Foydalanuvchi jarayon ketayotganini ko'rishi kerak; sekinlikni alohida tekshirish kerak | UX, performance |
| 10 | Qorong'i rejimda matn ko'rinmaydi | Matn va fon kontrasti yetarli bo'lishi kerak | Accessibility, UI |
| 11 | Tugma klaviatura ostida | Kichik ekranlarda ham asosiy harakat ko'rinishi kerak | Layout, moslik |
| 12 | 404 havola | Havolalar ishlashi kerak (App Store review uchun ham muhim) | Funksional |
E'tibor bering: bitta ekranda juda turli toifadagi muammolar bor. Shuning uchun test qilishda faqat "ishlayaptimi?" emas, **validatsiya, talab, til, xavfsizlik, tezlik, ko'rinish, turli qurilmalar** bo'yicha ham fikrlash kerak.
### Mashq 4: Hodisalardan saboq
Har bir hodisa uchun bitta **test** yoki **jarayon** amaliyotini taklif qiling, u zararni oldini olishi yoki kamaytirishi mumkin edi:
1. Ariane 5
2. Knight Capital
3. CrowdStrike
💡 Javobni ko'rish
1. **Ariane 5:** Ariane 5'ning real trayektoriya ma'lumotlari bilan SRI'ni o'z ichiga olgan to'liq tizim testi; qayta ishlatilgan kodning qiymat oraliqlarini (chegaralarini) yangi muhit uchun tekshirish; parvozda keraksiz funksiyani o'chirish.
2. **Knight Capital:** Deploy'dan keyin avtomatik tekshiruv — "barcha 8 serverda bir xil versiya turibdimi?"; ikkinchi xodim tasdiqlashini talab qiluvchi reliz checklisti; o'lik kodni o'chirib tashlash; g'ayrioddiy savdo hajmida tizimni to'xtatuvchi monitoring.
3. **CrowdStrike:** Har bir maydonni wildcard emas, haqiqiy qiymatlar bilan tekshiradigan test; kontent yangilanishini ham kod kabi test qilish; canary/staged reliz — avval kichik guruhga, keyin hammaga.
Umumiy xulosa: hech biri "bitta dasturchining xatosi" emas — har birida **bir nechta himoya qatlami** ishlamagan.
### Mashq 5: Vakansiyaga qarab rolni aniqlang
Quyidagi (xayoliy) vakansiya parchalari qaysi rolga mos keladi: Manual QA, AQA, SDET yoki Performance QA?
1. "Playwright + TypeScript'da regression testlarni yozish va qo'llab-quvvatlash, CI'da natijalarni tahlil qilish."
2. "Yangi funksiyalar uchun test case yozish, Jira'da bug report yuritish, mobil ilovani qo'lda testlash."
3. "Test infratuzilmasini noldan qurish: Docker'da test muhitlari, parallel ishga tushirish, ichki test kutubxonalarini ishlab chiqish."
4. "k6 bilan yuklama ssenariylarini yozish, p95 javob vaqti va xatolar foizini Grafana'da kuzatish."
💡 Javobni ko'rish
1. **AQA** — tayyor framework'da avtomatik testlar yozish va qo'llab-quvvatlash.
2. **Manual QA** — test case, bug report, qo'lda testlash.
3. **SDET** — infratuzilma va kutubxonalar: dasturchi darajasidagi muhandislik.
4. **Performance QA** — yuklama testlari va metrikalar.
Real vakansiyalarda bu chegaralar aralashib ketadi: ko'p kompaniyalar "Manual + Automation" ni bitta odamdan kutadi. Shuning uchun nomga emas, vazifalarga qarang.
### Mashq 6: Xabarni konstruktiv qiling
Tester jamoa chatiga shunday yozdi: "Sizning kodingiz yana buzildi! Promo-kod umuman ishlamayapti, kim test qildi buni?!" Shu xabarni faktga asoslangan, hurmatli va foydali ko'rinishda qayta yozing.
💡 Javobni ko'rish
Namunaviy variant:
> "Salom! Staging'da (build 145) promo-kod qo'llashda muammo topdim: `BAHOR15` kodi kiritilganda chegirma qo'llanmayapti, summa o'zgarmayapti. Qadamlar va video DB-312 bug'ida. Kecha (build 144) xuddi shu ssenariy ishlagan edi, ehtimol oxirgi o'zgarish ta'sir qilgandir. Birga ko'rib chiqsak bo'ladimi?"
Nima o'zgardi:
- Shaxsga emas, **xatti-harakatga** qaratilgan ("kodingiz" emas, "promo-kod qo'llashda").
- Aniq **dalil**: build raqami, kod, ticket raqami, video.
- **Foydali kontekst**: oldingi build'da ishlagan — regressiya ehtimoli.
- **Hamkorlik taklifi**, ayblash emas.
---
## O'zingizni tekshiring {#checklist}
- [ ] To'rt hodisaning (Ariane 5, Therac-25, Knight Capital, CrowdStrike) texnik sababini bir gapda ayta olaman.
- [ ] Testing, QC va QA farqini misol bilan tushuntira olaman.
- [ ] QA muhandisi yaratadigan 5 ta artefaktni sanay olaman.
- [ ] Manual QA, AQA va SDET farqini bilaman.
- [ ] DemoBozor'ning asosiy qoidalarini (yetkazib berish, SMS kod, promo-kod) eslay olaman.
- [ ] Bug haqidagi xabarni konstruktiv shaklda yoza olaman.
---
## Xulosa {#xulosa}
- Dasturiy xatolar raketani yo'q qilishi, odamlarga zarar yetkazishi va kompaniyani bir necha daqiqada katta zararga kiritishi mumkin. Har bir yirik hodisada bir nechta himoya qatlami ishlamay qolgan.
- **Testing** — mahsulotga qaratilgan, tuzatuvchi yondashuv va QC'ning asosiy shakli. **QA** — jarayonga qaratilgan, oldini oluvchi yondashuv va butun jamoaning mas'uliyati.
- QA ishi talab yozilgan kundan boshlanadi: talablarni o'qish, test dizayn, testlash, bug report, avtomatlashtirish va reliz uchun ma'lumot berish.
- Rollar ko'p (Manual QA, AQA, SDET, Mobile, Performance, Security, Lead) — vakansiyada nomga emas, vazifalarga qarang.
- Eng qadrli sifatlar: qiziquvchanlik, detallarga e'tibor va topilgan muammoni konstruktiv yetkazish.
- Kurs 5 moduldan iborat va butun kurs davomida xayoliy **DemoBozor** do'koni misolida ishlaymiz.
- **Keyingi dars:** [QA 2: Testlashning 7 printsipi va ISTQB tili — Error, Defect, Failure va test jarayoni](/ios-lessons/qa-principles-istqb)
## Manbalar {#manbalar}
1. [ISTQB — Certified Tester Foundation Level (CTFL) v4.0](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/)
2. [ISTQB CTFL Syllabus v4.0.1 (PDF, 2024-09-15)](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf)
3. [Ariane 501 Inquiry Board report (to'liq matn)](https://www-users.cse.umn.edu/~arnold/disasters/ariane5rep.html)
4. [ESA — Ariane 501: Presentation of Inquiry Board report](https://www.esa.int/Newsroom/Press_Releases/Ariane_501_-_Presentation_of_Inquiry_Board_report)
5. [Leveson N., Turner C. — An Investigation of the Therac-25 Accidents (IEEE Computer, 1993, PDF)](https://web.stanford.edu/class/cs240/old/sp2014/readings/therac-25.pdf)
6. [Wikipedia — Therac-25](https://en.wikipedia.org/wiki/Therac-25)
7. [SEC — SEC Charges Knight Capital With Violations of Market Access Rule (2013)](https://www.sec.gov/news/press-release/2013-222)
8. [SEC — Knight Capital Americas LLC buyrug'i, Release No. 34-70694 (PDF)](https://www.sec.gov/litigation/admin/2013/34-70694.pdf)
9. [CrowdStrike — External Technical Root Cause Analysis: Channel File 291 (PDF)](https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf)
10. [Microsoft — Helping our customers through the CrowdStrike outage (2024-07-20)](https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/)
11. [Postman — About plans (2026)](https://learning.postman.com/docs/billing/about-plans)
12. [Bruno — open source API client](https://www.usebruno.com/)
13. [Proxyman](https://proxyman.com/)