ATDD

ATDD — dasturiy imkoniyat ishlab chiqilishidan oldin uning qabul qilinish shartlarini biznes vakili, tester va developer birgalikda aniq misollar ko‘rinishida belgilaydigan yondashuv. To‘liq nomi Acceptance Test-Driven Development. ATDD “feature tayyor deb qachon aytiladi?” degan savolga test qilinadigan javob beradi.

Acceptance testlar faqat yakuniy tekshiruv emas, requirementni aniqlashtirish va developmentni yo‘naltirish vositasi sifatida ishlatiladi.

Acceptance criteria

Feature bajarishi kerak bo‘lgan observable shartlar.

Masalan, ish vakansiyasi yaratishda:

• majburiy fieldlar tekshiriladi;
• salary intervali to‘g‘ri bo‘ladi;
• draft public ro‘yxatda ko‘rinmaydi;
• published vakansiya qidiruvda chiqadi;
• muddati tugagan vakansiya yopiladi.

Har criteria o‘lchanadigan va tushunarli bo‘lishi kerak.

Hamkorlik

ATDD odatda uch rolning suhbatiga tayanadi:

• biznes yoki product vakili;
• developer;
• tester yoki QA.

Biznes maqsadni tushuntiradi, developer texnik cheklovni ko‘rsatadi, tester boundary va failure holatlarni topadi.

Bu hamkorlik requirement noto‘g‘ri tushunilishini erta kamaytiradi.

Testdan oldingi muhokama

Test kod yozilgandan keyin emas, implementationdan oldin kelishiladi.

Shu paytda:

• noaniq atamalar;
• default qiymat;
• permission;
• error holati;
• vaqt chegarasi;
• external dependency

aniqlanadi.

Keyin topilgan requirement xatosini tuzatish odatda qimmatroq.

Misol orqali aniqlashtirish

Umumiy gap:

faol foydalanuvchi chegirma oladi

yetarli emas.

Misollar:

status=active, total=100 000 → 10% chegirma
status=blocked → chegirma yo‘q
total=0 → chegirma 0

Concrete misollar yashirin qoidalarni ko‘rsatadi.

Specification by Example

ATDD Specification by Example bilan yaqin.

Talab abstrakt matn emas, real input-output misollar bilan ifodalanadi.

Misollar keyin executable test va living documentationga aylanishi mumkin.

Barcha misol avtomatik test bo‘lishi shart emas.

Acceptance test

Acceptance test user yoki business nuqtayi nazaridan yakuniy behaviorni tekshiradi.

U:

• API;
• service;
• UI;
• message;
• report;
• batch process

darajasida bo‘lishi mumkin.

Eng tez va ishonchli daraja tanlanadi.

Given–When–Then

ATDD ssenariylari ko‘pincha:

• Given — boshlang‘ich holat;
• When — action;
• Then — kutilgan natija

formatida yoziladi.

Bu BDD bilan umumiy.

ATDDning asosiy urg‘usi acceptance testlarni hamkorlikda oldindan aniqlashdir.

Test chegarasi

Acceptance test barcha internal methodlarni tekshirmaydi.

U feature contractini tekshiradi.

Masalan, order qaysi repository methodidan foydalangani emas, to‘g‘ri status va totalga ega bo‘lib yaratilgani muhim.

Internal refactor testni buzmasligi kerak.

Automation

Takroriy va muhim criteria avtomatlashtiriladi.

Automation:

• regression;
• tez feedback;
• CI;
• release gate;
• living documentation

uchun foydali.

Bir martalik, tez o‘zgaradigan yoki vizual baholash talab qiladigan criteria manual qolishi mumkin.

Test darajasi

Acceptance testni faqat browser E2E sifatida yozish suite’ni sekinlashtiradi.

Domain qoida service yoki API darajasida tezroq tekshiriladi.

UI interaction uchun oz sonli browser ssenariy saqlanadi.

Test piramidasi ATDDda ham muhim.

Example mapping

Feature muhokamasida quyidagilar ajratiladi:

• story;
• rule;
• example;
• question.

Har business rule uchun bir yoki bir nechta misol yoziladi.

Javobsiz savollar development boshlanishidan oldin hal qilinadi.

Definition of Done

Acceptance testlar Definition of Done’ning bir qismi bo‘lishi mumkin.

Feature:

• criteria bajarildi;
• testlar yashil;
• monitoring tayyor;
• documentation yangilandi;
• security tekshirildi

bo‘lganda tayyor hisoblanadi.

ATDD barcha sifat talablarini yakka o‘zi qamramaydi.

ATDD va TDD

TDD odatda developerning kichik code unitlari va Red–Green–Refactor sikliga yaqin.

ATDD esa yuqori darajadagi biznes qabul shartlarini boshqaradi.

Odatdagi oqim:

acceptance test qizil
→ TDD bilan implementation
→ acceptance test yashil

ATDD va UAT

ATDD developmentdan oldin acceptance criteria va testlarni yaratadi.

UAT esa ko‘pincha releasega yaqin real user yoki business vakili tomonidan bajariladigan qabul sinovi.

ATDD UATdagi kutilmagan talab farqlarini kamaytirishi mumkin.

Data

Acceptance test ma’noli business data bilan yoziladi.

foo, bar, test1 o‘rniga domainni tushuntiradigan qiymatlar ishlatiladi.

Biroq real personal data testga ko‘chirilmaydi.

Synthetic va xavfsiz data tanlanadi.

External service

Payment yoki SMS kabi servis acceptance testda sandbox yoki controlled fake bilan ishlashi mumkin.

Muhim contract integration test bilan alohida tekshiriladi.

To‘liq real providerga tayanish testni sekin va flaky qiladi.

Failure xabari

Acceptance test yiqilganda biznesga tushunarli sabab ko‘rsatishi kerak.

Masalan:

Expected expired vacancy to be hidden, but it remained visible.

Faqat selector yoki SQL xatosi ssenariy ma’nosini yashiradi.

Technical log qo‘shimcha artifact sifatida beriladi.

Maintenance

Requirement o‘zgarsa acceptance criteria va test birga yangilanadi.

Eski behaviorni saqlab qolish kerakmi yoki o‘zgartirish migrationmi, aniq belgilanadi.

Testlarni product decisiondan ajratib yangilash noto‘g‘ri.

Cheklovlar

ATDD noto‘g‘ri business maqsadni avtomatik tuzatmaydi.

U performance, security, accessibility va operatsion risklarni alohida testlash ehtiyojini yo‘qotmaydi.

Faqat happy-path criteria bilan cheklansa muhim failure holatlar qolib ketadi.

Acceptance test review

Ssenariy avtomatlashtirilgach biznes vakili uning matni va expected natijasini ko‘rib chiqadi. Test texnik jihatdan yashil, ammo requirementni noto‘g‘ri ifodalashi mumkin. Review automation bilan business kelishuvini bog‘laydi.

Release traceability

Story, acceptance criteria, test natijasi va release artifact orasida bog‘lanish saqlanishi mumkin. Regulated yoki katta tizimda qaysi requirement qaysi test bilan tasdiqlangani shu orqali topiladi.

Bog‘liq tushunchalar

Acceptance Test-Driven Development, Acceptance criteria, Specification by Example, Given-When-Then, BDD, TDD, UAT, Living documentation, Example mapping, Test automation