UAT

UAT — dasturiy mahsulot real biznes ehtiyojlari va foydalanuvchi jarayonlariga mos kelishini yakuniy qabul nuqtayi nazaridan tekshirish bosqichi. To‘liq nomi User Acceptance Testing. UAT odatda biznes vakillari, product owner, mijoz yoki haqiqiy foydalanuvchilarga yaqin guruh tomonidan bajariladi.

UAT “kod requirement bo‘yicha ishlaydimi?”dan tashqari “bu yechim amalda ish jarayonimizni to‘g‘ri hal qiladimi?” degan savolga javob beradi.

Maqsad

UATning asosiy maqsadlari:

• biznes jarayoni mosligini tekshirish;
• acceptance criteria’ni tasdiqlash;
• real user flow’ni ko‘rish;
• releasega rozilik berish;
• muhim gaplarni aniqlash;
• training va documentation ehtiyojini topish.

UAT unit yoki integration test o‘rnini bosmaydi.

Ishtirokchilar

UATda qatnashishi mumkin:

• mijoz vakili;
• product owner;
• business analyst;
• subject-matter expert;
• key user;
• support;
• compliance vakili;
• QA facilitator.

Developer xatoni tushuntirish va tuzatish uchun yordam beradi, ammo qabul qarorini odatda biznes beradi.

UAT muhiti

Muhit productionga yaqin bo‘ladi:

• configuration;
• role;
• integration;
• data hajmi;
• workflow;
• report;
• browser;
• device.

Real productionda test qilish xavfli.

Test environmentda personal va moliyaviy data himoyalanadi.

Test data

UAT data userga tanish business holatlarni ifodalaydi.

Masalan:

• realga o‘xshash order;
• turli customer turi;
• expired contract;
• qaytarilgan payment;
• regional qiymat;
• permission role.

Production dump ishlatilsa anonymization va access control zarur.

UAT plan

Plan quyidagilarni belgilaydi:

• scope;
• participant;
• vaqt;
• environment;
• scenario;
• entry criteria;
• exit criteria;
• defect process;
• sign-off.

Noaniq plan UATni tasodifiy browsingga aylantiradi.

Entry criteria

UAT boshlanishidan oldin:

• feature complete;
• critical testlar yashil;
• environment tayyor;
• data yuklangan;
• known issue ro‘yxati;
• documentation;
• access accountlari

mavjud bo‘lishi mumkin.

Beqaror build user vaqtini isrof qiladi.

Scenario

UAT ssenariysi real ish vazifasiga yaqin.

Masalan:

Yangi vakansiya yaratish, moderatorga yuborish, tasdiqlash va public sahifada tekshirish.

Faqat button va fieldlar ro‘yxati business oqimini yetarli ko‘rsatmaydi.

Acceptance criteria

Har scenario expected natijaga ega.

Natija:

• visible status;
• report;
• notification;
• calculation;
• audit record;
• permission;
• downstream update

bo‘lishi mumkin.

“Yaxshi ishlashi kerak” test qilinadigan criteria emas.

Happy path

Asosiy muvaffaqiyatli oqim birinchi tekshiriladi.

User normal sharoitda vazifani boshidan oxirigacha bajaradi.

Biroq UAT faqat happy path bilan cheklanmaydi.

Real ishda cancellation, correction va exceptionlar ham bor.

Negative va boundary holat

UATda biznes uchun muhim xato holatlari tekshiriladi:

• limitdan yuqori summa;
• noto‘g‘ri role;
• muddati tugagan record;
• duplicate;
• incomplete data;
• unavailable service.

Texnik barcha edge case unit va integration testda bo‘lishi mumkin.

Defect va change request

UAT topilmasi ikki turga ajratiladi:

• kelishilgan requirementga zid behavior — defect;
• yangi yoki o‘zgargan ehtiyoj — change request.

Ularni aralashtirish scope va release qarorini buzadi.

Requirement hujjati va acceptance criteria asos bo‘ladi.

Severity

Topilma business ta’siri bo‘yicha baholanadi.

Critical issue release’ni to‘xtatishi mumkin.

Minor wording yoki kosmetik xato known issue sifatida keyingi releasega qolishi mumkin.

Qaror product risk va workaroundga bog‘liq.

Retest

Defect tuzatilgach ayni scenario qayta bajariladi.

Yaqin business flow ham regression uchun tekshiriladi.

Faqat developer “tuzatildi” degani UAT closure emas.

Evidence va build version saqlanadi.

Sign-off

UAT yakunida vakolatli shaxs releasega rozilik beradi.

Sign-off:

• qamrov;
• natija;
• open issue;
• risk acceptance;
• build version;
• sana

ni ko‘rsatishi mumkin.

Bu sifatning mutlaq kafolati emas, biznes qabul qarori.

Beta test bilan farqi

UAT aniq requirement va acceptance criteria bo‘yicha boshqariladi.

Beta test ko‘proq keng user guruhidan real foydalanish feedbackini oladi.

Beta productionga yaqin yoki production channel’da bo‘lishi mumkin.

UAT esa nazoratli qabul bosqichi.

UAT va QA

QA UATni rejalashtirish, environment va defect trackingda yordam beradi.

Ammo QA mutaxassisi biznes nomidan yakuniy qabulni bera olmaydi, agar u shu vakolatga ega bo‘lmasa.

UAT owneri aniq belgilanadi.

Automation

Ayrim acceptance ssenariylar ATDD yoki regression suite sifatida avtomatlashtirilishi mumkin.

Biroq UATda human judgement muhim:

• workflow qulaymi;
• terminology to‘g‘rimi;
• real jarayon mosmi;
• report tushunarlimi.

Automation sign-offning o‘rnini to‘liq bosmaydi.

Production readiness

UAT bilan birga quyidagilar tekshirilishi mumkin:

• user training;
• support playbook;
• data migration;
• rollback;
• monitoring;
• access;
• operational procedure;
• communication.

Feature ishlashi yetarli, ammo operation tayyor bo‘lmasa release xavfli.

Pilot guruh

Katta tashkilotda UAT avval bitta bo‘lim yoki regiondagi key userlar bilan bajarilishi mumkin. Ular real workflow va terminology bo‘yicha feedback beradi. Pilot natijasi training material va rollout rejasini yangilaydi.

Data migration tekshiruvi

Yangi tizimga eski recordlar ko‘chirilsa UAT userlar tanish misollar orqali total, status, history va relationshiplarni tasdiqlaydi. Faqat row count tengligi business ma’no saqlanganini ko‘rsatmaydi.

Audit va compliance

Regulated jarayonda approval, role separation va audit log acceptance criteria’ga kiradi. User action kim, qachon va qanday o‘zgarish qilganini ko‘rsatishi kerak.

UAT report

Yakuniy report bajarilgan ssenariy, pass/fail, ochiq defect, workaround, risk va sign-offni bir joyda saqlaydi.

Bog‘liq tushunchalar

User Acceptance Testing, Acceptance criteria, Business testing, Sign-off, UAT environment, Test scenario, Defect, Change request, ATDD, Release readiness