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

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

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

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

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

android skills add testing-setup

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

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

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

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

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

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

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

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

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

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

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

टेस्टिंग की ऐसी रणनीति जिसे आसानी से बढ़ाया जा सके

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

• यूनिट टेस्ट
• इंटिग्रेशन टेस्ट
• एंड-टू-एंड टेस्ट.

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

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

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

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

सामान्य तौर पर, आपको पिरामिड की सबसे निचली लेयर पर मौजूद लोगों से सुझाव/राय लेनी चाहिए. इससे टीम को सही लेवल का फ़ीडबैक मिल सकता है.

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

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

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

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

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

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

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

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

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