तय करें कि क्या टेस्ट करना है, अपने टेस्ट केस तय करें, और प्राथमिकताएं तय करें.
पिछली पोस्ट में, आपको टेस्टिंग की रणनीतियों, किसी ऐप्लिकेशन की जांच करने के लिए ज़रूरी टेस्ट की संख्या, और अपने संसाधनों को ध्यान में रखते हुए नतीजों पर ज़्यादा भरोसा करने के लिए सबसे सही विकल्प ढूंढने का तरीका पता चला. हालांकि, इससे हमें यह पता चलता है कि कितनी जांच करनी है. आपको अब भी यह तय करना होगा कि किस चीज़ की जांच करनी है. यहां दी गई तीन शर्तों से, यह समझने में मदद मिल सकती है कि टेस्ट में क्या उम्मीद की जा सकती है. साथ ही, यह भी देखा जा सकता है कि किस तरह की टेस्टिंग और जानकारी का लेवल सबसे सही रहेगा:
- अपने 'हैप्पी पाथ' का ध्यान रखें. यह आपके ऐप्लिकेशन की सबसे सामान्य या मुख्य यूज़र स्टोरी है. इसमें आपके उपयोगकर्ता को तुरंत गड़बड़ी का पता चलेगा.
- जानकारी के लेवल को ध्यान से तय करें. अगर आपके इस्तेमाल के उदाहरण में कोई जोखिम है या गड़बड़ी होने पर ज़्यादा नुकसान हो सकता है, तो ज़्यादा जानकारी दें.
- जब भी हो सके, एंड-टू-एंड टेस्ट के बजाय, लोअर-लेवल टेस्ट को प्राथमिकता दें. जैसे, यूनिट और इंटिग्रेशन टेस्ट.
इस लेख के बाकी हिस्से में, इन शर्तों के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि टेस्ट केस तय करते समय ये शर्तें कैसे लागू होती हैं.
टेस्ट केस क्या होता है?
सॉफ़्टवेयर डेवलपमेंट में, टेस्ट केस, कार्रवाइयों या स्थितियों का क्रम होता है. इसे किसी सॉफ़्टवेयर प्रोग्राम या ऐप्लिकेशन के असरदार होने की पुष्टि करने के लिए बनाया जाता है. टेस्ट केस का मकसद यह पक्का करना है कि सॉफ़्टवेयर, प्लान के मुताबिक काम कर रहा है और उसकी सभी सुविधाएं और फ़ंक्शन सही तरीके से काम कर रहे हैं. सॉफ़्टवेयर टेस्टर या डेवलपर आम तौर पर ये टेस्ट केस बनाते हैं, ताकि यह पक्का किया जा सके कि सॉफ़्टवेयर तय की गई ज़रूरी शर्तों और खास बातों को पूरा करता है.
टेस्ट केस चलाने पर, सॉफ़्टवेयर कई तरह की जांच करता है, ताकि यह पक्का किया जा सके कि वह मनमुताबिक नतीजे दे रहा है या नहीं. ऐसा करते समय, टेस्ट इन टास्क को पूरा करता है:
- पुष्टि करना. सॉफ़्टवेयर की पूरी तरह से जांच करने की प्रोसेस, ताकि यह पक्का किया जा सके कि वह बिना किसी गड़बड़ी के काम कर रहा है. यह पता लगाना ज़रूरी है कि बनाया गया प्रॉडक्ट, फ़ंक्शन से जुड़ी सभी ज़रूरी शर्तों को पूरा करता है या नहीं. साथ ही, यह भी पता लगाना ज़रूरी है कि वह अपने मकसद को पूरा करता है या नहीं. इस मेट्रिक से इस सवाल का जवाब मिलता है: “क्या हम सही तरीके से प्रॉडक्ट बना रहे हैं?”
- पुष्टि करना. यह पक्का करने की प्रोसेस कि सॉफ़्टवेयर प्रॉडक्ट, ज़रूरी स्टैंडर्ड या उच्च-स्तर की ज़रूरी शर्तों को पूरा करता हो. इसमें यह जांच की जाती है कि प्रॉडक्ट की असल जानकारी, प्रॉडक्ट की उम्मीद के मुताबिक है या नहीं. असल में, हम इस सवाल का जवाब दे रहे हैं: “क्या हम उपयोगकर्ता की ज़रूरतों के हिसाब से सही प्रॉडक्ट बना रहे हैं?”
मान लें कि प्रोग्राम से उम्मीद के मुताबिक नतीजे नहीं मिलते. ऐसे में, टेस्ट केस ही मैसेंजर होगा. इसलिए, वह गलत नतीजे की रिपोर्ट करेगा. इसके बाद, डेवलपर या टेस्टर को समस्या की जांच करके उसका हल ढूंढना होगा. जांच और कार्रवाइयों को ऐसे पाथ के तौर पर देखें जिनका पालन कंप्यूटर करता है. भले ही, जांच का टाइप कुछ भी हो. जांच के लिए इस्तेमाल किए गए इनपुट डेटा या शर्तों के ग्रुप को "एक्विवलेंसी क्लास" कहा जाता है. उन्हें टेस्ट किए जा रहे सिस्टम से मिलता-जुलता व्यवहार या नतीजे मिलने चाहिए. किसी टेस्ट में चलाए गए खास पाथ अलग-अलग हो सकते हैं. हालांकि, ये आपके टेस्ट में की गई गतिविधियों और दावों से मेल खाने चाहिए.
टेस्ट पाथ: आम तौर पर इस्तेमाल होने वाले टेस्ट केस
सॉफ़्टवेयर डेवलपमेंट में, टेस्ट केस कोड को लागू करने की एक स्थिति होती है. इससे किसी खास तरह के व्यवहार की उम्मीद की जाती है और उसकी जांच की जाती है. आम तौर पर, टेस्ट केस बनाने के लिए तीन स्थितियां होती हैं.
पहला तरीका सबसे ज़्यादा जाना-पहचाना है. शायद आप इसका इस्तेमाल पहले से ही कर रहे हों. इसे हैप्पी पाथ भी कहा जाता है. इसे “हैप्पी डे सिनेरियो” या “गोल्डन पाथ” भी कहा जाता है. यह आपकी सुविधा, ऐप्लिकेशन या बदलाव के सबसे सामान्य इस्तेमाल के उदाहरण के बारे में बताता है. साथ ही, यह भी बताता है कि ग्राहक के लिए यह सुविधा कैसे काम करनी चाहिए.
टेस्ट केस में शामिल करने के लिए, दूसरा सबसे अहम टेस्ट पाथ अक्सर छोड़ दिया जाता है, क्योंकि यह असुविधाजनक होता है. इसे “डराने वाला पाथ” या दूसरे शब्दों में, नेगेटिव टेस्ट कहा जाता है. यह पाथ उन स्थितियों को टारगेट करता है जिनकी वजह से कोड गलत तरीके से काम करता है या गड़बड़ी की स्थिति में चला जाता है. इन स्थितियों की जांच करना तब ज़्यादा ज़रूरी होता है, जब आपके पास ऐसे इस्तेमाल के उदाहरण हों जिनमें शेयरहोल्डर या उपयोगकर्ताओं पर ज़्यादा जोखिम हो.
कुछ अन्य पाथ भी हैं जिनके बारे में आपको जानना चाहिए और जिनका इस्तेमाल किया जा सकता है. हालांकि, आम तौर पर इनका इस्तेमाल कम किया जाता है. यहां दी गई टेबल में इनके बारे में खास जानकारी दी गई है:
| टेस्ट पाथ | जानकारी |
|---|---|
| गुस्से वाला पाथ | इससे गड़बड़ी होती है, लेकिन यह गड़बड़ी सामान्य होती है. उदाहरण के लिए, अगर आपको यह पक्का करना है कि गड़बड़ी को ठीक करने की सुविधा सही तरीके से काम कर रही है या नहीं. |
| बकाया है | यह पाथ, सुरक्षा से जुड़ी उन सभी स्थितियों को ध्यान में रखता है जिन्हें आपके ऐप्लिकेशन को पूरा करना होता है. |
| सुनसान रास्ता | आपके ऐप्लिकेशन में स्थिति की जांच करने वाले पाथ को काम करने के लिए ज़रूरत के मुताबिक डेटा नहीं मिलता. उदाहरण के लिए, शून्य वैल्यू की जांच करना. |
| Forgetful path | कम संसाधनों के साथ अपने ऐप्लिकेशन के व्यवहार की जांच करना. उदाहरण के लिए, डेटा लॉस को ट्रिगर करना. |
| कोई पाथ नहीं चुना गया | ऐसे उपयोगकर्ता के साथ टेस्टिंग करना जो आपके ऐप्लिकेशन में कार्रवाइयां करने या उपयोगकर्ता की कहानियों को फ़ॉलो करने की कोशिश कर रहा है, लेकिन उसने वे वर्कफ़्लो पूरे नहीं किए हैं. उदाहरण के लिए, ऐसा तब हो सकता है, जब उपयोगकर्ता अपने वर्कफ़्लो में रुकावट डालता है. |
| लालची पाथ | बहुत सारे इनपुट या डेटा का इस्तेमाल करके जांच करने की कोशिश करना. |
| तनाव बढ़ाने वाला पाथ | अपने ऐप्लिकेशन पर लोड डालने की कोशिश करना, ताकि वह काम करना बंद कर दे. यह लोड टेस्ट जैसा ही होता है. |
उन पाथ को कैटगरी में बांटने के कई तरीके हैं. आम तौर पर, ये दो तरीके अपनाए जाते हैं:
- इक्विवैलेंसी पार्टिशनिंग. टेस्टिंग का एक तरीका, जो टेस्ट केस को ग्रुप या पार्टीशन में बांटता है. इससे, मिलते-जुलते क्लास बनाने में मदद मिलती है. यह इस सिद्धांत पर आधारित है कि अगर किसी पार्टीशन में एक टेस्ट केस से कोई गड़बड़ी का पता चलता है, तो उसी पार्टीशन के दूसरे टेस्ट केस में भी ऐसी ही गड़बड़ियां दिख सकती हैं. किसी खास एग्ज़ीक्वेंसी क्लास में मौजूद सभी इनपुट एक जैसे होने चाहिए. इसलिए, टेस्ट केस की संख्या कम की जा सकती है. एक्वाइवलेंसी पार्टिशनिंग के बारे में ज़्यादा जानें.
- विश्लेषण की सीमा तय करना. टेस्टिंग का एक तरीका, जिसे सीमा-वैल्यू विश्लेषण भी कहा जाता है. यह इनपुट वैल्यू की सीमाओं या चरम सीमाओं की जांच करता है, ताकि सिस्टम की क्षमताओं या सीमाओं की वजह से होने वाली संभावित समस्याओं या गड़बड़ियों का पता लगाया जा सके.
सबसे सही तरीका: टेस्ट केस लिखना
टेस्टर के लिखे गए क्लासिक टेस्ट केस में खास डेटा शामिल होता है. इससे आपको उस टेस्ट के कॉन्टेंट को समझने में मदद मिलती है जिसे आपको करना है. साथ ही, टेस्ट को लागू करने में भी मदद मिलती है. आम तौर पर, कोई टेस्टर अपनी टेस्टिंग की कोशिशों को टेबल में दस्तावेज़ के तौर पर सेव करता है. इस चरण में, दो पैटर्न का इस्तेमाल किया जा सकता है. इनसे हमें टेस्ट केस और बाद में, टेस्ट को स्ट्रक्चर करने में मदद मिलती है:
- व्यवस्थित करें, कार्रवाई करें, पुष्टि करें पैटर्न. "व्यवस्थित करें, कार्रवाई करें, पुष्टि करें" (इसे "AAA" या "ट्रिपल A" भी कहा जाता है) टेस्टिंग पैटर्न, टेस्ट को तीन अलग-अलग चरणों में व्यवस्थित करने का एक तरीका है: टेस्ट को व्यवस्थित करना, फिर टेस्ट करना, और आखिर में नतीजे निकालना.
- अगर, जब, तो पैटर्न. यह पैटर्न, AAA पैटर्न से मिलता-जुलता है. हालांकि, इसकी कुछ जड़ें व्यवहार से जुड़े डेवलपमेंट में हैं.
टेस्ट के स्ट्रक्चर के बारे में बताने के बाद, हम आने वाले समय में इन पैटर्न के बारे में ज़्यादा जानकारी देंगे. अगर आपको इस चरण में इन पैटर्न के बारे में ज़्यादा जानना है, तो ये दो लेख पढ़ें: व्यवस्थित करें-कार्रवाई करें-पुष्टि करें: अच्छे टेस्ट लिखने के लिए पैटर्न और दिया गया-जब-तब.
इस लेख में बताई गई सभी बातों के आधार पर, नीचे दी गई टेबल में एक क्लासिक उदाहरण दिया गया है:
| जानकारी | जानकारी |
|---|---|
| ज़रूरी शर्तें | टेस्ट लिखने से पहले की जाने वाली सभी ज़रूरी कार्रवाइयां. |
| जांचा जा रहा ऑब्जेक्ट | किसकी पुष्टि करनी है? |
| इनपुट डेटा | वैरिएबल और उनकी वैल्यू. |
| लागू करने के लिए चरण | टेस्ट को बेहतर बनाने के लिए की जाने वाली सभी कार्रवाइयां: टेस्ट में की गई सभी कार्रवाइयां या इंटरैक्शन. |
| अनुमानित नतीजा | क्या करना चाहिए और किन उम्मीदों को पूरा करना चाहिए. |
| असल नतीजा | असल में क्या होता है. |
ऑटोमेटेड टेस्टिंग में, आपको टेस्टर की तरह इन सभी टेस्ट केस को दस्तावेज़ में शामिल करने की ज़रूरत नहीं है. हालांकि, ऐसा करना ज़रूर फ़ायदेमंद होता है. ध्यान देने पर, आपको अपने टेस्ट में यह सारी जानकारी मिल सकती है. इसलिए, इस क्लासिक टेस्ट केस को ऑटोमेटेड टेस्ट में बदलने की कोशिश करते हैं.
| जानकारी | टेस्ट ऑटोमेशन में अनुवाद |
|---|---|
| ज़रूरी शर्तें | आपको जो भी चीज़ें चाहिए, टेस्ट को व्यवस्थित करना, और टेस्ट के लिए दिए गए डेटा के बारे में सोचना. |
| जांचा जा रहा ऑब्जेक्ट | यह “ऑब्जेक्ट” कई चीज़ें हो सकता है: टेस्ट किया जा रहा ऐप्लिकेशन, फ़्लो, यूनिट या कॉम्पोनेंट. |
| इनपुट डेटा | पैरामीटर वैल्यू. |
| लागू करने के लिए चरण | आपके टेस्ट में की गई सभी कार्रवाइयां और निर्देश, उन चीज़ों पर की गई कार्रवाइयां जिन पर आपने कार्रवाई की है, और यह पता लगाना कि कुछ चीज़ें करने पर क्या होता है. |
| अनुमानित नतीजा | आपके आवेदन की पुष्टि करने के लिए इस्तेमाल किया जाने वाला दावा. साथ ही, आपके आवेदन में जिन चीज़ों के बारे में दावा किया गया है. |
| असल नतीजा | अपने-आप होने वाले टेस्ट का नतीजा. |