Quality Control, qisqacha QC — mahsulot yoki xizmatning belgilangan sifat mezonlariga mosligini tekshirishga qaratilgan faoliyatlar majmuasidir. Dasturiy ta’minotda u build, funksiya, hujjat yoki release natijasidagi nuqsonlarni aniqlash uchun review, test, inspection va o‘lchovlardan foydalanadi. QC natijani tekshiradi; sifatni boshqarishning butun jarayoniga teng emas.
Quality Assurance bilan farqi
Quality Assurance jarayonlarning nuqson paydo bo‘lishini kamaytiradigan tarzda tashkil etilishiga urg‘u beradi. Coding standard, development lifecycle, audit va process improvement QA doirasiga kirishi mumkin. Quality Control esa konkret deliverable ni mezon bilan solishtirib, nuqsonni topadi.
Amaliy jamoada chegaralar kesishadi. Test avtomatlashtirish frameworkini standartlashtirish QA faoliyati, aynan release candidate testini bajarish QC faoliyati sifatida qaralishi mumkin. Atamalardan ko‘ra javobgarlik, mezon va natija aniq bo‘lishi muhim.
Tekshiruv obyektlari
QC faqat ishlayotgan UI ni tekshirmaydi. Talab, dizayn, source code, API contract, database migration, konfiguratsiya va deployment artifact ham inspection obyekti bo‘lishi mumkin. Erta bosqichdagi review noto‘g‘ri talab yoki arxitektura qarorini production testidan oldin topadi.
Static analysis kodni bajarmasdan mumkin bo‘lgan xato va standart buzilishini aniqlaydi. Dynamic test dastur xatti-harakatini kirishlar bilan tekshiradi. Code review mantiq, maintainability va xavfsizlik kontekstini inson tahlili bilan ko‘radi. Bir usul boshqasining barcha nuqson turini qamrab olmaydi.
Mezon va dalil
Tekshiruv acceptance criteria, specification, standard yoki tashkilot thresholdiga tayanadi. “Sifatli ko‘rinadi” subyektiv baho bo‘lib, qayta takrorlanmaydi. Test case boshlang‘ich shart, amal va kutilgan natijani belgilaydi. Performance uchun percentile latency, throughput va error rate kabi o‘lchanadigan mezon ishlatiladi.
Har topilma dalil bilan qayd etiladi: versiya, muhit, takrorlash qadamlari, kutilgan va amaldagi natija. Severity biznes ta’sirini, priority esa qachon tuzatish kerakligini ifodalashi mumkin. Ularni bir xil qiymat deb talqin qilish rejalashtirishni buzadi.
Sampling va risk
Barcha kirish, qurilma va holat kombinatsiyasini tekshirish ko‘pincha imkonsiz. Equivalence partitioning, boundary value va risk-based testing vakil holatlarni tanlaydi. Yuqori moliyaviy, xavfsizlik yoki foydalanish ta’siriga ega qism ko‘proq chuqurlikda tekshiriladi.
Sampling nuqson yo‘qligini isbotlamaydi; berilgan qamrovda topilmaganini bildiradi. Test coverage soni ham sifatning o‘zi emas. 100 foiz line coverage noto‘g‘ri assertion, yetishmayotgan requirement yoki integratsiya muammosini yashirishi mumkin.
Defect lifecycle
Topilgan defect triage qilinadi, egasi belgilanadi, tuzatiladi va qayta tekshiriladi. Fix verification aynan nuqson bartaraf etilganini, regression testing esa o‘zgarish boshqa xatti-harakatni buzmaganini tekshiradi. Duplicate, cannot reproduce va expected behavior kabi yopish sabablari dalil bilan asoslanadi.
Defect leakage productionda topilgan muammolarni ko‘rsatadi, lekin jamoani jazolash metrikasi sifatida ishlatilsa yashirishga rag‘bat beradi. Root cause analysis takrorlanuvchi xato manbasini topib, test, review yoki jarayon nazoratini yaxshilashga xizmat qiladi.
Release qarori
QC hisobotida o‘tgan va yiqilgan testlar, ochiq risklar, ma’lum cheklovlar va tekshirilgan build identifikatori ko‘rsatiladi. Yakuniy release qarori faqat testchilar zimmasiga yuklanmaydi; mahsulot, engineering, security va operatsion manfaatdor tomonlar qoldiq riskni baholaydi.
Test muhiti productionga yetarlicha o‘xshamasa, muvaffaqiyat noto‘g‘ri ishonch berishi mumkin. Artifact aynan tekshirilgan digest bilan release qilinadi; testdan keyin qayta build qilingan noma’lum binary boshqa obyekt hisoblanadi.
Bog‘liq tushunchalar
Quality Assurance, Software testing, Defect, Acceptance criteria, Risk-based testing, Test coverage, Inspection