टेस्टिंग प्रोजेक्ट और टेस्टिंग कल्चर में फ़र्क़
टेस्टिंग प्रोजेक्ट
कुछ टेस्ट चलाइए। देखिए क्या काम करता है। आगे बढ़ जाइए। टेस्टिंग एक औज़ार है जिसे आप ज़रूरत पड़ने पर इस्तेमाल करते हैं। फिर रुक जाते हैं।
टेस्टिंग कल्चर
टेस्ट लगातार चलाइए। जीता हुआ बदलाव अगले टेस्ट को दिशा देता है। सीख जमा होती रहती है। साल दर साल टेस्टिंग का फ़ायदा बढ़ता जाता है।
हर बदलाव टेस्ट होता है। हर फ़ैसला डेटा पर टिका होता है। टेस्टिंग वह तरीक़ा है जिससे आप फ़ैसले लेते हैं, कोई ऐसा प्रोजेक्ट नहीं जिसे आप कभी-कभार चलाएँ।
टेस्टिंग कल्चर वाली कंपनियाँ उन प्रतिस्पर्धियों से आगे निकल जाती हैं जिनके पास यह नहीं है। हर टेस्ट में बहुत ज़्यादा नहीं। लेकिन सालों में यह जुड़कर बहुत बड़ा फ़ायदा बन जाता है।
लीडरशिप का भरोसा जीतना
समस्या
ज़्यादातर टेस्टिंग प्रोग्राम इसलिए फ़ेल होते हैं क्योंकि लीडरशिप टेस्टिंग को समझती नहीं या उसके लिए प्रतिबद्ध नहीं होती।
लीडरशिप क्या सुनती है
जब आप टेस्टिंग प्रोग्राम का प्रस्ताव रखते हैं, तो लीडरशिप को सुनाई देता है: इसमें समय लगेगा और पैसा खर्च होगा।
लीडरशिप को क्या सुनना चाहिए
पैसे का हिसाब दिखाइए। एक टेस्ट चलाइए। साबित कीजिए कि यह काम करता है। रेवेन्यू पर असर निकालिए। इस टेस्ट ने कन्वर्ज़न 2 प्रतिशत बढ़ाया। इससे सालाना $50,000 की अतिरिक्त कमाई होती है। टेस्टिंग टूल की लागत $12,000 है। शुद्ध फ़ायदा $38,000।
अब लीडरशिप टेस्टिंग को खर्च नहीं, निवेश की तरह देखती है।
टेस्टिंग रोडमैप बनाना
बेतरतीब टेस्ट मत चलाइए
टेस्टिंग रोडमैप की योजना बनाइए। रोडमैप ज़्यादा असर वाले हिस्सों की पहचान करता है। फ़ॉर्म। हेडलाइन। ऑफ़र। चेकआउट। हर हिस्से को टेस्टिंग में प्राथमिकता मिलती है।
असर के हिसाब से क्रम
रोडमैप टेस्ट का क्रम तय करता है। ज़्यादा असर वाली चीज़ें पहले टेस्ट करें। मध्यम असर वाली उसके बाद। कम असर वाली बाद में।
टीम की प्रतिबद्धता
रोडमैप टीमों को टेस्टिंग के लिए प्रतिबद्ध करता है। डिज़ाइनर जानते हैं कि वे बटन डिज़ाइन टेस्ट कर रहे हैं। प्रोडक्ट टीम जानती है कि वह ऑफ़र टेस्ट कर रही है। सबको पता होता है कि आगे क्या आ रहा है।
तिमाही रोडमैप बनाइए। नतीजों के आधार पर हर महीने उसे अपडेट कीजिए। तिमाही प्लानिंग टीम को फ़ोकस में रखती है।
ज़िम्मेदारी और जवाबदेही तय करना
समस्या
जब टेस्टिंग का कोई मालिक नहीं होता, तो वह फ़ेल हो जाती है। मार्केटिंग कहती है कि प्रोडक्ट की ज़िम्मेदारी है। प्रोडक्ट कहता है कि इंजीनियरिंग की ज़िम्मेदारी है। टेस्टिंग कभी होती ही नहीं।
समाधान
टेस्टिंग का एक मालिक तय कीजिए। यह ग्रोथ मैनेजर हो सकता है। प्रोडक्ट मैनेजर हो सकता है। टेस्टिंग प्रोग्राम के लिए एक व्यक्ति जवाबदेह हो।
टेस्टिंग का मालिक रोडमैप बनाता है। टेस्ट चलाता है। नतीजे दर्ज करता है। सीख साझा करता है। टीमों के बीच तालमेल बिठाता है। मालिक के बिना टेस्टिंग अटक जाती है।
टीमों को स्टैटिस्टिकल सोच सिखाना
समस्या
ज़्यादातर लोगों ने स्टैटिस्टिक्स की ट्रेनिंग नहीं ली होती। वे संख्याएँ देखकर अंदाज़े से फ़ैसला कर लेते हैं।
ट्रीटमेंट 9 प्रतिशत है। कंट्रोल 8.8 प्रतिशत है। लगता है ट्रीटमेंट जीत गया। स्टैटिस्टिक्स न जानने वाला सोचता है कि ट्रीटमेंट बेहतर है।
स्टैटिस्टिशियन कॉन्फ़िडेंस लेवल जाँचता है। 82 प्रतिशत। यह 95 प्रतिशत की सीमा से नीचे है। नतीजा सार्थक नहीं है। फ़र्क़ किस्मत का भी हो सकता है।
समाधान
टीमों को बुनियादी स्टैटिस्टिक्स सिखाने से ग़लत फ़ैसले रुकते हैं। ट्रेनिंग के विषय: स्टैटिस्टिकल सिग्निफ़िकेंस क्या है। 95 प्रतिशत क्यों मायने रखता है। कॉन्फ़िडेंस इंटरवल कैसे पढ़ें। सैंपल साइज़ का क्या मतलब है।
अच्छा टेस्टिंग प्रोग्राम टीम को स्टैटिस्टिक्स सिखाता है।
साझा सीख और दस्तावेज़ बनाना
दस्तावेज़ क्यों ज़रूरी है
हर टेस्ट कुछ सिखाता है। अगर उसे दर्ज न किया जाए, तो सीख खो जाती है।
दस्तावेज़ कैसे बनाएँ
टेस्ट का एक रिपॉज़िटरी बनाइए। हर टेस्ट का एक पेज हो। हाइपोथेसिस। नतीजे। सीख।
50 टेस्ट के बाद आपके पास सीख के 50 पेज होंगे। टीम का नया सदस्य ये 50 पेज पढ़कर समझ जाता है कि आपकी ऑडियंस के लिए क्या काम करता है।
अच्छा दस्तावेज़: हाइपोथेसिस, नतीजे, इनसाइट, और आगे क्या टेस्ट करना है।
बुरा दस्तावेज़: पहला टेस्ट जीता, दूसरा हारा। कोई इनसाइट नहीं।
टेस्टिंग को प्रक्रिया का हिस्सा बनाना
वैकल्पिक टेस्टिंग फ़ेल हो जाती है
अगर टेस्टिंग वैकल्पिक है, तो व्यस्त होने पर वह रुक जाती है। टीमें ज़रूरी प्रोजेक्ट के सामने उसे पीछे कर देती हैं।
अनिवार्य टेस्टिंग टिकती है
टेस्टिंग को अनिवार्य बनाइए। हर बदलाव टेस्टिंग प्रक्रिया से गुज़रे। बिना टेस्ट वाला बदलाव मंज़ूर न हो।
इसके लिए प्रक्रिया बदलनी पड़ती है। लेकिन इससे टेस्टिंग लगातार होती रहती है।
प्रक्रिया का एक उदाहरण
एक: हाइपोथेसिस के साथ बदलाव का प्रस्ताव दीजिए। दो: टेस्ट की मंज़ूरी लीजिए। तीन: टेस्ट दो हफ़्ते चलाइए। चार: नतीजों को टेस्टिंग का मालिक मंज़ूर करे। पाँच: अगर नतीजा सार्थक है, तो लागू कीजिए। छह: सीख दर्ज कीजिए। सात: अगला टेस्ट डिज़ाइन कीजिए।
जीत का जश्न मनाना और उसे बताना
समस्या
अगर जीत की ख़बर किसी को न मिले, तो टेस्टिंग प्रोग्राम दम तोड़ देता है।
समाधान
जीत का जश्न मनाइए। नतीजे साझा कीजिए। असर दिखाइए। महीने का एक ईमेल: "हमारे टेस्टिंग प्रोग्राम ने इस तिमाही कन्वर्ज़न 7 प्रतिशत बढ़ाया। ये रहे वे पाँच टेस्ट जिन्होंने फ़र्क़ डाला। इन्हें चलाने वाली टीमों का शुक्रिया।"
जश्न से रफ़्तार बनती है। कल्चर बनता है। यह भरोसा बनता है कि टेस्टिंग काम करती है।
टेस्टिंग की राजनीति से निपटना
टकराव
कोई व्यक्ति बदलाव का प्रस्ताव देता है। टेस्ट दिखाता है कि बदलाव अच्छा आइडिया नहीं है। प्रस्ताव देने वाला व्यक्ति निराश होता है। जब नतीजे धारणाओं से मेल नहीं खाते, तो टेस्टिंग टकराव पैदा करती है।
समाधान
टेस्टिंग को सीखने का औज़ार बताइए। लोगों को ग़लत साबित करने का तरीक़ा नहीं। इसे ऐसे पेश कीजिए: "आइए मिलकर टेस्ट करें और सीखें।"
जब टेस्ट दिखाए कि किसी की बात ग़लत थी, तो कहिए "हमने कुछ सीखा।" इसे जीत की तरह रखिए, हार की तरह नहीं। अगर टेस्टिंग को ख़तरे की तरह देखा जाए, तो लोग बचाव में आ जाते हैं। अगर उसे सीखने की तरह देखा जाए, तो लोग टेस्टिंग का साथ देते हैं।
टेस्ट की रफ़्तार संभालना
तेज़ तरीक़ा
महीने में दस टेस्ट चलाइए। हर टेस्ट एक हफ़्ते में ख़त्म कीजिए। सीख तेज़ मिलती है। झूठे पॉज़िटिव का ख़तरा ज़्यादा रहता है। ग़लती की दर ऊँची रहती है।
सतर्क तरीक़ा
महीने में तीन टेस्ट चलाइए। हर टेस्ट दो से तीन हफ़्ते में ख़त्म कीजिए। सीख धीमी मिलती है। ग़लती की दर कम रहती है। यह ज़्यादा सुरक्षित है।
संतुलित तरीक़ा
ज़्यादातर कंपनियों को संतुलित तरीक़ा अपनाना चाहिए। महीने में पाँच से छह टेस्ट। दो हफ़्ते की अवधि। ग़लती की वाजिब दर। सीखने की वाजिब रफ़्तार। रफ़्तार के लिए क्वालिटी की क़ुर्बानी मत दीजिए। एक बढ़िया टेस्ट दस कमज़ोर टेस्ट से बेहतर है।
घटते रिटर्न को समझना
पैटर्न
पहले 20 टेस्ट असर दिखाते हैं। हर टेस्ट कुछ न कुछ बेहतर करता है। रोडमैप ज़्यादा असर वाले मौक़ों से भरा होता है।
20 से 40 तक के टेस्ट कम असर दिखाते हैं। सीख अब भी मिलती है, पर सुधार छोटे होते हैं। साफ़ दिखने वाले मौक़े कम हो जाते हैं।
40 और उसके आगे के टेस्ट: मौक़े छोटे होते हैं। सुधार बहुत मामूली होते हैं। यह सामान्य है।
समाधान
घटते रिटर्न को टेस्टिंग की नाकामी मत समझिए। इसे परिपक्वता समझिए। घटते रिटर्न के दौर में अपना फ़ोकस बदलिए। चारों तरफ़ टेस्ट करने की जगह नए इलाक़ों में टेस्ट चलाइए। नए प्रोडक्ट। नए सेगमेंट। नए बाज़ार।
टेस्टिंग प्रोग्राम को लंबे समय तक चलाना
जोखिम
टेस्टिंग प्रोग्राम छह महीने ज़ोर से चलता है। फिर धीमा पड़ जाता है। लोग व्यस्त हो जाते हैं। टेस्टिंग पीछे चली जाती है। प्रोग्राम फीका पड़ जाता है।
इसे कैसे टिकाएँ
टिकाऊ प्रोग्राम को लगातार प्रतिबद्धता चाहिए। संसाधन चाहिए। मालिक चाहिए। टेस्टिंग टूल का बजट रखिए। टेस्टिंग करने वाले व्यक्ति का बजट रखिए। टेस्टिंग को सालाना लक्ष्यों में शामिल कीजिए।
अगर टेस्टिंग सालाना प्राथमिकता है, तो टेस्टिंग होती है। अगर वह "हो जाए तो अच्छा" वाली चीज़ है, तो टेस्टिंग रुक जाती है।
अक्सर पूछे जाने वाले सवाल
शक करने वाले टीम सदस्यों को कैसे यक़ीन दिलाऊँ कि टेस्टिंग काम करती है?
उन्हें एक टेस्ट दिखाइए। ज़्यादा ट्रैफ़िक वाले किसी एलिमेंट पर एक सरल टेस्ट चलाइए। नतीजे लीजिए। जीतने वाला सुधार दिखाइए। रेवेन्यू पर असर दिखाइए। एक कामयाब टेस्ट शक करने वालों को क़ायल कर देता है। नतीजे बातों से ज़्यादा बोलते हैं। उदाहरण: बटन के रंग का टेस्ट चलाइए। नतीजे दिखाइए: नीले बटन पर 9 प्रतिशत कन्वर्ज़न, लाल बटन पर 8.5 प्रतिशत कन्वर्ज़न। 8 प्रतिशत सुधार। असर निकालिए: अगर वेबसाइट पर महीने में 10,000 विज़िटर आते हैं और 2 प्रतिशत कन्वर्ट होते हैं, तो महीने में 200 कन्वर्ज़न होते हैं। 8 प्रतिशत सुधार का मतलब महीने में 16 अतिरिक्त कन्वर्ज़न। अगर औसत ऑर्डर वैल्यू $100 है, तो यह महीने में $1,600 की अतिरिक्त कमाई है। सालाना $19,000। यह शक करने वाले साथी को दिखाइए। जब पैसे की बात आती है, तो शक ख़त्म हो जाता है। WEMASY के वेबसाइट बिल्डर से आप इसे सीधे अपनी वेबसाइट पर सेट अप कर सकते हैं।
अगर हम प्रोजेक्ट में व्यस्त हैं, तो क्या टेस्टिंग टाल देनी चाहिए?
नहीं। टेस्टिंग प्रोजेक्ट डिलीवरी का हिस्सा होनी चाहिए। हर प्रोजेक्ट के बदलाव को लागू करने से पहले टेस्ट किया जाए। अगर टेस्टिंग प्रक्रिया में पहले से शामिल है, तो वह समय नहीं बढ़ाती। वह ऐसी चीज़ें लागू होने से रोकती है जो काम नहीं करतीं। उदाहरण: आप नया चेकआउट फ़्लो रिलीज़ कर रहे हैं। टेस्टिंग के बिना: लागू करें, लॉन्च करें, पता चले कि 90 प्रतिशत विज़िटर नए फ़्लो से उलझ रहे हैं, वापस पुराना करें, ठीक करें, दोबारा लॉन्च करें। कुल तीन हफ़्ते। टेस्टिंग के साथ: लॉन्च से पहले नए फ़्लो को एक हफ़्ता टेस्ट करें, दिक़्क़तें पता चलें, ठीक करें, भरोसे के साथ फ़्लो लॉन्च करें। कुल दो हफ़्ते। टेस्टिंग ख़राब लॉन्च रोककर समय बचाती है। टेस्टिंग को शुरू से टाइमलाइन में रखिए, बाद की सोच की तरह नहीं।
पुराने टेस्ट के नतीजे हमें कितनी बार दोबारा देखने चाहिए?
जब हालात बदलें, तब दोबारा देखिए। नया सीज़न। नया प्रतिस्पर्धी। कारोबार में बड़ा बदलाव। वरना हर टेस्ट का नतीजा अपने दौर के लिए सही रहता है। बार-बार दोबारा टेस्ट करने की ज़रूरत नहीं। उदाहरण: आपने जनवरी में ऑफ़र टेस्ट किया। मनी-बैक गारंटी ने 10 प्रतिशत छूट को हरा दिया। आपने मनी-बैक गारंटी लागू कर दी। अब जुलाई आता है और एक प्रतिस्पर्धी भी मनी-बैक गारंटी लॉन्च कर देता है। आपका फ़ायदा ख़त्म हो जाता है। क्या ऑफ़र दोबारा टेस्ट करना चाहिए? शायद। प्रतिस्पर्धी की चाल ने बाज़ार बदल दिया। आपका विजेता अब शायद प्रासंगिक न रहे। सीज़न के हिसाब से दोबारा देखना: ब्लैक फ़्राइडे के सीज़न में ऑफ़र टेस्ट करें। जुलाई में नतीजे अलग हो सकते हैं, क्योंकि ख़रीदारी का व्यवहार अलग होता है। जुलाई में ऑफ़र दोबारा टेस्ट करें। नतीजों से जुलाई की अपनी रणनीति बनती है।
हमें औसत विज़िटर के लिए टेस्ट करना चाहिए या किसी ख़ास सेगमेंट के लिए?
औसत विज़िटर से शुरू कीजिए। बेसलाइन निकालिए। फिर ख़ास सेगमेंट पर जाइए। अगर आप सिर्फ़ एक सेगमेंट के लिए ऑप्टिमाइज़ करेंगे, तो कुल प्रदर्शन बिगड़ता है। उदाहरण: आप सिर्फ़ मोबाइल पर ऑप्टिमाइज़ेशन टेस्ट करते हैं, क्योंकि मोबाइल ट्रैफ़िक सबसे ज़्यादा है। डेस्कटॉप की बेसलाइन 10 प्रतिशत है। मोबाइल की बेसलाइन 7 प्रतिशत है। आप मोबाइल के लिए ऑप्टिमाइज़ करते हैं और मोबाइल 8 प्रतिशत सुधार पर पहुँच जाता है। लेकिन डेस्कटॉप की बेसलाइन गिरकर 9 प्रतिशत हो जाती है, क्योंकि बदलाव डेस्कटॉप पर काम नहीं करते। आपने मोबाइल में सुधार पाया पर डेस्कटॉप को नुक़सान पहुँचाया। कुल मिलाकर आप पीछे चले गए। पहले व्यापक टेस्ट कीजिए ताकि सब पर पड़ने वाला असर समझ आए। फिर हर सेगमेंट के लिए ऑप्टिमाइज़ करने को सेगमेंट टेस्ट कीजिए।
अगर टेस्ट बार-बार हारते रहें, तो हम रफ़्तार कैसे बनाए रखें?
हारने वाले टेस्ट बताते हैं कि क्या काम नहीं करता। यह क़ीमती डेटा है। जीतने वाले टेस्ट भी आएँगे। टेस्ट करते रहिए। हार से मिली सीख पर आगे बढ़िए। उदाहरण: पाँच हेडलाइन टेस्ट करें। तीन मौजूदा हेडलाइन से हार जाती हैं। दो जीतती हैं। जीत बताती है कि क्या काम करता है। हार बताती है कि आपकी ऑडियंस किस पर रिस्पॉन्ड नहीं करती। अब आप जानते हैं कि "जल्दी करो" वाला मैसेज हारता है (लोगों को दबाव पसंद नहीं)। आप जानते हैं कि "ख़ास फ़ायदा" वाला मैसेज जीतता है (लोगों को साफ़ बात पसंद है)। अगला टेस्ट इसी सीख पर बनता है। और भी ख़ास फ़ायदों को टेस्ट कीजिए। टेस्ट जुड़ते जाते हैं। हारने वाले टेस्ट नाकामी नहीं हैं। वे डेटा पॉइंट हैं।
अगर टेस्टिंग से पता चले कि हमारा पूरा तरीक़ा ही ग़लत है, तो हम क्या करें?
जश्न मनाइए। आपने कुछ क़ीमती सीखा। अब दिशा बदलिए। चुपचाप होते रेवेन्यू नुक़सान से सीखने से बेहतर है कि यह टेस्टिंग से सीखा जाए। उदाहरण: आपको लगता है कि आपकी टारगेट ऑडियंस प्रीमियम प्रोडक्ट चाहती है। टेस्ट दिखाता है कि ऑडियंस बजट विकल्प को पसंद करती है। आपकी प्रीमियम पोज़िशनिंग ग़लत थी। जश्न का पल: आपने अभी वह सीखा जो टेस्ट न करने पर सालों तक आपका पैसा डुबोता। अब रणनीति बदलिए। मैसेजिंग को बजट के अनुकूल कीजिए। नई पोज़िशनिंग टेस्ट कीजिए। $50,000 के रेवेन्यू नुक़सान पर यह पता चलना, $5 मिलियन के नुक़सान पर पता चलने से कहीं बेहतर है।