QA — dasturiy mahsulot va uni yaratish jarayonida sifatni rejalashtirish, ta’minlash, o‘lchash va yaxshilash faoliyatlari majmuasi. To‘liq nomi Quality Assurance. QA faqat tayyor application ichidan bug topish emas; requirement, development, test, release va production kuzatuvini qamrab oladi.
Sifat mahsulotning to‘g‘ri ishlashi bilan birga ishonchlilik, xavfsizlik, foydalanish qulayligi, unumdorlik va maintainability’ni ham o‘z ichiga olishi mumkin.
QA va QC
Quality Assurance jarayonning sifatli tashkil etilishiga urg‘u beradi.
Quality Control tayyor natijani tekshirish va nuqsonlarni aniqlashga yaqin.
Amaliy jamoalarda terminlar aralash ishlatilishi mumkin.
QA prevention, QC detection tamoyiliga yaqin.
Testlash bilan farqi
Software testing QAning muhim qismi, ammo yagona qismi emas.
QA quyidagilarni ham qamrab oladi:
- requirement review;
- process;
- coding standard;
- risk analysis;
- automation strategy;
- release criteria;
- incident learning;
- metric;
- training.
Faqat testerga sifat javobgarligini yuklash noto‘g‘ri.
Sifat atributlari
Mahsulot sifati turli xususiyatlardan tashkil topadi:
- functional correctness;
- reliability;
- performance;
- security;
- usability;
- accessibility;
- compatibility;
- maintainability;
- portability.
Har loyiha uchun ustuvorlik boshqacha.
Bank va media saytining risk profili bir xil emas.
Requirement sifati
Noaniq yoki qarama-qarshi requirement keyin bugga aylanadi.
QA requirementni tekshiradi:
- o‘lchanadimi;
- test qilinadimi;
- terminlar aniqmi;
- boundary bormi;
- error holati yozilganmi;
- permission tushunarlimi.
Erta aniqlangan muammo arzonroq tuzatiladi.
Test strategiyasi
Test strategiyasi:
- qaysi risklar;
- qaysi test darajalari;
- automation ulushi;
- environment;
- data;
- browser va device;
- release gate;
- responsibility
ni belgilaydi.
Har feature uchun bir xil test to‘plami shart emas.
Risk-based testing
Vaqt cheklangan bo‘lsa testlar risk bo‘yicha ustuvorlashtiriladi.
Risk taxminan:
ehtimol × ta’sir
bilan baholanishi mumkin.
Payment, authentication va data loss yuqori riskli.
Kam ishlatiladigan bezak elementi pastroq riskli bo‘lishi mumkin.
Shift-left
Sifat faoliyatlarini developmentning oldingi bosqichlariga ko‘chirish.
Misollar:
Maqsad bugni productionga yaqin bosqichda emas, erta topish.
Shift-right
Productiondagi sifat signalidan foydalanish:
- monitoring;
- canary;
- feature flag;
- synthetic check;
- real-user metric;
- incident;
- rollback.
Bu testing o‘rnini bosmaydi.
Production murakkabligi faqat real trafficda ko‘rinishi mumkin.
Test darajalari
QA balansni boshqaradi:
- unit;
- component;
- integration;
- contract;
- E2E;
- UAT;
- exploratory;
- non-functional.
Faqat E2Ega tayanish sekin va flaky suite yaratadi.
Faqat unit test esa integration xatolarini qoldiradi.
Functional test
Feature requirementga mos ishlashini tekshiradi.
Happy path, negative, boundary va permission holatlari qamrab olinadi.
Functional test “nima qiladi?” degan savolga javob beradi.
Non-functional test
Tizim qanday sifatda ishlashini tekshiradi:
- load;
- stress;
- security;
- accessibility;
- recovery;
- compatibility;
- localization;
- usability.
Feature to‘g‘ri, ammo juda sekin bo‘lsa ham sifat muammosi mavjud.
Exploratory testing
Tester oldindan qat’iy script bilan cheklanmay, mahsulotni o‘rganib, hypothesis va risk asosida tekshiradi.
Session maqsad va vaqt bilan boshqariladi.
Topilmalar, coverage va savollar yozib boriladi.
Automation kutilmagan behaviorni izlashni to‘liq almashtirmaydi.
Defect lifecycle
Bug:
- aniqlanadi;
- qayta takrorlanadi;
- yoziladi;
- severity va priority oladi;
- tuzatiladi;
- retest;
- yopiladi yoki qayta ochiladi.
Bug report aniq environment, qadam, expected, actual va evidence’ga ega.
Severity va priority
Severity texnik yoki user ta’sirini ko‘rsatadi.
Priority qachon tuzatish kerakligini bildiradi.
Kichik visual xato marketing launch oldidan yuqori priority bo‘lishi mumkin.
Kritik, ammo faqat foydalanilmaydigan legacy feature’dagi bug boshqa reja olishi mumkin.
Automation
Automation qayta-qayta bajariladigan stabil testlarda foydali.
Tanlash mezonlari:
- business ahamiyati;
- takrorlanish;
- barqarorlik;
- manual xarajat;
- data;
- maintenance.
Hamma manual testni automation qilish maqsad emas.
Quality gate
Pipeline release oldidan shartlarni tekshiradi:
- testlar;
- coverage;
- security scan;
- performance budget;
- lint;
- artifact signature;
- approval.
Gate juda ko‘p false positive bersa jamoa uni chetlab o‘tishga intiladi.
Metric
QA metriclari:
- escaped defect;
- defect trend;
- test pass rate;
- flaky rate;
- mean time to detect;
- mean time to recover;
- incident;
- coverage;
- customer complaint.
Faqat bug soni tester yoki developer sifatini adolatli o‘lchamaydi.
Root cause analysis
Production bugdan keyin faqat kim xato qilganini emas, tizim nega uni erta topmaganini o‘rganiladi.
Savollar:
- requirement noaniqmi;
- test yo‘qmi;
- review yetishmadimi;
- monitoring ko‘rmadimi;
- rollout katta bo‘ldimi.
Natija process improvementga aylanadi.
Sifat javobgarligi
QA mutaxassisi sifatni boshqarishga yordam beradi, ammo butun jamoa javobgar.
Developer testable kod, product aniq talab, DevOps barqaror environment, designer accessibilityga hissa qo‘shadi.
“QA keyin tekshiradi” modeli kech feedback beradi.
Test environment boshqaruvi
Environment versiyasi, configuration va test data aniq bo‘lmasa bir xil build turli natija beradi. QA environment driftni kuzatadi va kerakli service dependencylarini hujjatlashtiradi.
Quality risk
Yangi feature faqat functional bug emas, privacy, localization, migration va operatsion risk olib kelishi mumkin. QA review checklistni loyiha kontekstiga moslashtiradi.
Continuous improvement
Sprint yoki incidentdan keyin flaky test, kech topilgan bug va sekin pipeline sababi tahlil qilinadi. Jarayon kichik o‘lchanadigan o‘zgarishlar bilan yaxshilanadi.
Bog‘liq tushunchalar
Quality Assurance, Quality Control, Software testing, Test strategy, Risk-based testing, Shift-left, Shift-right, Defect lifecycle, Quality gate, Exploratory testing