इनोवा में परीक्षण खेल: विभाग के काम के बारे में एक कहानी

एक प्रस्तावना के रूप में, मैं कहता हूँ कि मैं एक साल पहले इनोवा में आया था, मेरा काम "कंपनी में परीक्षण करना" था। मेरे परीक्षण विभाग में दो समूह होते हैं: एक वेब अनुप्रयोग परीक्षण समूह और एक गेमिंग अनुप्रयोग परीक्षण समूह। यह विभाजन विकसित हुआ है क्योंकि इन क्षेत्रों में कर्मचारियों के लिए अलग-अलग कार्य और विभिन्न आवश्यकताएं हैं।

फिर कहानी खेल परीक्षण की दिशा के बारे में होगी। यह मेरे दोस्तों के बारे में, हमारी प्रक्रियाओं के बारे में, हमारे काम के संगठन के बारे में है। मैं आपको एक मौखिक दौरे के लिए आमंत्रित करता हूं।



बाहरी वातावरण

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

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

हम अपने सभी खेलों में इस राशि को कम करने की कोशिश करते हैं। क्योंकि जैसे ही हम रूस में खेल जारी करते हैं, यह "हमारा" हो जाता है। हम ऐसा सोचते हैं।

परीक्षण की प्रक्रिया

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

यही है, अद्यतन परीक्षण योजना कुछ इस प्रकार है:

- स्थानीयकरण परीक्षण:
- - सूची, समय सीमा की जाँच करें

- नई कार्यक्षमता का परीक्षण:
- - सत्यापन, प्राथमिकताओं, समय सीमा के लिए सूचियों की जांच करें

- विधानसभा परीक्षण:
- - धुआँ परीक्षण, पद

बीटा परीक्षण:
- - खिलाड़ियों के लिए कार्य, समय सीमा

मैंने उदाहरण के रूप में अटलांटिक का उपयोग करते हुए एक स्थानीयकृत खेल के परीक्षण के पूर्ण चक्र के बारे में बात की ।

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

पर्यावरण का परीक्षण करें

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

क्यूए स्टैंड पर, टीसीपी पर खिलाड़ियों को देने से पहले आंतरिक परीक्षण किया जाता है।

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

मुकाबला उत्पाद की गुणवत्ता

और फिर भी, आपको ज्ञात बग के साथ उत्पादों को जारी करना होगा। और - ऐसा होता है कि महत्वपूर्ण के साथ। उदाहरण के लिए, 28 दिसंबर को सर्वर पर स्थापित पौराणिक वंश II उच्च पांच भाग 3 परियोजना का अंतिम प्रमुख अद्यतन, एक गंभीर बग लाया: गेम क्लाइंट को टेलीपोर्टिंग करते समय एक महत्वपूर्ण त्रुटि के साथ उपयोगकर्ताओं के साथ यादृच्छिक रूप से दुर्घटनाग्रस्त हो गया।

यह इस तथ्य पर निर्भर हो सकता है कि, उदाहरण के लिए, यह बग तब होता है जब सर्वर पर लोड होता है। और फिर यह केवल लड़ाकू ऑपरेशन में पॉप अप होता है। हम अपने परीक्षण चक्र में लोड को फिर से नहीं बनाते हैं, क्योंकि विकास कंपनी ऐसा करती है। लेकिन, हमेशा प्रभावी नहीं होता है। चूंकि अद्यतन अक्सर कोरिया के रूप में और अक्सर यूरोप की तुलना में पहले ही लॉन्च किए जाते हैं, इसलिए हम अज्ञात बग के साथ लॉन्च करने का जोखिम रखते हैं।

यह, उदाहरण के लिए, नियोजित अपडेट लॉन्च की तारीख पर निर्भर हो सकता है, जिसका सभी खिलाड़ी इंतजार कर रहे हैं।

यह डेवलपर्स से समस्या के समाधान के अनिश्चित समय पर निर्भर हो सकता है।

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

बेशक, खिलाड़ियों को ज्ञात त्रुटियों के बारे में बताया जाता है। और उनके फैसलों की स्थिति लगातार अपडेट की जाती है। और, ज़ाहिर है, वे "डेवलपर कंपनी को भेजे गए" जवाब से नाखुश हैं, वे इस पर काम कर रहे हैं!

टीम संगठन

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

उनके कार्यों में शामिल हैं:

- परियोजना के परीक्षण के लिए योजना (या इसके अपडेट)
- परियोजना परीक्षण का संगठन (या इसके अद्यतन)
- - आंतरिक परीक्षण
- - बाहरी परीक्षण (बीटा टेस्टर का उपयोग करके)
- सभी इच्छुक पक्षों को परीक्षण की स्थिति और उत्पाद की स्थिति के बारे में सूचित करना

परीक्षण प्रबंधक काम पर बातचीत करता है:

