Web testing asoslari

Kod bir marta ishlagani uning barcha holatda to’g’ri ekanini anglatmaydi. Testing kutilgan xatti-harakatni aniq talabga aylantirib, o’zgarishdan keyin qayta tekshirish imkonini beradi. Test xato bo’lmasligini kafolatlamaydi, lekin muhim muammoni foydalanuvchidan oldin topish ehtimolini oshiradi.

Avval talabni yozing

Test yozishdan oldin nima to’g’ri hisoblanishini belgilang. Masalan, login formasi uchun:

• to’g’ri email va parol yuborilganda profil ochiladi;
• noto’g’ri parolda tushunarli xato ko’rsatiladi;
• yuborish tugmasi so’rov davomida takror bosilmaydi;
• forma klaviatura bilan ishlaydi;
• server javob bermasa, qayta urinish imkoniyati chiqadi.

Aniq qabul mezoni bo’lmasa, test faqat kodning hozirgi holatini tasdiqlab, asl foydalanuvchi ehtiyojini o’tkazib yuborishi mumkin.

Test turlari

Unit test

Bitta kichik funksiya yoki modulni alohida tekshiradi. Tez ishlaydi va xato joyini aniq ko’rsatadi. Masalan, chegirma hisoblash funksiyasi yoki emailni normalizatsiya qilish.

Integration test

Bir nechta qism birga ishlashini tekshiradi. Masalan, API route ma’lumotni tekshirishi, service qatlamini chaqirishi va bazaga yozishi.

End-to-end test

Ilovani foydalanuvchi kabi brauzerda boshdan-oxir boshqaradi: sahifani ochadi, formani to’ldiradi, tugmani bosadi va natijani tekshiradi. Ishonchi yuqori, ammo unit testdan sekinroq va sozlash qimmatroq.

Nimadan boshlash kerak

Loyihada hali bitta ham test bo’lmasa, “hammasini qoplash” degan maqsad qo’ymang — u boshlashga to’sqinlik qiladi. Uch mezon bo’yicha tanlang.

Avval eng qimmatga tushadigan xatoni himoya qiling: to’lov, ruxsat tekshiruvi, ma’lumot o’chirish. Bu joylardagi xato foydalanuvchiga real zarar keltiradi.

Keyin eng ko’p o’zgaradigan mantiqni oling. Tez-tez tahrirlanadigan kod tez-tez buziladi ham. Test uni har o’zgarishda tekshirib turadi.

Uchinchidan, xato topilgan har joyga test yozing. Xatoni tuzatishdan oldin uni takrorlaydigan test yozing, keyin tuzating. Shunda test o’sha xato qaytmasligini kafolatlaydi va siz tuzatish haqiqatan ishlaganini ko’rasiz.

Test nimani almashtiradi

E2E testda haqiqiy tashqi xizmatni chaqirmaslik kerak: to’lov tizimi, email yuborish yoki uchinchi tomon API’si. Ular sekin, pulli va sizga bog’liq emas.

Ularning o’rniga mock ishlatiladi — oldindan belgilangan javob qaytaradigan soxta versiya. Bu testni tez va barqaror qiladi.

Lekin muvozanat kerak: hamma narsani mock qilsangiz, test faqat mock’larni tekshiradi, haqiqiy tizimni emas. Amaliy qoida — o’z kodingizni haqiqiy ishlating, faqat tashqi chegarani mock qiling.

Web sifati faqat funksional test emas

Professional web test rejasi bir nechta yo’nalishni qamraydi:

• accessibility — klaviatura, semantika, kontrast va screen reader;
• cross-browser — maqsadli brauzer va qurilmalarda ishlash;
• responsive — kichik va katta ekranlarda layout;
• performance — yuklanish, javob va barqarorlik;
• security — ruxsat, ma’lumot tekshiruvi va keng tarqalgan zaifliklar;
• visual regression — komponent ko’rinishi kutilmaganda buzilmaganmi;
• usability — foydalanuvchi vazifani tushunib bajara oladimi.

Avtomatik test barcha yo’nalishni to’liq qoplay olmaydi. Masalan, rang kontrastini vosita topishi mumkin, lekin xato matni odam uchun tushunarliligini inson tekshiradi.

Chekka holatlarni tanlash

Ko’p xato “odatiy” holatda emas, chekka holatda chiqadi. Har funksiya uchun quyidagi ro’yxatni ko’rib chiqish odat bo’lsin:

Holat	Misol
Bo’sh	Bo’sh ro’yxat, bo’sh matn, null
Bitta element	Ko’plik shakli to’g’ri ishlaydimi
Juda katta	10 000 ta yozuv, 5 MB fayl
Chegara qiymat	0, manfiy son, maksimal uzunlik
Noto’g’ri format	Raqam o’rniga matn, buzilgan sana
Takroriy	Bir xil email ikki marta yuborildi

Bu ro’yxatni har safar yozib chiqish shart emas — vaqt o’tib u avtomatik o’ylanadigan odatga aylanadi.

Qo’lda test ham kerak

Avtomatik test ko’p narsani tekshiradi, lekin hammasini emas. Ba’zi savollarga faqat odam javob bera oladi: xato xabari tushunarlimi, tugma qayerdaligi mantiqiymi, foydalanuvchi keyingi qadamni bilyaptimi?

