"परिवर्तन करने के लिए, यह समझें कि लोग इसका विरोध क्यों करते हैं": जिम होम्स टेस्टिंग कल्चर पर

एक सेना एक परीक्षक को क्या सिखा सकती है? परीक्षण दृष्टिकोण में दो चरम सीमाएं क्या हैं? कैसे समझा जाए कि तकनीकी ऋण भुगतान से लाल है? पिछले प्रश्न आम में क्या हैं?

सामान्य बात यह है कि उनके अंतर के लिए, वे सभी एक व्यक्ति के करीब हैं। जिम होम्स ने कई दशकों के आईटी अनुभव को पीछे छोड़ दिया, जो अमेरिकी वायु सेना में 80 के दशक में शुरू हुआ था - यह आश्चर्यजनक नहीं है कि वह बहुत कुछ बताने के लिए तैयार है। "परीक्षण संस्कृति" की अवधारणा उसके लिए महत्वपूर्ण है, और हमने उससे ऐसे प्रश्न पूछे जो बहुत भिन्न हो सकते हैं, लेकिन अंततः परीक्षण संस्कृति से संबंधित हैं।

- परिचयात्मक प्रश्न: हमें अपने बारे में बताएं।

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

- शायद, परीक्षक के लिए, आपकी जीवनी का सबसे असामान्य हिस्सा सैन्य सेवा है। तुम वहाँ क्या कर रहे थे?

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

आपके प्रश्न के लिए, न केवल परीक्षकों के लिए, बल्कि कई अन्य क्षेत्रों के लिए भी सैन्य सेवा का अनुभव असामान्य है। मैं कह सकता हूं कि कम से कम मुझे वहां अनुशासन सिखाया गया था।

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

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

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

- यही है, आपको एक रणनीति के माध्यम से सोचने के लिए समय निकालने की आवश्यकता है।

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

- चलिए अपनी वर्तमान गतिविधियों पर चलते हैं। काम पर, आप अलग-अलग कंपनियों में अलग-अलग तरीकों से परीक्षण करने के तरीके से परिचित हैं। यह स्पष्ट है कि दृष्टिकोण निर्भर हो सकता है, उदाहरण के लिए, कंपनी के आकार पर। लेकिन शायद बहुत कम स्पष्ट अंतर हैं - क्या आप उनके बारे में बात कर सकते हैं?

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

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

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

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

- और काउंसलिंग की आपकी प्रैक्टिस में, कई बार कंपनी के साथ काम पूरा करने के बाद, उन्होंने आपको "कुछ भी बेहतर नहीं हुआ" बताया?

- मैं आपको एक रहस्य बताऊंगा कि यह लोगों के साथ मुश्किल है, हम बहुत मुश्किल प्राणी हैं। यह एक कारण है कि मेरे पास इतने भूरे बाल हैं (दूसरा मेरी बेटी है)। एक व्यक्ति को बदलना मुश्किल है, एक संगठन में लोगों को बदलना और भी मुश्किल है। तो हां, मेरी यह स्थिति काफी बार है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, , : Heisenbug , Fortune 10. , ? 6-7 Heisenbug , .

— . «The leadership journey» . , : , , — . ?

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

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

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

- मेरी बेटी के जन्म के 18 साल बीत चुके हैं, मैंने 13 या 14. दूर से काम किया है। इसलिए मैं वास्तव में इस मुद्दे पर एक राय हूं। मेरी राय में, रिमोट काम एक महत्वपूर्ण उपकरण है, यह आपको उन लोगों के सर्कल का विस्तार करने की अनुमति देता है जिनके साथ आप संभावित रूप से काम कर सकते हैं। उदाहरण के लिए, एक ऐसे व्यक्ति के साथ जो दूसरे राज्य में या किसी अन्य महाद्वीप में रहता है। इसलिए मैं दूरस्थ कार्यों का समर्थक हूं, कुछ स्थितियों में यह बहुत उपयोगी है।

इसी समय, यह मान्यता दी जानी चाहिए कि दूर से काम करते समय, संचार और उत्पादकता के साथ महत्वपूर्ण समस्याएं उत्पन्न होती हैं। विशुद्ध रूप से तकनीकी दृष्टिकोण से, एक टीम जो पूरी तरह से काम करती है या कुछ दूरी पर अधिकांश भाग के लिए अच्छा बुनियादी ढांचा होना चाहिए। ऐसी टीम के प्रत्येक सदस्य को DevOps सिद्धांत पर काम करना चाहिए। ऐसी स्थिति नहीं होनी चाहिए जहां डिबगिंग के लिए लॉग प्राप्त करने के लिए दिनों तक हम सर्वर व्यवस्थापक से संपर्क न कर सकें। इसके अलावा, आपको संचार साधनों के संगठन से गंभीरता से संपर्क करने की आवश्यकता है। और अगर आप तय करते हैं कि Skype और कुछ मैसेंजर आपके लिए पर्याप्त हैं, तो Skype for Business ने इसे नहीं लिया और Google Hangouts के मुक्त संस्करण का उपयोग किया, तो आपको समस्याएँ होंगी। रिमोट वर्क के लिए अच्छे इंफ्रास्ट्रक्चर की जरूरत होती है। इसके अलावा, अधिक जिम्मेदारी और अनुशासन की आवश्यकता है। , हाँआप अपने पजामा में भी काम कर सकते हैं, लेकिन आपको काम करना चाहिए, और अंत में दिनों के लिए Xbox पर नहीं खेलना चाहिए - यह स्वीकार करने के लिए शर्म की बात है, लेकिन मैं अपने अनुभव से यह कहता हूं।

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

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

— «Technical debt: payment plan». « » , « » , . , , , , ?

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

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

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

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

— , , , . , , , .

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

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

- इसलिए, यह हमेशा अच्छा होता है जब प्रबंधक या टीम लीडर को विकास का अनुभव होता है - तब वे इन बातों को समझते हैं। एक अच्छा प्रोजेक्ट बनाना आसान होता है जब प्रबंधन में तकनीकी विशेषज्ञता होती है।

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

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

- यहीं से हमारे सवाल खत्म हुए। आपके विस्तृत जवाब के लिए बहुत बहुत धन्यवाद।

- धन्यवाद, मुझे आपके सवाल पसंद आए। मुझे लगता है कि यह दिखाई दे रहा था: आप बहुत सारे विषयों को उठाने में कामयाब रहे जो व्यक्तिगत रूप से मेरे बहुत करीब हैं।