UI परफ़ॉर्मेंस टेस्टिंग टूल्स के दो परिवार
लैब, सिंथेटिक
नियंत्रित परिस्थितियों में एक पेज लोड करके उसे स्कोर देते हैं।
दोहराने योग्य और तुलना करने योग्य। साफ़ डेटा वाले साफ़-सुथरे माहौल को मापते हैं।
फ़ील्ड, असली यूज़र्स
असली सेशन्स से टाइमिंग इकट्ठा करते हैं।
हक़ीक़त के बारे में ईमानदार। पर बताते तब हैं जब किसी के साथ यह हो चुका होता है।
इनके बीच क्या छूट जाता है
लैब टूल्स टेस्ट एनवायरनमेंट पर चलते हैं, यानी छोटे डेटासेट पर। फ़ील्ड टूल्स असली डेटा वॉल्यूम देखते हैं, लेकिन रिपोर्ट तभी करते हैं जब कोई असली यूज़र इसे भुगत चुका हो। नतीजा यह कि जो स्क्रीन दस रो के साथ तेज़ है और दो हज़ार के साथ बेकार, वह लैब में पास हो जाती है और फ़ील्ड में सामने आती है — यही सबसे ख़राब क्रम है।
इस गैप को भरने के लिए टूल्स की कोई नई श्रेणी नहीं चाहिए। चाहिए बस एक सीडेड अकाउंट, जो किसी बड़े कस्टमर जितना बड़ा हो, और रिलीज़ से पहले उसी पर वही फ़्लो चलाए जाएँ।
हर परिवार के भीतर चुनाव कैसे करें
लैब टूल्स: ऐसे टूल्स चुनें जो सिर्फ़ इनिशियल लोड नहीं, इंटरैक्शन लेटेंसी भी मापें। लोड हर सेशन में एक बार की लागत है, इंटरैक्शन लगातार होता रहता है।
फ़ील्ड टूल्स: देखें कि क्या आप अकाउंट साइज़ के हिसाब से सेगमेंट कर सकते हैं। सभी कस्टमर्स का औसत ठीक उन्हीं कस्टमर्स को छिपा देता है जो परेशानी झेल रहे हैं।
दोनों: किसी निरपेक्ष स्कोर की बजाय अपने ही इतिहास से तुलना करें। उधार लिए गए थ्रेशोल्ड शायद ही कभी एक प्रोडक्ट से दूसरे पर लागू होते हैं।
फ़ील्ड डेटा को ऐसे सेगमेंट करें कि उसका कोई मतलब बने
दोनों परिवारों में रियल-यूज़र मॉनिटरिंग ज़्यादा ईमानदार है, और ग़लत ऐग्रीगेट देखकर उसे बेकार बना देना बहुत आसान है।
सभी यूज़र्स का औसत पचास रिकॉर्ड वाले कस्टमर और पचास हज़ार रिकॉर्ड वाले कस्टमर को एक साथ मिला देता है, जबकि पूरा सिग्नल दूसरे वाले में है। यही बात डिवाइस मिलाने, भौगोलिक क्षेत्र मिलाने और अपने इंटरनल यूज़र्स को कस्टमर्स के साथ मिलाने पर भी लागू होती है। कुल आँकड़ा सुधरता दिख सकता है जबकि आपके सबसे बड़े अकाउंट्स लगातार बदतर होते जा रहे हों — और यही वह ख़राबी है जिसकी क़ीमत रिन्यूअल गँवाकर चुकानी पड़ती है।
उस डाइमेंशन के हिसाब से सेगमेंट करें जिस पर आपका प्रोडक्ट सचमुच बदलता है — ज़्यादातर बिज़नेस सॉफ़्टवेयर के लिए यह डिवाइस या नेटवर्क नहीं, अकाउंट साइज़ होता है। अगर टूलिंग इस तरह सेगमेंट नहीं कर सकती, तो वह जो आँकड़ा देती है वह उस चीज़ को माप ही नहीं रहा जिसकी आपको परवाह है।
वह पूर्वशर्त जिसका ज़िक्र कोई नहीं करता
जो स्क्रीन इसलिए तुरंत रेंडर हो जाती है क्योंकि रिक्वेस्ट चुपचाप फ़ेल हो गई थी, वह लैब टूल में शानदार स्कोर करेगी। करेक्टनेस हर परफ़ॉर्मेंस आँकड़े के नीचे की ज़मीन है, और उसे वेरिफ़ाई करना ऊपर बताई गई किसी भी टूलिंग से सस्ता है।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप लोकल मशीन पर कुछ भी इंस्टॉल नहीं करना चाहते, तो यही सेटअप TestSprite डैशबोर्ड में भी मौजूद है। बाक़ी पूरा CLI सरफ़ेस यहाँ मिलेगा — CLI रिपॉज़िटरी।
हर एक कहाँ चलता है
लैब टूल्स पाइपलाइन में, हर पुल रिक्वेस्ट पर, आपकी बेसलाइन से तुलना करते हुए। फ़ील्ड मॉनिटरिंग हमेशा चालू। और वास्तविक आकार वाले अकाउंट पर फ़ंक्शनल वेरिफ़िकेशन, वह भी हर बदलाव पर — क्योंकि यही वह गैप है जिसे बाक़ी दोनों खुला छोड़ देते हैं।
मैकेनिज़्म से ज़्यादा मायने ट्रिगर रखता है। इसे अपने डिप्लॉयमेंट इवेंट से जोड़ देने का मतलब है कि हर बदलाव की जाँच अपने आप हो जाती है, बिना किसी के अलग से तय किए; GitHub App यह काम डैशबोर्ड से करता है, और GitHub Actions स्टेप इसे आपके वर्कफ़्लो के भीतर से करता है।
लैब और फ़ील्ड के बीच TestSprite कहाँ बैठता है
ठीक उसी गैप में जिसे दोनों खुला छोड़ देते हैं: रिलीज़ से पहले, असली जैसे डेटा वाले एनवायरनमेंट पर असली फ़्लो चलाना। कवरेज आपके प्रोडक्ट से ही बनता है और हर बदलाव पर चलता है, इसलिए जो स्क्रीन दस रो के साथ काम करती है और दो हज़ार पर टूट जाती है, वह किसी पर्सेंटाइल से नहीं, व्यवहार से पकड़ी जाती है।
यह वह पूर्वशर्त भी पूरी करता है जिसे दोनों में से कोई परिवार नहीं जाँचता। जो पेज इसलिए तुरंत रेंडर हो जाता है क्योंकि फ़ेच फ़ेल हो गया, वह तेज़ है और ग़लत भी — और लैब स्कोर आपको यह नहीं बताएगा।
लैब टूलिंग लोड और इंटरैक्शन टाइमिंग मापती रहती है, फ़ील्ड मॉनिटरिंग बताती रहती है कि यूज़र्स ने क्या अनुभव किया। यहाँ फ़ायदा यह है कि जो ख़राबी सिर्फ़ आपके सबसे बड़े कस्टमर के डेटा वॉल्यूम पर दिखती है, वह उस कस्टमर से पहले पकड़ में आ जाती है।
क्या TestSprite इसी श्रेणी में आता है?
नहीं। यह जाँचता है कि फ़्लो सही तरह से काम कर रहे हैं या नहीं — और यही वह पूर्वशर्त है जिसके बिना किसी भी परफ़ॉर्मेंस आँकड़े का कोई मतलब नहीं।
क्या हमें लैब और फ़ील्ड, दोनों तरह के टूल्स चाहिए?
हाँ। लैब रिलीज़ से पहले दोहराने योग्य सिग्नल देती है, फ़ील्ड बताती है कि असल में क्या हुआ। अकेले कोई भी काफ़ी नहीं है।
और सिंथेटिक मॉनिटरिंग का क्या?
यह एक लैब टूल ही है, जो तय शेड्यूल पर प्रोडक्शन पर चलाया जाता है। उपलब्धता के लिए उपयोगी, और वह भी उसी डेटा पर चलता है जो उस अकाउंट में मौजूद है।
सीडेड टेस्ट अकाउंट कितना बड़ा होना चाहिए?
उतना बड़ा जितना आपका सबसे बड़ा असली कस्टमर। इससे छोटा कुछ भी हुआ तो आप ऐसे केस की टेस्टिंग कर रहे हैं जो प्रोडक्शन में है ही नहीं।
क्या परफ़ॉर्मेंस स्कोर को मर्ज रोकने देना चाहिए?
अपनी ही बेसलाइन के मुक़ाबले बड़ा रिग्रेशन हो, तो हाँ। किसी निरपेक्ष स्कोर थ्रेशोल्ड पर, आम तौर पर नहीं — क्योंकि वह आपके प्रोडक्ट को नहीं, बेंचमार्क को ट्रैक करता है।
लैब बहुत ज़्यादा साफ़-सुथरी है, फ़ील्ड बहुत देर से आती है।
UI परफ़ॉर्मेंस टेस्टिंग टूल्स या तो लैब वाले होते हैं या फ़ील्ड वाले, और दोनों असली डेटा वॉल्यूम पर आने वाली गिरावट चूक जाते हैं। किसी बड़े कस्टमर जितना बड़ा अकाउंट सीड करें, रिलीज़ से पहले उस पर फ़्लो चलाएँ, और सबसे पहले करेक्टनेस वेरिफ़ाई करें।