परीक्षण के बारे में 5 मिथक

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

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

ज़रा देखिए और बताइए कि आप मुझसे सहमत हैं या नहीं।

मिथक एक: परीक्षण उबाऊ है।

अक्सर आप सुनते हैं कि परीक्षण सेक्स की तरह है: यदि यह आनंद नहीं देता है, तो आप इसे गलत कर रहे हैं। एक उबाऊ और नीरस गतिविधि के रूप में परीक्षण का मिथक मीडिया में फैला हुआ है, जिसमें सॉफ्टवेयर उद्योग की असेंबली लाइन में श्रमिकों के रूप में परीक्षक देखे जाते हैं। वास्तव में, परीक्षण में आपको हर दिन कई नई और दिलचस्प समस्याओं को हल करना होगा। यहाँ माइकल बोल्टन का एक उद्धरण है, ऊपर दिए गए अजीब परिणाम को संक्षेप में लिखें:

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

मिथक दो: परीक्षण आसान है।

यह अक्सर कहा जाता है कि सॉफ्टवेयर परीक्षण SO कठिन नहीं हो सकता है, क्योंकि नियमित उपयोगकर्ता लगातार कार्यक्रमों में त्रुटियां पाते हैं। वास्तव में, परीक्षण एक बहुत ही कठिन कौशल है, जो औसत व्यक्ति मास्टर नहीं कर सकता है। यहाँ Google के पैट्रिक कोपलैंड ने परीक्षक के आवश्यक गुणों के बारे में क्या कहा है:

“यह एक विशेष मानसिकता और एक विशेष जुनून है। परीक्षकों के लिए आयोजित 100 साक्षात्कारों में, मैंने मुख्य रूप से ध्यान आकर्षित किया: 1) समस्याओं को खोजने के लिए एक विशेष क्षमता की उपस्थिति और 2) परीक्षण के लिए एक जुनून, जो इस क्षमता के साथ एक व्यक्ति में मौजूद है। दूसरे शब्दों में, परीक्षक अपने काम से प्यार करते हैं और इसे अच्छे से करते हैं। वे ध्यान दें कि परीक्षण के दौरान उन समस्याओं को हल करना आवश्यक है जो बराबर हैं, और कभी-कभी जटिलता में भी बेहतर होती हैं, जिन्हें प्रोग्रामिंग के दौरान हल करना होता है । जो भगवान से परीक्षक है और नौकरी के बारे में सही है वह कभी भी काम के बिना नहीं रहेगा। ऐसे लोग सोने में अपने वजन के लायक होते हैं। "

मिथक तीन: परीक्षक सिर्फ बग ढूंढ रहे हैं।

परीक्षक वास्तव में बग ढूंढ रहे हैं, लेकिन यह उनके काम के एकमात्र लक्ष्य से दूर है। लेखक इस मिथक के बारे में बहुत अच्छी तरह से बोलता है, अंकुर के नाम से एक लेख freesoftwaretesting.info वेबसाइट पर प्रकाशित किया है:

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

मिथक चार: मशीनें परीक्षक की जगह लेंगी, और वे अनावश्यक हो जाएंगी।

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

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

मिथक पांच: परीक्षकों को डेवलपर्स के साथ नहीं मिलता है।

यह समझ में आता है कि यह मिथक इतना व्यापक क्यों है। यह एक बार गुरु जेम्स बाख के परीक्षण द्वारा लिखा गया था:

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

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

मैं मिथकों की सूची में जोड़ना चाहता हूं: मैंने प्रोग्रामर्स से ऐसा मिथक सुना है कि परीक्षक केवल एक पंक्ति में सभी बटन दबाकर बग की तलाश करते हैं, इनपुट और आउटपुट मापदंडों के बारे में भी सोचे बिना। सॉफ्टवेयर स्वचालन के बारे में कई मिथक हैं, उदाहरण के लिए:

• स्वचालन लागत को कम करता है;
• स्वचालन संसाधनों की कमी की समस्या को हल करता है;
• अधिक ऑटोटेस्ट्स, बेहतर;

या सबसे आम मिथक है कि परीक्षण एक सॉफ्टवेयर उत्पाद की गुणवत्ता में सुधार करता है। गुणवत्ता में सुधार करने के लिए, आपको इसे बनाने की आवश्यकता है, और परीक्षण केवल गुणवत्ता की जांच करता है। हां, बेशक, परीक्षकों ने सॉफ्टवेयर की गुणवत्ता की जांच की, त्रुटियां पाईं, एक परीक्षण रिपोर्ट, प्रोग्रामर तय किए, गुणवत्ता में सुधार हुआ। लेकिन परीक्षक सॉफ्टवेयर गुणवत्ता में सुधार नहीं करते हैं।

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

