रणनीतियां आज़माएं

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

जब टीमें जांच के लिए व्यवस्थित तरीके का इस्तेमाल करती हैं और साथ ही, इन्फ़्रास्ट्रक्चर को बेहतर बनाती हैं, तो उनकी प्रॉडक्टिविटी बढ़ती है. ऐसा करने से, कोड के काम करने के तरीके के बारे में समय पर जानकारी मिलती है. टेस्टिंग की अच्छी रणनीति से ये काम किए जा सकते हैं:

• समस्याओं को जल्द से जल्द पता चलता है.
• तेज़ी से काम करता है.
• जब किसी चीज़ को ठीक करने की ज़रूरत होती है, तब इसका साफ़ तौर पर पता चलता है.

इस पेज से आपको यह तय करने में मदद मिलेगी कि किस तरह के टेस्ट लागू करने हैं, उन्हें कहां चलाना है, और कितनी बार टेस्ट करना है.

टेस्टिंग पिरामिड

मॉडर्न ऐप्लिकेशन में, साइज़ के हिसाब से टेस्ट को अलग-अलग कैटगरी में बांटा जा सकता है. छोटे टेस्ट, कोड के सिर्फ़ एक छोटे हिस्से पर फ़ोकस करते हैं. इससे, ये तेज़ और भरोसेमंद होते हैं. बड़े टेस्ट का दायरा बड़ा होता है. साथ ही, इनके लिए ज़्यादा मुश्किल सेटअप की ज़रूरत होती है, जिन्हें मैनेज करना मुश्किल होता है. हालांकि, बड़े टेस्ट में भरोसेमंद* होता है और वे एक ही बार में कई सारी समस्याओं का पता लगा सकते हैं.

*फ़िडेलिटी का मतलब है, टेस्ट रनटाइम एनवायरमेंट और प्रोडक्शन एनवायरमेंट के बीच का अंतर.

ज़्यादातर ऐप्लिकेशन में कई छोटे टेस्ट और कुछ बड़े टेस्ट होने चाहिए. हर कैटगरी में टेस्ट का बंटवारा पिरामिड के तौर पर होना चाहिए. इसमें सबसे ज़्यादा छोटे टेस्ट और सबसे कम बड़े टेस्ट होने चाहिए.

गड़बड़ी की लागत कम करना

टेस्टिंग की अच्छी रणनीति से, डेवलपर की प्रोडक्टिविटी बढ़ती है. साथ ही, गड़बड़ियों का पता लगाने की लागत कम होती है.

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

इसका मतलब है कि मर्ज करने से पहले, बहुत कम टेस्ट चलाए जाते हैं. अगर कोई गड़बड़ी होती है, तो हो सकता है कि हर रात या हर हफ़्ते शुरू से आखिर तक टेस्ट चलाए जाने तक टेस्ट उसे न पहचान पाएं.

यह ज़रूरी है कि आप इस बात पर ध्यान दें कि बग की पहचान करने और उन्हें ठीक करने की लागत पर इसका क्या असर पड़ता है. साथ ही, यह भी जानें कि टेस्टिंग के लिए छोटे और ज़्यादा बार किए जाने वाले टेस्ट को प्राथमिकता क्यों देना ज़रूरी है:

• जब यूनिट टेस्ट से गड़बड़ी का पता चलता है, तो आम तौर पर उसे कुछ ही मिनटों में ठीक कर दिया जाता है. इसलिए, इसकी लागत कम होती है.
• एंड-टू-एंड टेस्ट में, उसी बग का पता लगाने में कई दिन लग सकते हैं. इसकी वजह से टीम के कई सदस्य शामिल हो सकते हैं. इससे उत्पादकता कम हो सकती है और रिलीज़ में देरी हो सकती है. यह बग ज़्यादा कीमत में आता है.

हालांकि, कोई रणनीति न होने से बेहतर है कि कोई खराब रणनीति अपनाई जाए. जब किसी गड़बड़ी की वजह से ऐप्लिकेशन प्रोडक्शन तक पहुंच जाता है, तो उस गड़बड़ी को ठीक करने में उपयोगकर्ता के डिवाइस पर पहुंचने में काफ़ी समय लग सकता है. इसमें कभी-कभी कई हफ़्ते भी लग सकते हैं. इसलिए, फ़ीडबैक लूप सबसे लंबा और महंगा होता है.

