50 yillik QA tajribasidan tug'ilgan 7 ta fundamental qoida β ularsiz siz professional testor bo'lolmaysiz. Har biri real misol bilan.
Tasavvur qiling, siz yangi testor bo'lib ishga keldingiz. Sizga dasturiy mahsulot berildi va "tekshir" deyishdi. Qayerdan boshlaysiz? Qanday qilib hamma narsani sinab ko'rasiz? Qancha test yetarli?
Aynan shu savollarga javob berish uchun 7 ta prinsip yaratilgan. Ular sizga to'g'ri fikrlash usulini beradi β "qayerdan boshlasam?" muammosini yechadi.
Bu prinsiplar ISTQB CTFL sertifikat imtihonida so'raladi. Intervyularda ham tez-tez so'ralgan mavzulardan biri. Yodlash emas, tushunish muhim.
Siz 100 ta test o'tkazdingiz va hammasi muvaffaqiyatli o'tdi. Bu bug yo'q degani emas β balki siz sinagan joylarda bug yo'q degani. Qolgan yo'llarda bug bo'lishi mumkin.
Click jamoasi 1000 ta test o'tkazdi, hammasi muvaffaqiyatli. Keyin foydalanuvchi iPhone Safari'dan 999,999 so'm miqdorida to'lov qilmoqchi bo'ldi β tizim ishlamay qoldi. Bu aniq kombinatsiya sinalmagan edi.
Hech qachon "bu mahsulotda bug yo'q" demang. To'g'risi: "men sinagan joylarda bug topmadim". Bu kichkina farq β lekin professional testor tili.
Barcha mumkin bo'lgan kombinatsiyalarni sinab ko'rish imkonsiz. Oddiy login formasi uchun ham minglab, hatto millionlab variantlar mavjud.
Uzum Market qidiruv maydoniga foydalanuvchi nima yozishi mumkin? "iPhone", "Π°ΠΉΡΠΎΠ½", bo'sh joylar, emoji, 10,000 belgili matn, SQL injection urinishlari... Hammasini sinab ko'rish imkonsiz.
"Hamma narsa"ni sinash o'rniga eng muhim joylarni tanlab sinang. Buni qanday qilishni 14-19 darslarda (test texnikalari) o'rganamiz.
Bug qanchalik kech topilsa, shuncha qimmat bo'ladi. Talablarni o'qiyotganda topilgan muammo β 1 daqiqada tuzatiladi. Production'da topilsa β haftalab vaqt va millionlab zarar.
Talablar hujjatida yozilgan: "Foydalanuvchi pul o'tkaza oladi".
Agar testor shu paytda so'rasa: "Maksimal summa qancha? Limit bormi?" β muammo 10 daqiqada hal bo'ladi. Agar production'da foydalanuvchi 100 million so'm o'tkazma qilishga urinsa va tizim qulasa β kompaniyaga millionlab zarar.
Testorlik faqat tugmani bosish emas. Talablarni o'qiyotganda savol berish β allaqachon testlash. Bu Shift Left yondashuvi (7-darsda ko'rgan edik).
Buglar tasodifiy tarqalmaydi. Ular ma'lum "xavfli" joylarda to'planadi. Bu 80/20 qoidasi β 80% buglar 20% modullarda bo'ladi.
Bir O'zbek onlayn-do'konida 10 ta modul bor edi. 1000 ta bugning 720 tasi faqat ikkitasida: to'lov va yetkazib berish. Sababi β bu modullar tashqi tizimlarga (bank, taxi API) bog'langan va murakkab.
Agar bir joyda bug ko'p topilayotgan bo'lsa β yana qidiring. Bu yerda hali ko'p bug bor. Yangi dasturchi kodi va murakkab integratsiyalarga alohida e'tibor bering.
Bir xil testlarni qayta-qayta ishlatsangiz β ular yangi buglarni topmaydi. Dehqonchilikda bir xil pestitsidni qo'llash zararkunandalarga moslashish imkonini berishi kabi.
Bir IT kompaniyada 2 yil davomida 500 ta bir xil test ishlatilardi. Hammasi yashil. Lekin foydalanuvchilar shikoyat qilardi: "Ilova sekin", "Kechqurun yopiladi". Testlar funksional narsalarni tekshirardi, lekin tezlik va barqarorlikni emas.
Test case'laringizni "tirik hujjat" deb biling. Har 3-6 oyda tahlil qiling: haligacha kerakli narsalarni tekshiryaptimi? Yangi senariylar qo'shing.
Bank ilovasini va o'yinni bir xil usulda test qilib bo'lmaydi. Har loyihaning o'z yondashuvi kerak.
Payme β har tranzaksiya 3 xil tekshiruvdan o'tadi, hujjatlash to'liq. Mobil o'yin β tez release, exploratory testing ko'p. Tibbiy qurilma β 100% talablarga muvofiqlik, sertifikatlash shart.
"Eng yaxshi usul" yo'q. Sizning loyihangiz uchun nima yaxshi ekanini tushuning. Internetda o'qigan narsalarni ko'r-ko'rona qo'llamang.
Siz barcha bug'larni tuzatdingiz, testlar o'tdi β lekin bu dastur foydalanuvchiga kerak ekanini bildirmaydi. Mukammal ishlaydigan, lekin kerak bo'lmagan mahsulot β bekor urinish.
Bir davlat idorasi yangi elektron tizim yaratdi. Barcha talablar bajarildi, 0 ta critical bug, yuklamaga bardoshli. Lekin xodimlar foydalanmadi β interfeys noqulay, ish jarayoniga mos kelmaydi edi.
"Talablarga muvofiqmi?" dan tashqari, "foydalanuvchiga kerakmi?" deb ham so'rang. Faqat texnik sifat emas β real foydalanuvchi tajribasi ham muhim.
Chap tomondagi vaziyatni bosing, keyin o'ng tomondan mos prinsipni tanlang. Jami 5 ta juft.
Bu savollar O'zbekistondagi IT kompaniyalarda (Click, Uzum, EPAM, Exadel) QA testor lavozimiga intervyularda tez-tez so'raladi. Har biriga javob tayyorlang β suhbat paytida ishonchli gapirasiz.
π‘ Har savol ustiga bosing β tayyor javob va maslahatni ko'rasiz.
Javob shabloni: "Testlashning 7 ta fundamental prinsipi mavjud. Ular ISTQB tomonidan belgilangan va barcha QA testorlar ular haqida bilishi kerak. Bular: [sanab bering]..."
Maslahat: Hamma 7 tasini yod ayting. Keyin intervyu oluvchi so'raydi: "Qaysi biri eng muhim?" β bu yerda o'z fikringizni aytish mumkin. Ko'pchilik "Early testing" va "Exhaustive testing impossible" ni tanlaydi.
Javob: "Biz testlar orqali bug'lar borligini isbotlashimiz mumkin, lekin ularning yo'qligini isbotlay olmaymiz. Hatto 1000 ta test muvaffaqiyatli o'tsa ham, biz sinalmagan senariylarda bug bo'lishi mumkin."
Qo'shimcha: Misol keltiring β "Masalan, Click'da 1000 ta test o'tgan, lekin iPhone Safari'da aniq kombinatsiya sinalmagani uchun bug chiqqan."
Javob: "Barcha mumkin bo'lgan input kombinatsiyalarini sinab ko'rish matematik jihatdan imkonsiz. Oddiy login formasi uchun ham millionlab variantlar bor. Shuning uchun biz risk-based va test texnikalaridan foydalanamiz β eng muhim stsenariylarni tanlab sinaymiz."
Professional qo'shimcha: "Misol uchun, Equivalence Partitioning va Boundary Value Analysis texnikalari yordamida biz 1000 ta testni 10 tagacha kamaytirishimiz mumkin β va shu bilan ham 90% bug'larni topamiz."
Javob: "Early testing β bu testlash faoliyatini SDLC ning erta bosqichlarida boshlash. Bu Shift Left yondashuvining asosidir."
Asoslash: "Bug'ni erta topish qancha arzon. Talablar hujjatida topilgan bug β bir necha daqiqada tuzatiladi. Production'da topilgan bug β minglab dollar va reputatsiya yo'qotish."
Amaliy misol: "Men testor sifatida faqat dastur tayyor bo'lgandan keyin kutmay, talablarni o'qish bosqichida ham ishtirok etaman va savollar beraman."
Javob: "Bug'lar tasodifiy tarqalmaydi. Ular 'xavfli' joylarda to'planadi β odatda 80% bug'lar 20% modullarda bo'ladi (Pareto prinsipi)."
Qayerda xavfli joylar?
Xulosa: "Agar men bir modulda ko'p bug topsam, o'sha yerda yana qidirma davom etaman β bu yerda hali ko'p bo'lishi mumkin."
Javob: "Agar bir xil testlarni qayta-qayta ishlatsangiz, ular yangi bug'larni topmaydi. Dehqonchilikda bir xil pestitsid zararkunandalarga moslashish imkonini berishi kabi."
Yechim: "Test case'larni muntazam yangilab turish, yangi senariylar qo'shish, boshqa texnikalardan foydalanish."
Muhim eslatma: "Lekin regression testing uchun bir xil testlar β bu maqsadli va foydali. Chunki regression testning maqsadi β eski funksionallik ishlashda davom etayotganini tasdiqlash."
Javob: "Bug'larning yo'qligi mahsulot muvaffaqiyatini kafolatlamaydi. Mukammal ishlaydigan, lekin foydalanuvchiga kerak bo'lmagan mahsulot β muvaffaqiyatsizlikdir."
Verification vs Validation:
Xulosa: "Testor faqat texnik buglarni emas, foydalanuvchi tajribasini ham kuzatishi kerak."
Prinsiplar β bu nazariya emas, amaliy fikrlash tarzi. TestShop'da ularning har birini o'z ko'zingiz bilan ko'rishingiz mumkin.
Bu saytda 10 ta bug bor. Ularni topish uchun 7 prinsipdan foydalaning.
π TestShop'ga o'tishIntervyuda "prinsiplarni amaliyotda qo'llaganingizni aytib bering" deb so'rashadi. Shu TestShop tajribangizni aytsangiz β intervyu oluvchi e'tirof qiladi. Chunki siz nazariya emas, amaliy tajriba haqida gapirasiz.
Ushbu darsdan eslab qolishingiz kerak bo'lgan eng muhim g'oyalar