परीक्षण बग खोज नहीं है!

बहुत से लोग सोचते हैं कि सॉफ़्टवेयर परीक्षण बग की खोज है। कभी-कभी मैं परीक्षकों से कहता हूं: "जितना संभव हो उतनी गलतियां खोजने की कोशिश मत करो, जितना संभव हो उतना कम याद करने की कोशिश करो!", और वे मुझे नहीं समझते: क्या अंतर है?

और अंतर बहुत बड़ा है! इस लेख में मैं आपको बताना चाहता हूं कि इसमें क्या हैं और वास्तविक उपयोगी परीक्षण के लिए आपको किन उपकरणों का उपयोग करने की आवश्यकता है।

त्रुटि खोज क्या है?

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

इस मामले में मैं किन क्षेत्रों का परीक्षण करूंगा? सबसे पहले, सबसे अस्थिर। अक्सर वे अस्थिर होते हैं क्योंकि वे कम प्राथमिकता वाले होते हैं, लेकिन इससे कोई फर्क नहीं पड़ता, कीड़े की संख्या बहुत अधिक महत्वपूर्ण है।

यदि मैं बग को पुन: पेश करने के लिए एक मुश्किल सामना करता हूं तो क्या होगा उनके शोध के लिए आरओआई को सिर में बहुत जल्दी माना जाता है। मुझे उसके साथ क्यों परेशान होना चाहिए अगर उसी समय के दौरान मुझे 3 कम महत्वपूर्ण मिल सकते हैं, लेकिन स्थापित करना आसान है?

मैं पहली बार कौन से परीक्षण करूंगा? कोनो, सबसे अ-मानक। लॉगिन फ़ील्ड "वॉर एंड पीस" में दर्ज करें, शून्य से विभाजित करें, प्रोफ़ाइल में .exe प्रारूप में एक प्रोफ़ाइल फ़ोटो डालें।

मैं आपको एक रहस्य बताऊंगा - कभी-कभी साक्षात्कार में परीक्षकों को "कैलकुलेटर का परीक्षण" करने के अनुरोध के जवाब में दिलचस्प और व्यावहारिक परीक्षण करते हैं, लेकिन पहले तीस के बीच कोई परीक्षण "चेक अतिरिक्त" और अन्य बुनियादी संचालन नहीं है।

यह ठीक वैसा ही है जैसे खोज में त्रुटि होती है - परीक्षण से कोई लेना-देना नहीं है।

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

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

इस मामले में मैं किन क्षेत्रों का परीक्षण करूंगा? स्वाभाविक रूप से, मैं उपयोगकर्ता के लिए सर्वोच्च प्राथमिकता के साथ शुरू करूंगा। यहां तक ​​कि अगर वे दृढ़ता से और सफलतापूर्वक काम करते हैं, तो मैं अभी भी मुख्य उपयोगकर्ता परिदृश्यों की जांच करूंगा ताकि किसी भी स्थिति में मुझे गंभीर समस्याएं न हों।

अगर मैं मुश्किलों में भागूं तो क्या होगा? उदाहरण के लिए, दोष को पुन: उत्पन्न करने के लिए एक कठिन, या उपयोगकर्ता की व्यावसायिक प्रक्रिया की समझ की कमी, या आवश्यकताओं की कमी के साथ? यदि यह एक महत्वपूर्ण कार्यात्मक है, तो मुझे पता चलेगा कि "क्या गलत है", "कैसे सही ढंग से।" नतीजतन, एक दोष स्थापित करने में बहुत समय लग सकता है, और बग / समय के दृष्टिकोण से परीक्षण दक्षता का परिणाम बहुत अधिक नहीं होगा, लेकिन मुझे उत्पाद, वास्तुकला, उपयोगकर्ताओं के बारे में अधिक गहराई से ज्ञान होगा।

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

परीक्षण और त्रुटि ढूँढना परिणाम

त्रुटियों की खोज के मामले में, अल्पावधि में, परिणाम अधिक होते हैं: अधिक बग तुरंत शुरू होते हैं।

