0%
9-dars

Test darajalari va Regression

Test darajalari — qaysi bosqichda kim, nima test qiladi. Test piramidasi va Regression Testing — professional QA uchun asosiy tushunchalar.

90 daqiqa
Darajalar va strategiya
6 ta interaktiv topshiriq
Kirish

Nega test darajalari kerak?

Tasavvur qiling: siz 100 qavatli bino quryapsiz. Har qavatda bir xil tarzda tekshirasizmi? Albatta yo'q. Poydevorni — muhandislar, xonalarni — sozlovchilar, umumiy ko'rinishni — arxitektor tekshiradi.

Dasturlashda ham shunday. Kichik qismlarni dasturchilar, modullar orasidagi bog'liqlikni senior dasturchilar, butun tizimni QA'lar, yakuniy qabul qilishni biznes tomoni sinaydi.

Bu darsda 4 ta test darajasini, ular orasidagi balansni (Test Piramidasi) va Regression Testing'ni ko'rib chiqamiz.

1-qism

4 ta asosiy test darajasi

Har bir test darajasi boshqacha maqsadga xizmat qiladi. Ularning har biri kim tomonidan, qachon va qanday asboblar bilan bajariladi — bilish kerak.

1
Component Testing
UNIT TESTING
Dasturning eng kichik qismi — bitta funksiya yoki metod testlanadi. Maqsad: kodning har birligi alohida to'g'ri ishlayotganini ta'minlash.
Kim qiladi
Dasturchilar
Qachon
Kod yozayotganda
Asboblar
JUnit, Jest, pytest
Misol: Calculator ilovasida qo'shish(2, 3) funksiyasi 5 qaytarayaptimi? Agar ha — test Pass, agar yo'q — Fail. Foydalanuvchi bu testni ko'rmaydi, bu faqat kod darajasida.
2
Integration Testing
INTEGRATSIYA TESTLASH
Modullar yoki qismlar o'zaro bog'lanib ishlayaptimi tekshiriladi. Ikki yoki undan ko'p komponent birga to'g'ri ishlayaptimi?
Kim qiladi
Dasturchilar + QA
Qachon
Component'lar tayyor bo'lganda
Asboblar
Postman, REST Assured
Misol: Login sahifasi (Frontend) → Server (Backend) → Database. Frontend'ga email/parol kiritiladi, backend'ga yuboriladi, database'dan tekshiriladi. 3 ta komponent birga ishlayaptimi? — integration test.
3
System Testing
TIZIM TESTLASHI
Butun tizim to'liq yig'ilgan holda testlash. Foydalanuvchi kabi tizimni ishlatib ko'rish — boshdan oxirigacha senariylar.
Kim qiladi
QA'lar (sizning asosiy ishingiz!)
Qachon
Butun tizim tayyor bo'lganda
Asboblar
Selenium, Playwright, manual
Misol: Uzum Market'da: foydalanuvchi ro'yxatdan o'tadi → login qiladi → mahsulot qidiradi → savatga qo'shadi → to'lov qiladi → xarid tasdiqlangan xabarni oladi. Butun bu jarayonni QA sinab ko'radi.
4
Acceptance Testing
QABUL TESTLASHI (UAT)
Biznes tomon yoki haqiqiy foydalanuvchi mahsulotni qabul qilish uchun tekshiradi. "Bu mening talablarimga javob beryaptimi?" savoliga javob.
Kim qiladi
Product Owner, Mijoz
Qachon
System Testing tugagandan so'ng
Asboblar
Manual, real ma'lumotlar
Misol: Click'ning mijozi (bank) tizimni o'zlari sinab ko'radi: "Pul o'tkazish bizning real shartnomalarga mos keladimi?". Agar ha — tizim production'ga chiqadi.
💡 Hayotiy misol
Pizza pishirish jarayoni
Component: Har ingredient alohida yaxshimi? (xamir, sos, pishloq) · Integration: Ular birga qo'shilganda mos keladimi? · System: Pishirilgan pizza yaxlit holda yaxshimi? · Acceptance: Mijoz ta'mi yoqadimi, buyurtmasiga mos keladimi?
🎯 Amaliy topshiriq

Test darajalarini tartibga qo'ying

Darajalarni pastdan yuqoriga (boshlanishdan yakunigacha) tartibda sudrab joylashtiring.

1-daraja
2-daraja
3-daraja
4-daraja
System Testing
Component Testing
Acceptance Testing
Integration Testing
0 / 4 to'g'ri
🎯 Bog'lang

