हम टीके से पोस्ट-प्रोडक्शन और टीम के भीतर मैत्रीपूर्ण संबंधों को बनाए रखने की सुविधा का परीक्षण कैसे करते हैं

नमस्कार। मेरा नाम दशा है, मैं iOS पर 2GIS मोबाइल एप्लिकेशन का परीक्षण कर रहा हूं। मैं सुविधाओं के संचालन की हमारी प्रक्रिया को साझा करना चाहता हूं, जो न केवल समय बचाने में मदद करता है, बल्कि मेरे व्यक्तिगत कौशल को भी उन्नत करता है। यह जानने के लिए कि हम उत्पादों, डिजाइनरों, विकास को एक ही संदर्भ में कैसे प्रबंधित करते हैं, यह जानने के लिए लेख पढ़ें। हम मानते हैं कि सभी इच्छुक लोगों द्वारा पहली टेस्ट असेंबली की समीक्षा वास्तव में जीवन को आसान बनाती है। और संचार एक विशेषता के प्रबंधन की कुंजी है।

हमारा दर्द

जब अन्य कंपनियों के परीक्षकों के साथ संवाद करते हैं, तो मैं अक्सर ध्यान देता हूं कि उनकी विशेषताओं का परीक्षण किसी भी तरह से गड़बड़ है, असंरचित। इस वजह से, समय बर्बाद होता है, विकास में शामिल लोगों की ताकत। लोग क्रोधित हो जाते हैं, अपने सहयोगियों से नफरत करने लगते हैं, पोर्च में उनका इंतजार करते हैं।

पहले, हमारे पास भी कुछ ऐसा ही था: स्प्रिंट की योजना बनाते समय, एक कार्य शुरू हुआ, स्प्रिंट की शुरुआत में इसे विकास में लिया गया था, हमने इस प्रक्रिया में काम किया। यदि अन्य टीमों के साथ बातचीत पर सवाल थे, तो हम उत्पाद पर गए। अक्सर ऐसा हुआ कि कुछ टीमों में काम पहले से ही पूरी तरह से जारी था: हर कोई रिहाई के लिए उत्सुक था, किसी ने पहले से ही लड़ाई में सुविधा के बारे में सपना देखा था; और दूसरी टीम में वे इसके अस्तित्व के बारे में भी नहीं जानते थे। इस तरह की प्रक्रिया अप्रभावी थी, काफी समय / प्रयास बिताया, अराजकता लाया।

नतीजतन, उन्होंने महसूस किया कि इस तरह से जीना असंभव था, और एक नई प्रक्रिया का निर्माण करना शुरू किया। उसने पहले से ही किसी की नसों और संभवतः जीवन को बचाने में मदद की है।

टीम के बारे में

हमारी टीम में शामिल हैं: 9 डेवलपर्स, 6 परीक्षक, एक उत्पाद और एक डिजाइनर। पुनरावृत्ति की योजना बनाते समय (हम अगले 4 महीनों के लिए क्या करेंगे), सुविधाएँ संकलित की जाती हैं जो आप वर्तमान समय अवधि में जारी करना चाहते हैं। जब सूची संकलित की जाती है, तो विकास और परीक्षण से टीम की प्रत्येक विशेषता के लिए एक सुविधा आवंटित की जाती है, जो शुरुआत से अंत तक की सुविधाओं के साथ होगी।

हमारे लिए, फ़ीचर्ड एक ऐसा व्यक्ति है जो TK से लेकर रिलीज़ तक की विशेषताओं के साथ रहता है। उनके पास अप-टू-डेट जानकारी है कि फीचर के रूप में क्या होता है, और अन्य टीमों के लोगों के लिए सुविधाओं पर काम करने के बारे में प्रश्नों के लिए एक प्रवेश बिंदु के रूप में कार्य करता है। आप साशा कार्तवसेव की रिपोर्ट के अंत में सुविधाओं के बारे में अधिक जान सकते हैं। इस शब्द को याद रखें, तो यह एक से अधिक बार मिल जाएगा।

9 चरणों में रिलीज

सुविधाओं को जारी करने की पूरी प्रक्रिया को 9 मुख्य चरणों में विभाजित किया जा सकता है। स्पष्टता के लिए, हम "रिवार्ड्स" की हाल ही में जारी की गई विशेषता लेते हैं और बताते हैं कि हमने इसे सभी नौ चरणों में कैसे संचालित किया।

पुरस्कार उत्पाद में उनके योगदान के लिए उपयोगकर्ताओं के लिए एक पुरस्कार हैं। उपयोगकर्ता उन्हें समीक्षा लिखने, फ़ोटो अपलोड करने, निर्देशिका में नई कंपनियों को जोड़ने के लिए प्राप्त करते हैं। उन्हें टैब "My 2GIS" पर देखा जा सकता है।

चरण 1 - टीके विकास प्रक्रिया

