मेन्यू

टेस्ट परिदृश्य बनाम टेस्ट केस: इनमें क्या अंतर है?

test scenario vs test case

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

टेस्ट परिदृश्य बनाम टेस्ट केस के बीच अंतर।

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

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

टेस्ट परिदृश्य बनाम टेस्ट केस

4 साल बाद , कंपनी को एक परीक्षण परियोजना प्राप्त हुई, जहां एकमात्र बाधा समय था और एकमात्र उम्मीद पूर्ण प्रमाण था परिक्षण।

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

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

आप क्या सीखेंगे:

क्या टेस्ट मामलों को टेस्ट परिदृश्य के साथ तेजी से बदला जा रहा है?

समय के साथ, जैसा कि सब कुछ बदल रहा है, सॉफ्टवेयर उद्योग और प्रक्रियाओं में भी बहुत बदलाव आया है।

सॉफ्टवेयर परीक्षण में परीक्षण मामलों के प्रकार

पारंपरिक झरना तथा वी-मॉडल इसकी जगह फुर्तीले और पुनरावृति वाले मॉडल बनाए जा रहे हैं। प्रलेखन आवश्यक है लेकिन समय सीमा को पूरा करने और प्रक्रिया को आसान और पारदर्शी बनाने के लिए, प्रलेखन के तरीके को बदला जा सकता है।

जब परीक्षण मामलों का प्रलेखन महत्वपूर्ण है?

  1. क्लाइंट ने परियोजना के भाग के समान ही मांगा है।
  2. कोई समय की कमी नहीं है (मुझे नहीं लगता कि यह संभव है)।
  3. परीक्षक उत्पाद के लिए नए या अज्ञात हैं।
  4. कंपनी की नीति (मेरा दृढ़ विश्वास है कि इसे बदला जा सकता है)।

मुझे आपके साथ एक अनुभव साझा करें:

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

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

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

उनके अनुसार, इस बारे में सोचने के लिए अधिक कुछ नहीं था क्योंकि हमने सभी परिदृश्यों को कवर किया था। और उन्हें समझाने के लिए एक बॉक्स से बाहर निकलें और अधिक विचार उत्पन्न करें वास्तव में कठिन था।

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

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

एक और अनुभव:

साप्ताहिक टीम चुनौती गतिविधि के दौरान, हमने आवेदन की घोषणा की और टीम के सदस्यों को परीक्षण परिदृश्यों में डालने के लिए कहा।

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

मेरे अनुभव का पक्ष लेने के लिए, मैं एक उदाहरण प्रस्तुत करना चाहूंगा।

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

लेकिन अगर परीक्षण परिदृश्यों को लिखा जाए, तो यह नीचे की तरह 10 लाइनों का मामला होगा:

उच्च-स्तरीय परिदृश्य: कार्यक्षमता में प्रवेश करें
निम्न-स्तरीय परिदृश्य :

1. जाँच करने के लिए अनुप्रयोग लॉन्च हो रहा है
2. लॉगिन पृष्ठ पर पाठ सामग्री की जांच करने के लिए
3. उपयोगकर्ता नाम क्षेत्र की जांच करने के लिए
4. पासवर्ड फ़ील्ड की जांच करने के लिए
5. लॉग इन बटन की जांच करने और बटन की कार्यक्षमता को रद्द करने के लिए

बग रिपोर्ट कैसे दर्ज करें

यह सभी देखें=> वेब और डेस्कटॉप अनुप्रयोगों के परीक्षण के लिए 180+ नमूना परीक्षण परिदृश्य।

जैसा कि हम सभी समय से कम हैं, परीक्षण परिदृश्य उस पुराने समय के IODEX के बजाय दर्द निवारक स्प्रे के रूप में काम करते हैं। और फिर भी, प्रभाव समान है।

टेबुल प्रारूप में टेस्ट परिदृश्य बनाम टेस्ट केस के बीच अंतर

अंत में, मैं टेस्ट परिदृश्य बनाम टेस्ट केस के बीच अंतर को संक्षेप में बताना चाहूंगा:

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

निष्कर्ष

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

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

हमेशा की तरह, हम आपके विचारों और प्रश्नों का स्वागत करते हैं। में धुन दें।

PREV ट्यूटोरियल | अगले ट्यूटोरियल

अनुशंसित पाठ

^