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

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

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

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

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

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

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

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

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

बग की वजह से होने वाले नुकसान को कम करना

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

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

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

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

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

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

टेस्टिंग की ऐसी रणनीति जिसे आसानी से लागू किया जा सके

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

• यूनिट टेस्ट
• इंटिग्रेशन की जांच
• एंड-टू-एंड टेस्ट.

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

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

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

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

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

सामान्य तौर पर, आपको पिरामिड की सबसे निचली लेयर पर ध्यान देना चाहिए. इससे टीम को सही लेवल का फ़ीडबैक मिल सकता है.

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

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

कुछ मामलों में, यह तय करना मुश्किल हो सकता है कि कोई चीज़ किस कैटगरी में आती है. किसी टेस्ट को ऊपर या नीचे ले जाने की अन्य वजहें भी हो सकती हैं. जैसे, बुनियादी ढांचे की लागत, टेस्ट के नतीजे में उतार-चढ़ाव, और टेस्ट में लगने वाला ज़्यादा समय.

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

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

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

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

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

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

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

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