सुविधाओं का काम शुरू करने से पहले, हमने सुस्त में एक चैट रूम बनाया और उसमें शामिल सभी लोगों को बुलाया। हम इस बात पर सहमत हुए कि इसमें हम उन सभी मुद्दों पर चर्चा करेंगे जो चैट प्रतिभागियों के जीवन में सुविधाओं और घटनाओं पर चर्चा करेंगे जो रिलीज के दौरान प्रभावित हो सकते हैं। यह कहने की आवश्यकता नहीं है कि आप दूध के लिए गए थे, लेकिन आपको छुट्टियों / बीमार छुट्टी के बारे में बात करने की आवश्यकता है, अन्यथा आप गैर-जिम्मेदाराना के लिए घृणा में दौड़ने का जोखिम उठाते हैं।



सबसे पहले, अन्य सुविधाओं के अनुभव के आधार पर, विकास और परीक्षण से सुविधाओं ने टीके / डिज़ाइन, पूछे गए प्रश्न, प्रस्तावित सुधार को देखा। सुविधा की निगरानी की गई ताकि एक दिन के भीतर सवालों के जवाब दिए जा सकें। यदि समय सीमा में देरी हुई, तो इन लोगों ने उत्पाद / जिम्मेदार लोगों को संकेत दिया कि घड़ी टिक रही है और पहले से ही जवाब देना अच्छा होगा।
टीके को विकसित करने की प्रक्रिया को पूरा माना जाता है जब सभी मुख्य मुद्दे बंद हो जाते हैं, अंतिम डिजाइन हैं, तो सुविधाओं के कार्यान्वयन पर विकास का कोई सवाल नहीं है।



पहले चरण में, एक फीचर का प्रोटोटाइप बनाने के लिए यह बहुत अच्छा है और टीओआर विकसित करते समय इसका उपयोग करें: यह डिवाइस पर सुविधा को महसूस करने और प्रारंभिक अवस्था में खामियों की पहचान करने में मदद करेगा, परीक्षण के लिए मामलों के साथ आएगा। प्लेटफॉर्म पर विकास शुरू होने से पहले ही उत्पाद तर्क में बदलाव करने में सक्षम होंगे।

चरण 2 - चेकलिस्ट को आरेखित करना

ToR को काम करने की प्रक्रिया में, परीक्षण के लिए एक विशेषता के रूप में, मैंने TestRail में फीचर के लिए परीक्षण मामले बनाए, जिसके अनुसार बाद में इस सुविधा की जाँच की गई। उनके आगे के स्वचालन के लिए प्राथमिकता वाले मामले। चूंकि फ़ीचर में एक बैकएंड है, मैंने इसके लिए एक परीक्षण योजना में जोड़ा: हम जो फ़ील्ड भेजते हैं, जो हम प्राप्त करते हैं, और अगर कुछ असाध्य बकवास है तो क्या होगा। आइए, सुविधा से अपेक्षाओं को सिंक्रनाइज़ करने के लिए विकास और उत्पादों को तैयार चेकलिस्ट दें, ताकि यह न हो कि परीक्षण ने एक चीज के बारे में सोचा, उत्पाद एक और उम्मीद करता है, और डेवलपर ने कुछ और किया।

स्टेज 3 - विकास

ToR के विकास के बाद, फीचर का विकास शुरू हुआ। उस समय परीक्षण ने टीओआर और चैट रूम में खुले / बहस वाले मुद्दों को बंद कर दिया, सभी परिवर्तनों के विकास की सूचना दी, यदि कोई दिखाई दिया: नई आवश्यकताओं, नए डिजाइन, नए ग्रंथ, कुछ और - विकास को सब कुछ पता होना चाहिए, अन्यथा लड़ाई से बचने का कोई तरीका नहीं है।

स्टेज 4 - पहली फीचर असेंबली की समीक्षा

पहली असेंबली प्राप्त करने के बाद, हमने इसे फीचर चैट में फेंक दिया, जहां हमने उत्पादों और डिजाइनरों को समीक्षा के लिए बुलाया। परीक्षण को नियंत्रित किया गया कि विधानसभा को देखा गया और प्रतिक्रिया दी गई - तेज, बेहतर। यह शुरुआती चरणों में किया जाता है, ताकि बाद में अप्रिय स्थिति न हो।

चरण 5 - प्लेटफ़ॉर्म परीक्षण

पहले विधानसभा की समीक्षा के समानांतर, पहले संकलित किए गए परीक्षण मामलों का उपयोग करके मंच पर परीक्षण शुरू हुआ। परीक्षण प्रक्रिया के दौरान, यदि आपको समस्याएँ मिलीं जो रिलीज़ को बाधित करने की धमकी देती हैं, या महसूस किया गया कि कुछ बेहतर किया जा सकता है, तो वे चैट में सुविधाओं को जोड़ देंगे या काम के बयान में एक टिप्पणी छोड़ देंगे। हमने सुनिश्चित किया कि प्रश्न खुला न रहे।

उसी चरण में, सुविधाओं (यूआई, उदाहरण के लिए) के तर्क में बदलाव हुए - उन्होंने यह भी सुनिश्चित करने के लिए उत्पाद और डिजाइनर को एक समीक्षा के लिए विधानसभा दी कि उम्मीदें वास्तविकता के साथ मेल खाती हैं।

