0%
6-dars

Whole Team Approach va TDD/ATDD/BDD

Zamonaviy IT jamoalari qanday ishlaydi? Test birinchi, kod keyinmi? BDD nima va Given-When-Then sintaksisi qanday? Sodda misollar bilan o'rganamiz.

75 daqiqa
Zamonaviy metodologiyalar
6 ta interaktiv topshiriq
Kirish

Zamonaviy yondashuv

5-darsda siz IT jamoasidagi rollarni o'rgandingiz. Endi savol: bu odamlar qanday hamkorlik qiladi? Testor faqat oxirida bug topadimi yoki boshidanoq qatnashadimi?

Zamonaviy yondashuvda javob aniq: butun jamoa birga ishlaydi. Bu darsda 4 ta muhim tushunchani ko'rib chiqamiz: Whole Team Approach, TDD, ATDD va BDD. Barchasi — bugungi IT dunyosining asosiy praktikalari.

Bu darsdan keyin siz intervyuda bu atamalarni bemalol ishlata olasiz va "BDD ssenariysi" deb sizdan so'rashganda — aniq javob bera olasiz.

1-qism

Whole Team Approach

Asosiy atama

Whole Team Approach (Butun Jamoa Yondashuvi) — sifat uchun faqat testor emas, butun jamoa mas'ul bo'ladi degan falsafa.

Oddiy qilib: dasturchi ham sifatni o'ylaydi, dizayner ham, biznes analitik ham. Testor yolg'iz "sifat qo'riqchisi" emas — u jamoaning bir qismi.

Eski va yangi yondashuvlar

Eski (Siloed)

Har bir mutaxassis o'z ishini alohida qiladi.

  • Dasturchi kod yozadi — bu uning ishi
  • Testor bug topadi — bu uning ishi
  • Dizayner rasm chizadi — bu uning ishi
  • Bir-birini kutadilar (sekin)
  • "Meniki emas" deyish tez-tez

Yangi (Whole Team)

Butun jamoa birga ishlaydi, sifat umumiy mas'uliyat.

  • Hamma sifatni o'ylaydi (dasturchi ham)
  • Testor boshidanoq qatnashadi
  • 3 Amigos — PO, Dev, QA birga
  • Tezroq natija
  • "Biz birga yaratamiz"

"3 Amigos" meetings

