तुमच्या अॅपची beta चाचणी कशी घ्यायची
beta चाचणी घेण्यासाठी तुम्हाला काय शिकायचे आहे ते ठरवा, तुमच्या खऱ्या वापरकर्त्यांशी जुळणाऱ्या छोट्या गटाला आमंत्रित करा, त्यांना स्पष्ट पहिले काम द्या, आणि एका ठिकाणी ठरलेल्या वेळापत्रकावर अभिप्राय गोळा करा. ज्या गोष्टी त्यांना अडवतात त्या दुरुस्त करा, गट फेऱ्यांमध्ये वाढवा, आणि आधी लिहिलेल्या exit criteria पूर्ण झाल्यावर beta संपवा — संयम संपला म्हणून नव्हे.
beta म्हणजे soft launch नव्हे. ती एक संरचित प्रयोग आहे, ज्याला सुरुवात, शेवट आणि उत्तर द्यायचा एक प्रश्न असतो.
beta कुठे बसतो
Validation विचारते की समस्या सोडवण्यायोग्य आहे का. beta एक अरुंद प्रश्न विचारतो: प्रॉडक्टची ही आवृत्ती खऱ्या लोकांसाठी, खऱ्या परिस्थितीत समस्या सोडवते का? Launching नंतर येते, उत्तर बहुतेक होय असेल तेव्हा.
कोणालाही आमंत्रित करण्याआधी स्वतः चाचणी करा — लाँच करण्यापूर्वी तुमच्या अॅपची चाचणी कशी घ्यायची त्यावर मार्गदर्शन करते. साइन-अप तुटलेले आहे हे testers ना शोधू देऊ नका.
पायरी 1: beta ने काय उत्तर द्यायला हवे ते लिहा
दोन-तीन प्रश्न निवडा. योजनेतील बाकी सर्व त्यांच्यावरून ठरते.
| उद्दिष्ट | उदाहरण प्रश्न | काय मोजायचे |
|---|---|---|
| वापरण्यायोग्यता | नवीन वापरकर्ते मदतीशिवाय मुख्य काम पूर्ण करू शकतात का? | स्वतःहून पूर्ण करणारे किती जण |
| मूल्य | लोक आठवण न देता परत येतात का? | दुसऱ्या आणि तिसऱ्या आठवड्यातील परत भेटी |
| विश्वासार्हता | खऱ्या डेटा आणि डिव्हाइसवर टिकते का? | गंभीरतेनुसार bugs, error logs |
| पैसे देण्याची इच्छा | लोक नियोजित किंमत देतील का? | शेवटी रूपांतरण किंवा pre-orders |
| onboarding | पहिल्या सत्रात लोक कुठे अडकतात? | drop-off बिंदू, सपोर्ट प्रश्न |
काल्पनिक उदाहरण: लहान कॅफेंसाठी शिफ्ट-नियोजन अॅप दोन उद्दिष्टे ठेवते: “व्यवस्थापक पहिल्या सत्रात मदतीशिवाय आठवड्याचे रोटा प्रकाशित करू शकतो का?” आणि “कर्मचारी दुसऱ्या आठवड्यात स्वतःहून अॅप उघडतात का?”
पायरी 2: beta चा प्रकार निवडा
| प्रकार | कोण | कधी योग्य | तडजोड |
|---|---|---|---|
| मित्र आणि alpha | तुम्ही ओळखणारे लोक | अगदी सुरुवातीला, स्पष्ट तुटफूट शोधण्यासाठी | सभ्य अभिप्राय, प्रातिनिधिक नाही |
| closed beta | आमंत्रित लक्ष्य वापरकर्ते | बहुतेक सुरुवातीची उत्पादने | भरती प्रयत्न लागतात |
| open beta | साइन अप करणारे कोणीही | स्केल आणि विविधता तपासण्यासाठी | जास्त सपोर्ट, प्रत्येक tester कडून कमी खोली |
| paid beta | संस्थापक किंमत देणारे वापरकर्ते | पैसे देण्याची इच्छा तपासण्यासाठी | जास्त अपेक्षा |
पहिल्या प्रॉडक्टसाठी, अनेक फेऱ्यांसह closed beta सहसा योग्य निर्णय असतो.
पायरी 3: योग्य testers शोधा
सर्वोत्तम testers ना आत्ता ती समस्या असते, ते तुमच्या लक्ष्य वापरकर्त्याशी जुळतात, आणि beta कालावधीत अॅप वापरायला वेळ असतो. ते शोधण्याची ठिकाणे:
- तुमची waitlist किंवा ईमेल यादी — लाँचआधी प्रेक्षक कसा तयार करायचा पहा.
- समस्या तपासताना तुम्ही मुलाखत घेतलेले लोक.
- niche समुदाय जिथे तुमचे वापरकर्ते एकत्र येतात, त्यांच्या प्रचाराच्या नियमांचे पालन करून.
- प्रोफाइलशी जुळणाऱ्या तुमच्या नेटवर्कमधील लोकांना थेट आमंत्रण.
मिश्रण निवडण्यासाठी काही स्क्रीनिंग प्रश्न विचारा: त्यांची भूमिका, ते आज समस्या कशी सोडवतात, ते कोणते डिव्हाइस वापरतील, आणि समस्या किती वेळा येते. तुमच्या लक्ष्य वापरकर्त्याशी जुळणाऱ्या उत्तरांच्या लोकांना आमंत्रित करा, आणि ते लक्ष्य वापरकर्ते नसतील तर beta सहसंस्थापकांनी भरू नका.
आमंत्रण टेम्पलेट
नमस्कार [नाव] — तुम्ही साइन अप करताना [समस्या] चा उल्लेख केला होता. मी [प्रॉडक्ट] ची एक छोटी खाजगी beta सुरू करत आहे, जे [परिणाम] देते. ती [सुरुवात] ते [शेवट] चालेल. मी testers ना [खरे काम] साठी आठवड्यातून किमान एकदा वापरण्याची आणि दर शुक्रवारी एक छोटा check-in भरण्याची विनंती करत आहे. बदल्यात: beta दरम्यान मोफत प्रवेश आणि [संस्थापक किंमत / वाढवलेला मोफत कालावधी]. रस आहे का?
वेळेची बांधिलकी प्रामाणिकपणे सांगा. त्यांनी काय साइन अप केले आहे हे माहीत असलेले लोक अधिक चांगला अभिप्राय देतात.
पायरी 4: beta kit तयार करा
पहिले आमंत्रण जाण्याआधी हे तयार ठेवा:
- स्वागत संदेश लिंक, साइन इन कसे करायचे, पहिले काम काय वापरून पहायचे, आणि समस्या कशा नोंदवायच्या यासह.
- ज्ञात समस्यांची यादी, जेणेकरून testers एकच गोष्ट दहा वेळा नोंदवणार नाहीत.
- एक अभिप्राय चॅनल. फॉर्म, शेअर केलेला चॅट गट किंवा ईमेल पत्ता — पाच नव्हे, एकच ठिकाण.
- bug report टेम्पलेट. त्यांनी काय केले, काय अपेक्षित होते, काय घडले, डिव्हाइस आणि ब्राउझर, आणि स्क्रीनशॉट विचारा. चांगला bug report कसा लिहायचा मध्ये शेअर करण्याजोगी आवृत्ती आहे.
- मूलभूत analytics किंवा logs, जेणेकरून स्मरणावर अवलंबून न राहता काय घडले ते तुम्हाला दिसेल.
- डेटाबद्दल स्पष्ट अपेक्षा. beta दरम्यान डेटा रीसेट होऊ शकतो हे testers ना सांगा, आणि अपूर्ण अॅपमध्ये संवेदनशील माहिती टाकायला सांगू नका.
- अटी आणि गोपनीयतेची मूलभूत गोष्टी. एक छोटा beta करार आणि गोपनीयता नोट; वैयक्तिक डेटा हाताळत असाल तर स्थानिक नियम किंवा सल्लागार तपासा.
पायरी 5: फेऱ्यांमध्ये चालवा
फेऱ्या तुम्हाला अधिक लोक येण्याआधी समस्या दुरुस्त करू देतात.
| फेरी | Testers | लक्ष |
|---|---|---|
| फेरी 1 | मूठभर | ते साइन अप करू शकतात आणि मुख्य काम पूर्ण करू शकतात का? काही सत्रे थेट पहा. |
| फेरी 2 | मोठा गट | काही आठवड्यांचा खरा वापर; फेऱ्यांमधील टॉप समस्या दुरुस्त करा. |
| फेरी 3 (ऐच्छिक) | विस्तृत किंवा खुला | तुमच्या मदतीशिवाय onboarding, विश्वासार्हता, किंमत चाचणी. |
फेरी 1 मध्ये, दोन-तीन testers ना अॅप पहिल्यांदा वापरताना त्यांची स्क्रीन शेअर करायला सांगा. शांत राहा आणि ते कुठे अडखळतात ते पहा. हा बहुतेक वेळा संपूर्ण beta मधील सर्वात उपयुक्त तास असतो.
पायरी 6: ठरलेल्या लयीत अभिप्राय गोळा करा
असंरचित “काही अभिप्राय?” संदेशांना अस्पष्ट उत्तरे मिळतात. त्याऐवजी लहान, नियमित check-in वापरा:
साप्ताहिक check-in (काल्पनिक उदाहरण प्रश्न)
- या आठवड्यात तुम्ही [प्रॉडक्ट] कशासाठी वापरले?
- काय निराशाजनक किंवा गोंधळात टाकणारे होते?
- काही गहाळ होते का ज्यामुळे तुम्ही एखादे काम पूर्ण करू शकला नाहीत?
- तुम्ही ते पुन्हा वापरू शकला नाहीत तर तुम्हाला कसे वाटेल? (खूप निराश / थोडे / अजिबात नाही)
- आणखी काही?
लोक जे म्हणतात आणि जे करतात ते एकत्र पहा. जे म्हणतात की ते छान आहे पण कधीच लॉगिन करत नाहीत, तेही तुम्हाला काहीतरी सांगत असतात.
पायरी 7: येणाऱ्या गोष्टींचे वर्गीकरण करा
प्रत्येक अभिप्राय एका यादीत ठेवा आणि आठवड्याला वर्गीकृत करा.
| श्रेणी | उदाहरणे | कृती |
|---|---|---|
| अडथळा | साइन अप होत नाही, डेटा हरवला, पेमेंट अयशस्वी | लगेच दुरुस्त करा, प्रभावित testers ना सांगा |
| मोठा bug | सामान्य डिव्हाइसवर मुख्य फीचर तुटले | या फेरीत दुरुस्त करा |
| गोंधळ | लोकांना बटण सापडत नाही, लेबल चुकीचे वाचतात | मजकूर किंवा लेआउट दुरुस्त करा; स्वस्त आणि मौल्यवान |
| किरकोळ bug | दृश्य त्रुटी, दुर्मिळ प्रकरण | नंतरसाठी गट करा |
| फीचर विनंती | “हे X देखील करू शकते का?” | नोंदवा, कोणती समस्या सुटेल विचारा, नमुने पहा |
beta दरम्यान मोठी फीचर्स जोडण्यास विरोध करा. प्रत्येक नवीन फीचरमुळे मुख्य प्रॉडक्ट चालते का ते सांगणे कठीण होते.
पायरी 8: लूप बंद करा
त्यांचा अभिप्राय वापरलेला दिसला की testers अभिप्राय देत राहतात.
- प्रत्येक फेरीनंतर एक छोटा changelog पाठवा: “तुम्ही X नोंदवले; ते दुरुस्त झाले आहे.”
- जेव्हा त्यांच्या अहवालामुळे दुरुस्ती झाली, तेव्हा लोकांचे नाव घेऊन खाजगीत आभार माना.
- beta कधी संपेल, त्यांच्या डेटा आणि खात्याचे काय होईल, आणि त्यांची संस्थापक ऑफर काय आहे ते testers ना सांगा.
पायरी 9: तुम्ही तयार आहात का ते ठरवा
beta सुरू होण्याआधी exit criteria लिहा, मग शेवटी प्रामाणिकपणे तपासा. एक टेम्पलेट:
- कोणतेही ज्ञात अडथळे किंवा डेटा-हानी bugs नाहीत
- बहुतेक नवीन testers मदतीशिवाय मुख्य काम पूर्ण करतात
- पुढील आठवड्यांत लक्षणीय हिस्सा स्वतःहून परत येतो
- सर्वात मोठे गोंधळाचे मुद्दे दुरुस्त आणि पुन्हा चाचणी केले गेले आहेत
- साइन-अप, पासवर्ड रीसेट आणि कोणताही पेमेंट फ्लो सुरुवातीपासून शेवटपर्यंत काम करतो
- तुमच्याकडे testers च्या शब्दांत स्पष्ट संदेश आहे की प्रॉडक्ट कोणासाठी आहे
बहुतेक चौकटी टिक झाल्या तर onboarding पॉलिश आणि सार्वजनिक लाँचकडे जा. परत वापर कमी असेल तर तो बग यादीचा नाही तर प्रॉडक्टचा प्रश्न आहे — लाँच करण्याआधी मुलाखतींकडे परत जा.
Mythex सह beta चालवणे
Mythex वर बिल्ड करत असाल तर काही फीचर्स beta सोबत नीट जुळतात:
- फेरी 1 साठी preview लिंक्स. Share बटण तुमच्या लाइव्ह preview ची लिंक तयार करते जी Mythex खाते नसलेल्या लोकांसाठीही काम करते, त्यामुळे लवकर tester अपूर्ण काम प्रकाशित करण्याआधी वापरू शकतो. प्रत्येक गटासाठी एक लिंक बनवा आणि झाल्यावर ती हटवा — Preview docs स्पष्ट करतात की लिंक्स प्रोजेक्ट कसे जागे करतात आणि क्रेडिट्स कसे वापरतात.
- लांब फेऱ्यांसाठी प्रकाशित करा. प्रकाशित अॅप स्वतःच्या पत्त्यावर चालते, जे अनेक आठवडे वापरणाऱ्या testers साठी योग्य आहे.
- प्रत्येक फेरीपूर्वी App Testing. चॅटमध्ये
/testटाइप करा आणि एजंट तुमचा preview क्लिक करून तुटलेले फ्लो कळवतो — कोणालाही आमंत्रित करण्याआधी उपयुक्त तपासणी (App Testing docs). - Checkpoints. beta दरम्यान दुरुस्तीने काहीतरी मोडले तर मागील checkpoint वर परत जा.
tester चा bug report थेट चॅटमध्ये पेस्ट करा आणि एजंटला तो पुन्हा तयार करून दुरुस्त करायला सांगा, मग tester ला सांगा की ती दुरुस्ती आता लाइव्ह आहे.
प्रश्न
मला किती beta testers हवेत?
लोक वाटतात त्यापेक्षा कमी. तुमच्या लक्ष्य वापरकर्त्याशी जुळणारा आणि अॅप खरोखर वापरणारा छोटा गट बहुतेक मोठ्या समस्या शोधतो. थोड्या लोकांपासून सुरुवात करा, त्यांना सापडलेल्या गोष्टी दुरुस्त करा, मग मोठा गट वाढवा.
beta चाचणी किती काळ चालावी?
testers ना अॅप खऱ्या आयुष्यात वापरतील तसे वापरता येईल इतका काळ — आठवड्याला वापरले जाणारे काहीतरी असेल तर सहसा काही आठवडे. beta अनिश्चित काळ रेंगाळू नये म्हणून आधीच शेवटची तारीख ठरवा.
beta testers ना पैसे द्यावे का?
तुम्हाला काय शिकायचे आहे त्यावर अवलंबून. मोफत beta साठी लोक शोधणे सोपे जाते; पैसे देऊन किंवा सवलतीत केलेला beta सांगतो की लोक प्रॉडक्टला पैसे देण्याइतके मूल्य देतात का. अनेक संस्थापक आधी मोफत बंद beta चालवतात आणि नंतरच्या फेरीत पेमेंट मागतात.
closed आणि open beta मध्ये काय फरक आहे?
closed beta फक्त आमंत्रणाने होतो, सहसा तुम्ही निवडलेला छोटा गट ज्यांच्याशी तुम्ही थेट बोलता. open beta मध्ये कोणीही साइन अप करू शकतो, ज्यामुळे जास्त संख्या आणि विविधता मिळते, पण वैयक्तिक संपर्क कमी आणि सपोर्टचे काम जास्त.
beta testers च्या feature requests चे मी काय करू?
त्यांची नोंद ठेवा, प्रत्येकामुळे कोणती समस्या सुटेल ते विचारा, आणि नमुने शोधा. बहुतेक beta ने आधी bugs आणि गोंधळ दुरुस्त करावेत; beta दरम्यान फीचर्स जोडल्याने मुख्य प्रॉडक्ट चालते का ते सांगणे कठीण होते.