मैं एक या दूसरेबीटा करने के लिए या बीटा के लिए नहीं .. यह सवाल
बीटा के लिए एक आम सहमति के लिए देख रहा हूँ है; रिलीज सॉफ़्टवेयर जो सेमी - सीमित श्रोताओं के लिए कार्यात्मक है और उपयोगकर्ताओं को प्रक्रिया को तब तक मार्गदर्शन करने दें जब तक कोई एप्लिकेशन पूर्ण न हो।
कोई बीटा नहीं; पिछली उपयोगकर्ता-फीडबैक और/या व्यावसायिक तर्क के आधार पर सभी कार्यक्षमता परिभाषित करें, सॉफ़्टवेयर बनाएं, और जो भी आप के साथ स्वयं को दें (या दिए गए) के साथ परीक्षण करें।
हम्म ... बीटा एक उत्पाद के लिए है आपको लगता है कि समाप्त हो गया है ... जब तक आप बीटा उपयोगकर्ताओं को इसके साथ खेलने के लिए नहीं देते हैं और वे इसे उन तरीकों से तोड़ते हैं जिनके बारे में आपने सोचा नहीं है।
तो, हाँ, बीटा के साथ जाएं, जब तक कि आप अपने उत्पाद को कई उपयोगकर्ताओं पर जला नहीं चाहते।
मैं दोनों सिरों (उपयोगकर्ता और प्रकाशक) पर बीटा के साथ शामिल हूं जो उपयोगकर्ता इनपुट और बीटा के लिए अनुमति देता है जिसमें छोटे उपयोगकर्ता इनपुट शामिल हैं, जहां तक सुविधाएं और बदलाव चलते हैं। – madcolor
मैंने जो कुछ लिखा था, वह ज्यादातर मामलों के लिए एक राय थी, सब कुछ के लिए हमेशा अपवाद होते हैं। –
मैं आपके दोनों मामलों से असहमत हूं।
आंतरिक क्यूए के बारे में कैसे? उन्हें बग भी मिलते हैं, आपको पता है। जब आपको कोई गंभीर बग नहीं है तो केवल ग्राहकों को बीटा जारी करें।
इसके अलावा, हमेशा पर्याप्त परीक्षण करें। यदि समय दबा रहा है और आपने अपने सभी परीक्षणों को पूरा नहीं किया है, तो यह मुश्किल है। परीक्षण समाप्त करें, चाहे आपके पास समय हो या नहीं।
देख नहीं सकता कि क्यूए को या तो कैसे बाहर निकाला जाता है। – madcolor
यह जानने के बिना कि ऐप क्या है और यह दर्शकों का क्या होगा, मुझे लगता है कि बनाना मुश्किल होगा। हालांकि अगर यह ओपन सोर्स प्रोजेक्ट है, तो ऐसा लगता है कि सर्वसम्मति आम तौर पर "रिलीज अर्ली एंड रिलीज अक्सर" होती है।
वास्तविक प्रश्न यह है: क्या आप जानते हैं बिल्कुल आपके उपयोगकर्ता क्या चाहते हैं?
यदि आप हाँ का जवाब देते हैं, तो सबकुछ डिज़ाइन और बनाएं और इसे बीटा के साथ लॉन्च करें।
यदि आप कोई जवाब नहीं देते हैं, तो बीटा जाने का तरीका है - आपके उपयोगकर्ता आपके सॉफ़्टवेयर को परिभाषित करने में मदद करेंगे और वे प्रक्रिया का अधिक हिस्सा महसूस करेंगे और कुछ स्वामित्व लेंगे।
मैं बीटा कहता हूं। लेकिन मैं आपके आधार से असहमत हूं। आपको सेमी-कुछ भी सॉफ्टवेयर जारी नहीं करना चाहिए। बीटा के रूप में जारी सॉफ्टवेयर कम से कम सुविधा पूर्ण होना चाहिए। इस तरह आपके उपयोगकर्ता जानते हैं कि वे क्या प्राप्त कर रहे हैं।
जहां तक बग ढूंढ रहे हैं। आंतरिक परीक्षण सबसे अच्छा है। हालांकि, सॉफ़्टवेयर जारी करने वाले किसी भी व्यक्ति को पता है कि इससे कोई फर्क नहीं पड़ता कि उपयोगकर्ता को इसे तोड़ने का नया और दिलचस्प तरीका क्या मिलेगा।
तो बीटा आपके दिल की सामग्री को टाइल करें।
हालांकि आप सही हैं, आपने कितने बीटा परीक्षण किए हैं और आपके परीक्षण से पहले हटाए गए बग नहीं पाए गए हैं? – madcolor
बिल्कुल कोई नहीं। यहां तक कि सामानों पर मैंने लिखा या लिखने में मदद की। – Jeremy
यहां तक कि मंगल ग्रह के रोवरों में भी उत्पादन में कीड़े थीं। हे जेपीएल, हमारे यहां एक उम्मीदवार है .. – madcolor
मैं एक चुनिंदा समूह के लिए पहले अल्फा परीक्षण का सुझाव दूंगा, जो सुविधा पूर्ण नहीं है, इसलिए वे आपको बग खोजने और निर्धारित करने के लिए कौन सी विशेषताओं की आवश्यकता है, यह निर्धारित करने में सहायता कर सकते हैं।
एक बार जब आप फीचर को पूरा करने के बारे में सोचते हैं, तो इसे एक बड़े समूह में छोड़ दें, मुख्य रूप से बग ढूंढने के लिए, और फीचर में बदलावों पर टिप्पणियां प्राप्त करने के लिए, लेकिन जब तक कुछ महत्वपूर्ण न हो तो आप फीचर बदलाव नहीं कर सकते।
इस बिंदु पर आप रिलीज के लिए तैयार हैं, और आप अगली रिलीज के लिए चरण (1) पर वापस जाएं।
अपने सॉफ़्टवेयर को खत्म करने के बाद (और आपको लगता है), और मान लें कि कोई गंभीर बग नहीं है, अल्फा परीक्षण आयोजित करें। सॉफ़्टवेयर को अपनी कंपनी के टेस्ट स्टाफ के भीतर उपलब्ध कराएं, रिपोर्ट की गई बग को ठीक करें।
अगला, बीटा परीक्षण के रूप में ग्राहकों को सॉफ़्टवेयर जारी करें, टिप्पणियां एकत्र करें, & त्रुटियों को ठीक करें।
तभी आप रिलीज के लिए तैयार हैं।
न तो।
आपको बीटा जारी नहीं करना चाहिए जब तक आपको लगता है कि उत्पाद बग-फ्री है। और उस बिंदु पर, बीटा उपयोगकर्ता बग पाएंगे। वे मुझ पर भरोसा करेंगे। बीटा उपयोगकर्ताओं को 'डिज़ाइन गाइड' देने के लिए, शायद एक अच्छा विचार नहीं है - आप सॉफ़्टवेयर के साथ समाप्त हो जाएंगे जो होमर सिम्पसन द्वारा बनाई गई कार की तरह दिखाई देगी। एक कारण है कि बीटा उपयोगकर्ता सॉफ्टवेयर डिजाइनर नहीं हैं।
जहां तक दूसरा विकल्प है - जब तक कि आप एक असाधारण परीक्षक नहीं हैं, आप इसे परीक्षण करने के साथ-साथ अंतिम उपयोगकर्ताओं (वे आपके सॉफ़्टवेयर में सबसे शानदार चीजें करेंगे) का परीक्षण नहीं कर पाएंगे। और यदि आप इसे "जो भी समय देते हैं (या दिए गए हैं) के साथ परीक्षण करें, तो आपके पास पर्याप्त समय नहीं होगा।
मेरा जवाब कई कारक का निर्धारण होता है कि जो अधिक समझ में आता है यह है कि: कीड़े की
1) परिणाम - कीड़े लोगों को मरते हुए में परिणाम होगा, तो मुझे लगता है कि एक बीटा एक बुरा विचार किया जाएगा। क्या आप परमाणु रिएक्टर या मिसाइल सिस्टम पर चल रहे बीटा सॉफ़्टवेयर की कल्पना कर सकते हैं? दूसरी तरफ, यदि परिणाम काफी मामूली है जैसे कि कुछ फंतासी स्पोर्ट्स साइट पर अस्थायी आबादी है, तो बीटा में डालना इतना बुरा नहीं हो सकता है।
2) उपयोगकर्ताओं की अपेक्षाएं। आवेदन के उपयोगकर्ताओं के बारे में सोचें और वे "बीटा" जैसी किसी चीज़ का उपयोग करने के बारे में कैसा महसूस करेंगे? यदि इससे उन्हें वास्तव में सॉफ़्टवेयर का उपयोग करने के लिए डर दिया जाएगा और डर जाएंगे कि यह नियमित रूप से उन पर उड़ाएगा और बग के साथ झुकाएगा, जो भी भूमिका निभा सकता है।
3) आवेदन का आकार। यदि आप 101 देशों की कानूनी आवश्यकताओं को संभालने के लिए एक ईआरपी कहने के लिए बहुत बड़ा निर्माण करने जा रहे हैं और मॉड्यूल पर सैकड़ों जोड़ों को शामिल करते हैं, तो बीटा इसे पूरा करने की कोशिश करने से अधिक ध्वनि हो सकता है और कभी भी आपके पास नहीं पहुंच सकता ग्राहकों।
4) परिनियोजन। यदि आप कुछ ऐसी चीजें स्थापित कर रहे हैं जहां कोड आपकी मशीनों पर चल रहा है और आसानी से अपग्रेड और पैच किया जा सकता है, तो बीटा शुरुआत में सही तरीके से करने की कोशिश करने से बेहतर हो सकता है।
5) विकास पद्धति। यदि आप झरना दृष्टिकोण लेते हैं, तो कोई बीटा संभवतः एक बेहतर विकल्प नहीं है, जबकि एक चुस्त परिदृश्य में बीटा अधिक समझ में आता है। उत्तरार्द्ध का कारण यह है कि चुस्त मामले में कई रिलीज होंगे जो समय के साथ उत्पाद को बेहतर बनाएंगे।
बस कुछ चीजें जो मुझे याद रखती हैं क्योंकि कुछ ऐसे मामले हैं जहां मैं आसानी से बीटा का उपयोग करके कल्पना करता हूं और अन्य मामलों में मैं जितना संभव हो बीटा से बचता हूं।
निस्संदेह बीटा!
बीटा अवधि चलाने के कुछ लाभ ...
लॉन्च उत्पन्न और अक्सर पुनरावृति।
क्या आप ओपन सोर्स या वाणिज्यिक विकास के बारे में बात कर रहे हैं? – Zifre
वाणिज्यिक देव। – madcolor