इंटरएक्टिव परीक्षण - चाहे खेल मोमबत्ती के लायक हो

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

अगर किसी को दिलचस्पी है - मैं एक बिल्ली के लिए पूछना।

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

तो, पेशेवरों:

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

• जैसा कि अनुभव (मेरे व्यक्तिगत) से पता चलता है, सबसे महत्वपूर्ण समस्याओं को पहले 15-20 मिनट में पता लगाया जाता है (यह निर्भर करता है, फिर से, कार्य की जटिलता और अन्य चीजों पर, लेकिन चलो औसत विकल्प लेते हैं)। पहले बिंदु को देखते हुए, कल्पना करें कि यदि यह परीक्षण भंडार करने से पहले किया जाता है तो कितना समय बचता है। यह बार-बार हुआ कि, डेवलपर की मशीन पर बैठकर, 15 मिनट में मैंने 2-3 महत्वपूर्ण और लगभग 5 गैर-महत्वपूर्ण, लेकिन फिर भी अप्रिय समस्याओं के बारे में पाया।

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

लेकिन निश्चित रूप से, नुकसान हैं:

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

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

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

• मूल रूप से, इस तरह की प्रथाओं, यह मुझे लगता है, केवल उन लोगों द्वारा लागू किया जा सकता है जो केवल अपना काम नहीं करते हैं, न केवल उनकी गतिविधियों के फल के बारे में चिंता करते हैं, बल्कि कुछ हद तक, उनके काम के कट्टरपंथी :)

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