Whole Team yondashuvining eng muhim amaliyoti — 3 Amigos meeting (3 do'st uchrashuvi). Bu — PO, Developer, QA birga o'tiradigan qisqa yig'ilish.

3 Amigos — har biri o'z savolini beradi

PO
Product Owner
"Biznes uchun bu nima foyda?"
D
Developer
"Buni qanday yaratsam bo'ladi?"
QA
QA / Testor
"Qanday buzishim mumkin?"

Uchta nuqtai nazar birga = har bir funksiya to'liq o'ylangan

Real misol: 3 Amigos meeting

Mavzu: "Foydalanuvchi parolni tiklashi mumkin"

PO: "Foydalanuvchi parolini unutsa — email orqali tiklay oladi. Bu oddiy narsa."

Developer: "OK, email yuborish 5 daqiqa vaqt oladi. Kod yozish 2 soat."

QA: "Bir daqiqa — agar email mavjud bo'lmasa nima bo'ladi? Noto'g'ri email kiritilsa? SMS orqali ham bo'ladimi? Qancha vaqt email ishlaydi? Havola 1 marta ishlatiladimi yoki qayta-qayta?"

Natija: 5 ta muhim savol ochildi. Agar QA bu yig'ilishda bo'lmaganda — keyin bug topar edi va kodni qayta yozish kerak bo'lar edi.

Amaliy xulosa

3 Amigos meeting 15-30 daqiqa oladi, lekin keyinchalik soatlik ishlarni tejaydi. Sifat meeting'idan boshlanadi, kod yozishdan emas.

2-qism

TDD — Test Driven Development

Asosiy atama

TDD (Test Driven Development) — avval test yoziladi, keyin kod. Test birinchi!

Oddiy qilib: dasturchi awal "bu kod qanday ishlashi kerak" degan testni yozadi, keyin shu testga mos kod yozadi.

Red-Green-Refactor sikli

TDD doimiy 3 bosqichli sikl orqali ishlaydi. Har yangi funksiya shu bosqichlardan o'tadi:

01
RED
Test yozing. U ishlamaydi (chunki kod yo'q)
→
02
GREEN
Minimal kod yozing — test o'tsin
→
03
REFACTOR
Kodni yaxshilang — test baribir o'tsin
↻ Sikl takrorlanadi: har yangi xususiyat uchun qaytadan Red → Green → Refactor

Sodda misol: Kalkulyator

Tasavvur qiling, dasturchi qo'shish(a, b) funksiyasini yozmoqchi. TDD bo'yicha qanday ishlaydi:

🔴 1-qadam: RED

Dasturchi test yozadi:

test('qo\'shish(2, 3) = 5 bo\'lishi kerak', () => {
  assert(qoshish(2, 3) === 5);
});

Natija: ❌ Test Fail (chunki qoshish funksiyasi hali yo'q)

🟢 2-qadam: GREEN

Dasturchi eng oddiy kod yozadi:

function qoshish(a, b) {
  return a + b;
}

Natija: ✅ Test Pass

🔧 3-qadam: REFACTOR

Kod allaqachon yaxshi yozilgan — hech narsa o'zgartirmaymiz. Agar murakkabroq bo'lganida, bu bosqichda kodni tozalash mumkin edi. Test baribir Pass bo'lishi kerak.

TDD'da QA roli nima?

TDD asosan dasturchilar qiladigan ish. Lekin QA ham muhim:

💡 Hayotiy misol
Uy qurish — avval reja chizing
Siz uy qurmoqchisiz. Normal odam avval chizma chizadi ("5 xonali, oshxona shu yerda"), keyin qurishga kirishadi. Hech kim g'ishtni birinchi qo'yib, keyin "qanday uy bo'ladi?" deb o'ylamaydi. TDD ham shunday — avval "qanday ishlashi kerak" (test), keyin "qanday ishlaydi" (kod).
🎯 Amaliy topshiriq

TDD siklini tartibga qo'ying

TDD ning 3 bosqichini to'g'ri tartibda joylashtiring.

1-qadam
2-qadam
3-qadam
🟢 GREEN — kod yozish, test o'tsin
🔴 RED — test yozish (u ishlamaydi)
🔧 REFACTOR — kodni yaxshilash
0 / 3 to'g'ri
3-qism

ATDD — Acceptance Test Driven Development

Asosiy atama

ATDD (Acceptance Test Driven Development) — TDD ning biznes versiyasi. Avval Acceptance Criteria (qabul shartlari) yoziladi, keyin shu asosda dasturlash boshlanadi.

Oddiy qilib: "Bu funksiya qachon tayyor deb hisoblanadi?" savoliga oldindan aniq javob bermiladi.

ATDD qanday ishlaydi?

ATDD
Acceptance Criteria bilan boshlanadi
Acceptance Criteria — bu shartlar ro'yxati. Funksiya "tayyor" deb hisoblanishi uchun har bir shart bajarilishi kerak.

Sodda misol: Login funksiyasi

Tasavvur qiling, siz yangi login sahifasi yaratmoqchisiz. ATDD bo'yicha avval qabul shartlari yoziladi:

User Story

Foydalanuvchi sifatida men email va parol orqali tizimga kirmoqchiman, shunda o'z akkountimdagi ma'lumotlarni ko'ra olaman.

Acceptance Criteria (qabul shartlari)
  1. Email va parol maydonlari bo'lishi kerak
  2. Ikkisi ham majburiy — bo'sh bo'lsa xato xabari chiqsin
  3. To'g'ri ma'lumotlar bilan — foydalanuvchi Dashboard sahifasiga o'tadi
  4. Noto'g'ri parol bilan — "Email yoki parol noto'g'ri" xabari chiqsin
  5. 3 marta noto'g'ri urinishda — akkount 5 daqiqa bloklansin
  6. "Parolni unutdim" havolasi bo'lishi kerak
Muhim

Bu shartlar 3 Amigos meetingda tuziladi — PO, Dev, QA birga. Dasturchi faqat shulardan keyin kod yozishni boshlaydi. Testor esa shu shartlar asosida test case'lar yozadi.

ATDD'ning afzalliklari

4-qism

BDD — Behavior Driven Development

Asosiy atama

BDD (Behavior Driven Development) — mahsulotning xatti-harakati (behavior) asosida test yozish uslubi. Oddiy tilda yoziladi — hamma tushunadi.

Oddiy qilib: ATDD'ning zamonaviy versiyasi. Acceptance Criteria'lar maxsus formatda (Given-When-Then) yoziladi.

Given-When-Then — BDD'ning 3 so'zi

BDD'da har bir ssenariy 3 qismdan iborat bo'ladi:

Sodda misol: Login BDD ssenariysi

Endi yuqoridagi Login Acceptance Criteria'larni BDD formatida yozamiz:

# Login funksiyasi Feature: Foydalanuvchi tizimga kirishi Scenario: Muvaffaqiyatli login Given men login sahifasidaman And to'g'ri akkount ma'lumotlarim bor When men email va parolni kiritaman And "Kirish" tugmasini bosaman Then men Dashboard sahifasiga o'taman Scenario: Noto'g'ri parol Given men login sahifasidaman When men email va noto'g'ri parolni kiritaman And "Kirish" tugmasini bosaman Then men "Email yoki parol noto'g'ri" xabarini ko'raman And men login sahifasida qolaman
E'tibor bering

Bu matn texnik emas — Product Owner ham, biznes direktor ham tushuna oladi. Lekin bu haqiqiy test — Cucumber kabi asboblar orqali avtomatik bajariladi.

Gherkin syntax — BDD tili

Gherkin — bu BDD ssenariylari yoziladigan "til". Yuqoridagi misol Gherkin'da yozilgan. Asosiy kalit so'zlar:

BDD asboblari

Gherkin ssenariylarini bajarib beradigan asboblar:

Cucumber
Eng mashhur BDD asbobi
Java, JavaScript, Ruby tillarida ishlatiladi. Click, Uzum kabi kompaniyalarda ham uchraydi.
SpecFlow
.NET uchun Cucumber
Microsoft texnologiyalari (C#) bilan ishlaydigan kompaniyalarda ishlatiladi.
Behave
Python uchun
Python dasturchilari uchun BDD asbobi. Sodda va o'rganishi oson.
Junior uchun

Hozir bu asboblarni chuqur o'rganish shart emas. Lekin Gherkin sintaksisni bilish va BDD ssenariysi yoza olish — bu Junior QA uchun katta afzallik.

🎯 Bog'lang

Metodologiya va uning asosiy savoli

Har bir metodologiyani uning asosiy savoli bilan bog'lang.

Metodologiya

Whole Team Approach
TDD
ATDD
BDD
Given-When-Then

Asosiy savoli / tavsifi

Mahsulot xatti-harakatini tasvirlash
Sifat — hamma uchun umumiy mas'uliyat
BDD ssenariysining 3 qismi
Avval test, keyin kod
Acceptance Criteria birinchi
0 / 5 juft topildi
⚡ BDD ssenariy
TestShop uchun BDD ssenariysi tuzing: "Foydalanuvchi savatga mahsulot qo'shadi". Qaysi variant to'g'ri?
🎬 Haqiqiy stsenariy
Uzum'da yangi feature

Dushanba, 10:00. Siz Uzum Market'da QA'siz. 3 Amigos meetingga keldingiz. Mavzu: "Chegirma kodi" funksiyasi.

PO: "Foydalanuvchi checkout'da chegirma kodini kiritib, pul tejay olsin."

Developer: "OK, oddiy narsa. 1 kunda yozib bo'laman."

Savol: Siz QA sifatida qaysi savollarni berishingiz kerak?

Eng professional yondashuv qaysi?
🎯 Amaliyot vaqti

TestShop uchun BDD ssenariylari yozing

Endi amaliyotga. TestShop uchun 3 ta BDD ssenariysini yozasiz. Bu sizning portfolio'ingiz uchun zo'r material bo'ladi.

🛒

TestShop — BDD amaliyoti

Gherkin syntax bilan 3 ta professional ssenariy yozing.

🚀 TestShop'ga o'tish

Sizning vazifangiz: 3 ta BDD ssenariy

1
Muvaffaqiyatli ro'yxatdan o'tish
Given-When-Then formatida yozing. Kamida 3 ta Given va 2 ta Then bo'lsin.
2
Noto'g'ri login bilan kirish urinishi
Negative scenario — xatolik holatini qoplang. "Email yoki parol noto'g'ri" xabari chiqishi kerak.
3
Savatga mahsulot qo'shish va badge yangilash
Feature + Scenario + Given/When/Then'lar. Natija: savat badge'i +1.
💡 Pro maslahat

Ssenariylarni Google Docs'da yoki oddiy feature.txt faylida saqlang. Intervyuda "BDD ssenariy yoza olasizmi?" deb so'rashganda — darhol ko'rsatasiz. Bu Middle darajasi uchun ham katta afzallik.

Intervyuga tayyorlov

Intervyu savollari

TDD, ATDD, BDD — zamonaviy intervyularning eng ko'p so'raladigan mavzularidan. Javoblarni puxta o'rganing.

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

Q1 Whole Team Approach nima? Nega muhim? +

Javob: "Whole Team Approach — sifat uchun faqat testor emas, butun jamoa mas'ul bo'ladi degan falsafa. Dasturchi ham, dizayner ham, PO ham sifatni o'ylaydi."

Nega muhim?

  • Bug'lar ertaroq topiladi (arzon tuzatiladi)
  • Hamma "meniki emas" deyishdan voz kechadi
  • Jamoa birdamligi oshadi
  • Mahsulot sifati yaxshi bo'ladi

Amaliy yondashuv: "Men 3 Amigos meetingda doim qatnashaman — talablar aniqlashdan oldin savollar beraman."

Q2 TDD, ATDD va BDD farqini tushuntiring. +

Javob:

  • TDD (Test Driven Development) — texnik yondashuv. Avval Unit test, keyin kod. Red-Green-Refactor sikli. Asosan dasturchilar uchun.
  • ATDD (Acceptance Test Driven) — biznes yondashuv. Avval Acceptance Criteria, keyin kod. 3 Amigos birga yozadi.
  • BDD (Behavior Driven Development) — ATDD ning zamonaviy versiyasi. Given-When-Then formatida yoziladi. Biznes va texnik odamlar birga ishlashadi.

Qaysi biri qachon?

  • TDD — Unit testlar uchun (dasturchi)
  • ATDD — biznes talablar aniq emas holatda
  • BDD — zamonaviy Agile jamoalarda
Q3 TDD ning Red-Green-Refactor siklini tushuntiring. +

Javob: "TDD 3 bosqichli sikl orqali ishlaydi:"

  • 🔴 RED — Test yozasiz. U Fail bo'ladi (chunki kod hali yo'q). Bu normal.
  • 🟢 GREEN — Minimal kod yozasiz — faqat test o'tsin. Chiroyli emas, oddiy.
  • 🔧 REFACTOR — Kodni tozalaysiz, yaxshilaysiz. Test baribir o'tishi kerak.

Keyin sikl qaytadan — yangi funksiya uchun RED bosqichidan boshlaysiz.

Nega shunday? "Oldindan test yozish — kodingiz albatta testlanadigan qilib yozilishini ta'minlaydi."

Q4 BDD da Given-When-Then nima? Misol bering. +

Javob: "Given-When-Then — BDD ssenariysining 3 qismi:"

  • Given — boshlang'ich holat (bu yerda tizim qanday?)
  • When — foydalanuvchi nima qiladi?
  • Then — natija nima bo'lishi kerak?

Misol:

Scenario: Muvaffaqiyatli login
  Given men login sahifasidaman
  When men to'g'ri email va parolni kiritaman
  Then men Dashboard'ga o'taman

Afzallik: Bu matnni PO ham tushunadi — texnik bilim kerak emas.

Q5 3 Amigos meeting nima? Kimlar qatnashadi? +

Javob: "3 Amigos — bu 15-30 daqiqalik qisqa uchrashuv. 3 ta asosiy rol qatnashadi:"

  • Product Owner (PO) — "Biznes uchun bu nima foyda?"
  • Developer — "Buni qanday yaratsam bo'ladi?"
  • QA / Testor — "Qanday buzishim mumkin?"

Maqsadi: Kod yozishdan oldin, yangi funksiya 3 xil nuqtai nazardan ko'rib chiqiladi. Bu keyinchalik soatlarcha qayta ishlashdan qutqaradi.

Pro javob: "Bu meeting Whole Team Approach'ning asosiy amaliyoti. Men unda doim savollar beraman — masalan 'Noto'g'ri ma'lumot kiritilsa nima bo'ladi?' yoki 'Mobil versiyada qanday ishlaydi?'"

Q6 QA TDD da qanday qatnashadi? +

Javob: "TDD asosan dasturchilar ishi, lekin QA ham muhim rol o'ynaydi:"

  • Test senariylarini ro'yxatlash — dasturchi qaysi holatlarni Unit test qilishi kerakligini aytadi
  • Code Review — dasturchi yozgan testlar yetarli'mi tekshiradi
  • Integration/System testlar — TDD faqat Unit darajasida, yuqori darajalar QA zimmasida
  • Edge case'lar — "Bu holatni ham test qildingizmi?" deb so'raydi

Muhim: "QA TDD'ni bilsada, o'zi Unit test yozmaydi. Lekin u — dasturchining eng yaxshi hamkori."

Q7 Cucumber nima? Qayerda ishlatiladi? +

Javob: "Cucumber — eng mashhur BDD asbobi. Gherkin sintaksisida yozilgan ssenariylarni avtomatik test sifatida bajaradi."

Qanday ishlaydi?

  • QA yoki BA Gherkin ssenariysini yozadi
  • Dasturchi har bir Given/When/Then uchun kod yozadi
  • Cucumber avtomatik ravishda testlarni bajaradi

Qayerda ishlatiladi? Click, Uzum, EPAM, Exadel kabi kompaniyalarda. Asosan Java va JavaScript loyihalarda.

Muqobillari:

  • SpecFlow — .NET uchun
  • Behave — Python uchun
Yakuniy

3 ta asosiy fikr

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

01
Sifat — umumiy mas'uliyat
Whole Team Approach: testor yolg'iz emas, butun jamoa sifatga mas'ul. 3 Amigos bu falsafaning amaliy ifodasi.
02
Test birinchi, kod keyin
TDD: Red → Green → Refactor sikli. Bu dasturchi uchun, lekin QA — hamkor.
03
BDD = Biznes tili bilan test
Given-When-Then — hamma tushunadi. Cucumber orqali avtomatlashtiriladi. Intervyuda so'raladi.
← Oldingi dars
5-dars · Rollar va Traceability
Keyingi dars →
7-dars · Shift Left Testing
🏆 Darsni muvaffaqiyatli tugatdingiz!