Avvalgi rejalashtirish jarayonida talablar va xizmat siyosatlarini tartibga solib, IA, menyu tuzilmasi va foydalanuvchi oqimini ma’lum darajada ishlab chiqqach, bu ma’lumotlarni amaldagi ekran darajasidagi dizaynlarga aylantiruvchi ekran spetsifikatsiyalarini yaratishga kirishdim.
Dastlab ekran spetsifikatsiyasida har bir ekranda qaysi funksiyalar kerakligi va qaysi ma’lumotlar ko‘rsatilishi bayon qilinsa, shu yetarli deb o‘yladim. Biroq amaldagi loyihada bir nechta ekran yaratganimdan so‘ng, ekran spetsifikatsiyasida men kutganimdan ancha ko‘p jihatlarni hisobga olish kerakligini angladim.
Ishlab chiqish bosqichiga o‘tgach, funksiyalar men yozgan ekran spetsifikatsiyalari asosida amalga oshirilgan-oshirilmaganini shaxsan sinab ko‘rdim. Bu jarayon orqali rejalashtirish vaqtida e’tibordan chetda qolgan istisno holatlarni va ishlab chiqish jarayonida yuzaga kelgan xatolarni aniqlay oldim. Tajriba orqali funksiya faqat rejalashtirilgan, dizayn qilingan, ishlab chiqilgan va amalda sinovdan o‘tkazilgandan keyingina to‘liq yakunlangan hisoblanishini o‘rgandim. Shuningdek, sinov paytida aniqlangan xatolarni ko‘rib chiqish va tuzatish orqali xizmatdagi xatolar darajasini kamaytirishga ham e’tibor qarata boshladim.
Bu jarayon davomida ekran dizayni va QA ning har bir bosqichida muhim deb hisoblay boshlagan mezonlarni ishlab chiqdim. Ushbu maqolada amaldagi loyihada ekran spetsifikatsiyalarini yaratish va QA o‘tkazish jarayonida boshdan kechirgan sinov va xatolarimni, shuningdek, shu jarayon davomida belgilagan mezonlarimni tanishtiraman.
1. Ekranlarni batafsil rejalashtirish — ekran spetsifikatsiyalarini yaratishdagi sinovlar, xatolar va takomillashtirishlar
Men amalda foydalangan ekran spetsifikatsiyasining asosiy tuzilmasi quyidagicha edi.
[Muqova] → [Mundarija] → [O‘zgartirishlar tarixi] → [Menyu tuzilmasi] → [Ekranlar ro‘yxati (IA)] → [Ruxsatlar matritsasi] → [Blok-sxema] → [Umumiy siyosatlar] → [Batafsil spetsifikatsiyalar]
Xususan, quyidagi jihatlarni muhim deb hisobladim va ekran spetsifikatsiyalarini shunga muvofiq boshqarishga harakat qildim.
1) O‘zgartirishlar tarixi
Loyiha ustida ishlash jarayonida kutilmaganda katta e’tibor qaratgan sohalarimdan biri hujjat versiyalarini boshqarish bo‘ldi.
Ekranlarni rejalashtirish bir marta bajarilgach tugaydigan vazifa emas edi.
Dasturchilar bilan ekranlarni ko‘rib chiqish paytida o‘zgarishlar yuzaga kelar, siyosatlar o‘zgarganda esa mavjud ekranlarni ba’zan yana qayta ko‘rib chiqishga to‘g‘ri kelardi.
Muammo shundan iborat ediki, hujjat qayta-qayta tahrir qilina boshlagach, men “Hozir ko‘rib turgan hujjatim eng so‘nggi versiyami?” degan savolni tekshirishimga to‘g‘ri kelardi.
va “Bu ekranda qachon va nima o‘zgartirilgan?”
Shu sababli loyiha rivojlangani sari fayl nomlari va versiyalarini izchil qoidalar asosida boshqara boshladim.
Masalan, fayl nomlarini quyidagicha standartlashtirdim.
프로젝트명_화면 설계서_v1.2_20260613.pdfAsosiy siyosat o‘zgarganda yoki ekran tuzilmasi sezilarli darajada o‘zgartirilganda, boshidagi versiya raqamini oshirdim,
matn tahrirlari yoki ayrim komponentlardagi o‘zgarishlar kabi kichik o‘zgarishlarni esa oxiridagi versiya raqamini oshirish orqali ajratdim.
Versiyalarni shu tarzda ajratish avvalgi va joriy hujjatlarni taqqoslashni yoki ekranning ma’lum bir vaqtdagi holatini tekshirishni ancha osonlashtirdi.
-
Versiyani oshirish qoidalari:
-Ishga joriy etilgan va mijoz/jamoa tomonidan dastlab tasdiqlangan versiya: v1.0
-UI maketini to‘liq qayta ko‘rib chiqish yoki asosiy biznes siyosatlaridagi o‘zgarishlar kabi yirik arxitekturaviy o‘zgarishlar: boshidagi raqamni oshirish (masalan, v1.0 ➔ v2.0)
-Kichik qo‘shimcha funksiyalar, ogohlantirish matnlaridagi o‘zgarishlar yoki ayrim komponentlarni takomillashtirish: oxiridagi raqamni oshirish (masalan, v1.0 ➔ v1.1)
Versiyalarni boshqarishda yana bir sinov va xato holatiga duch keldim.
Dastlab ekranlardagi har bir kichik o‘zgarishni tarix varag‘iga qayd etardim.
Masalan, bitta tugma nomini o‘zgartirish yoki Description matnini tahrirlashni ham qo‘shib, hamma narsani tarixga kiritardim.
Avvaliga har bir o‘zgarishni qoldirmasdan qayd etish eng to‘g‘ri yo‘l deb o‘yladim.
Biroq tahrirlar to‘planishda davom etgani sari tarix varag‘i haddan tashqari murakkablashdi.
Muhim siyosatdagi o‘zgarishni tekshirmoqchi bo‘lganimda ham, mayda tahrirlar u bilan aralashib ketar va bu aslida kerakli ma’lumotni topish uchun ko‘proq vaqt sarflashga olib kelardi.
Shu sababli keyinchalik o‘zgarishlarni ikki toifaga ajratib, ularni alohida boshqardim.
Asosiy o‘zgarishlarni hujjat boshidagi umumiy tarixda qayd etdim, oddiy matn tahrirlari yoki komponentlar joylashuvidagi o‘zgarishlar kabi kichik o‘zgarishlar uchun esa tegishli ekran Description qatori yoniga tahrir belgisini qo‘ydim.
Masalan, o‘sha ekranda v1.2 tahririni, tahrir sanasini va o‘zgarish tafsilotlarini ko‘rsatdim.
Bu o‘zgarishdan so‘ng umumiy hujjatdagi yirik o‘zgarishlar tarixini alohida ekranlardagi batafsil o‘zgarishlardan ajrata oldim.
Ayniqsa, muayyan ekranlar uchun mas’ul dasturchilar faqat o‘sha ekranlardagi o‘zgarishlarni tezda tekshirishlari ham osonlashdi.
2) Description
Batafsil ekranlarni loyihalashda ekranning chap tomoniga Wireframe chizib, o‘ng tomoniga Description yozib ishladim.
Wireframe’da ekranda amalda ko‘rinadigan Input Box, Select Box, Radio Button, Checkbox va Data Grid kabi komponentlarni joylashtirdim hamda izoh talab qiladigan joylarga raqamlar qo‘shdim.
Dastlab Wireframe yaratishga e’tibor qaratdim, biroq ko‘proq ekranlarni rejalashtirganim sari Description sohasi hamma narsadan muhimroq ekanini angladim.
Ekranlarni ilk bor rejalashtirganimda, ekranda talab qilinadigan funksiyalar va ularning asosiy ishlash tartibini hujjatlashtirishga e’tibor qaratdim. Biroq bir nechta ekranlarni rejalashtirish davomida nafaqat odatiy holatlarni, balki istisno yuz berganda qaysi ogohlantirishni ko‘rsatish, foydalanuvchi ekranga ilk bor kirganda yoki ma’lumot bo‘lmaganda ekran qanday ko‘rinishi kabi holatlarni ham oldindan belgilashim kerakligini angladim.
Ekranlarni yaratish jarayonida dastlabki holatni, ma’lumotlar qanday ko‘rsatilishini, foydalanuvchi o‘zaro ta’sirlarini, validatsiyani va istisno holatlarni tekshirishga harakat qildim.
① Dastlabki holat va ma’lumotlarni ko‘rsatish
Avvalo foydalanuvchi ekranga dastlab kirgan paytdagi holatni hujjatlashtirdim.
Masalan, shunchaki “Jadvalni ko‘rsatish” deb yozish o‘rniga, amalda amalga oshirish uchun zarur mezonlarni, masalan, “Jadval ‘Failed > Warning > Canceled > Running > Passed’ holatlari ustuvorligi tartibida saralanadi va ko‘pi bilan 20 ta yozuvni ko‘rsatadi” deb hujjatlashtirdim.
② Foydalanuvchi o‘zaro ta’siri va ekranlar bo‘ylab navigatsiya siyosatlari
Tugma yoki komponent bosilganda nima sodir bo‘lishini ham batafsil bayon qildim.
Masalan, “[Edit] tugmasi bosilganda boshqa ekranga o‘tmasdan, markazda MB_01_P01 qatlamli qalqib chiquvchi oynasi ko‘rsatiladi” va “Kombinatsion katakdagi tanlangan qiymat o‘zgarganida pastki grid ma’lumotlari yangilanadi.”
Ekranlar bo‘ylab navigatsiya amalga oshirilishi yoki amalga oshirilmasligi va qalqib chiquvchi oynaning shakli kabi tafsilotlarni hujjatlashtirdim.
③Tekshirish va istisno holatlar
Oddiy vaziyatlarda ekranning qanday ishlashini tasavvur qilish oson, biroq
-
kiritilgan qiymatlar yaroqsiz bo‘lganda
-
qidiruv natijalari mavjud bo‘lmaganda
-
allaqachon qayta ishlangan ma’lumotlarni o‘zgartirishga urinilganda
-
ruxsati bo‘lmagan foydalanuvchi undan foydalanishga urinilganda
shu kabi odatiy jarayondan chetga chiqadigan vaziyatlarni e’tibordan chetda qoldirish oson edi.
Shuning uchun ekran yaratgandan so‘ng, “Bu funksiya odatdagidek ishlamasa, nima bo‘lishi kerak?” deb yana bir bor o‘ylashni odat qildim.
Bu jarayon orqali ekran spetsifikatsiyasi shunchaki ekranni tavsiflovchi hujjat emas, balki ishlab chiqish jarayonida yuzaga kelishi mumkin bo‘lgan talqin farqlarini oldindan kamaytiradigan hujjat ekanini tushundim.
2. QA test holatlarini o‘zim yozish orqali o‘rganganlarim
Ishlab chiqish deyarli yakunlangach, xizmat men yozgan ekran spetsifikatsiyalariga muvofiq amalga oshirilganini tekshirish uchun test ssenariylarini yozdim.
QA tekshiruvini ilk bor o‘tkazganimda, funksiyalar to‘g‘ri ishlayotganini tekshirishning o‘zi kifoya deb o‘yladim.
Biroq amalda test ssenariylarini yozganimdan so‘ng, “nimani test qilish kerakligini” oldindan belgilashning o‘zi ham muhim ekanini angladim.
Shu sababli test holatlarida quyidagi bandlarni tartibga soldim.
-
Test ID
-
Funksiya va modul
-
Ekran ID
-
Test hisobi va ma’lumotlar
-
Test uchun zarur shartlar
-
Test tartibi
-
Kutilgan natija
-
Haqiqiy natija
-
Test holati
-
Nuqsonni bartaraf etish tafsilotlari
Testlarni yozishda test tartibi va kutilgan natijalarni imkon qadar batafsil qismlarga ajratdim.
Ularni amaldagi testni o‘tkazayotgan shaxs barcha amallarni aynan ko‘rsatilganidek bajara oladigan darajada yozdim.
Ularni shu tarzda yozish test paytida o‘tkazib yuborgan bandlarim sonini kamaytirdi, shuningdek, nuqsonlar haqida xabar berishda muammo yuzaga kelgan sharoitlarni dasturchilarga tushuntirishni osonlashtirdi.
Test natijalarini PASS, FAIL, BLOCK va TO DO holatlari yordamida tasnifladim.
Biror narsa kutilganidek ishlaganda, uni PASS deb belgiladim, kutilgan natijadan boshqacha ishlaganda esa FAIL sifatida qayd etdim.
FAIL yuz berganda, shunchaki “Ishlamaydi” deb yozish o‘rniga, amalda nima sodir bo‘lganini qayd etdim.
Masalan, kutilgan natija “Tasdiqlangan ma’lumotlar uchun [Tahrirlash] tugmasi ko‘rsatilmaydi” bo‘lsa, ammo amaldagi ekranda [Tahrirlash] tugmasi paydo bo‘lsa, “Holati tasdiqlangan ma’lumotlar so‘ralganda [Tahrirlash] tugmasi ko‘rsatiladi” deb yozdim
haqiqiy natija sifatida.
Shu tarzda qayd etish orqali dasturchilar muammo qanday sharoitlarda yuzaga kelganini darhol aniqlay oldilar.
Bundan tashqari, kirishdagi xato kabi zarur shart bo‘lgan funksiyada muammo yuzaga kelgani sababli keyingi testni o‘tkazib bo‘lmaganda, uni BLOCK deb belgiladim.
Bu jarayonni takrorlash orqali QA shunchaki funksiyalarni bosib ko‘rishdan iborat vazifa emas, balki rejalashtirish bosqichida belgilangan talablarni amaldagi amalga oshirish natijalari bilan taqqoslash jarayoni ekanini his qildim.
3. Xulosa
Loyihani ilk boshlaganimda, ekran spetsifikatsiyasi ekranning ko‘rinishi va funksiyalarini tavsiflovchi hujjat deb o‘ylardim. Biroq bir nechta ekran yaratib, dasturchilar bilan hamkorlik qilganimdan so‘ng, nuqtayi nazarim sezilarli darajada o‘zgardi.
Hatto bitta ekranni rejalashtirayotganda ham, “Ekranda nima ko‘rinadi?” degan savol bilan cheklanmay, “Foydalanuvchi ilk bor kirganda ekran qanday holatda bo‘ladi?”, “Ma’lumot bo‘lmaganda nima sodir bo‘ladi?”, “Foydalanuvchining ruxsatlari boshqacha bo‘lsa, nima o‘zgaradi?” va “Yaroqsiz ma’lumot kiritilganda nima sodir bo‘ladi?” kabi savollar haqida o‘ylay boshladim.
Shuningdek, ekran dizaynini yakunlash funksiya tayyor degani emasligini o‘rgandim. Ishlab chiqishdan so‘ng amaldagi amalga oshirishni men yozgan spetsifikatsiyalar bilan taqqoslab tekshirish, test paytida aniqlangan xatolar yoki tushirib qoldirilgan bandlarni ko‘rib chiqish va tuzatish zarur edi. Funksiya rejalashtirish bosqichida belgilangan mazmunni amaldagi amalga oshirish natijalari bilan taqqoslagan holda QA o‘tkazilmaguncha, u chinakam yakunlangan hisoblanmaydi, degan xulosaga keldim.
Boshidanoq har bir vaziyatni mukammal belgilashga urinish o‘rniga, dasturchilarning savollariga javob berish, QA paytida tushirib qoldirilgan bandlarni aniqlash va hujjatlarni boshqarishda yuzaga kelgan noqulayliklarni boshdan kechirish orqali mezonlarni asta-sekin, birma-bir shakllantirdim.
Oxir-oqibat, yaxshi ekran spetsifikatsiyasi loyiha ishtirokchilarining barchasi bir xil ekran va uning xatti-harakatlarini ko‘rishi hamda tushunishi uchun mezonlarni bir xillashtiradigan hujjat, QA esa amaldagi xizmat aynan shu mezonlarga muvofiq amalga oshirilganini tekshirish jarayoni, deb hisoblayman.
ryu