लेकिन लंबे समय में, चीजें इतनी रसीली नहीं हैं:

• उत्पाद के बारे में गहराई से ज्ञान की कमी के कारण, मिस्ड दोष का% धीरे-धीरे बढ़ने लगता है
• विकास टीम पूर्णिमा में IE के तहत 144 बार एक ही बटन पर क्लिक करके प्राप्त डरावने-भयानक-समझ में नहीं आने वाले कीड़े को ठीक करने में व्यस्त है
• रिलीज कुछ खराब और अप्रिय उपयोगकर्ता कीड़े के लिए स्पष्ट हो जाता है
• लंबी अवधि में पाई गई त्रुटियों की संख्या गिर रही है

परीक्षण करने के लिए कीड़े खोजने से कैसे जाएं?

लंबे समय में प्रभावी और उपयोगी होने के लिए परीक्षण के लिए, आपको सरल नियमों का पालन करने और कुंजी परीक्षण उपकरणों का उपयोग करने की आवश्यकता है :

1. उत्पाद विश्लेषण और परीक्षण प्रलेखन

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

वे क्या देते हैं:

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

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

2. परीक्षण मूल्यांकन

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

सुधार करने के लिए हमेशा कुछ है, और एक निरंतर सुधार प्रक्रिया की कमी एक अपरिहार्य दलदल है।

3. टीम के साथ परीक्षण उद्देश्यों की चर्चा

बहुत से लोग सोचते हैं कि परीक्षण के कुछ पौराणिक लक्ष्य हैं। और यह कि वे हमेशा समान हैं।

कोई फर्क नहीं पड़ता कि कैसे!

प्रत्येक परियोजना में, कंपनी, टीम, लक्ष्य अपने हैं। क्या हर कोई उन्हें उसी तरह समझता है? क्या आपने उन्हें ज़ोर से बोला है?

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

4. उपयोगकर्ताओं और उनके व्यावसायिक प्रक्रियाओं को समझना

मेरे लिए, पहेली यह है कि यह कैसे संभव है, लेकिन फिर भी यह एक तथ्य है: अक्सर परीक्षक उपयोगकर्ता के बारे में कुछ भी जानने के बिना उत्पाद का परीक्षण करते हैं।

• इस उत्पाद का उपयोग कैसे किया जाता है?
• उसकी आखिर जरूरत क्यों है, वह किन समस्याओं का समाधान करता है?
• उपयोगकर्ताओं की औसत योग्यता क्या है?
• उपयोगकर्ता किन परिस्थितियों में काम करते हैं? किस पर्यावरण, उपकरण पर?

"औसत उद्योग" के बारे में अनुमान या विचार की कोई आवश्यकता नहीं है! परीक्षकों को सही मायने में अपने उपयोगकर्ताओं को जानना चाहिए। अक्सर वे विश्लेषकों को यह जानकारी नहीं देते हैं। इस पर सोचो! उपयोगकर्ता को जानने के बिना, सामान्य तरीके से उत्पाद का परीक्षण करना असंभव है।

5. तकनीकी योग्यता और वास्तुकला की समझ

वर्णन करने के लिए, मैं एक बग दूंगा जो हाल ही में मुझे एक बग ट्रैकर में लाया गया था:
फ़ायरफ़ॉक्स ब्राउज़र में परीक्षण किए गए उत्पाद http: //****.ru की वेबसाइट पर जाएं
उपयोगकर्ता नाम और पासवर्ड दर्ज करें
उसी कंप्यूटर से ओपेरा में लॉग इन करें
लॉगिन और पासवर्ड को फिर से दर्ज करने के लिए पूछता है, स्वचालित रूप से लॉग इन नहीं करता है।

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

निष्कर्ष

कई डेवलपर्स को परीक्षक पसंद नहीं हैं। और वे इसे सही कर रहे हैं!

लेकिन अच्छे परीक्षक हर किसी को पसंद और सराहे जाते हैं। लेकिन परीक्षक, क्लिकर्स और बैगोडर्स नहीं!

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

और बल आपके साथ हो सकता है!