- प्रोजेक्ट मैनेजर के साथ (वे अपडेट की योजना बनाते हैं, लॉन्च को मंजूरी देते हैं)
- परियोजना अभियंता (पैच स्थापित करने के बारे में जानकारी, निर्माण त्रुटियों को ठीक करना)
- डेवलपर्स (परीक्षण परिणामों पर पाए जाने वाले कीड़े पर रिपोर्ट)
- साथी खेल परीक्षक (कार्य सेट करता है, परिणाम एकत्र करता है)
- परियोजना संपादक (स्थानीयकरण त्रुटियों के बारे में संदेश, उनका सुधार)
- सामुदायिक परियोजना प्रबंधक (ज्ञात कीड़े, बीटा टेस्टर्स के साथ काम करना)
- उपयोगकर्ता समर्थन टीम (कार्यों को सेट करता है, परिणाम एकत्र करता है, उपयोगकर्ताओं द्वारा पाई गई त्रुटियों के बारे में जानकारी एकत्र करता है)

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





इसके अलावा, अगर एक बड़े हमले की आवश्यकता होती है (उदाहरण के लिए, सभी प्रोजेक्ट सर्वर पर क्लाइंट बिल्ड की जांच करना), तो एक उपयोगकर्ता सहायता टीम बचाव में आती है: वे खेल की सामग्री को जानते हैं और मदद करने के लिए तैयार हैं। यहाँ, परीक्षक फिर से कार्य निदेशक के रूप में कार्य करता है।

दिन के लिए टीम वर्क प्लानिंग सुबह के स्टैंड-अप पर होती है। टीम जिन मुख्य मुद्दों पर चर्चा करती है वे हैं:

- "आज मैं इसे करूंगा"
"आज मुझे इसकी जांच के लिए 4 लोगों की आवश्यकता है।"
"मैं आज लोड नहीं हुआ, किसे मदद की ज़रूरत है?"

मालिक दृष्टिकोण

हमारी कंपनी की अवधारणा "कार्य चालक" है। इसका अर्थ है "इसका मालिक होना", इसके निर्णय में सबसे अधिक रुचि होना। यह स्पष्ट है कि परीक्षक अपने दम पर बहुत कुछ नहीं कर सकता है:

- यह सीधे डेवलपर्स द्वारा तेज बग फिक्स को प्रभावित नहीं कर सकता है
- यह सीधे इंस्टॉलेशन त्वरण को प्रभावित नहीं कर सकता है
- वह एक इंजीनियर को नियंत्रित नहीं कर सकता
आदि

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

एक व्यक्ति, जो कठिनाई के मामले में, बस एक पत्र लिखता है, अपने हाथों को मोड़ता है और इंतजार करता है, हमें सूट नहीं करता है।

मेरे परीक्षक उनके प्रोजेक्ट मैनेजर हैं। परियोजनाओं का परीक्षण करने के लिए परियोजनाएं। प्रक्रिया के मालिक।

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

मुझे लगता है कि हर किसी के लिए ऐसा करना गलत है, इसलिए मैं अपने लोगों को इसे करना सिखाता हूं। यह उन्हें विकसित करता है, और यह मुझे और अधिक रणनीतिक कार्यों में संलग्न होने के लिए एक नेता के रूप में स्वतंत्रता देता है।

साइड इफेक्ट

सच है, इस दृष्टिकोण का साइड-इफेक्ट भी है। लोग परियोजना के सभी पक्षों को देखते हैं, कंपनी के लगभग सभी विभागों के साथ, सभी परियोजना प्रतिभागियों के साथ संवाद करते हैं। उन्हें देखा जाता है, उन्हें देखा जा रहा है। और वे बढ़ रहे हैं।

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

और इससे कम नहीं मैं उन लोगों के लिए आनन्दित हूं जिनके लिए परीक्षण उद्योग है जहां वे विकास करना चाहते हैं और उपयोगी होना चाहते हैं। वे परीक्षक के रूप में बढ़ते हैं, परीक्षण प्रबंधकों के रूप में, और कहीं भी स्कीइंग करने के लिए नहीं जा रहे हैं।

कंपनी का स्तर

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

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

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

ऐसी परियोजनाओं में, हम विशेषज्ञता के वाहक के रूप में कार्य करते हैं: हम सुझाव दे सकते हैं, परीक्षण लिखने में मदद कर सकते हैं, सुझाव दे सकते हैं कि कलाकृतियों को ठीक से कैसे व्यवस्थित किया जाए।

यह कठिन है, लेकिन दिलचस्प है। हमें डांटा गया है, और उपयोगकर्ता हमें धन्यवाद कहते हैं। हम सिस्टम से लड़ते हैं और डेवलपर्स के साथ दोस्ती करते हैं।

धन्यवाद दोस्तों!