Shu sababli har muhim o’zgarishdan keyin qisqa qo’lda tekshiruv o’tkazing. Asosiy oqimni foydalanuvchi kabi bajaring, faqat klaviatura bilan ham sinang va kichik ekranda ko’ring. Bu bir necha daqiqa oladi, lekin avtomatik test sezmaydigan muammolarni topadi.

Testni ishonchli qilish

Ishonchli test xususiyatlari

Yaxshi test:

• natijani foydalanuvchi ko’radigan xatti-harakat orqali tekshiradi;
• boshqa testdan mustaqil ishlaydi;
• vaqt, tarmoq yoki tasodifga keraksiz bog’lanmaydi;
• muvaffaqiyatsiz bo’lsa, sababini tushunarli ko’rsatadi;
• implementation detali o’zgarganda, xatti-harakat saqlansa buzilmaydi.

Masalan, tugmani ichki CSS class nomi bilan emas, accessible nomi — Savatga qo'shish — orqali topish testni foydalanuvchi tajribasiga yaqinlashtiradi.

Bu tanlov yana bir foyda beradi: agar test elementni accessible nomi orqali topa olmasa, demak ekran o’quvchi ham topa olmaydi. Ya’ni to’g’ri yozilgan test bir vaqtning o’zida accessibility muammosini ham ochib beradi.

Test nomiga ham e’tibor bering. test1 yoki login works o’rniga nima tekshirilayotgani aniq yozilsin: “noto’g’ri parolda xato xabari ko’rinadi”. Test yiqilganda uning nomi birinchi ma’lumot manbai bo’ladi.

Beqaror testlar

Eng zararli test — ba’zan o’tadigan, ba’zan yiqiladigan test. U flaky deb ataladi va jamoada ishonchni yo’q qiladi: bir necha marta bekorga yiqilgach, odamlar qizil natijaga e’tibor bermay qo’yadi.

Sabablari odatda bir nechta:

Sabab	Belgisi	Yechim
Qat’iy kutish	sleep(2000) bilan kutish	Element paydo bo’lishini kuting
Testlar bir-biriga bog’liq	Alohida ishlasa o’tadi	Har testda toza holat
Umumiy ma’lumot	Parallel ishlaganda yiqiladi	Har test o’z ma’lumotini yaratadi
Vaqt yoki tasodif	Ba’zi kunlarda yiqiladi	Vaqtni va tasodifni boshqaring

Flaky testni “keyinroq tuzataman” deb qoldirmang. Uni darhol tuzating yoki vaqtincha o’chiring — ishonchsiz test testsizlikdan yomonroq.

Qamrov haqida ehtiyotkorlik

Test qamrovi (coverage) — kodning necha foizi test paytida bajarilgani. Foydali ko’rsatkich, lekin uni maqsadga aylantirish xato.

Sababi oddiy: qamrov kod bajarilganini o’lchaydi, natija tekshirilganini emas. Hech qanday tekshiruvsiz funksiyani chaqiradigan test ham qamrovni oshiradi, lekin hech narsani himoya qilmaydi.

Yuz foiz qamrov ham xatosizlikni anglatmaydi. Ko’p xato kodning o’zida emas, unutilgan holatda bo’ladi — bo’sh ro’yxat, juda katta son, kutilmagan format. Bunday holat kodda umuman yozilmagan bo’lsa, qamrov uni ko’rsatmaydi.

Qamrovni yo’nalish sifatida ishlating: past qamrovli fayllar ro’yxati qayerga e’tibor kerakligini aytadi. Lekin sonni ko’tarish uchun ma’nosiz test yozish faqat qo’llab-quvvatlash yukini oshiradi.

CI ichidagi test

Test va build pull request ochilganda avtomatik ishlasa, xato asosiy branchga qo’shilishidan oldin ko’rinadi. CI jarayonida odatda format, lint, type check, unit/integration test va production build ketma-ket bajariladi. E2E testlar alohida preview muhitida ishlashi mumkin.

CI’ning eng muhim xususiyati — tezlik. Natija bir necha daqiqada kelsa, dasturchi kutadi va tuzatadi. Yarim soat davom etsa, u boshqa ishga o’tadi va kontekstni yo’qotadi. Shu sababli tez testlar (lint, unit) avval, sekinlari (E2E) keyin ishlatiladi — muammo bo’lsa erta to’xtaydi.

Yana bir qoida: qizil CI tuzatilmaguncha yangi ish qo’shilmaydi. Buzilgan asosiy branch butun jamoani to’sadi va vaqt o’tgani sari sabab topish qiyinlashadi. Bu tamoyil Git workflow darsida ham asosiy o’rin egallaydi.

Qisqacha xulosa

• Test kutilgan xatti-harakatni qayta tekshiriladigan talabga aylantiradi.
• Unit kichik qismni, integration qismlar hamkorligini, E2E to’liq oqimni tekshiradi.
• Accessibility, browser mosligi, performance va security ham test rejasiga kiradi.
• Yaxshi test foydalanuvchi xatti-harakatiga yaqin va mustaqil bo’ladi.
• CI testlarni har o’zgarishda avtomatik bajaradi.

Keyingi darsda Git va GitHub workflow — o’zgarishlarni xavfsiz boshqarish va jamoa bilan ishlashni ko’ramiz.