તમારી એપનો beta test કેવી રીતે ચલાવવો
beta test ચલાવવા માટે, નક્કી કરો કે તમારે શું શીખવું છે, તમારા વાસ્તવિક વપરાશકર્તાઓ સાથે મેળ ખાતા લોકોના નાના જૂથને આમંત્રિત કરો, તેમને સ્પષ્ટ પ્રથમ કાર્ય આપો, અને નિશ્ચિત સમયપત્રક પર એક જ જગ્યાએ પ્રતિસાદ એકત્ર કરો. જે તેમને અટકાવે તે ઠીક કરો, રાઉન્ડમાં જૂથ વિસ્તારો, અને જ્યારે તમે અગાઉથી લખેલા બહાર નીકળવાના માપદંડો પૂરા થાય ત્યારે beta સમાપ્ત કરો — ધીરજ ખૂટે ત્યારે નહીં.
beta એ soft launch નથી. તે એક શરૂઆત, અંત અને જવાબ આપવાના પ્રશ્ન સાથેનો સંરચિત પ્રયોગ છે.
beta ક્યાં બંધબેસે છે
Validation પૂછે છે કે સમસ્યા ઉકેલવા યોગ્ય છે કે નહીં. beta વધુ સાંકડો પ્રશ્ન પૂછે છે: આ પ્રોડક્ટનું આ સંસ્કરણ વાસ્તવિક સંજોગોમાં વાસ્તવિક લોકો માટે સમસ્યા ઉકેલે છે? લૉન્ચ કરવું પછી આવે છે, જ્યારે જવાબ મોટે ભાગે હા હોય.
કોઈને આમંત્રિત કરતા પહેલા, પહેલા તમારું પોતાનું પરીક્ષણ કરો — લૉન્ચ પહેલાં તમારી એપનું પરીક્ષણ કેવી રીતે કરવું એ આવરી લે છે. Testers એ શોધનારા ન હોવા જોઈએ કે sign-up તૂટેલું છે.
પગલું 1: લખો કે beta ને શું જવાબ આપવો જ જોઈએ
બે કે ત્રણ પ્રશ્નો પસંદ કરો. યોજનાની બાકીની દરેક વસ્તુ તેમાંથી આવે છે.
| લક્ષ્ય | ઉદાહરણ પ્રશ્ન | શું માપવું |
|---|---|---|
| ઉપયોગિતા | નવા વપરાશકર્તાઓ મદદ વગર મુખ્ય કાર્ય પૂરું કરી શકે? | કોણ તેને જાતે પૂર્ણ કરે છે તેનો હિસ્સો |
| મૂલ્ય | લોકો યાદ અપાવ્યા વગર પાછા આવે છે? | બીજા અને ત્રીજા અઠવાડિયામાં પાછી મુલાકાતો |
| વિશ્વસનીયતા | વાસ્તવિક ડેટા અને devices પર તે ટકે છે? | ગંભીરતા પ્રમાણે bugs, ભૂલ logs |
| ચૂકવવાની ઇચ્છા | લોકો આયોજિત કિંમત ચૂકવશે? | અંતે રૂપાંતરણ કે pre-orders |
| Onboarding | પહેલા સત્રમાં લોકો ક્યાં અટકે છે? | છોડવાના બિંદુઓ, support પ્રશ્નો |
કાલ્પનિક ઉદાહરણ: નાના કૅફે માટે શિફ્ટ-શેડ્યૂલિંગ એપ બે લક્ષ્યો રાખે છે: "શું મેનેજર તેમના પ્રથમ સત્રમાં મદદ વગર અઠવાડિયાનું રોટા પ્રકાશિત કરી શકે?" અને "શું સ્ટાફ બીજા અઠવાડિયામાં જાતે એપ ખોલે છે?"
પગલું 2: beta નો પ્રકાર પસંદ કરો
| પ્રકાર | કોણ | ક્યારે શ્રેષ્ઠ | વેપાર-વિનિમય |
|---|---|---|---|
| મિત્રો અને alpha | તમે ઓળખતા લોકો | ખૂબ શરૂઆતમાં, સ્પષ્ટ તૂટફૂટ પકડવા | વિવેકી પ્રતિસાદ, પ્રતિનિધિત્વ વગરનો |
| બંધ beta | આમંત્રિત લક્ષ્ય વપરાશકર્તાઓ | મોટા ભાગની શરૂઆતની પ્રોડક્ટ્સ | ભેગા કરવામાં પ્રયાસ લાગે |
| ખુલ્લો beta | જે કોઈ સાઇન અપ કરે | સ્કેલ અને વિવિધતા ચકાસવા | વધુ support, પ્રતિ tester ઓછી ઊંડાઈ |
| ચૂકવેલો beta | સ્થાપક કિંમતે ચૂકવતા વપરાશકર્તાઓ | ચૂકવવાની ઇચ્છા ચકાસવી | ઊંચી અપેક્ષાઓ |
પ્રથમ પ્રોડક્ટ માટે, થોડા રાઉન્ડવાળો બંધ beta સામાન્ય રીતે સાચી પસંદગી છે.
પગલું 3: યોગ્ય testers ભેગા કરો
શ્રેષ્ઠ testers ને અત્યારે સમસ્યા હોય છે, તે તમારા લક્ષ્ય વપરાશકર્તા સાથે મેળ ખાય છે, અને beta ની વિન્ડો દરમિયાન એપ અજમાવવાનો સમય ધરાવે છે. તેમને શોધવાની જગ્યાઓ:
- તમારી waitlist કે ઇમેઇલ યાદી — જુઓ લૉન્ચ પહેલાં પ્રેક્ષકો કેવી રીતે બનાવવા.
- માન્યતા દરમિયાન તમે ઇન્ટરવ્યૂ કરેલા લોકો.
- નિશ-સમુદાયો જ્યાં તમારા વપરાશકર્તાઓ ભેગા થાય, તેમના પ્રમોશન નિયમો પાળીને.
- પ્રોફાઇલ સાથે બંધબેસતા તમારા નેટવર્કના લોકોને સીધા આમંત્રણ.
તમે મિશ્રણ પસંદ કરી શકો તે માટે થોડા સ્ક્રીનિંગ પ્રશ્નો પૂછો: તેમની ભૂમિકા, તેઓ અત્યારે સમસ્યા કેવી રીતે ઉકેલે છે, તેઓ કયું device વાપરશે, અને સમસ્યા કેટલી વાર આવે છે. જેમના જવાબો તમારા લક્ષ્ય વપરાશકર્તા સાથે મેળ ખાય તેમને આમંત્રિત કરો, અને જ્યાં સુધી તેઓ લક્ષ્ય વપરાશકર્તા ન હોય ત્યાં સુધી beta ને સાથી સ્થાપકોથી ભરવાનું ટાળો.
આમંત્રણ નમૂનો
નમસ્તે [નામ] — તમે સાઇન અપ કરતી વખતે [સમસ્યા] નો ઉલ્લેખ કર્યો હતો. હું [પ્રોડક્ટ] નો એક નાનો ખાનગી beta ખોલી રહ્યો છું, જે [પરિણામ] આપે છે. તે [શરૂઆત] થી [અંત] સુધી ચાલશે. હું testers ને [વાસ્તવિક કાર્ય] માટે દર અઠવાડિયે ઓછામાં ઓછું એક વાર વાપરવા અને દર શુક્રવારે ટૂંકી check-in માં જવાબ આપવા કહું છું. બદલામાં: beta દરમિયાન મફત પ્રવેશ અને [સ્થાપક કિંમત / લંબાવેલો મફત સમયગાળો]. રસ છે?
સમયની પ્રતિબદ્ધતા પ્રામાણિકપણે જણાવો. જે લોકો જાણે છે કે તેમણે શું સાઇન કર્યું છે તેઓ વધુ સારો પ્રતિસાદ આપે છે.
પગલું 4: beta કિટ તૈયાર કરો
પહેલું આમંત્રણ જાય તે પહેલાં, આ તૈયાર રાખો:
- સ્વાગત સંદેશ લિંક સાથે, કેવી રીતે સાઇન ઇન કરવું, પ્રથમ કાર્ય શું અજમાવવું, અને સમસ્યાઓ કેવી રીતે જણાવવી.
- જાણીતી સમસ્યાઓની યાદી, જેથી testers એક જ વાત દસ વાર ન નોંધાવે.
- એક પ્રતિસાદ ચેનલ. ફોર્મ, shared chat group કે ઇમેઇલ સરનામું — એક જગ્યા, પાંચ નહીં.
- bug report નમૂનો. તેઓએ શું કર્યું, શું અપેક્ષા હતી, શું થયું, device અને browser, અને screenshot માંગો. સારો bug report કેવી રીતે લખવો માં શેર કરી શકાય તેવી આવૃત્તિ છે.
- મૂળભૂત analytics અથવા logs, જેથી યાદશક્તિ પર આધાર રાખ્યા વગર શું થયું તે તમે જોઈ શકો.
- ડેટા વિશે સ્પષ્ટ અપેક્ષાઓ. જો beta દરમિયાન ડેટા રીસેટ થઈ શકે તો testers ને જણાવો, અને અધૂરી એપમાં સંવેદનશીલ માહિતી મૂકવાનું ન કહો.
- શરતો અને ગોપનીયતાની મૂળભૂત બાબતો. ટૂંકો beta કરાર અને privacy નોંધ; જો તમે વ્યક્તિગત ડેટા સંભાળો તો સ્થાનિક નિયમો અથવા સલાહકાર તપાસો.
પગલું 5: રાઉન્ડમાં ચલાવો
રાઉન્ડ તમને વધુ લોકો સુધી પહોંચે તે પહેલાં સમસ્યાઓ ઠીક કરવા દે છે.
| રાઉન્ડ | Testers | ધ્યાન |
|---|---|---|
| રાઉન્ડ 1 | થોડાક | શું તેઓ સાઇન અપ કરી મુખ્ય કાર્ય પૂરું કરી શકે? કેટલાક સત્રો લાઇવ જુઓ. |
| રાઉન્ડ 2 | મોટું જૂથ | બે અઠવાડિયામાં વાસ્તવિક ઉપયોગ; રાઉન્ડ વચ્ચે ટોચની સમસ્યાઓ ઠીક કરો. |
| રાઉન્ડ 3 (વૈકલ્પિક) | વ્યાપક અથવા ખુલ્લો | તમારી મદદ વગર onboarding, વિશ્વસનીયતા, કિંમત પરીક્ષણ. |
રાઉન્ડ 1 માં, બે કે ત્રણ testers ને એપ પહેલી વાર અજમાવતી વખતે તેમની સ્ક્રીન શેર કરવા કહો. શાંત રહો અને જુઓ તેઓ ક્યાં અચકાય છે. આ ઘણી વાર આખા beta નો સૌથી ઉપયોગી કલાક હોય છે.
પગલું 6: એક લયમાં પ્રતિસાદ એકત્ર કરો
બિનરચનાત્મક "કોઈ પ્રતિસાદ?" સંદેશાઓ અસ્પષ્ટ જવાબ આપે છે. તેના બદલે ટૂંકી, નિયમિત check-in વાપરો:
સાપ્તાહિક check-in (કાલ્પનિક ઉદાહરણ પ્રશ્નો)
- આ અઠવાડિયે તમે [પ્રોડક્ટ] શા માટે વાપર્યું?
- શું નિરાશાજનક કે મૂંઝવણભર્યું હતું?
- શું કંઈ ખૂટતું હતું જેણે તમને કાર્ય પૂરું કરતા અટકાવ્યા?
- જો તમે હવે તેને વાપરી ન શકો તો તમને કેવું લાગશે? (ખૂબ નિરાશ / થોડું / બિલકુલ નહીં)
- બીજું કંઈ?
લોકો જે કહે તેને તેઓ જે કરે છે તેની સાથે જોડો. જે કહે છે કે તે ખૂબ સરસ છે પણ ક્યારેય લોગ ઇન નથી કરતો, એ પણ તમને કંઈક કહે છે.
પગલું 7: જે આવે તેની પ્રાથમિકતા નક્કી કરો
દરેક પ્રતિસાદ એક યાદીમાં મૂકો અને સાપ્તાહિક ક્રમ લગાવો.
| શ્રેણી | ઉદાહરણો | ક્રિયા |
|---|---|---|
| અવરોધ | સાઇન અપ ન થાય, ડેટા ખોવાય, પેમેન્ટ નિષ્ફળ | તરત ઠીક કરો, અસરગ્રસ્ત testers ને જણાવો |
| મોટો bug | સામાન્ય device પર મુખ્ય સુવિધા તૂટી | આ રાઉન્ડમાં ઠીક કરો |
| મૂંઝવણ | લોકોને બટન ન મળે, લેબલ ખોટું વાંચે | copy અથવા લેઆઉટ ઠીક કરો; સસ્તું અને મૂલ્યવાન |
| નાનો bug | દૃશ્ય ખામી, દુર્લભ edge case | પછી માટે બૅચ કરો |
| Feature request | "શું તે X પણ કરી શકે?" | નોંધો, કયો સમસ્યા ઉકેલે તે પૂછો, પેટર્ન શોધો |
beta વચ્ચે મોટી સુવિધાઓ ઉમેરવાનો પ્રતિકાર કરો. દરેક નવી સુવિધા એ જાણવું મુશ્કેલ બનાવે છે કે મુખ્ય પ્રોડક્ટ કામ કરે છે કે નહીં.
પગલું 8: લૂપ બંધ કરો
જ્યારે testers જુએ કે તેમનો પ્રતિસાદ વપરાયો છે ત્યારે તેઓ પ્રતિસાદ આપતા રહે છે.
- દરેક રાઉન્ડ પછી ટૂંકો changelog મોકલો: "તમે X નોંધાવ્યું; તે ઠીક થઈ ગયું છે."
- જ્યારે કોઈનો અહેવાલ fix તરફ દોરી જાય ત્યારે તેમનો નામથી, ખાનગી રીતે આભાર માનો.
- beta ક્યારે સમાપ્ત થાય છે, તેમના ડેટા અને ખાતાનું શું થાય છે, અને તેમની સ્થાપક ઑફર શું છે તે testers ને જણાવો.
પગલું 9: નક્કી કરો કે તમે તૈયાર છો
beta શરૂ થાય તે પહેલાં બહાર નીકળવાના માપદંડો લખો, પછી અંતે પ્રામાણિકપણે તપાસો. એક નમૂનો:
- કોઈ જાણીતા અવરોધ કે ડેટા-ગુમાવતા bugs નથી
- મોટા ભાગના નવા testers મદદ વગર મુખ્ય કાર્ય પૂરું કરે છે
- પછીના અઠવાડિયામાં testers નો નોંધપાત્ર હિસ્સો જાતે પાછો આવે છે
- ટોચના મૂંઝવણ બિંદુઓ ઠીક થયા છે અને ફરી ચકાસાયા છે
- Sign-up, password reset અને કોઈ પણ પેમેન્ટ flow શરૂથી અંત સુધી કામ કરે છે
- testers ના શબ્દોમાં, પ્રોડક્ટ કોના માટે છે તેનો સ્પષ્ટ સંદેશ તમારી પાસે છે
જો મોટા ભાગના બૉક્સ ટિક થયા હોય, તો onboarding પોલિશ અને જાહેર લૉન્ચ તરફ જાઓ. જો પાછા આવીને ઉપયોગ ઓછો હોય, તો તે પ્રોડક્ટનો પ્રશ્ન છે, bugs ની યાદીનો નહીં — લૉન્ચ પહેલાં ફરી ઇન્ટરવ્યૂ પર જાઓ.
Mythex સાથે beta ચલાવવો
જો તમે Mythex સાથે બનાવી રહ્યા છો, તો કેટલીક સુવિધાઓ beta સાથે સરસ રીતે બંધબેસે છે:
- રાઉન્ડ 1 માટે preview લિંક. Share બટન તમારા live preview માટે એક લિંક બનાવે છે જે Mythex ખાતા વગરના લોકો માટે પણ કામ કરે છે, જેથી પ્રકાશિત કરતા પહેલાં શરૂઆતનો tester અધૂરું કામ અજમાવી શકે. દરેક જૂથ માટે એક લિંક બનાવો અને પૂરું થયે તેને કાઢી નાખો — Preview દસ્તાવેજો સમજાવે છે કે લિંક પ્રોજેક્ટને કેવી રીતે જગાડે છે અને credits કેવી રીતે વાપરે છે.
- લાંબા રાઉન્ડ માટે પ્રકાશિત કરો. પ્રકાશિત એપ પોતાના સરનામે ચાલે છે, જે અઠવાડિયાઓ સુધી એપ વાપરતા testers ને અનુકૂળ છે.
- દરેક રાઉન્ડ પહેલાં App Testing. chat માં
/testટાઇપ કરો અને એજન્ટ તમારા preview માં ક્લિક કરીને તૂટેલા flows ની જાણ કરશે, કોઈને આમંત્રિત કરતા પહેલા ઉપયોગી તપાસ (App Testing દસ્તાવેજો). - Checkpoints. જો beta વચ્ચે કોઈ fix કંઈક તોડે, તો પાછલા checkpoint પર રોલબેક કરો.
tester નો bug report સીધો chat માં પેસ્ટ કરો અને એજન્ટને તેનું પુનઃઉત્પાદન કરીને ઠીક કરવા કહો, પછી તે લાઇવ થાય ત્યારે tester ને જણાવો.
પ્રશ્નો
મને કેટલા beta testers જોઈએ?
મોટા ભાગના લોકો ધારે તેના કરતાં ઓછા. તમારા લક્ષ્ય વપરાશકર્તા સાથે મેળ ખાતું અને ખરેખર એપ વાપરતું નાનું જૂથ મોટાભાગની મોટી સમસ્યાઓ બહાર લાવશે. થોડાક લોકોથી શરૂ કરો, તેમને મળેલું ઠીક કરો, પછી મોટા જૂથ સુધી વિસ્તારો.
beta test કેટલો સમય ચાલવો જોઈએ?
એટલો લાંબો કે testers તેને વાસ્તવિક જીવનમાં જેવી રીતે વાપરે તેવી રીતે વાપરી શકે, જે ઘણી વાર સાપ્તાહિક વપરાતી વસ્તુ માટે થોડા અઠવાડિયા હોય છે. અગાઉથી અંતિમ તારીખ નક્કી કરો, જેથી beta અનિશ્ચિત સમય સુધી ખેંચાય નહીં.
શું beta testers એ પૈસા ચૂકવવા જોઈએ?
તમારે શું શીખવું છે તેના પર આધાર રાખે છે. મફત beta માટે લોકોને ભેગા કરવું સરળ છે; ચૂકવેલો અથવા છૂટવાળો beta કહે છે કે લોકો પ્રોડક્ટને પૈસા ચૂકવવા જેટલી કિંમત આપે છે કે નહીં. ઘણા સ્થાપકો પહેલા મફત બંધ beta ચલાવે છે અને પછીના રાઉન્ડમાં ચુકવણી માંગે છે.
બંધ beta અને ખુલ્લા beta વચ્ચે શો તફાવત છે?
બંધ beta આમંત્રણ-આધારિત હોય છે, સામાન્ય રીતે તમે પસંદ કરેલું અને સીધી વાત કરો તે નાનું જૂથ. ખુલ્લો beta કોઈ પણ સાઇન અપ કરી શકે તેવું બનાવે છે, જે વધુ જથ્થો અને વિવિધતા લાવે છે પણ ઓછો વ્યક્તિગત સંપર્ક અને વધુ support કામ.
beta testers ની feature requests નું હું શું કરું?
તેમને નોંધો, દરેક કયા સમસ્યાને ઉકેલશે તે પૂછો, અને પેટર્ન શોધો. મોટા ભાગના betas પહેલા bugs અને મૂંઝવણ ઠીક કરવા જોઈએ; beta દરમિયાન સુવિધાઓ ઉમેરવાથી એ જાણવું મુશ્કેલ બને છે કે મુખ્ય પ્રોડક્ટ કામ કરે છે કે નહીં.