हमने परीक्षकों के लिए हैकथॉन का आयोजन क्यों किया?

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

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

मैं सभी आईटी कंपनियों के बारे में नहीं बोल सकता, लेकिन हमने अपने गुणवत्ता विशेषज्ञों को क्यूए/क्यूसी की भूमिका सौंपी है। वे विकास टीम का हिस्सा हैं और अनुसंधान से लेकर नए संस्करण के जारी होने तक विकास के सभी चरणों में भाग लेते हैं।

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

परीक्षकों की तलाश करते समय हमें क्या सामना करना पड़ा

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

आगे, मैं आपको बताऊंगा कि गुणवत्ता के लिए लंबे समय से प्रतीक्षित सेनानियों को खोजने के लिए हमने क्या कदम उठाए और क्या गलतियाँ कीं।

हमने स्थिति को कैसे ठीक करने का प्रयास किया

तैयार विशेषज्ञों की सोर्सिंग से खुद को थका लेने के बाद, हमने आस-पास के क्षेत्रों को लक्षित करना शुरू किया:

1. हमने कई "इसे छोड़ दें" लोगों में से उन लोगों की पहचान करने के लिए मूल्यांकन प्रथाओं को लागू करने का प्रयास किया, जिनसे हम मजबूत विशेषज्ञ विकसित कर सकते हैं।

   हमने कार्यों को पूरा करने के लिए लगभग समान स्तर के ज्ञान वाले संभावित उम्मीदवारों के एक समूह से पूछा। उनकी विचार प्रक्रिया का अवलोकन करते हुए, हमने सबसे आशाजनक उम्मीदवार की पहचान करने का प्रयास किया।

   विशेष रूप से, हम चौकसी, प्रौद्योगिकी की क्षमताओं की समझ और बहुसंस्कृतिवाद की विशेषताओं का परीक्षण करने के लिए कार्य लेकर आए हैं:

   
   

2. हमने मौजूदा दल के बीच पेशे की समझ की सीमाओं का विस्तार करने के लिए परीक्षकों के लिए बैठकें आयोजित कीं।

   मैं आपको उनमें से प्रत्येक के बारे में थोड़ा बताऊंगा।

   ऊफ़ा सॉफ्टवेयर क्यूए और टेस्टिंग मीटअप #1 उन लोगों को इकट्ठा करने का हमारा पहला प्रयास है जो पेशे की परवाह करते हैं और साथ ही यह समझते हैं कि हम उन्हें जो बताना चाहते हैं उसमें जनता की दिलचस्पी होगी या नहीं। मूल रूप से, हमारी रिपोर्टें इस बारे में थीं कि यदि आपने परीक्षक बनने का निर्णय लिया है तो कहां से शुरुआत करना बेहतर है। शुरुआती लोगों को अपनी आँखें खोलने और एक वयस्क की तरह परीक्षण देखने में मदद करें। हमने उन कदमों के बारे में बात की जो नौसिखिए परीक्षकों को इस पेशे में शामिल होने के लिए उठाने होंगे। गुणवत्ता क्या है और वास्तविक परिस्थितियों में इसे कैसे प्राप्त किया जाए, इसके बारे में। और साथ ही, स्वचालित परीक्षण क्या है और इसका उपयोग कहाँ करना अधिक उपयुक्त है।

   
   
   फिर, 1-2 महीने के अंतराल पर, हमने दो और बैठकें कीं। वहाँ पहले से ही दोगुने प्रतिभागी थे। "उफ़ा सॉफ़्टवेयर क्यूए और टेस्टिंग मीटअप #2" में हमने विषय क्षेत्र में गहराई से प्रवेश किया। उन्होंने बग ट्रैकिंग सिस्टम, यूआई/यूएक्स परीक्षण के बारे में बात की, डॉकर, एन्सिबल पर बात की, और डेवलपर और परीक्षक के बीच संभावित संघर्ष और उन्हें हल करने के तरीकों के बारे में भी बात की।

   हमारी तीसरी बैठक, "उफा सॉफ्टवेयर क्यूए और टेस्टिंग मीटअप #3", परोक्ष रूप से परीक्षकों के काम से संबंधित थी, लेकिन प्रोग्रामर को उनके तकनीकी और संगठनात्मक कर्तव्यों की समय पर याद दिलाने में उपयोगी थी: लोड परीक्षण, ई2ई परीक्षण, ऑटोटेस्टिंग में सेलेनियम, वेब एप्लिकेशन कमजोरियां .

   इस समय हम सीख रहे हैं कि अपने कार्यक्रमों के प्रसारण में सामान्य प्रकाश और ध्वनि कैसे बनाई जाए:

   → परीक्षण में पहला कदम - ऊफ़ा सॉफ्टवेयर क्यूए और टेस्टिंग मीटअप #1
   → यूआई/यूएक्स परीक्षण - ऊफ़ा सॉफ्टवेयर क्यूए और टेस्टिंग मीटअप #2
   → सुरक्षा परीक्षण, लोड परीक्षण और ऑटो परीक्षण - ऊफ़ा क्यूए और परीक्षण मीटअप #3

