𝟭𝟬 𝗖𝗲𝗿𝘁𝗶𝗳𝗶𝗰𝗮𝘁𝗲𝘀 𝗪𝗮𝗹𝗮 𝗩𝗮𝗵 𝗧𝗲𝘀𝘁𝗲𝗿 𝗝𝗼 𝗘𝗸 𝗕𝘂𝗴 𝗕𝗵𝗶 𝗡𝗮𝗵𝗶 𝗗𝗼𝘂𝗻𝗱𝗵 𝗣𝗮𝘆𝗮
आपके पास हर तरह का सर्टिफिकेशन है। ISTQB, ScrumMaster, Cloud, और Security। आपका रिज्यूमे संक्षिप्त शब्दों (acronyms) की एक दीवार है।
लेकिन आप एक भी ऐसा टेस्ट नहीं लिख सकते जो असली बग ढूंढ सके।
पिछली तिमाही में मैंने एक उम्मीदवार का इंटरव्यू लिया। वे केवल थ्योरी की बात कर रहे थे। उन्होंने V-model और shift-left का ज़िक्र किया। जब मैंने उनसे उनके द्वारा लिखे गए किसी ऐसे टेस्ट को दिखाने के लिए कहा जिसने कोई बग पकड़ा हो, तो वे चुप रहे।
उन्होंने कभी ऐसा टेस्ट नहीं लिखा था जिससे कुछ टूट सके। वे केवल वही टेस्ट लिखते थे जो पास हो जाते थे।
सर्टिफिकेशन आपकी याददाश्त का परीक्षण करते हैं। बग आपकी सोच का परीक्षण करते हैं।
सर्टिफिकेशन आपको शब्दावली और संरचना प्रदान करते हैं। वे रिक्रूटर की स्क्रीनिंग पास करने में आपकी मदद करते हैं। वे आपको डिफेक्ट्स ढूंढना नहीं सिखाते।
परीक्षा के प्रश्न एक सिलेबस का पालन करते हैं। वास्तविक एप्लिकेशन ऐसा नहीं करते। एक लॉगिन फॉर्म का कोई सिलेबस नहीं होता। इसमें अजीबोगरीब edge cases होते हैं, जैसे सर्वर क्लॉक का चार मिनट पीछे होना या विशिष्ट टाइमिंग संबंधी समस्याएं।
सर्टिफाइड टेस्टर एक चेकलिस्ट का पालन करता है। वे आवश्यकताओं (requirements) के आधार पर टेस्ट लिखते हैं और उन्हें पास या फेल के रूप में मार्क करते हैं।
बग हंटर टेस्टिंग को एक जांच (investigation) की तरह मानता है। वे एक परिकल्पना (hypothesis) के साथ शुरुआत करते हैं। वे एप्लिकेशन को गलत साबित करने की कोशिश करते हैं।
मानसिकता में अंतर देखें।
एक मानक टेस्ट 'happy path' की जांच करता है:
- प्रोडक्ट्स पर जाएं।
- कार्ट में जोड़ें।
- वैध कार्ड विवरण दर्ज करें।
- ऑर्डर कन्फर्मेशन की अपेक्षा करें।
यह टेस्ट साबित करता है कि फीचर तब काम करता है जब सब कुछ सही हो। यह कभी भी बग नहीं ढूंढ पाएगा।
एक बग हंटर टेस्ट संदिग्ध होता है:
- टाइपो (लिखने की गलती) के साथ कार्ड नंबर दर्ज करें।
- एरर मैसेज की अपेक्षा करें।
- जांचें कि क्या ऑर्डर कन्फर्मेशन फिर भी नहीं आया।
दूसरा टेस्ट यह मानकर चलता है कि एप्लिकेशन फेल हो जाएगा। यह पूछता है: "यह कहाँ टूटता है?"
कई टेस्टर्स के अनुभव में कमी होती है, उनके रिज्यूमे में नहीं। आपने खराब डेटा या डाउन एनवायरनमेंट के कारण टेस्ट फेल होते देखे हैं। आपने टेस्ट इसलिए फेल होते नहीं देखे क्योंकि आपने लॉजिक में कोई कमी ढूंढ ली हो।
नए एग्जाम्स के लिए पढ़ाई करना बंद करें। फेल होने के लिए डिज़ाइन किए गए टेस्ट लिखकर इस कमी को दूर करें।
इस अभ्यास को आजमाएं: एक फीचर चुनें। उसे तोड़ने (break करने) की कोशिश करने में एक घंटा बिताएं।
सर्च फीचर के लिए:
- gibberish क्वेरीज़ का टेस्ट करें।
- SQL injection कैरेक्टर्स का टेस्ट करें।
- empty strings का टेस्ट करें।
फ़ाइल अपलोड के लिए:
- बिना एक्सटेंशन वाली फ़ाइलों का टेस्ट करें।
- बहुत बड़ी फ़ाइल साइज़ का टेस्ट करें।
- malicious फ़ाइल नामों का टेस्ट करें।
मैंने एक बार 95% कवरेज वाले एक पेमेंट सिस्टम पर काम किया था। हर टेस्ट पास हो गया। फिर, राउंडिंग एरर (rounding error) की वजह से प्रोडक्शन में सिस्टम ने पैसे गंवा दिए। हमारे टेस्ट 'हैप्पी पाथ' (happy path) को कवर कर रहे थे, लेकिन किसी ने मैथ लॉजिक (math logic) को टेस्ट करने के बारे में नहीं सोचा।
अब, मैं हर टेस्ट की शुरुआत एक सवाल से करता हूँ: "इस फीचर के चुपचाप (silently) फेल होने के लिए क्या होना ज़रूरी होगा?"
पोर्टफोलियो साइट न बनाएं। अपना LinkedIn अपडेट न करें।
एक ऐसा टेस्ट लिखें जिसे फेल होने के लिए ही डिज़ाइन किया गया हो। अगर यह पास हो जाता है, तो आपके पास सुरक्षा की गारंटी है। अगर यह फेल हो जाता है, तो आपने एक बग ढूंढ लिया है।
आपने क्या टेस्ट किया, कैसे टेस्ट किया, और आपको क्या मिला, इसे लिख लें। यही इस बात का असली प्रमाण है कि आप सोच सकते हैं।
इस हफ्ते आप बग्स ढूंढने की अपनी क्षमता साबित करने के लिए कौन सा एक टेस्ट लिखेंगे?
Optional learning community: https://t.me/GyaanSetuAi