Test darajasi va uni kim bajaradi

Chap tomonda darajani tanlang, o'ngdan kim bajarishini bog'lang.

Test darajasi

Component Testing
Integration Testing
System Testing
Acceptance Testing

Kim bajaradi

Product Owner yoki Mijoz
QA (sizning asosiy ishingiz)
Dasturchilar (o'zlari yozgan kod uchun)
Dasturchi + QA birga
0 / 4 juft topildi
2-qism

Test Piramidasi

Asosiy atama

Test Piramidasi — test darajalari orasida qancha test bo'lishi kerakligi haqidagi nazariya. Mike Cohn tomonidan taklif qilingan.

Asosiy g'oya: Ko'p sonli kichik (tez) testlar pastda, kam sonli katta (sekin) testlar yuqorida.

Piramidaning ideal ko'rinishi

Yuqorida UI / E2E Tests ~10%
3-daraja System Tests ~15%
2-daraja Integration Tests ~25%
1-daraja (eng pasti) Unit / Component Tests ~50%
↑ Tez, arzon, ko'p miqdor = pastda · Sekin, qimmat, kam miqdor = yuqorida ↓

Nega bunday proporsiya?

Pastdagi testlar (Unit)

Afzalliklari: Juda tez bajariladi (millisekunddalarda), arzon yozish, ishonchli. Shuning uchun ko'p miqdor yozish mumkin va kerak.

Yuqoridagi testlar (E2E)

Kamchiliklari: Sekin (minutlarda), qimmat, ba'zida "flaky" (bir xil natija bermaydi). Shuning uchun kam, faqat eng muhim sahnalar uchun.

Amaliy xulosa

Agar sizning loyihangizda 1000 ta Unit test va 10 ta E2E test bo'lsa — bu sog'lom piramida. Agar 100 ta Unit va 500 ta E2E — bu muammo (Ice Cream Cone).

Anti-pattern: Ice Cream Cone (muzqaymoq konus)

Ba'zi loyihalarda piramida teskari bo'ladi — ko'p E2E testlar, kam Unit testlar. Bu yomon holat:

⚠️ Ice Cream Cone Anti-Pattern
Manual Testing ~40%
E2E / UI Tests ~30%
Integration ~20%
Unit ~10%
Bu holat sekin, qimmat va nazorat qilish qiyin!
💡 Hayotiy misol
Poydevor va tom
Bino qurayotganingizda kuchli poydevor va yengil tom kerak. Agar poydevor zaif, tom og'ir bo'lsa — bino yiqiladi. Xuddi shunday testlarda ham — ko'p Unit test va kam E2E test — bu kuchli strategiya.
3-qism

Regression Testing

Asosiy atama

Regression Testing — dasturga yangi o'zgarish kiritilgandan so'ng, eski funksiyalar ishlayaptimini tekshirish.

Oddiy qilib: yangi feature qo'shildi — qolgan narsalar yana ishlayaptimi? Regression Testing aynan shuni tekshiradi.

Nima uchun kerak?

Real misol

Uzum Market'da yangi "Chegirma kodi" funksiyasi qo'shildi. Dasturchi kodni yozdi, yangi funksiya ishlayapti. Lekin... endi savat ham ishlamay qoldi! Chunki yangi kod eski savat kodiga ta'sir qilgan. Bu holatni oldini olish uchun — Regression Testing.

Qachon bajariladi?

Manual vs Automation

Regression Testing juda ko'p marta takrorlanadigan ish. Shuning uchun u avtomatlashtirish uchun ideal. Keling qaraymiz:

Manual Regression

Yangi jamoalarda yoki kichik loyihalarda ishlatiladi.

  • Asosiy senariylar qo'lda tekshiriladi
  • Har release oldidan 1-2 kun ketadi
  • Inson xatosi bo'lishi mumkin
  • Yangi boshlovchilar uchun yaxshi

Automation Regression

Katta loyihalarda albatta kerak.

  • Yuzlab testlar 30 daqiqada
  • Har night'da avtomatik ishga tushadi
  • Bug'larni darhol topadi
  • Senior QA yoki SDET yozadi

Smoke Testing vs Regression Testing

Bu ikkala atamani ko'pchilik aralashtirib yuboradi. Intervyu'da so'raydi.

Smoke Testing

Smoke — "ishlayaptimi umuman?" degan savolga javob. Eng asosiy funksiyalar ishlayaptimi? 15-30 daqiqalik tez tekshiruv.

Misol: Sayt ochilayaptimi? Login ishlayaptimi? Bosh sahifa chiqayaptimi? Agar ha — keyingi testlarga o'tamiz.

Regression Testing

Regression — "eski narsalar yana ishlayaptimi?" degan savolga javob. Chuqurroq, batafsilroq tekshiruv. Bir necha soatdan bir necha kungacha.

Misol: Barcha eski funksiyalarni bir-bir tekshirish. Login, ro'yxatdan o'tish, savat, to'lov, profil... hammasini.

Oddiy farqlash

Smoke = tez, yuzaki ("ishlayaptimi?") · Regression = sekin, chuqur ("to'liq ishlayaptimi?")

🎯 Bug classifier

Bug qaysi test darajasida topilishi kerak?

Har bir bug'ni o'qing va ideal holda qaysi darajada topilishi kerakligini tanlang.

Qo'shish funksiyasi noto'g'ri natija qaytarmoqda
calculator.add(2, 3) = 6 qaytaryapti, 5 o'rniga. Bu faqat bitta funksiyaga tegishli.
Frontend'dan ma'lumot Backend'ga yetib bormaydi
Forma to'ldiriladi, lekin server xato qaytaradi — ikki komponent orasidagi bog'liqlik buzilgan.
Mobil versiyada "Savatga qo'shish" tugmasi ko'rinmaydi
Butun tizim ishlayapti, lekin UI muammosi foydalanuvchi tajribasiga ta'sir qiladi.
Mijoz: "Bu bizning brend ranglarga mos kelmaydi"
Texnik jihatdan hammasi to'g'ri ishlayapti, lekin biznes talablariga to'liq mos emas.
Component / Unit
Integration
System
Acceptance
0 / 4 to'g'ri
🎬 Haqiqiy stsenariy
Payme'da yangi feature qo'shildi

Juma, 14:00. Payme jamoasi yangi funksiya qo'shdi — "Do'stga pul yuborish". Dasturchilar kodni yozdi, test server'ga joyladi.

Sizning vazifangiz: Testorsiz. Bu yangi funksiyani test qilish kerak, lekin yana nima tekshirasiz?

Eng to'g'ri strategiya qaysi?
⚡ Tezkor tekshiruv
Sog'lom Test Piramida'da qaysi test ko'proq bo'lishi kerak?
🎯 Amaliyot vaqti

TestShop'da test darajalarini qo'llash

Endi nazariyani TestShop'da amaliy sinab ko'ramiz. Har bir test darajasi uchun konkret vazifalar bor.

🛒

TestShop — Test darajalari amaliyoti

System Testing va Regression Testing'ni amaliy bajaring.

🚀 TestShop'ga o'tish

Sizning 3 bosqichli vazifangiz:

1
System Testing — End-to-End senariy
Foydalanuvchi sifatida to'liq senariyni bajaring: Ro'yxatdan o'ting → Login qiling → Mahsulot tanlang → Savatga qo'shing → Checkout'ga boring. Har bosqichda nima ishlayapti, nima yo'q? Hisobot tuzing.
2
Regression Test Suite tuzing
Tasavvur qiling: TestShop'da yangi funksiya qo'shildi. Qaysi 10 ta eski funksiyani albatta qayta sinash kerak? Google Sheets'da Regression Test Suite ro'yxatini tuzing.
3
Smoke Test ro'yxatini tuzing
Har ertalabki 15 daqiqali Smoke Test uchun 5 ta eng muhim tekshiruvni aniqlang. Masalan: sayt ochilayaptimi, login ishlayaptimi, bosh sahifa chiqayaptimi va hokazo.
💡 Pro maslahat

Tuzilgan Regression va Smoke Test ro'yxatlaringizni saqlang. Intervyu'da: "Siz qanday Regression strategiyasi yaratasiz?" degan savolga konkret misol bilan javob bera olasiz. Bu sizni boshqa nomzodlardan ustun qiladi.

Intervyuga tayyorlov

Intervyu savollari

Test darajalari va Regression — intervyu'da eng ko'p so'raladigan mavzular. Javoblarni puxta o'rganing.

💡 Har savol ustiga bosing — professional javobni ko'rasiz.

Q1 Test darajalarini sanab bering va kim bajarishini ayting. +

Javob: "4 ta asosiy test darajasi bor:"

  • Component/Unit Testing — Dasturchilar bajaradi. Eng kichik qism — bir funksiya.
  • Integration Testing — Dasturchi + QA. Modullar o'zaro ishlayaptimi.
  • System Testing — QA'lar bajaradi. Butun tizim end-to-end.
  • Acceptance Testing — Product Owner yoki mijoz. Biznes talablar bajarilganmi.

Muhim: "Men aynan System Testingda ishlayman — bu QA'ning asosiy sohasi."

Q2 Test Piramidasi nima va u nima uchun muhim? +

Javob: "Test Piramidasi — test darajalari orasida balans haqidagi nazariya. Ko'p Unit, o'rtacha Integration, kam E2E."

Nima uchun?

  • Unit testlar tez (millisekund) va arzon
  • E2E testlar sekin (minut) va qimmat
  • Ko'p arzon test = tez feedback = pul tejash

Anti-pattern: Ice Cream Cone — ko'p E2E, kam Unit. Bu yomon — tez natija yo'q.

Q3 Regression Testing nima? Qachon bajariladi? +

Javob: "Regression Testing — dasturga yangi o'zgarish kiritilgandan so'ng, eski funksiyalar buzilmaganligini tekshirish."

Qachon bajariladi:

  • Yangi funksiya qo'shilganda
  • Bug tuzatilgandan so'ng
  • Har release'dan oldin
  • Konfiguratsiya o'zgarganda

Pro javob: "Katta loyihalarda Regression Testing avtomatlashtirilishi kerak — chunki u har safar takrorlanadi. Manual qilish ko'p vaqt oladi."

Q4 Smoke Testing va Regression Testing farqi? +

Javob:

  • Smoke Testing — "ishlayaptimi umuman?". Eng asosiy funksiyalar (login, bosh sahifa). 15-30 daqiqa.
  • Regression Testing — "barcha eski funksiyalar ishlayaptimi?". Chuqur, batafsil. Soatlar yoki kunlar.

Ketma-ketlik: "Build kelsa, avval Smoke qilamiz. Agar smoke o'tsa — keyin Regressionga o'tamiz. Smoke Fail bo'lsa — Regression'ga o'tmaymiz, build'ni qaytaramiz."

Q5 Unit Testing bilan Integration Testing farqi? +

Javob:

  • Unit Testing — bitta komponent (masalan, bir funksiya) alohida test qilinadi. Boshqalardan ajratilgan.
  • Integration Testing — 2 yoki undan ko'p komponent birga ishlayaptimi tekshiriladi.

Misol:

  • Unit: add(2, 3) = 5 — bitta funksiya
  • Integration: Login formasidan yuborilgan ma'lumot → server → database'ga yetib borayaptimi — 3 ta komponent birga
Q6 Siz qaysi test darajasida ko'proq ishlaysiz? +

Javob shabloni: "Men asosan System Testingda ishlayman — bu QA'ning asosiy sohasi. Butun tizimni end-to-end sinab ko'raman."

Qo'shimcha:

  • Integration Testingda ham qatnashaman — API testing uchun (Postman)
  • Acceptance Testingda PO bilan birga ishlayman
  • Unit Testing bilan to'g'ridan-to'g'ri ishlamayman — bu dasturchilarning sohasi

Pro javob: "Lekin Unit test natijalarini ko'rib boraman — agar unit test'larda muammo bo'lsa, bu kelgusida System darajasida ham chiqadi."

Q7 Acceptance Testing'da QA qanday vazifa bajaradi? +

Javob: "Acceptance Testing'ni asosan Product Owner yoki mijoz bajaradi. Lekin QA:"

  • UAT muhitini tayyorlashda yordam beradi
  • Test ma'lumotlarini tayyorlaydi
  • PO'ga test senariylar tushuntiradi
  • UAT paytida topilgan bug'larni qabul qilib, developer'larga yuboradi
  • Tuzatilgan bug'larni qayta tekshiradi

Muhim: "UAT — QA'ning qaror qabul qilish sohasi emas. QA biznes emas, texnik mutaxassis."

Yakuniy

3 ta asosiy fikr

Bu darsdan eslab qolish kerak bo'lgan eng muhim g'oyalar

01
4 ta test darajasi
Component → Integration → System → Acceptance. Har biri boshqa maqsad va ishchi.
02
Test Piramidasi — balans
Ko'p Unit (pastda), kam E2E (yuqorida). Ice Cream Cone — anti-pattern.
03
Regression — eski ham ishlashi kerak
Har yangilanishdan keyin eski funksiyalarni tekshirish. Automation uchun ideal.
← Oldingi dars
8-dars · 7 prinsip
Keyingi dars →
10-dars · Test turlari
🏆 Darsni muvaffaqiyatli tugatdingiz!