टेस्टफ्लाइट सेटअप गाइड
TestFlight के माध्यम से ग्राहक समीक्षा संरचित होनी चाहिए, तात्कालिक नहीं।
एक उपयोगी टेस्टफ़्लाइट रोलआउट परिभाषित करता है कि कौन परीक्षण करता है, उन्हें क्या बिल्ड प्राप्त होता है, वे किस प्रवाह की जाँच करते हैं, फीडबैक कैसे रूट किया जाता है, और ऐप समीक्षा से पहले क्या तय किया जाना चाहिए।
TestFlight किसी क्लाइंट को ऐप लिंक भेजने का एक तरीका मात्र नहीं है। यह ऐप समीक्षा से पहले की रिहर्सल परत है। यह हस्ताक्षर, निर्माण, लॉगिन, ऑनबोर्डिंग, अनुमतियाँ, पुश, भुगतान, डीप लिंक और उपयोगकर्ता-समर्थन समस्याओं को उजागर करता है जबकि टीम अभी भी उन्हें जानबूझकर ठीक कर सकती है।
आधिकारिक स्रोत नोट: ऐप्पल ने ऐप स्टोर कनेक्ट सहायता में टेस्टफ़्लाइट समूहों, आंतरिक परीक्षकों, बाहरी परीक्षकों और बीटा समीक्षा व्यवहार का दस्तावेजीकरण किया है: टेस्टफ़्लाइट अवलोकन।
टेस्टफ्लाइट वर्कफ़्लो
त्वरित उत्तर
एक अच्छे टेस्टफ़्लाइट सेटअप में समूह, नोट्स, पहुंच, फीडबैक और निकास मानदंड होते हैं।
परीक्षकों को आमंत्रित करने से पहले, बिल्ड, परीक्षक समूह, बीटा समीक्षा के लिए ऐप विवरण, फीडबैक ईमेल, डेमो लॉगिन, परीक्षण के लिए प्रवाह, ज्ञात सीमाएं, डिवाइस कवरेज और उत्पादन सबमिशन से पहले क्या तय किया जाना चाहिए, इसकी पुष्टि करें।
त्वरित उत्तर: टेस्टफ़्लाइट सेटअप चेकलिस्ट
सही संस्करण, बिल्ड नंबर, हस्ताक्षर, कॉन्फ़िगरेशन और रिलीज़ नोट्स के साथ रिलीज़ उम्मीदवार अपलोड करें।
आंतरिक टीम, ग्राहक हितधारकों, क्यूए और बीटा उपयोगकर्ताओं को अलग करें ताकि पहुंच और फीडबैक व्यवस्थित रहें।
डेमो क्रेडेंशियल, परीक्षण डेटा, हार्डवेयर नोट्स, भुगतान नोट्स और अपेक्षित परीक्षण पथ प्रदान करें।
तय करें कि कौन सा फीडबैक ऐप समीक्षा को अवरुद्ध करता है और कौन सा बाद के रिलीज के लिए इंतजार कर सकता है।
एक रिलीज़ कैंडिडेट बिल्ड अपलोड करें
TestFlight का उपयोग केवल उस निर्माण के लिए न करें जो सुविधाजनक हो। एक ऐसे रिलीज़ उम्मीदवार का उपयोग करें जो आपकी सबमिट करने की योजना के करीब हो। बिल्ड को अंतिम बंडल आईडी, उत्पादन-सुरक्षित कॉन्फ़िगरेशन, सही अनुमतियाँ, अंतिम आइकन और एक संस्करण/बिल्ड नंबर का उपयोग करना चाहिए जिसे टीम ट्रैक कर सके।
तैयारी वर्कशीट बनाएं
| वस्तु | क्या पुष्टि करें? | यह क्यों मायने रखता है? |
|---|---|---|
| संस्करण | उपयोगकर्ता-सामना वाला रिलीज़ संस्करण | ग्राहकों और समीक्षकों को सही रिलीज़ का संदर्भ देने में मदद करता है |
| निर्माण संख्या | अद्वितीय अपलोड संख्या | जब एकाधिक बिल्ड का परीक्षण किया जाता है तो भ्रम से बचा जाता है |
| लॉग इन करें | डेमो या क्लाइंट-अनुमोदित परीक्षण खाते | समीक्षा अवरोधकों और ग्राहक भ्रम को रोकता है |
| कॉन्फिग | उत्पादन-सुरक्षित सेवाएँ | स्टेजिंग डेटा, डिबग फ़्लैग या ग़लत समापन बिंदु से बचा जाता है |
| टिप्पणियाँ | क्या बदला और क्या परीक्षण करना है | फीडबैक को सही प्रवाह की ओर निर्देशित करता है |
आंतरिक बनाम बाहरी परीक्षक
आंतरिक परीक्षक आमतौर पर टीम सत्यापन के लिए सबसे तेज़ मार्ग होते हैं क्योंकि वे ऐप स्टोर कनेक्ट उपयोगकर्ता होते हैं जिनके पास पहुंच होती है। बाहरी परीक्षक ग्राहकों, बीटा उपयोगकर्ताओं और टीम के बाहर के हितधारकों के लिए उपयोगी होते हैं, लेकिन पहले बाहरी निर्माण पथ के लिए बीटा समीक्षा की आवश्यकता हो सकती है।
रिलीज़ ट्राइएज के लिए उपयोग करें
डेवलपर्स, क्यूए, संस्थापक और उत्पाद मालिक बिल्ड स्वास्थ्य, लॉगिन, महत्वपूर्ण प्रवाह और क्रैश व्यवहार को तुरंत मान्य कर सकते हैं।
क्लाइंट या बीटा समीक्षा के लिए उपयोग करें
बाहरी समूह आंतरिक ऐप स्टोर कनेक्ट टीम में शामिल हुए बिना ग्राहकों और वास्तविक उपयोगकर्ताओं को परीक्षण में मदद करते हैं।
अलग फीडबैक धाराएँ
संस्थापकों, ग्राहक समीक्षकों, क्यूए और बीटा उपयोगकर्ताओं को अलग-अलग समूहों में रखें ताकि असाइनमेंट और फीडबैक की व्याख्या करना आसान हो।
परीक्षकों को बताएं कि क्या परिवर्तन हुआ
बिल्ड नोट्स में यह बताया जाना चाहिए कि क्या परीक्षण करना है, क्या बदला है, और किन ज्ञात सीमाओं को नए बग के रूप में नहीं माना जाना चाहिए।
ग्राहक समीक्षा योजना
क्लाइंट टेस्टफ़्लाइट योजना विशिष्ट होनी चाहिए। लिंक भेजने और टिप्पणियाँ माँगने से अक्सर अस्पष्ट प्रतिक्रिया उत्पन्न होती है। बेहतर: उन वर्कफ़्लो को परिभाषित करें जिन्हें ऐप समीक्षा से पहले पारित किया जाना चाहिए।
क्लाइंट टेस्टफ्लाइट समीक्षा योजना
- कम से कम एक वास्तविक डिवाइस पर TestFlight से ऐप इंस्टॉल करें।
- ऑनबोर्डिंग, लॉगिन, पासवर्ड रीसेट और मुख्य कार्य पूरा करने का परीक्षण करें।
- यदि लागू हो तो पुश नोटिफिकेशन, ईमेल/एसएमएस प्रवाह और डीप लिंक की पुष्टि करें।
- परीक्षण सदस्यता, भुगतान, या गेटेड सामग्री अनुमोदित परीक्षण निर्देशों के साथ प्रवाहित होती है।
- ऐप का नाम, आइकन, स्प्लैश स्क्रीन, खाली स्थिति और समर्थन मार्ग जांचें।
- वास्तविक ऐप के विरुद्ध स्क्रीनशॉट और लिस्टिंग कॉपी की समीक्षा करें।
- गोपनीयता नीति, खाता हटाने और संपर्क लिंक की पुष्टि करें।
- अवरोधन संबंधी मुद्दों को अच्छी प्रतिक्रिया से अलग रिकॉर्ड करें।
फीडबैक और हैंडओवर
फीडबैक एक रिलीज़ निर्णय बनना चाहिए, न कि चैट थ्रेड। बिल्ड नंबर, डिवाइस, आईओएस संस्करण, स्क्रीन, पुनरुत्पादन के चरण, अपेक्षित व्यवहार, वास्तविक व्यवहार और रिलीज प्रभाव के साथ प्रत्येक मुद्दे को रिकॉर्ड करें।
इकट्ठा करो
फीडबैक को एक ही स्थान पर रूट करें: इश्यू ट्रैकर, साझा दस्तावेज़, या रिलीज़ चैनल। एकाधिक चैट ऐप्स पर निर्णय खोने से बचें।
वर्गीकृत करें
फीडबैक को ब्लॉकर, प्री-रिव्यू फिक्स, पोस्ट-लॉन्च फिक्स, कॉपी इश्यू या प्रश्न के रूप में चिह्नित करें।
ठीक करें और पुनर्निर्माण करें
नया बिल्ड तभी अपलोड करें जब टीम यह बता सके कि क्या बदलाव हुआ है और परीक्षकों को किन चीज़ों की दोबारा जांच करनी चाहिए।
सौंप दो
दस्तावेज़ टेस्टफ़्लाइट समूह, नवीनतम स्वीकृत निर्माण, ज्ञात सीमाएँ, समीक्षक नोट्स और रिलीज़ स्वामी।
अक्सर पूछे जाने वाले प्रश्न
आंतरिक और बाह्य टेस्टफ्लाइट परीक्षण के बीच क्या अंतर है?
आंतरिक परीक्षण ऐप स्टोर के उपयोगकर्ताओं को ऐप तक पहुंच से जोड़ने के लिए है। बाहरी परीक्षण बड़ी संख्या में बाहरी दर्शकों तक पहुंच सकता है और परीक्षकों को बिल्ड तक पहुंचने से पहले ऐप्पल बीटा समीक्षा की आवश्यकता हो सकती है।
क्या ग्राहकों को ऐप समीक्षा से पहले TestFlight के माध्यम से समीक्षा करनी चाहिए?
हाँ, जब संभव हो. TestFlight क्लाइंट को बिल्ड के ऐप रिव्यू में जाने से पहले इंस्टॉल पथ, लॉगिन, कुंजी प्रवाह, अनुमतियाँ, सूचनाएं और रिलीज़ कॉपी का परीक्षण करने देता है।
टेस्टफ्लाइट बिल्ड नोट्स में क्या शामिल किया जाना चाहिए?
इसमें क्या परिवर्तन हुआ, क्या परीक्षण करना है, ज्ञात सीमाएँ, लॉगिन निर्देश, परीक्षण डेटा, भुगतान या हार्डवेयर नोट्स और फीडबैक कहाँ भेजा जाना चाहिए, शामिल करें।
