परीक्षण कीड़े खोजने के लिए सीमित क्यों नहीं है

( टेस्टर स्टोरी साइकिल से )

सभी को नमस्कार। जैसा कि आपने देखा होगा, हर महीने OTUS में पाठ्यक्रम शुरू करने की तीव्रता बढ़ जाती है, और मार्च में विशेष रूप से उनमें से कई हैं। आज हम पाठ्यक्रम "वेब परीक्षण के स्वचालन" के लॉन्च के साथ मेल खाना चाहते हैं, जो मार्च के मध्य में शुरू होता है। अच्छी पढाई हो।



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

मुख्य विचार यह है कि परीक्षण विधि उन त्रुटियों के प्रकार से निर्धारित होती है जिन्हें आपको खोजने की आवश्यकता है।

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

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

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

प्रभावी त्रुटि सुधार की कुंजी, मेरी राय में, इन त्रुटियों को जल्द से जल्द ढूंढना है, आदर्श रूप में जैसे ही वे दिखाई देते हैं। यद्यपि मेरे दृष्टिकोण से, यहां तक ​​कि "त्रुटि की गुणवत्ता" उच्चतम माप से दूर है।

हम त्रुटि की गुणवत्ता के लिए बहुत महत्व देते हैं, लेकिन क्या यह वास्तव में है कि उनकी संख्या आमतौर पर महत्वहीन है?

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

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

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

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

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

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

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

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

इस अंतर को समझने और तैयार करने में सक्षम होने के कारण, परीक्षक "सत्यापन" और "परीक्षण" के बीच बेकार (केवल लेखक की राय) मतभेदों से परे जा सकते हैं और इसके बजाय मानव और स्वचालित दोनों तरीकों का पता लगाने की रचनात्मक समझ का निर्माण करते हैं, जो अनुमति देते हैं लोगों को तेज़ी से बेहतर निर्णय लेने में मदद करने के लिए परीक्षण।

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