अपने ऐप का बीटा टेस्ट कैसे चलाएं
बीटा टेस्ट चलाने के लिए तय करें कि आपको क्या जानना है, अपने असली यूज़र्स से मेल खाने वाले छोटे समूह को आमंत्रित करें, उन्हें एक साफ़ पहला काम दें, और तय शेड्यूल पर सारा फ़ीडबैक एक जगह इकट्ठा करें। जो उन्हें रुकाता है उसे ठीक करें, समूह को चरणों में बढ़ाएं, और बीटा तब खत्म करें जब आपके पहले से लिखे गए निकास मानदंड पूरे हो जाएं, न कि जब आपका धैर्य खत्म हो जाए।
बीटा सॉफ़्ट लॉन्च नहीं है। यह एक संरचित प्रयोग है, जिसकी शुरुआत, अंत और एक सवाल होता है जिसका जवाब चाहिए।
बीटा कहाँ फ़िट होता है
सत्यापन पूछता है कि समस्या हल करने लायक है या नहीं। बीटा एक संकीर्ण सवाल पूछता है: क्या प्रोडक्ट का यह संस्करण असली लोगों के लिए, असली परिस्थितियों में, समस्या हल करता है? लॉन्च उसके बाद आता है, जब जवाब ज़्यादातर “हाँ” हो।
किसी को आमंत्रित करने से पहले अपना खुद का टेस्टिंग करें। लॉन्च से पहले अपने ऐप को कैसे टेस्ट करें इसके बारे में है। टेस्टरों को यह नहीं खोजना चाहिए कि साइनअप टूटा हुआ है।
चरण 1: लिखें कि बीटा से क्या जानना है
दो या तीन सवाल चुनें। योजना के बाकी हिस्से उन्हीं से तय होंगे।
| लक्ष्य | उदाहरण सवाल | क्या मापें |
|---|---|---|
| उपयोगिता | क्या नए यूज़र बिना मदद के मुख्य काम पूरा कर सकते हैं? | कितने लोग उसे खुद पूरा करते हैं |
| मूल्य | क्या लोग बिना याद दिलाए वापस आते हैं? | दूसरे और तीसरे हफ़्ते में वापसी |
| विश्वसनीयता | क्या यह असली डेटा और डिवाइस के साथ टिकता है? | गंभीरता के हिसाब से बग, एरर लॉग |
| पैसे देने की इच्छा | क्या लोग तय कीमत चुकाएंगे? | अंत में रूपांतरण या प्री-ऑर्डर |
| ऑनबोर्डिंग | पहले सत्र में लोग कहाँ अटकते हैं? | ड्रॉप-ऑफ़ बिंदु, सपोर्ट सवाल |
काल्पनिक उदाहरण: छोटे कैफ़े के लिए एक शिफ़्ट-शेड्यूलिंग ऐप दो लक्ष्य रखता है: “क्या मैनेजर अपने पहले सत्र में बिना मदद के एक हफ़्ते की रोस्टर पब्लिश कर सकता है?” और “क्या स्टाफ़ दूसरे हफ़्ते में खुद ऐप खोलते हैं?”
चरण 2: बीटा का प्रकार चुनें
| प्रकार | कौन | कब सबसे अच्छा | समझौता |
|---|---|---|---|
| दोस्त और alpha | जिन्हें आप जानते हैं | बहुत शुरुआत में, साफ़ टूटन पकड़ने के लिए | विनम्र फ़ीडबैक, प्रतिनिधि नहीं |
| Closed बीटा | आमंत्रित लक्ष्य यूज़र | ज़्यादातर शुरुआती प्रोडक्ट | भर्ती में मेहनत लगती है |
| Open बीटा | जो भी साइन अप करे | पैमाने और विविधता की जाँच के लिए | ज़्यादा सपोर्ट, हर टेस्टर से कम गहराई |
| भुगतान वाला बीटा | संस्थापक कीमत पर भुगतान करने वाले यूज़र | पैसे देने की इच्छा जाँचने के लिए | ज़्यादा उम्मीदें |
पहले प्रोडक्ट के लिए, कुछ दौर वाला closed बीटा आम तौर पर सही है।
चरण 3: सही टेस्टर भर्ती करें
सबसे अच्छे टेस्टर अभी वह समस्या झेल रहे हैं, आपके लक्ष्य यूज़र से मेल खाते हैं, और बीटा की अवधि में ऐप आज़माने का समय रखते हैं। उन्हें ढूँढने की जगहें:
- आपकी वेटलिस्ट या ईमेल सूची; देखें लॉन्च से पहले ऑडियंस कैसे बनाएं।
- जिन लोगों से आपने सत्यापन के दौरान इंटरव्यू किए।
- ऐसे niche समुदाय जहाँ आपके यूज़र इकट्ठा होते हैं, उनके नियमों के अनुसार प्रचार करते हुए।
- आपके नेटवर्क में ऐसे लोग जो प्रोफ़ाइल से मेल खाते हों, उन्हें सीधे आमंत्रण।
कुछ स्क्रीनिंग सवाल पूछें ताकि मिश्रण चुन सकें: उनकी भूमिका, वे समस्या आज कैसे हल करते हैं, वे किस डिवाइस पर इस्तेमाल करेंगे, और समस्या कितनी बार आती है। ऐसे लोगों को आमंत्रित करें जिनके जवाब आपके लक्ष्य यूज़र से मेल खाते हों, और बीटा को साथी संस्थापकों से न भरें, जब तक वे खुद लक्ष्य यूज़र न हों।
आमंत्रण का टेम्पलेट
नमस्ते [नाम] — साइन अप करते समय आपने [समस्या] का ज़िक्र किया था। मैं [प्रोडक्ट] का एक छोटा निजी बीटा खोल रहा हूँ, जो [नतीजा] देता है। यह [शुरू] से [अंत] तक चलेगा। मैं टेस्टरों से कहूँगा कि [असली काम] के लिए इसे कम से कम हफ़्ते में एक बार इस्तेमाल करें और हर शुक्रवार एक छोटा चेक-इन जवाब दें। बदले में बीटा के दौरान मुफ़्त पहुँच और [संस्थापक कीमत / बढ़ी हुई मुफ़्त अवधि] मिलेगी। क्या आप इच्छुक हैं?
समय की प्रतिबद्धता ईमानदारी से बताएं। जो लोग जानते हैं कि उन्होंने किस चीज़ के लिए हामी भरी है, वे बेहतर फ़ीडबैक देते हैं।
चरण 4: बीटा किट तैयार करें
पहला आमंत्रण जाने से पहले ये तैयार रखें:
- स्वागत संदेश जिसमें लिंक हो, साइन इन कैसे करें, पहला काम क्या है, और समस्याएँ कैसे बताएं।
- ज्ञात समस्याओं की सूची, ताकि टेस्टर एक ही बात दस बार न बताएं।
- एक फ़ीडबैक चैनल। एक फ़ॉर्म, एक साझा चैट ग्रुप या एक ईमेल पता; एक जगह, पाँच नहीं।
- बग रिपोर्ट टेम्पलेट। पूछें कि उन्होंने क्या किया, उन्हें क्या उम्मीद थी, क्या हुआ, डिवाइस और ब्राउज़र, और एक स्क्रीनशॉट। अच्छी बग रिपोर्ट कैसे लिखें में इसका एक संस्करण है जो आप साझा कर सकते हैं।
- बुनियादी analytics या लॉग, ताकि आप याददाश्त पर निर्भर हुए बिना देख सकें कि क्या हुआ।
- डेटा के बारे में साफ़ उम्मीदें। बताएं कि बीटा के दौरान डेटा रीसेट हो सकता है, और अधूरे ऐप में संवेदनशील जानकारी डालने को न कहें।
- शर्तें और प्राइवेसी की मूल बातें। एक छोटा बीटा समझौता और प्राइवेसी नोट; अगर आप व्यक्तिगत डेटा संभालते हैं तो स्थानीय नियम या किसी सलाहकार से जाँच करें।
चरण 5: दौरों में चलाएं
दौर आपको ज़्यादा लोगों के समस्या से टकराने से पहले उसे ठीक करने देते हैं।
| दौर | टेस्टर | फ़ोकस |
|---|---|---|
| दौर 1 | कुछ लोग | क्या वे साइन अप करके मुख्य काम पूरा कर सकते हैं? कुछ सत्र लाइव देखें। |
| दौर 2 | बड़ा समूह | कुछ हफ़्तों तक असली इस्तेमाल; दौरों के बीच शीर्ष समस्याएँ ठीक करें। |
| दौर 3 (वैकल्पिक) | व्यापक या खुला | आपकी मदद के बिना ऑनबोर्डिंग, विश्वसनीयता, कीमत की जाँच। |
दौर 1 में दो-तीन टेस्टरों से कहें कि वे पहली बार ऐप आज़माते समय अपनी स्क्रीन शेयर करें। चुप रहें और देखें कि वे कहाँ झिझकते हैं। बीटा का यह सबसे उपयोगी घंटा अक्सर होता है।
चरण 6: एक लय में फ़ीडबैक लें
बिना संरचना वाले “कोई फ़ीडबैक?” संदेशों के जवाब धुंधले आते हैं। इसके बजाय एक छोटा, नियमित चेक-इन इस्तेमाल करें:
साप्ताहिक चेक-इन (काल्पनिक उदाहरण सवाल)
- इस हफ़्ते आपने [प्रोडक्ट] किस काम के लिए इस्तेमाल किया?
- क्या निराशाजनक या भ्रमित करने वाला था?
- क्या कुछ गायब था जिसकी वजह से कोई काम पूरा नहीं हो सका?
- अगर आप अब इसका इस्तेमाल नहीं कर पाते, तो आपको कैसा लगेगा? (बहुत निराश / कुछ हद तक / बिल्कुल नहीं)
- और कुछ?
लोग जो कहते हैं और जो करते हैं, दोनों को मिलाकर देखें। जो कहता है कि यह बढ़िया है पर कभी लॉगिन नहीं करता, वह भी आपको कुछ बता रहा है।
चरण 7: जो आता है उसे छाँटें
हर फ़ीडबैक को एक ही सूची में डालें और हर हफ़्ते छाँटें।
| श्रेणी | उदाहरण | कार्रवाई |
|---|---|---|
| रुकावट | साइन अप नहीं हो रहा, डेटा खो गया, भुगतान विफल | तुरंत ठीक करें, प्रभावित टेस्टरों को बताएं |
| बड़ा बग | आम डिवाइस पर मुख्य फ़ीचर टूटा | इस दौर में ठीक करें |
| भ्रम | लोग बटन नहीं ढूँढ पाते, लेबल गलत पढ़ते हैं | कॉपी या लेआउट ठीक करें; सस्ता और मूल्यवान |
| छोटा बग | दृश्य गड़बड़ी, दुर्लभ एज केस | बाद के लिए इकट्ठा करें |
| फ़ीचर अनुरोध | “क्या यह X भी कर सकता है?” | दर्ज करें, पूछें कि कौन सी समस्या हल होगी, पैटर्न खोजें |
बीटा के बीच में बड़े फ़ीचर जोड़ने से बचें। हर नया फ़ीचर यह पता लगाना कठिन बनाता है कि मुख्य प्रोडक्ट काम करता है या नहीं।
चरण 8: लूप बंद करें
टेस्टर फ़ीडबैक देते रहते हैं जब वे देखते हैं कि उसका इस्तेमाल होता है।
- हर दौर के बाद एक छोटा चेंजलॉग भेजें: “आपने X की रिपोर्ट की थी; वह ठीक हो गया है।”
- जब किसी की रिपोर्ट से फ़िक्स हुआ, तो उन्हें नाम से, निजी रूप से धन्यवाद दें।
- टेस्टरों को बताएं कि बीटा कब खत्म होगा, उनके डेटा और खाते का क्या होगा, और उनका संस्थापक ऑफ़र क्या है।
चरण 9: तय करें कि आप तैयार हैं
बीटा शुरू होने से पहले निकास मानदंड लिखें, और अंत में ईमानदारी से जाँचें। एक टेम्पलेट:
- कोई ज्ञात रुकावट या डेटा खोने वाला बग नहीं
- ज़्यादातर नए टेस्टर बिना मदद के मुख्य काम पूरा करते हैं
- बाद के हफ़्तों में काफ़ी टेस्टर अपने-आप वापस आते हैं
- शीर्ष भ्रम वाले बिंदु ठीक हो गए और दोबारा टेस्ट हुए
- साइनअप, पासवर्ड रीसेट और कोई भी पेमेंट फ़्लो शुरू से अंत तक काम करते हैं
- आपके पास टेस्टरों की अपनी भाषा में एक साफ़ संदेश है कि प्रोडक्ट किसके लिए है
अगर ज़्यादातर बॉक्स टिक हो गए हैं, तो ऑनबोर्डिंग की पॉलिश और सार्वजनिक लॉन्च की ओर बढ़ें। अगर वापसी का उपयोग कम है, तो यह प्रोडक्ट का सवाल है, बग की सूची का नहीं; लॉन्च से पहले इंटरव्यू पर वापस जाएं।
Mythex के साथ बीटा चलाना
अगर आप Mythex से बना रहे हैं, तो कुछ फ़ीचर बीटा से सीधे मेल खाते हैं:
- दौर 1 के लिए प्रीव्यू लिंक। Share बटन आपके लाइव प्रीव्यू का एक लिंक बनाता है, जो Mythex खाते के बिना लोगों के लिए भी काम करता है, ताकि कोई शुरुआती टेस्टर पब्लिश करने से पहले अधूरा काम आज़मा सके। हर समूह के लिए एक लिंक बनाएं और काम खत्म होने पर उसे हटाएं; Preview दस्तावेज़ बताते हैं कि लिंक प्रोजेक्ट को कैसे जगाते हैं और क्रेडिट कैसे इस्तेमाल करते हैं।
- लंबे दौरों के लिए पब्लिश करें। पब्लिश्ड ऐप अपने पते पर चलता है, जो कई हफ़्तों तक टेस्ट करने वालों के लिए ठीक है।
- हर दौर से पहले App Testing। चैट में
/testटाइप करें और एजेंट आपके प्रीव्यू में क्लिक करके टूटे फ़्लो की रिपोर्ट देता है, किसी को आमंत्रित करने से पहले एक उपयोगी जाँच (App Testing दस्तावेज़)। - Checkpoints। अगर बीटा के बीच कोई फ़िक्स कुछ और तोड़ दे, तो पिछले checkpoint पर लौट जाएं।
किसी टेस्टर की बग रिपोर्ट सीधे चैट में पेस्ट करें और एजेंट से उसे दोबारा बनाकर ठीक करने को कहें, फिर टेस्टर को बताएं कि यह लाइव है।
सवाल
मुझे कितने बीटा टेस्टर चाहिए?
लोग जितना सोचते हैं उससे कम। आपके लक्षित यूज़र से मेल खाने वाला और सचमुच ऐप इस्तेमाल करने वाला एक छोटा समूह ज़्यादातर बड़ी समस्याएँ सामने ले आएगा। कुछ लोगों से शुरू करें, जो मिले उसे ठीक करें, फिर बड़े समूह तक जाएं।
बीटा टेस्ट कितने समय तक चलना चाहिए?
इतना लंबा कि टेस्टर ऐप को वैसे इस्तेमाल करें जैसे वे असल ज़िंदगी में करते, जो अक्सर हफ़्ते में इस्तेमाल होने वाली चीज़ के लिए कुछ हफ़्ते होते हैं। पहले से एक अंतिम तारीख तय करें, ताकि बीटा बिना अंत के न खिंचे।
क्या बीटा टेस्टरों को पैसे देने चाहिए?
यह इस पर निर्भर है कि आपको क्या जानना है। मुफ़्त बीटा के लिए लोग आसानी से मिलते हैं; भुगतान वाला या छूट वाला बीटा बताता है कि लोग प्रोडक्ट को पैसे देने लायक मानते हैं या नहीं। कई संस्थापक पहले मुफ़्त closed बीटा चलाते हैं और बाद के दौर में भुगतान माँगते हैं।
closed और open बीटा में क्या फ़र्क है?
closed बीटा केवल आमंत्रण से होता है, आम तौर पर आपके चुने हुए छोटे समूह के साथ जिससे आप सीधे बात करते हैं। open बीटा में कोई भी साइन अप कर सकता है, जिससे ज़्यादा मात्रा और विविधता मिलती है, पर व्यक्तिगत संपर्क कम और सपोर्ट का काम ज़्यादा।
बीटा टेस्टरों के फ़ीचर अनुरोधों का क्या करूँ?
उन्हें दर्ज करें, पूछें कि हर एक किस समस्या को हल करेगा, और पैटर्न खोजें। ज़्यादातर बीटा में पहले बग और भ्रम ठीक होने चाहिए; बीटा के दौरान फ़ीचर जोड़ने से यह पता लगाना मुश्किल हो जाता है कि मुख्य प्रोडक्ट काम करता है या नहीं।