क्या परीक्षण मिथकों आप जानते हैं?


युपीडी। मेरे लेख में आपकी रुचि के लिए बहुत-बहुत धन्यवाद। मैं हब्र के पाठकों से मिथकों / विरोधी मिथकों / तथ्यों के एक जोड़े का सारांश दूंगा:
पोस्ट करनेवाले: evans2094
मिथक:

1. डेवलपर्स और प्रकाशक परीक्षक को सुनते हैं।
2. उत्पाद परीक्षण डिजाइन चरण में शुरू होता है और अपने पूरे जीवन चक्र में जारी रहता है।
विकास और परीक्षण कुछ हद तक एक हाथी की धुलाई की याद दिलाता है। यह पूरी तरह से और साफ तरीके से नहीं धोया जा सकता है, जबकि एक कान धोया जाता है - दूसरा पहले से ही कुछ में कवर किया गया है :) बेशक, यह पूरी तरह से तूफान परीक्षण द्वारा doused किया जा सकता है, लेकिन फिर सावधानीपूर्वक ग्राहक हाथी की पूरी सतह पर कुछ रगड़ पाएंगे ... लेकिन अगर यह पूरी तरह से एसिड में भिगो नहीं है, तो यह मर जाएगा :)

द्वारा पोस्ट किया गया: netmike
तथ्य:

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

नताल्यरुक से परिशिष्ट:

स्वचालन केवल उन मामलों में उचित है जहां मुख्य लागतें क्लिक हैं (स्थिर, कार्यशील कार्यक्षमता, जो पहले से ही स्पष्ट है कि परीक्षण कैसे करना है और जिसमें बड़ी संख्या में त्रुटियां नहीं हैं)

पोस्ट करनेवाले: graninas
मिथक:

मैं हैस्केल पर लिखता हूं और मुझे अपने कोड का परीक्षण नहीं करना पड़ता है, सब कुछ उसी तरह काम करता है।

पेट्रोपावेल ने कहा कि ये मिथक सार्वभौमिक हैं और इन्हें किसी भी पेशे में लागू किया जा सकता है:

मिथक एक: सफाई कमरे उबाऊ है।
एक उबाऊ और नीरस गतिविधि के रूप में हाउसकीपिंग का मिथक मीडिया में फैला हुआ है, जिसमें सफाईकर्मियों को कार्यालय मजदूर के रूप में देखा जाता है। वास्तव में, सफाई में आपको हर दिन कई नई और दिलचस्प समस्याओं को हल करना होगा। [लगभग। ट्रांस। उदाहरण के लिए एक कुर्सी पर गम चबाना]

मिथक दो: सफाई आसान है।
यह भी अक्सर कहा जाता है कि सफाई एसओ जटिल नहीं हो सकती है, सामान्य रूप से
लोग लगातार अपने अपार्टमेंट की सफाई करते हैं ...

मिथक तीन: क्लीनर सिर्फ कचरा उठा रहे हैं।
सफाईकर्मी वास्तव में कचरा उठा रहे हैं, लेकिन यह उनके काम के एकमात्र लक्ष्य से दूर है ...

मिथक चार: कारें क्लीनर को बदल देंगी, और वे अनावश्यक हो जाएंगे।
कंप्यूटर प्रौद्योगिकी के विकास के साथ, लोगों द्वारा परिसर की सफाई करने वाली राय जल्द ही गायब हो जाएगी और व्यापक रूप से ...

मिथक पांच: सफाई कर्मचारियों को कार्यालय के कर्मचारियों के साथ नहीं मिलता है।
यह समझ में आता है कि यह मिथक इतना व्यापक क्यों है ... हर कोई नहीं जानता कि कई सफाई कर्मचारी पूर्व कार्यालय कर्मचारी हैं ...

दुष्टों ने मेरे एक मिथक का खंडन किया कि परीक्षक सॉफ्टवेयर की गुणवत्ता में सुधार नहीं करते हैं:

मेरे नवाचारों की संख्या कस्टम से अनुप्रयोगों की तुलना में थोड़ा कम है। खैर, किसी तरह यह हुआ। सरल लोगों को तुरंत किया जाता है, जटिल वाले - एक जोड़े के लिए एक ही अनुरोध के बाद।

पुनश्च। मेरे सहयोगी आंद्रेईमेलेलियनोव के अनुवाद के लिए बहुत बहुत धन्यवाद