स्केल की जा सकने वाली टेस्टिंग की रणनीति

टेस्टिंग पिरामिड को आम तौर पर तीन कैटगरी में बांटा गया है:

• यूनिट टेस्ट
• इंटिग्रेशन टेस्ट
• शुरू से आखिर तक जांच करना.

हालांकि, इन कॉन्सेप्ट की सटीक परिभाषाएं नहीं हैं. इसलिए, हो सकता है कि टीमें अपनी कैटगरी को अलग तरीके से परिभाषित करना चाहें. उदाहरण के लिए, पांच लेयर का इस्तेमाल करके:

• यूनिट टेस्ट, होस्ट मशीन पर चलाया जाता है. यह लॉजिक की एक फ़ंक्शनल यूनिट की पुष्टि करता है. इसमें Android फ़्रेमवर्क पर कोई डिपेंडेंसी नहीं होती.
  • उदाहरण: गणितीय फ़ंक्शन में, एक से ज़्यादा गड़बड़ियों की पुष्टि करना.
• कॉम्पोनेंट टेस्ट से, सिस्टम के अन्य कॉम्पोनेंट से अलग किसी मॉड्यूल या कॉम्पोनेंट की सुविधा या दिखावट की पुष्टि की जाती है. यूनिट टेस्ट के उलट, कॉम्पोनेंट टेस्ट का सर्फ़ेस एरिया, अलग-अलग तरीकों और क्लास के ऊपर, ज़्यादा एब्स्ट्रैक्शन तक फैला होता है.
  • उदाहरण: कस्टम बटन के लिए स्क्रीनशॉट टेस्ट
• सुविधा टेस्ट, दो या उससे ज़्यादा इंडिपेंडेंट कॉम्पोनेंट या मॉड्यूल के इंटरैक्शन की पुष्टि करता है. सुविधा की जांच बड़े और ज़्यादा जटिल होती है. आम तौर पर, यह सुविधा के लेवल पर की जाती है.
  • उदाहरण: यूज़र इंटरफ़ेस (यूआई) के व्यवहार की जांच, जो किसी स्क्रीन में स्टेटस मैनेजमेंट की पुष्टि करती है
• ऐप्लिकेशन टेस्ट, डिप्लॉय किए जा सकने वाले बाइनरी के तौर पर पूरे ऐप्लिकेशन की फ़ंक्शनैलिटी की पुष्टि करता है. ये बड़े इंटिग्रेशन टेस्ट होते हैं, जो जांचे जा रहे सिस्टम के तौर पर, डीबग की जा सकने वाली बाइनरी का इस्तेमाल करते हैं. जैसे, टेस्टिंग हुक वाला डेवलपर बिल्ड.
  • उदाहरण: फ़ोल्ड किए जा सकने वाले डिवाइस, स्थानीय भाषा में अनुवाद, और सुलभता से जुड़े टेस्ट में कॉन्फ़िगरेशन में हुए बदलावों की पुष्टि करने के लिए, यूज़र इंटरफ़ेस (यूआई) के काम करने के तरीके का टेस्ट
• रिलीज़ कैंडिडेट टेस्ट, रिलीज़ बिल्ड की फ़ंक्शनैलिटी की पुष्टि करता है. ये ऐप्लिकेशन टेस्ट की तरह ही होते हैं. हालांकि, इनमें ऐप्लिकेशन बाइनरी को छोटा और ऑप्टिमाइज़ किया गया होता है. ये बड़े एंड-टू-एंड इंटिग्रेशन टेस्ट होते हैं. ये टेस्ट, ऐप्लिकेशन को सार्वजनिक उपयोगकर्ता खातों या सार्वजनिक बैकएंड के संपर्क में लाए बिना, प्रोडक्शन के जितने करीब हो सके उतने करीब के एनवायरमेंट में चलते हैं.
  • उदाहरण: क्रिटिकल यूज़र जर्नी, परफ़ॉर्मेंस टेस्टिंग

