परीक्षक का काम क्या है?

ट्विटर पर आज, मेलिसा बगई (@melbugai) ने सवाल पूछा: "परीक्षक का काम क्या है?" 140 चरित्रों पर संक्षिप्त जवाब देने के कई प्रयासों के बाद, मैंने ब्लॉग पर इसके बारे में लिखने का फैसला किया।





परीक्षक का कार्य उत्पाद को बेहतर बनाना है।



मैं मानता हूं कि इस परिभाषा को बहुत सरल बनाया गया है और यह बेहतर ढंग से समझाने की कोशिश करेगा कि यहां क्या है।



एक परीक्षक सिर्फ समस्या निवारण की तुलना में बहुत अधिक है। मैं ऐसे परीक्षकों को जानता था जो बग ढूंढने में बहुत अच्छे हैं, लेकिन अंततः वे इन बगों को उनके द्वारा परीक्षण किए गए उत्पाद के लिए महत्वपूर्ण सुधार में बदलने में विफल होते हैं। ऐसा क्यों है?



कभी-कभी ऐसा इसलिए होता है क्योंकि परीक्षक इस त्रुटि का खराब बचाव करते हैं। वे डेवलपर्स, अधिकारियों और हितधारकों को समझाने में सक्षम नहीं हैं कि बग को ठीक करने की आवश्यकता है। वे प्रयास करते हैं, लेकिन उन्हें अनदेखा करते हैं, और तब वे नाराज हो जाते हैं जब उत्पाद में कोई त्रुटि मिलती है और बाकी सभी को परेशान करना शुरू कर देता है।



ऐसा होता है कि यह परीक्षक में विश्वास की हानि के परिणामस्वरूप होता है। उनका मानना ​​है कि प्रत्येक बग उन्हें लगता है, यहां तक ​​कि कुछ बेहद जटिल प्रतिबंध बग जो किसी पाठ क्षेत्र में 10 मिलियन वर्णों में प्रवेश करने की कोशिश करते समय होता है, महत्वपूर्ण है और इसे तुरंत ठीक किया जाना चाहिए। वे हर किसी पर बरसते हैं जो उन्हें शांत करने की कोशिश करता है। यह तब तक होता है जब तक कि हर कोई उनके बीमार न हो जाए और उनकी सभी त्रुटि रिपोर्ट को नजरअंदाज न कर दिया जाए।



अन्य मामलों में, समस्या की जड़ परीक्षकों और विकास टीम के बीच खराब समझ में है। शायद वे डेवलपर्स से बहुत पीछे हैं, और बाद वाले ने कोड के क्षेत्र में रुचि खो दी है जिसमें परीक्षण किया जाता है। या, शायद, परीक्षक विकास टीम से आगे हैं और उन चीजों की जांच करते हैं जो मौजूदा स्थिति में छूने का कोई मतलब नहीं है।



ये सभी कौशल के स्तर के बारे में प्रश्न हैं जिन्हें तब प्रशिक्षित किया जा सकता है, प्रशिक्षित किया जा सकता है और इसमें सुधार किया जा सकता है। अगला कारण मुझे और उत्साहित करता है।



कभी-कभी चीजें इस तथ्य के कारण गलत हो जाती हैं कि परीक्षक इन सभी चीजों को अपने काम का हिस्सा नहीं मानते हैं।



“मुझे सिर्फ गलतियाँ मिलीं। आप उनके साथ क्या करते हैं, मेरा कोई काम नहीं है। ”



मुझे सॉफ्टवेयर परीक्षण के लिए इस तरह का एक अलग दृष्टिकोण पसंद नहीं है। परीक्षण किए गए उत्पाद के लिए सतर्कता के परीक्षकों को प्रशिक्षित करना असंभव है, इसके लिए जिम्मेदारी। इसके लिए, सबसे पहले, उन्हें अपने सिर को शरीर के अंधेरे गुहा से बाहर निकालना होगा जिसमें उन्हें अनुकूलित किया गया है।



"लेकिन ... लेकिन ...", आप आपत्ति करने की कोशिश करते हैं। कम से कम इस तथ्य से कि कोई अंतर नहीं है, क्योंकि वे उन परीक्षकों के समान बग ढूंढते हैं जो परियोजना की परवाह करते हैं।



खैर, शायद यह अभी भी मामला नहीं है। वे समान त्रुटियां नहीं पाएंगे। उनका परीक्षण यह दिखाने पर ध्यान केंद्रित करेगा कि उन्होंने सभी कोडों का पर्याप्त रूप से परीक्षण किया है, न कि उन बगों पर ध्यान केंद्रित करने के लिए जो विकास की गुणवत्ता में सुधार और अंतिम उत्पाद को बेहतर बनाने में सबसे महत्वपूर्ण हैं।



परीक्षकों को अच्छे कौशल के साथ देखना दुखद है, लेकिन जो अपने काम के परिणामों के प्रति इतने उदासीन हैं कि वे अधिक दूर के दृष्टिकोण से दक्षता को देखने की कोशिश भी नहीं करते हैं। ऐसा करने के बाद, ऐसे परीक्षकों को समझ में आ जाएगा कि वे, बाकी विकास प्रतिभागियों की तरह, सामान्य कारण में योगदान करते हैं।



टीम के विफल होने पर परीक्षक सफल नहीं हो सकता।



उत्पाद को बेहतर नहीं बनाने वाले परीक्षक विफल होते हैं। यह पूरी तरह से उनकी गलती नहीं हो सकती है: यह हो सकता है कि संगठन ने बस उन्हें बहुत अनदेखा किया। या यह हो सकता है कि डेवलपर्स केवल संकीर्णतावादी गधे हैं जो आलोचना को स्वीकार करने में सक्षम नहीं हैं। यह हो सकता है कि प्रबंधक अंतिम उपयोगकर्ता लाइसेंस समझौते में एक सामान्य टाइपो से एक महत्वपूर्ण त्रुटि को भेदने में असमर्थ हैं। जैसा कि हो सकता है, यह सब महत्वपूर्ण नहीं है। यदि, उपरोक्त सभी के कारण, आप एक परीक्षक के रूप में सफलता प्राप्त करने में असमर्थ थे ...



तुम अभी भी असफल हो। आपने अपना काम पूरा नहीं किया है।