Vaziyat: IT kompaniya yangi qoida joriy qildi: dasturchilar kod yozishda Coding Standards'ga rioya qilishi va har bir Pull Request kamida ikki mutaxassis tomonidan Review qilinishi kerak. Savol: Bu QA, QC yoki Testing faoliyatimi?, QA. Izoh: Bu yerda hali tayyor mahsulot tekshirilmayapti. Kompaniya xatolar paydo bo'lishining oldini olish uchun ishlab chiqish jarayonini yaxshilayapti. Bu QA'ning proaktiv faoliyatiga kiradi, Vaziyat: Login sahifasi tayyor. Tester to'g'ri email, lekin noto'g'ri parol kiritdi. Tizim xato xabarini ko'rsatdi va foydalanuvchini Dashboard'ga o'tkazmadi. Savol: Bu qanday faoliyat va tester nimani solishtiradi?, QC va Testing. Izoh: Tayyor mahsulot tekshirilmoqda. Tester Expected Result va Actual Result'ni solishtiradi. Kutilgan natija: xato xabari chiqishi va foydalanuvchi login sahifasida qolishi. Haqiqiy natija ham shunday bo'lsa, bu test Pass hisoblanadi., Vaziyat: QA mutaxassisiga yangi loyiha talablari berildi. Hujjatda foydalanuvchi parolini email orqali tiklashi mumkinligi yozilgan. Lekin tiklash havolasi qancha vaqt amal qilishi ko'rsatilmagan. Savol: Tester nima qilishi kerak? Kod yozilishini kutish kerakmi?, Yo'q. Requirement Analysis bosqichidayoq aniqlik kiritish kerak. QA Business Analyst'dan quyidagilarni so'rashi mumkin: Link necha daqiqa amal qiladi? Link faqat bir marta ishlatiladimi? Muddati o'tgach nima bo'ladi? Bu Early Testing prinsipidir. Xatoni talablar bosqichida topish keyinchalik tuzatishdan arzonroq., Vaziyat: Ro'yxatdan o'tish formasida 3 ta maydon bor. Har bir maydonga 100 xil qiymat kiritish mumkin. Jami 1 million kombinatsiya hosil bo'ladi. Loyihada esa test uchun atigi 2 kun vaqt bor.Savol: Tester barcha kombinatsiyalarni tekshirishi shartmi?, Yo'q. Risk-based Testing orqali eng muhim holatlarni tanlaydi. Izoh: Bu Exhaustive Testing is Impossible prinsipidir. Barcha kombinatsiyalarni tekshirish amaliy jihatdan imkonsiz. Tester muhim va xavfli holatlarni tanlashi, kerakli joyda Equivalence Partitioning va Boundary Value Analysis'dan foydalanishi mumkin, Vaziyat: Bank ilovasining 5 ta moduli bor. Testing davomida aniqlangan 100 ta bugning 80 tasi to'lov modulida topildi. Savol: QA keyingi testing jarayonida qanday qaror qabul qilishi kerak?, To'lov moduliga ko'proq test resursi ajratishi kerak. Izoh: Bu Defect Clustering prinsipi. Ko'pincha buglarning katta qismi dasturdagi kichik modullar sonida to'planadi. Tester ko'proq muammo chiqayotgan va murakkab modullarga e'tibor qaratadi., Vaziyat: Tester har bir yangi versiyada aynan bir xil 20 ta Test Case'ni bajaradi. Bir necha sprint davomida yangi xatolar topilmadi. Lekin foydalanuvchilar yangi funksiyalarda muammolar borligini bildirishmoqda. Savol: Tester nima qilishi kerak?, Test Case'larni qayta ko'rib chiqishi va yangilarini qo'shishi kerak. Izoh: Bu Pesticide Paradox. Bir xil testlarni takrorlash vaqt o'tishi bilan yangi buglarni topish imkoniyatini kamaytiradi. Yangi funksiyalar, yangi kombinatsiyalar va yangi test ma'lumotlarini qo'shish kerak., Vaziyat: Kompaniya ikkita mahsulot ishlab chiqarmoqda: bemorlarning tibbiy tarixini saqlovchi dastur va bolalar uchun rasm chizish ilovasi. QA Lead ikkala loyihaga ham bir xil testing strategiyasini qo'llashni taklif qildi. Savol: Bu to'g'ri qarormi?, Yo'q. Izoh: Testing is Context Dependent. Tibbiy dasturda maxfiylik, xavfsizlik va ma'lumotlarning to'g'riligi juda muhim. Rasm chizish ilovasida esa UX va qulaylikka ko'proq e'tibor berilishi mumkin. Testing mahsulotning vazifasi va xavfiga qarab tanlanadi., Vaziyat: Taksi chaqirish ilovasi barcha testlardan muvaffaqiyatli o'tdi. Hech qanday bug topilmadi. Lekin foydalanuvchilar haydovchi bilan chat orqali yozishishni kutishgan, ilovada esa faqat qo'ng'iroq qilish funksiyasi mavjud. Savol: Mahsulotni muvaffaqiyatli deb hisoblash mumkinmi?, Yo'q. Izoh: Bu Absence of Errors Fallacy. Dastur texnik jihatdan xatosiz bo'lishi mumkin, lekin foydalanuvchining ehtiyojini qondirmasa, mahsulot muvaffaqiyatsiz hisoblanadi., Vaziyat: Sizga kompaniyaning yangi Login funksiyasini test qilish vazifasi berildi. Team Lead sizdan bitta to'liq Test Case yozishni so'radi. Savol: Test Case'da qanday maydonlar bo'lishi kerak?, Izoh: ID, Title, Steps va Expected Result majburiy maydonlar. Preconditions tavsiya etiladi. Test Case aniq va boshqa tester ham tushuna oladigan tarzda yozilishi kerak., Vaziyat: Tester email ilovasini tekshirmoqda. U uchta alohida tekshiruv yozdi: 1. Email manzilini kiritish. 2. Xabar matnini kiritish. 3. Send tugmasini bosish. Bundan tashqari, butun email yuborish jarayonini ham tekshirmoqchi. Savol: Umumiy jarayon Test Case yoki Test Scenario hisoblanadimi?, Test Scenario. Izoh: Test Scenario butun jarayonni yuqori darajada qamrab oladi. Test Case esa har bir elementni aniq qadamlar bilan tekshiradi. Masalan, "Xabarni muvaffaqiyatli yuborish" Test Scenario bo'ladi., Vaziyat: Senior QA login sahifasi uchun quyidagi ro'yxatni tayyorladi: Login maydoni bo'sh qolganda xato chiqishi. Parol yashirin ko'rinishi. Noto'g'ri parolda xabar chiqishi. Login tugmasi ishlashi. Unda qadamlar va Expected Result batafsil yozilmagan. Savol: Bu qanday test hujjati?, Checklist. Checklist'da nima tekshirilishi ko'rsatiladi, lekin batafsil Steps va Expected Result shart emas. Test Case esa aniq qadamlar va natijalarni o'z ichiga oladi., Vaziyat: Tester savatchaga mahsulot qo'shish tugmasida bug topdi. Developer muammoni tuzatdi va statusni Fixed qildi. QA qayta tekshirganida bug yana takrorlandi. Savol: QA bug statusini nima qilishi kerak?, Reopened. Izoh: Retest muvaffaqiyatsiz bo'ldi, demak bug hali bartaraf etilmagan. Tester muammoni qayta ochib, izoh bilan developerga yuboradi. Bug Life Cycle: New → Assigned → Open → Fixed → Retest → Closed Agar qayta tekshirish muvaffaqiyatsiz bo'lsa: Retest → Reopened → Open, Vaziyat: Kompaniyaning bosh sahifasidagi logotip rangi noto'g'ri ko'rsatilmoqda. Texnik jihatdan sayt ishlashda davom etmoqda. Lekin ertaga katta reklama kampaniyasi boshlanadi va logotip barcha foydalanuvchilarga ko'rinadi. Savol: Severity va Priority qanday belgilanadi?, Severity- Low (Texnik ta'siri kichik); Priority - High (Tez tuzatilishi kerak). Izoh: Severity texnik jiddiylikni, Priority esa bugni qanchalik tez tuzatish kerakligini bildiradi. Logotip rangi sayt funksiyalarini buzmaydi, ammo marketing kampaniyasi sababli biznes uchun muhim.

QA flashcards

by
Print
Embed

Leaderboard

Visual style

Options

Switch template

Continue editing: ?