नमस्ते! मेरा नाम यूलिया है और मैं एक परीक्षक हूं। पिछले साल मैंने आपको इसके बारे में बताया था बागोडेलन्या - बग बैकलॉग को साफ़ करने के लिए हमारी कंपनी में एक कार्यक्रम आयोजित किया गया। इसे केवल एक दिन में (विभिन्न टीमों में 10 से 50% तक) उल्लेखनीय रूप से कम करने का यह एक पूरी तरह से व्यवहार्य विकल्प है।

आज मैं आपको हमारे स्प्रिंग बैगोडेलनी प्रारूप - बगहंटिंग (बीयूएच) के बारे में बताना चाहता हूं। इस बार हमने पुराने बग ठीक नहीं किए, बल्कि नए बग ढूंढे और सुविधाओं के लिए विचार प्रस्तावित किए। कट के नीचे ऐसे आयोजनों के आयोजन, हमारे परिणामों और प्रतिभागियों की प्रतिक्रिया के बारे में कई विवरण हैं।

नियमों पर विचार करने और उन्हें लिखने के बाद, हमने कॉर्पोरेट स्लैक के सभी चैनलों को निमंत्रण भेजा, जिसमें कोई प्रतिबंध नहीं था:

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

क्यों?

ऐसा प्रतीत होता है कि प्रत्येक टीम अपनी कार्यक्षमता का परीक्षण करती है। उपयोगकर्ता हमें बग की रिपोर्ट करते हैं। आखिर ऐसा आयोजन क्यों करें?

हमारे कई लक्ष्य थे.

1. लोगों को संबंधित परियोजनाओं/उत्पादों से परिचित कराएं.
   अब हमारी कंपनी में सभी लोग अलग-अलग टीमों-इकाइयों में काम करते हैं। ये परियोजना टीमें हैं जो कार्यक्षमता के अपने हिस्से पर काम कर रही हैं और हमेशा इस बात से पूरी तरह अवगत नहीं होती हैं कि अन्य परियोजनाओं में क्या हो रहा है।
2. बस अपने सहकर्मियों को एक-दूसरे से मिलवाएं.
   हमारे मॉस्को कार्यालय में लगभग 800 कर्मचारी हैं; सभी सहकर्मी एक-दूसरे को दृष्टि से नहीं जानते।
3. डेवलपर्स की अपने उत्पादों में बग ढूंढने की क्षमता में सुधार करें.
   अब हम एजाइल टेस्टिंग को बढ़ावा दे रहे हैं और लोगों को इस दिशा में प्रशिक्षित कर रहे हैं।
4. परीक्षण में केवल तकनीकी विशेषज्ञों से अधिक को शामिल करें.
   तकनीकी विभाग के अलावा, हमारे पास अन्य विशिष्टताओं के कई सहकर्मी हैं जो परीक्षण के बारे में अधिक बात करना चाहते थे, बग की ठीक से रिपोर्ट कैसे करें ताकि हमें "आह... कुछ भी काम नहीं करता" जैसे कम संदेश प्राप्त हों।
5. और, निःसंदेह, पेचीदा और स्पष्ट बग ढूँढ़ें.
   मैं टीमों को नई सुविधाओं का परीक्षण करने में मदद करना चाहता था और उन्हें कार्यान्वित कार्यक्षमता को एक अलग कोण से देखने का अवसर देना चाहता था।

कार्यान्वयन

हमारे दिन में कई ब्लॉक शामिल थे:

• ब्रीफिंग;
• परीक्षण पर एक संक्षिप्त व्याख्यान, जिसमें हमने केवल मुख्य बिंदुओं (परीक्षण के लक्ष्य और सिद्धांत, आदि) पर बात की;
• बग्स का परिचय देते समय "अच्छे व्यवहार के नियम" पर अनुभाग (यहां सिद्धांतों का अच्छी तरह से वर्णन किया गया है);
• उच्च-स्तरीय वर्णित परिदृश्यों वाली परियोजनाओं के लिए चार परीक्षण सत्र; प्रत्येक सत्र से पहले परियोजना और टीमों में विभाजन पर एक संक्षिप्त परिचयात्मक व्याख्यान था;
• घटना पर संक्षिप्त सर्वेक्षण;
• सारांश

(हम सत्र और दोपहर के भोजन के बीच ब्रेक के बारे में भी नहीं भूले)।

मूल नियमावली