इस कैटगरी में, फ़िडेलिटी, समय, दायरा, और अलगाव के लेवल को ध्यान में रखा जाता है. आपके पास कई लेयर में अलग-अलग तरह के टेस्ट हो सकते हैं. उदाहरण के लिए, ऐप्लिकेशन टेस्ट लेयर में व्यवहार, स्क्रीनशॉट, और परफ़ॉर्मेंस टेस्ट शामिल हो सकते हैं.

	दायरा	नेटवर्क ऐक्सेस	प्लान लागू करना	बिल्ड किस तरह का है	लाइफ़साइकल
यूनिट	एक तरीका या कम से कम डिपेंडेंसी वाला क्लास.	नहीं	लोकल	डीबग करने लायक	मर्ज करने से पहले
कॉम्पोनेंट	मॉड्यूल या कॉम्पोनेंट लेवल एक साथ कई क्लास	नहीं	स्थानीय Robolectric Emulator	डीबग किया जा सकता है	मर्ज करने से पहले
सुविधा	सुविधा का लेवल अन्य टीमों के मालिकाना हक वाले कॉम्पोनेंट के साथ इंटिग्रेशन	मज़ाक उड़ाया गया	लोकल Robolectric एमुलेटर डिवाइस	डीबग किया जा सकता है	मर्ज करने से पहले
ऐप्लिकेशन	ऐप्लिकेशन लेवल अन्य टीमों के मालिकाना हक वाली सुविधाओं और/या सेवाओं के साथ इंटिग्रेशन	मॉक किया गया स्टैजिंग सर्वर प्रोडक्शन सर्वर	एम्युलेटर डिवाइस	डीबग किया जा सकता है	मर्ज करने से पहले मर्ज करने के बाद
रिलीज़ कैंडिडेट	ऐप्लिकेशन लेवल अन्य टीमों के मालिकाना हक वाली सुविधाओं और/या सेवाओं के साथ इंटिग्रेशन	प्रोडक्शन सर्वर	एम्युलेटर डिवाइस	छोटा किया गया रिलीज़ बिल्ड	मर्ज करने के बाद रिलीज़ से पहले

टेस्ट की कैटगरी तय करना

आम तौर पर, आपको पिरामिड की सबसे निचली लेयर को चुनना चाहिए, ताकि टीम को सही लेवल का सुझाव या राय मिल सके.

उदाहरण के लिए, इस सुविधा के लागू होने की जांच करने का तरीका देखें: साइन-इन फ़्लो का यूज़र इंटरफ़ेस (यूआई). आपको जो टेस्ट करना है उसके आधार पर, आपको अलग-अलग कैटगरी चुननी होंगी:

इस व्यक्ति की जांच की जा रही है	टेस्ट किए जा रहे आइटम की जानकारी	टेस्ट की कैटगरी	टेस्ट के टाइप का उदाहरण
फ़ॉर्म की पुष्टि करने वाला लॉजिक	ऐसी क्लास जो रेगुलर एक्सप्रेशन के हिसाब से ईमेल पते की पुष्टि करती है. साथ ही, यह जांच करती है कि पासवर्ड फ़ील्ड डाला गया है या नहीं. इसमें कोई डिपेंडेंसी नहीं है.	यूनिट टेस्ट	लोकल जेवीएम यूनिट टेस्ट
साइन-इन फ़ॉर्म के यूज़र इंटरफ़ेस (यूआई) का व्यवहार	ऐसा फ़ॉर्म जिसमें एक बटन हो और वह सिर्फ़ तब चालू हो, जब फ़ॉर्म की पुष्टि हो गई हो	कॉम्पोनेंट टेस्ट	Robolectric पर चल रहा यूज़र इंटरफ़ेस (यूआई) के व्यवहार का टेस्ट
साइन-इन फ़ॉर्म के यूज़र इंटरफ़ेस (यूआई) के दिखने का तरीका	उपयोगकर्ता अनुभव के हिसाब से बनाया गया फ़ॉर्म	कॉम्पोनेंट टेस्ट	झलक दिखाने वाले स्क्रीनशॉट का टेस्ट बनाना
पुष्टि करने वाले मैनेजर के साथ इंटिग्रेशन	यह यूज़र इंटरफ़ेस (यूआई), पुष्टि करने वाले मैनेजर को क्रेडेंशियल भेजता है और उसे अलग-अलग गड़बड़ियों के जवाब मिलते हैं.	सुविधा की जांच	नकली डेटा का इस्तेमाल करके जेवीएम टेस्ट करना
साइन-इन करने के लिए डायलॉग बॉक्स	लॉगिन बटन दबाने पर, साइन-इन फ़ॉर्म दिखाने वाली स्क्रीन.	ऐप्लिकेशन की जांच	Robolectric पर चलने वाला यूज़र इंटरफ़ेस (यूआई) टेस्ट
क्रिटिकल यूज़र जर्नी: साइन इन करना	स्टेजिंग सर्वर के ख़िलाफ़ टेस्ट खाते का इस्तेमाल करके, साइन-इन करने की पूरी प्रोसेस	रिलीज़ कैंडिडेट	डिवाइस पर चल रहा, Compose UI के व्यवहार की जांच का पूरा चरण

