हम अपनी फर्म पर ऐसा नहीं करते हैं, लेकिन मेरे एक मित्र का कहना है कि उसके प्रोजेक्ट मैनेजर ने प्रत्येक डेवलपर को उत्पाद के क्यूए में जाने से ठीक पहले जानबूझकर बग को जोड़ने के लिए कहा। यह इस तरह काम करता है:
- उत्पाद के क्यूए में जाने से ठीक पहले, विकास टीम कोड में यादृच्छिक स्थानों पर कुछ जानबूझकर बग जोड़ती है। वे यह सुनिश्चित करने के लिए मूल, काम करने वाले कोड का ठीक से बैकअप लेते हैं कि उन बग्स को अंतिम उत्पाद के साथ शिप नहीं किया गया है।
- परीक्षकों को भी इसके बारे में सूचित किया जाता है। इसलिए वे कड़ी परीक्षा करेंगे, क्योंकि वे जानते हैं कि वहाँ कीड़े मौजूद हैं और उन्हें नहीं ढूंढना अक्षमता का संकेत माना जा सकता है।
- यदि बग (जानबूझकर या अन्यथा) पाया गया है, तो उन्हें विकास टीम को ठीक करने के लिए सूचित किया जाएगा। विकास टीम दूसरे स्तर के क्यूए में जाने से ठीक पहले कोड के संबंधित अनुभाग में एक और जानबूझकर बग जोड़ती है। परियोजना प्रबंधक का कहना है कि एक परीक्षक को एक डेवलपर की तरह सोचना चाहिए और उसे उन खंडों में नए बग की उम्मीद करनी चाहिए जहां बदलाव किए गए थे।
खैर, यह है कि यह कैसे जाता है। वे कहते हैं कि इस दृष्टिकोण के निम्नलिखित फायदे हैं।
- परीक्षक हमेशा अपने पैर की उंगलियों पर होंगे और वे पागलों की तरह परीक्षण करेंगे। इससे उन्हें छिपे (अनजाने) बगों को खोजने में मदद मिलती है ताकि डेवलपर्स उन्हें ठीक कर सकें।
- परीक्षक कीड़े पर फ़ीड करते हैं। किसी भी कीड़े को नहीं ढूंढने से उनके मनोबल पर असर पड़ेगा। इसलिए उन्हें खोजने के लिए एक आसान देने से उनके मनोबल में मदद मिलेगी।
यदि आप उस परिदृश्य को नजरअंदाज करते हैं जहां इन जानबूझकर बगों में से एक को अंतिम उत्पाद के साथ भेज दिया जाता है, तो इस दृष्टिकोण को अपनाने से पहले हमें क्या विचार करना चाहिए?
कुछ स्पष्टीकरण:
- वे स्रोत नियंत्रण में मूल कोड का ठीक से बैकअप लेते हैं।
- जब कोई परीक्षक जानबूझकर बग पाता है, तो विकास टीम इसे अनदेखा कर देती है। यदि परीक्षक को एक अनजाने (मूल) बग का पता चलता है, तो विकास टीम पहले यह जांचती है कि क्या यह किसी जानबूझकर बग के कारण हुआ है। यही है, विकास टीम सबसे पहले मूल कार्य कोड पर पुन: पेश करने की कोशिश करती है और यदि वे कर सकते हैं तो इसे ठीक करने की कोशिश करते हैं।
- बस क्यूए और विकास टीम के बीच संबंधों के मुद्दों की अनदेखी करें। मैंने विशेष रूप से प्रोग्रामर्स पर यह सवाल पूछा था , द वर्कप्लेस पर नहीं । विचार करें कि क्यूए और विकास टीम के बीच अच्छा तालमेल है, और वे काम के घंटों के बाद एक साथ पार्टी करते हैं। प्रोजेक्ट मैनेजर एक अच्छा, पुराना सज्जन व्यक्ति है जो दोनों टीमों (गॉडसेंड) का समर्थन करने के लिए हमेशा तैयार रहता है।
59
"एक परीक्षण को एक डेवलपर की तरह सोचना चाहिए" ... दिलचस्प। मुझे लगा कि यह स्पष्ट है कि एक परीक्षक को एक डेवलपर की तरह नहीं बल्कि एक उपयोगकर्ता की तरह सोचना चाहिए।
—
14
अगर जानबूझकर पेश किया गया बग किसी अन्य बग को कवर करता है तो क्या हो सकता है कि परीक्षक जान सकते थे कि जानबूझकर बग को पेश नहीं किया गया है? उदाहरण के लिए, मान लीजिए कि कोड का एक हिस्सा एक समस्या है और विकास दल इस बग से अनजान है। एक प्रोग्रामर उस स्थान पर एक जानबूझकर फ़ॉस्टपोस्ट त्रुटि डालने का फैसला करता है। अब कोड में डबल फेलपोस्ट त्रुटि है। मान लीजिए कि परीक्षक त्रुटि का पता लगाते हैं, लेकिन यह मत देखिए कि यह एक दोहरी बाड़ त्रुटि है। बधाई! परीक्षकों को एक बग मिला। मूल फ़ेडपोस्ट त्रुटि को रोकने के लिए मूल कोड को पुनर्स्थापित किया जाएगा। ऊप्स!
—
डेविड हैमेन
मैं क्यूई हूं। मुझे असली कीड़े मिलेंगे, धन्यवाद। मैं इस कंपनी को ऐसे छोड़ देता हूँ जैसे आग लगी हो। कोई भी (जानबूझकर) मेरा समय बर्बाद नहीं करता है।
—
अर्जुनशंकर
"हम अपनी फर्म पर ऐसा नहीं करते हैं, लेकिन मेरे एक मित्र का कहना है कि उनके सीटीओ ने प्रत्येक उत्पाद प्रबंधक को प्रत्येक सुविधा विकास चक्र की शुरुआत में अतिरिक्त सुविधाएँ जोड़ने के लिए कहा ..."
—
मार्को
मुझे संदेह है कि जानबूझकर बग जोड़ने से जोखिम पैदा होता है। क्या होगा यदि एक जानबूझकर बग वास्तव में कुछ अनपेक्षित रूप से ठीक करता है? सकारात्मक साइड इफेक्ट की सूचना नहीं है, कोड हटा दिया जाता है और एक वास्तविक बग क्यूए के माध्यम से हो जाता है। उनकी प्रकृति से, ये अंतिम मिनट "जानबूझकर बग" पर विचार किया जाएगा, यदि नहीं, तो कीड़े बहुत डेवलपर समय बर्बाद कर रहे हैं।
—
जोडेल