"यह माना जाता था कि कोड को यूएमएल आरेखों द्वारा बदल दिया जाएगा, और परीक्षण की कोई आवश्यकता नहीं होगी": अलेक्सी बरनतसेव के साथ एक साक्षात्कार

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

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

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

- ठीक है, कुछ प्रौद्योगिकियां न केवल "दिखाई दी और गायब हो गईं", लेकिन एक ऐसा बन गया जिसके बिना अब उद्योग की कल्पना करना मुश्किल है: "हम बिना गिट के भी कैसे रहते थे?"

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

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

ऐसा क्यों हो रहा है? बेशक, उपकरण विकसित हो रहे हैं। लेकिन यह भी उपकरण की बात नहीं है, कुछ अभी भी vi या emacs में कोड लिखते हैं। इससे भी महत्वपूर्ण बात यह है कि बहुत सारे तैयार कोड पहले ही लिखे जा चुके हैं, अच्छी लाइब्रेरी हैं जिन्हें अच्छी तरह से परखा गया है। कहीं न कहीं, आपको अभी भी अपने बहुत सारे कोड लिखने, अद्वितीय एल्गोरिदम विकसित करने, और सब कुछ अभी भी वहाँ एक लंबा समय लगता है। लेकिन अन्य स्थितियों में, आप तैयार किए गए घटकों को ले सकते हैं, उनमें से जल्दी से, एक डिजाइनर से, तैयार उत्पाद को इकट्ठा कर सकते हैं। और, तदनुसार, इसका परीक्षण करना भी आसान है, क्योंकि हम पहले से ही इसे विश्वसनीय, परीक्षण किए गए घटकों से इकट्ठा कर रहे हैं। यह बहुत बदल गया है।

- और लोगों की विश्वदृष्टि में क्या बदलाव आया है - हम परीक्षण / विकास को कैसे देखते हैं और हम उनसे क्या उम्मीद करते हैं?

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

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

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

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

- चलो हमारे समय पर चलते हैं। आप software-testing.ru का उपयोग कर रहे हैं। उन लोगों के लिए जो सक्रिय रूप से उसका पालन नहीं करते हैं: वहां क्या हो रहा है?

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

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

- अब लोग टेक्स्ट से वीडियो ब्लॉगिंग से भी दूर जा रहे हैं - लेकिन क्या परीक्षण में ऐसा है?

- परीक्षण में, यह प्रवृत्ति लगभग अदृश्य है। वस्तुतः एक या दो वीडियो ब्लॉगर हैं, पृथक मामले।

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

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

- Indiscreet सवाल। Software-testing.ru पर बैनर विज्ञापन है, लेकिन पत्रकारिता में इसके साथ मुद्रीकरण करना मुश्किल है - क्या यह परीक्षण के मामले में बेहतर है, या क्या यह आपके काम की भरपाई नहीं करता है और कला के प्यार के लिए साइट मौजूद है?

- कोई विज्ञापन राजस्व साइट पर काम के लिए क्षतिपूर्ति नहीं करता है। यह नेटवर्क पर हमारी उपस्थिति बनाए रखने के लिए एक छवि, एक छवि बनाने के लिए मौजूद है। और प्रशिक्षण केंद्र हमसे कमाता है।

- अगला सवाल सिर्फ ट्रेनिंग के बारे में है। आप कई सालों से दूसरों को परीक्षा देना सिखा रहे हैं, लेकिन यह कैसे प्रभावित करता है कि आप खुद को कैसे परखते हैं?

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

- जब आप कई लोगों को पढ़ाते हैं, तो आप कई लोगों की कुछ गलतियों को नोटिस करना शुरू करते हैं। क्या आप कुछ सामान्य "विशिष्ट परीक्षक त्रुटि" तैयार कर सकते हैं?

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

इस संबंध में, मैं एक नास्तिक व्यक्ति हूं। जब मैं कुछ घरेलू उपकरण खरीदता हूं, तो मैं सबसे पहले बैठ जाता हूं और निर्देश पढ़ता हूं। इसलिए, अपने स्वयं के मनोवैज्ञानिक अनुभव को अन्य लोगों में स्थानांतरित करना मेरे लिए काफी मुश्किल है। मैं समझता हूं कि हां, ज्यादातर लोग इस तरह की कार्रवाई नहीं करते हैं, वे पहले रेक के आसपास जाते हैं, और फिर वे यह पता लगाने लगते हैं कि इससे कैसे बचा जाए। मेरा मानना ​​है कि यह गलत है, और वे मानते हैं कि यह सही है।

- अब मैं सेलेनियम के बारे में पूछना चाहता हूं। सेलेनियम चालक समुदाय और उसके आसपास का पूरा पारिस्थितिकी तंत्र समुदाय में कैसे आता है? क्या कोई कदम और उपलब्धियां हैं? उदाहरण के लिए, "दस पुल अनुरोध करें और अगले चरण पर जाएं।"

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

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

- और किसके माध्यम से तोड़ने के लिए लिखने के लिए?

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

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

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

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

- अक्सर विवाद होते हैं कि "कौन सा ब्राउज़र बेहतर है", और चूंकि आप उन्हें बग रिपोर्ट भेजते हैं, इसलिए गैर-मानक पक्ष से तुलना करना दिलचस्प है: कौन से ब्राउज़र बग रिपोर्ट की सबसे अच्छी प्रतिक्रिया है और कौन से बदतर हैं?

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

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

- कुछ साल पहले आपने कहा था कि सेलेनियम का काम वेब स्टैंडर्ड बनना है। वह बन गया, और फिर क्या? अगला बड़ा मील का पत्थर क्या है?

- ऑटोमेशन टूल्स के चक्कर में दुनिया पर कब्जा। यही है, हमें यह सुनिश्चित करने की आवश्यकता है कि इस नए मानक का समर्थन किया जाता है।

- अर्थात, अन्य सभी नए UI स्वचालन उपकरण के लिए अंतर्निहित मॉड्यूल बनना?

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

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

"आप और साइमन स्टीवर्ट सेलेनियम के प्रमुख योगदानकर्ता हैं?"

- यह जावा भाग के लिए सच है।

"जहाँ तक मुझे पता है, तुम कभी नहीं मिले हो।" यह कैसे हुआ? सेलेनियम डेवलपर्स के पास कोई "कॉर्पोरेट" नहीं है?

- "कॉर्पोरेट पार्टियां" हमारे पास सम्मेलनों में बैठकों के रूप में हैं, लेकिन अलग से - नहीं। और सम्मेलनों के मामले में, साइमन यहां तक ​​कि पिछले साल के हेइसेनबग में मास्को आया था, लेकिन मैं उस समय मास्को में नहीं था, इसलिए हमने अंतर नहीं किया।

लेकिन, स्पष्ट रूप से, हम अब ऐसी दुनिया में रहते हैं कि यह ठीक है, हम अभी भी लगातार संवाद करते हैं।

- अंतिम सवाल, आखिरकार। आपको क्या लगता है कि विशेष रूप से सामान्य और यूआई में परीक्षण स्वचालन का भविष्य क्या होगा?

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

एलेक्सी 6-7 दिसंबर को मॉस्को हेइज़ेनबग में प्रदर्शन करेंगे - और उनके अलावा, दर्जनों अन्य वक्ता होंगे। हाइजेनबग वेबसाइट पर आप पूरा कार्यक्रम देख सकते हैं और टिकट खरीद सकते हैं।