• आयोजनों के लिए पंजीकरण व्यक्तिगत है, जो एक व्यक्ति के न जाने का निर्णय लेने पर जड़ता के कारण पूरी टीम के थक जाने की समस्या को हल करता है।
• प्रतिभागी हर सत्र में टीमें बदलते हैं. इससे प्रतिभागी किसी भी समय आ-जा सकते हैं और आप अधिक लोगों से भी मिल सकते हैं।
• आदेशों प्रत्येक सत्र से पहले दो लोग बेतरतीब ढंग से बनते हैं, यह इसे अधिक गतिशील और तेज़ बनाता है।
• पेश किए गए बग के लिए आपको पुरस्कृत किया जाता है गंभीरता के आधार पर अंक (3 से 10 तक)।.
• डुप्लिकेट के लिए कोई अंक नहीं दिए जाते हैं।
• बग को सभी आंतरिक मानकों के अनुसार टीम के सदस्य द्वारा दर्ज किया जाना चाहिए।
• फ़ीचर अनुरोध एक अलग कार्य में बनाए जाते हैं और एक अलग नामांकन में भाग लेते हैं।
• ऑडिट टीम सभी नियमों के अनुपालन की निगरानी करती है।

अन्य विवरण

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

कार्यक्रम आयोजित करते समय हर किसी को समस्याओं का सामना करना पड़ता है, और आपके लिए इसे थोड़ा आसान बनाने के लिए, मैं हमारी समस्याओं का वर्णन करूंगा जिनसे आप बच सकते हैं।

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

हमारे पास कार्यक्षमता शुरू करने का समय नहीं था, हमें ब्लॉकों को स्वैप करना पड़ा.
पूरे ब्लॉक को बर्बाद होने से बचाने के लिए, बैकअप योजना बनाना बेहतर है।

कुछ परीक्षण उपयोगकर्ताओं को छोड़ दिया गया, हमें जल्दी से नए उपयोगकर्ताओं को फिर से बनाना पड़ा.
परीक्षण उपयोगकर्ताओं को पहले से क्रॉस-चेक करें या उन्हें शीघ्रता से करने में सक्षम हों।

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

उपयोगी संगठनात्मक बिंदु:

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

निष्कर्ष

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

सभी प्रतिभागियों को मीठे पुरस्कार मिले।

और विजेता थर्मोज़, बैज, स्वेटशर्ट हैं।

क्या दिलचस्प निकला:

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

क्या सुधार किया जा सकता है:

• कम परियोजनाएँ करें और सत्र का समय 1,5 घंटे तक बढ़ाएँ;
• उपहार/स्मृति चिन्ह बहुत पहले से तैयार करें (कभी-कभी अनुमोदन/भुगतान में एक महीना लग जाता है);
• आराम करें और स्वीकार करें कि कुछ योजना के अनुसार नहीं होगा और अप्रत्याशित घटना होगी।

समीक्षा

अन्ना बिस्ट्रिकोवा, सिस्टम प्रशासक: “भिक्षागृह मेरे लिए बहुत शिक्षाप्रद है। मैंने परीक्षण प्रक्रिया सीखी और परीक्षकों के सभी "दर्द" को महसूस किया।
सबसे पहले, परीक्षण प्रक्रिया के दौरान, एक अनुकरणीय उपयोगकर्ता के रूप में, आप मुख्य बिंदुओं की जांच करते हैं: क्या बटन क्लिक करता है, क्या यह पृष्ठ पर जाता है, क्या लेआउट बाहर चला गया है। लेकिन बाद में आपको एहसास होता है कि आपको बॉक्स के बाहर और अधिक सोचने और एप्लिकेशन को "तोड़ने" का प्रयास करने की आवश्यकता है। परीक्षकों का काम कठिन है; पूरे इंटरफ़ेस पर "प्रहार" करना पर्याप्त नहीं है; आपको बॉक्स के बाहर सोचने की कोशिश करने और बेहद सावधान रहने की आवश्यकता है।
प्रभाव केवल सकारात्मक थे, अब भी, घटना के कुछ समय बाद, मैं देख रहा हूँ कि मुझे मिले बग पर कैसे काम किया जा रहा है। उत्पाद को बेहतर बनाने में शामिल महसूस करना बहुत अच्छा है ^_^।"

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

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

निष्कर्ष

यदि आप अपनी टीम के जीवन में विविधता लाना चाहते हैं, कार्यक्षमता पर नए सिरे से विचार करें, एक मिनी की व्यवस्था करें "अपने कुत्ते का खाना खुद खाओ", तो आप इस तरह का आयोजन करने का प्रयास कर सकते हैं, और फिर हम एक साथ इस पर चर्चा कर सकते हैं।

सभी बेहतरीन और कम बग!

स्रोत: www.habr.com