QA 1: QA Engineer kim — Testing, QC va QA farqi, rollar va 2026-yil kasb xaritasi

🧪 QA Engineer — Zero to Hero

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
2. Testing, Quality Control va Quality Assurance
3. QA muhandisi aslida nima qiladi
4. QA sohasidagi rollar
5. Ko'nikmalar xaritasi
6. QA haqidagi 6 ta afsona
7. Kurs yo'l xaritasi: Zero → Hero
8. Kursning yo'ldoshi: DemoBozor
9. Kurs davomida kerak bo'ladigan asboblar
10. Amaliy mashqlar
11. O'zingizni tekshiring
12. Xulosa
13. 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).

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 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:

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.

QA, QC va Testing — ichma-ich joylashgan uch qatlam

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):

QA yaratadigan asosiy artefaktlar (ISTQB ularni testware deb ataydi):

• Test plan — nimani, qanday, kim va qachon test qilamiz (QA 7).
• Checklist va test case — tekshiruvlar ro'yxati va batafsil qadamlar (QA 7).
• Bug report — topilgan defekt haqida aniq hujjat (QA 8).
• Avtomatlashtirilgan testlar — kod ko'rinishidagi testlar (QA 16–22).
• Test hisobotlari va metrikalar — reliz qarori uchun ma'lumot (QA 27).

⚠️ 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:

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).

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

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}

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.

Kurs yo'l xaritasi: 5 modul va har biridan keyingi daraja

Modul 1 — Poydevor

Modul 2 — Manual QA yadrosi

Modul 3 — Texnik ko'nikmalar

Modul 4 — Avtomatlashtirish

Modul 5 — Hero darajasi

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 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:

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 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:

⚠️ 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).

💡 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 va QA 15 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.

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

Asosiy qoida: natija — o'zgargan jarayon bo'lsa QA, natija — mahsulot haqidagi ma'lumot bo'lsa QC/Testing.

</details>

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.).

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

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.

</details>

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 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.

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

To'g'ri ishlayotganlar: 1 va 8. Qolgan 10 tasi — muammo:

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.

</details>

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

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

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.

</details>

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."

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

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.

</details>

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.

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

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.

</details>

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

Manbalar {#manbalar}

1. ISTQB — Certified Tester Foundation Level (CTFL) v4.0
2. ISTQB CTFL Syllabus v4.0.1 (PDF, 2024-09-15)
3. Ariane 501 Inquiry Board report (to'liq matn)
4. ESA — Ariane 501: Presentation of Inquiry Board report
5. Leveson N., Turner C. — An Investigation of the Therac-25 Accidents (IEEE Computer, 1993, PDF)
6. Wikipedia — Therac-25
7. SEC — SEC Charges Knight Capital With Violations of Market Access Rule (2013)
8. SEC — Knight Capital Americas LLC buyrug'i, Release No. 34-70694 (PDF)
9. CrowdStrike — External Technical Root Cause Analysis: Channel File 291 (PDF)
10. Microsoft — Helping our customers through the CrowdStrike outage (2024-07-20)
11. Postman — About plans (2026)
12. Bruno — open source API client
13. Proxyman