कुछ मामलों में, किसी चीज़ को किसी कैटगरी में रखना या नहीं, यह तय करना मुश्किल हो सकता है. किसी टेस्ट को ऊपर या नीचे ले जाने की और भी वजहें हो सकती हैं. जैसे, इन्फ़्रास्ट्रक्चर की लागत, गड़बड़ियां, और टेस्ट में लगने वाला लंबा समय.

ध्यान दें कि टेस्ट कैटगरी से टेस्ट के टाइप का पता नहीं चलता. साथ ही, हर कैटगरी में सभी सुविधाओं की जांच करना ज़रूरी नहीं है.

मैन्युअल टेस्टिंग को भी टेस्टिंग की रणनीति का हिस्सा बनाया जा सकता है. आम तौर पर, क्यूए टीमें रिलीज़ के लिए तैयार वर्शन की जांच करती हैं. हालांकि, वे अन्य चरणों में भी शामिल हो सकती हैं. उदाहरण के लिए, स्क्रिप्ट के बिना किसी सुविधा में बग की एक्सप्लोरेटरी टेस्टिंग.

टेस्ट इन्फ़्रास्ट्रक्चर

टेस्टिंग की रणनीति के लिए, इन्फ़्रास्ट्रक्चर और टूल की ज़रूरत होती है. इससे डेवलपर को लगातार टेस्ट चलाने और ऐसे नियम लागू करने में मदद मिलती है जिनसे यह पक्का हो सके कि सभी टेस्ट पास हो जाएं.

जांच को दायरे के हिसाब से अलग-अलग कैटगरी में बांटा जा सकता है. इससे यह तय किया जा सकता है कि कौनसे टेस्ट कब और कहां करने हैं. उदाहरण के लिए, 5-लेयर मॉडल में दिए गए निर्देशों का पालन करें:

कैटगरी	एनवायरमेंट (कहां)	ट्रिगर (कब)
यूनिट	[Local][4]	हर कमिट
कॉम्पोनेंट	लोकल	हर कमिट
सुविधा	लोकल और एमुलेटर	मर्ज करने या बदलाव सबमिट करने से पहले
ऐप्लिकेशन	लोकल, एम्युलेटर, एक फ़ोन, एक फ़ोल्ड किए जा सकने वाला फ़ोन	मर्ज करने या बदलाव सबमिट करने के बाद
रिलीज़ कैंडिडेट	आठ अलग-अलग फ़ोन, एक फ़ोल्ड करने वाला फ़ोन, एक टैबलेट	रिलीज़ से पहले

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

जब टेस्ट की संख्या से उत्पादकता पर असर पड़ता है, तब ये नियम बदल सकते हैं. उदाहरण के लिए, अगर टेस्ट को हर रात चलाया जाता है, तो सीआई बिल्ड और टेस्ट में लगने वाला समय कम हो सकता है. हालांकि, फ़ीडबैक लूप में भी ज़्यादा समय लग सकता है.