3. और अंत में हमने परीक्षकों के लिए एक हैकथॉन आयोजित करने का प्रयास करने का निर्णय लिया

हमने परीक्षकों के लिए हैकथॉन कैसे तैयार किया और संचालित किया

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

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

हमने प्रतिभागियों की संभावित संख्या का अनुमान लगाया और निर्णय लिया कि हमें एमवीपी रिलीज, 5 उत्पादों और 5 लोगों के लिए कम से कम 5 बैकलॉग की आवश्यकता है जो उत्पाद मालिकों के रूप में कार्य करेंगे, व्यावसायिक जरूरतों को समझेंगे और प्रतिबंधों पर निर्णय लेंगे।

यहाँ हमें क्या मिला है: हैकथॉन के लिए बैकलॉग.

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

हमने क्या गलतियाँ कीं और हम क्या बेहतर कर सकते थे?

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

मिलना-जुलना अच्छी बात है. विस्तार के लिए एक व्यापक आधार तैयार किया जाता है, और प्रतिभागियों का सामान्य स्तर बढ़ता है। कंपनी बाजार में अधिक से अधिक पहचान बनाती जा रही है। लेकिन ऐसे उपक्रमों की श्रम तीव्रता छोटी नहीं है। आपको यह स्पष्ट रूप से समझने की आवश्यकता है कि मीटअप आयोजित करने में प्रति वर्ष लगभग 700-800 मानव-घंटे लगेंगे।

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

घटना के परिणामों का विश्लेषण करने के बाद, हमें एहसास हुआ कि हमने बहुत सारी गलतियाँ की हैं:

1. सबसे अक्षम्य गलती यह मानना ​​था कि 4-5 घंटे हमारे लिए पर्याप्त होंगे। परिणामस्वरूप, बैकलॉग से परिचय और परिचित होने में ही लगभग 2 घंटे लग गए।
   प्रारंभिक चरण में उत्पाद स्वामियों के साथ काम करने और विषय क्षेत्र में गहराई से उतरने में समान समय लगा। इसलिए शेष समय स्पष्ट रूप से परीक्षण मानचित्रों के व्यापक विकास के लिए पर्याप्त नहीं था।
2. प्रत्येक मानचित्र पर विस्तृत प्रतिक्रिया के लिए पर्याप्त समय और ऊर्जा नहीं थी, क्योंकि पहले ही रात हो चुकी थी। इसलिए, हम स्पष्ट रूप से इस भाग में विफल रहे, लेकिन शुरू में इसका उद्देश्य हैकथॉन में सबसे मूल्यवान होना था।
3. हमने सभी प्रतिभागियों के एक साधारण वोट द्वारा विकास की गुणवत्ता का मूल्यांकन करने का निर्णय लिया, प्रत्येक टीम के लिए 3 वोट आवंटित किए, जो वे उच्चतम गुणवत्ता वाले काम के लिए दे सकते थे। शायद जूरी का गठन करना बेहतर होगा.

आपने क्या हासिल किया है?

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

स्रोत: www.habr.com