स्टेज 6 - एकीकरण परीक्षण

यह आइटम आवश्यक है यदि मोबाइल फोन के अलावा अन्य टीम सुविधा के विकास में भाग लेते हैं। उदाहरण के लिए, मोबाइल फोन + बैकएंड। यदि हमने आइकन के फ़ॉन्ट या रंग को बदल दिया है, तो, निश्चित रूप से, कोई एकीकरण नहीं होता है। हालांकि, रिवार्ड्स के साथ हमारे उदाहरण में, एक बैकेंड शामिल है - एकीकरण अपरिहार्य था।
पहली बात यह है कि कंफ्लुएंस में एक गोदी थी। एक नियम के रूप में, पहले एक व्यक्ति ऐसा करता है।

दस्तावेज़ निर्धारित करता है:
- बाहर ले जाने की तारीखें;
- प्रतिभागी - ताकि टीम नायकों को दृष्टि से जान सके, और नायक इस तथ्य का खंडन न कर सकें;
- चेक की सूची;
- मामलों की सूची - विशिष्ट परिस्थितियों के साथ परिदृश्यों का सत्यापन।

एक डॉक संकलित करने के बाद, मैंने इसे फीचर चैट में फेंक दिया और सभी एकीकरण प्रतिभागियों को मामलों की समीक्षा / पूरक करने के लिए बुलाया।



दिन एक्स पर, एकीकरण प्रतिभागियों ने एक कार्यालय में इकट्ठा किया और एकीकरण डॉक्स से सभी परिदृश्यों की जांच की। बैकएंड टीम के साथ संयुक्त एकीकरण करना बहुत अच्छा है - आप तुरंत मौके पर सभी मुद्दों को हल करते हैं और सभी विषमताओं को स्पष्ट करते हैं।

स्टेज 7 - सपोर्ट ब्रीफिंग

रिलीज़ से पहले, उन्होंने समर्थन को सूचित किया कि एक फीचर जल्द ही जारी किया जाएगा, यह तैयार होने का समय है। डाली पढ़े टीके, पोक असेंबली। उन्होंने बताया कि कौन से चैट लिखने हैं और अगर उन्हें उपयोगकर्ताओं से फीडबैक मिलता है तो उन्हें किससे संपर्क करना चाहिए।

स्टेज 8 - रिलीज़

हमने फीचर को रोल करना शुरू कर दिया, इसके बारे में और समानांतर रूप से देखे गए क्रैशलाईटिक्स, स्टोर में फीडबैक और समर्थन के बारे में सूचित किया। हम सर्वश्रेष्ठ के लिए आशा करते थे, वेलेरियन पिया। रिवार्ड्स के साथ सब कुछ सुचारू रूप से चला गया, लेकिन हम तुरंत एक हॉटफ़िक्स बनाने के लिए तैयार थे और यदि प्लेटफ़ॉर्म की तरफ एक महत्वपूर्ण बग पाया गया था तो रोलआउट के दौरान सभी को फ़ीचर चैट में सूचित करें।

स्टेज 9 - रिलीज के बाद सुविधाओं के लिए समर्थन

फीचर के युद्ध में प्रवेश करने के बाद, हमारी भूमिका सूचनात्मक हो गई: उन्होंने आने वाले प्रश्नों का उत्तर दिया, संकेत दिया, कुछ प्लेटफ़ॉर्म समस्याओं को हल किया या, अगर वे समझ गए कि समस्या बैकएंड पर है, तो उन्होंने उन्हें पारित कर दिया। विमोचन के बाद, मैंने रिवार्ड चैक में रिवार्ड्स चैक के मामलों को भी टेस्ट ट्रेल में डाला ताकि भविष्य में उनका पुन: उपयोग किया जा सके।

और अगर संक्षेप में

• हमेशा सभी को एक ही संदर्भ में रखें। महत्वपूर्ण परिवर्तनों की रिपोर्ट करें।
• जैसे ही सुविधाओं के साथ एक विधानसभा दिखाई देती है, सभी इच्छुक पार्टियों द्वारा पहली विधानसभा की समीक्षा का आयोजन करें।
• यदि किसी चरण में किसी विशेषता के तर्क में परिवर्तन होते हैं, तो एक समीक्षा भी आयोजित करें।
• उत्तर प्राप्त करें: लिखें, कॉल करें, किक करें, जब तक आप प्रतिक्रिया न दें।
• एक नई सुविधा के लिए समर्थन तैयार करें और लॉन्च के बाद इसकी मदद करें।

इस प्रक्रिया में मुझे जो ज्ञान और अनुभव प्राप्त हुआ, वह मुझे काम और जीवन दोनों में मदद करता है। मैंने संचार, स्वतंत्रता, जिम्मेदारी को पंप किया, खुद को हमारी टीम के काम से परे उत्पाद में डुबो दिया। वैसे, टीम भी खुश है - एक फकप के मामले में, अब वह शराब पीता है, वेलेरियन नहीं।