DevOps - ठीक है, लेकिन क्या करें? मैनुअल श्रम को कैसे कम करें और वांछित परिणाम प्राप्त करें

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

Dano

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

कंपनी

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

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

परीक्षण समारोह

अब संरचना के बारे में कुछ शब्द: जैसा कि मैंने कहा, लगभग 30 लोग परीक्षण समारोह का हिस्सा हैं। इनमें से 17-19 इस क्षेत्र में 1 वर्ष से अधिक नहीं के अनुभव के साथ कनिष्ठ लिंक है। अक्सर, ये तकनीकी शिक्षा के बिना लोग होते हैं, लेकिन "जलती हुई आँखें" और आईटी क्षेत्र में काम करने की एक बड़ी इच्छा के साथ (क्यों उनकी यह इच्छा चर्चा के लिए एक अलग विषय है)। शेष 11-13 लोग वरिष्ठ और मध्य प्रबंधक हैं: 3-4 लोग वरिष्ठ और 7-10 लोगों का प्रतिनिधित्व करते हैं - औसत। संपूर्ण परीक्षण समारोह में भागीदारी, जटिलता और भागीदारी की अलग-अलग डिग्री के साथ 13-15 विभिन्न उत्पादों / परियोजनाओं को वितरित किया जाता है।

संस्कृति

यह अंतिम परिचय है।

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

समस्या का बयान

और जैसा कि वे कहते हैं, समस्या क्या है? अगर सब कुछ उस तरह से काम करता है तो कुछ क्यों बदलें? अगर एक कामकाजी मॉडल है, तो कहीं और क्यों जाएं और यह अपने लाभांश लाता है?

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

अगला - आईटी क्षेत्र में विभिन्न लेखकों और विशेषज्ञों की सामग्री के आधार पर शुद्ध फंतासी और सुझाव।

समाधान (संभव)

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

हम भविष्य की एक तस्वीर खींचते हैं। हम किस चीज के लिए प्रयास कर रहे हैं?

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

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

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

तो, हमारा लक्ष्य है: " जल्दी, कुशलता से और उचित धन के लिए " (सस्ते में, सबसे अधिक संभावना है, आप इसे तुरंत नहीं कर सकते)।

अब आइए इस बात को सहसंबद्ध करने का प्रयास करें कि क्या उद्देश्य के साथ दिया गया था।

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

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

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

मुख्य समस्या को हल करने के लिए क्या करने की आवश्यकता है?

अनुभव के आधार पर, मेरी अपनी राय में, इसकी आवश्यकता है:

1. अपने उत्पाद के उत्पाद लक्ष्यों में डेवलपर्स को अधिक विसर्जित करें;
   
2. व्यवसाय को समझाने के लिए कि स्वचालन लागत महत्वपूर्ण है और सभी आर्थिक लागतों के लिए अधिक आर्थिक लाभ प्रदान करती है।
   
3. मूल्य वितरण प्रक्रिया से अधिकतम तक मैनुअल काम को बाहर करने के लिए, स्वचालित रूप से सब कुछ स्वचालित किया जा सकता है।
   
4. जीरो बग पॉलिसी को लागू करें, जिसके बिना उपयोगकर्ताओं को हमारे उत्पादों को पीछे हटाने वाली समस्याओं का सामना करना पड़ेगा। वैसे, "DoDo" का एक सफल उदाहरण बताता है कि यह काफी साध्य है।
   

व्यवहार और विश्वदृष्टि बदलने के लिए प्रतिभागियों को समझाने के लिए हमें क्या करने की आवश्यकता है?

डेवलपर्स

बहस कैसे करें - उन्हें अपने पसंदीदा कार्यात्मक कोड प्रोग्रामिंग के अलावा कुछ और करने की आवश्यकता क्यों है? मैं ऐसे संगठन के साथ उत्पन्न होने वाली समस्याओं पर सीधे ध्यान देने का प्रस्ताव करता हूं। उनमें से कई हैं:

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

परीक्षण डेवलपर्स की मदद कैसे करेगा या संकेतित मुद्दों को हल करने में उनकी मदद कैसे करेगा?

1. विषय क्षेत्र या हल किए जाने वाले कार्यों के उद्देश्य के बारे में अधिक जानकारी प्राप्त करें। किसी कार्य को शुरू करते समय एक डेवलपर क्या विशिष्ट प्रश्न पूछता है? "यह कैसे करना है?" "और यहाँ क्या करने की आवश्यकता है?" "और इस तथ्य के बावजूद कि यह कैसे जाना जाता है कि यह कैसे करना है?" "और यह उस फ़ंक्शन को कैसे प्रभावित करेगा?" इन सभी सवालों का उद्देश्य कार्य के कार्यान्वयन को स्पष्ट करना है , और इस कार्य की परिवर्तनशीलता को समझने के लिए नहीं। एक परीक्षक एक नए कार्य के नए विवरण से परिचित होने पर क्या करता है? वह सवाल भी पूछता है, लेकिन थोड़े अलग तरीके से: "क्या होगा अगर?" "ऐसा क्यों होना चाहिए?" "मुझे आखिर में क्या मिलना चाहिए?" "शुरुआत में मेरे पास क्या है?" "यह कैसे संबंधित होना चाहिए?" उस के साथ? ” यही है, लगभग सभी सवालों का उद्देश्य उपयोगकर्ता के परिदृश्य की पहचान करना और इस फ़ंक्शन के परिणाम को समझना है।
   
   क्या महत्वपूर्ण है? न केवल स्पष्ट प्रश्न (लागू करने के तरीके), बल्कि अंतिम परिणाम को समझने के उद्देश्य से प्रश्न पूछकर, आप कार्य के बारे में अधिक जानकारी प्राप्त कर सकते हैं, न केवल परिचित तरीकों की उम्मीद कर सकते हैं, बल्कि सरल और अधिक प्रभावी भी हो सकते हैं। एक सकारात्मक परिदृश्य में, यह अतिरिक्त कोड लिखने या वास्तव में अंतिम उपयोगकर्ता की आवश्यकता बनाने के लिए मदद नहीं करेगा, जो कि हमें चाहिए।
   
   कोई पूछेगा: "मुझे एक डेवलपर के रूप में क्यों दिलचस्पी लेनी चाहिए, या मुझे इसके बारे में सोचना चाहिए?" हम जवाब देंगे - "तालिका में" विकसित नहीं करने के लिए। मेरे वातावरण में डेवलपर्स के एक सर्वेक्षण के परिणाम बताते हैं कि जब आप कुछ करते हैं तो यह कितना विध्वंसकारी होता है, लेकिन इसे जारी न करें (इसे एक शेल्फ पर रखें)।
   
2. एक और सवाल: "मुझे एक डेवलपर के रूप में परीक्षण करने की आवश्यकता क्यों है अगर हमारे पास परीक्षक हैं?" या "मुझे कुछ अतिरिक्त कोड विकसित करने की आवश्यकता क्यों है जो सेट उत्पाद कार्यों को पूरा नहीं करता है?" । यहां आप कुछ और पेश कर सकते हैं। स्वचालित परीक्षण अनिवार्य रूप से समान कोड होते हैं जो एक ही प्रोग्रामिंग कानूनों को थोड़ी बारीकियों के साथ पालन करते हैं। जब कोई डेवलपर किसी बड़े उत्पाद के ढांचे के भीतर काम करता है, तो उसे उत्पाद के भीतर चुने गए विकास नियमों और प्रौद्योगिकियों का पालन करने के लिए मजबूर किया जाता है, और इस उत्पाद में उपयोग किए गए चौखटे का उपयोग करने के लिए लिखा जाता है। परीक्षण लिखते समय ऐसा करना आवश्यक नहीं है: कोई भी आपको एक ही भाषा या समान दृष्टिकोण का उपयोग करने के लिए मजबूर नहीं करता है: स्वचालित परीक्षण को लागू करते समय, आप आसानी से पूरी तरह से नई भाषा आज़मा सकते हैं और इसके साथ अनुभव प्राप्त कर सकते हैं।
   
   एक सरल नियम है कि डेवलपर्स उत्पाद कोड लिखते समय पालन करते हैं - जो आप कर रहे हैं उसका अधिकतम अनुकूलन, संसाधनों का इष्टतम उपभोग, इष्टतम प्रदर्शन, (अधिमानतः) अधिकतम पुन: उपयोग और इसी तरह। स्वचालित परीक्षणों का विकास करते समय, नियम भी होते हैं, टेम्पलेट होते हैं, फ्रेमवर्क होते हैं, लेकिन वे भिन्न होते हैं। उनका कार्य उन्हें परीक्षा कोड को जल्द से जल्द बनाने में सक्षम बनाना है, जो काम करेगा ... यह सिर्फ काम करेगा।
   
   ऑटोटेस्ट में अनुकूलन और निष्पादन की गति माध्यमिक बिंदु हैं और उन्हें तुरंत याद नहीं किया जाता है। इसलिए यदि आप अचानक कोटलिन, जावा, या किसी अन्य भाषा के साथ प्रयास करना चाहते हैं, लेकिन परियोजना पूरी तरह से अलग भाषा में लिखी गई है, जो आप चाहते हैं (उदाहरण के लिए, सी # में), तो आप ऑटोटेस्ट्स विकसित करके इसे अपने वांछित में बदल सकते हैं।
   
3. “मैं कैसे परीक्षण करूं? मैं इस बारे में कुछ नहीं समझता। मैं सिर्फ एक डेवलपर हूं। ” यहां, परीक्षक बचाव में आएंगे, या बल्कि क्यूए इंजीनियर जो उन सभी तकनीकों से अच्छी तरह वाकिफ हैं, जिन पर मुख्य उत्पाद लिखा है। अपने ज्ञान के लिए धन्यवाद, वे डेवलपर्स को यह समझने में मदद कर सकते हैं कि कैसे और क्या परीक्षण करना है, कैसे सही डेटा का चयन करना है, डेटा जनरेटर को अपने प्रकार से जोखिमों को कम करने के लिए क्या करना चाहिए और आपको बिल्कुल भी ध्यान नहीं देना चाहिए। इस तरह के अग्रानुक्रम में, परीक्षक अपने ज्ञान का सबसे अधिक उपयोग करते हैं, और डेवलपर्स अनावश्यक और अनावश्यक काम नहीं करते हैं।
   
4. “लेकिन गति के बारे में क्या? वह पीड़ित है! ” हां, वह परियोजना के विकास के शुरुआती चरणों में पीड़ित होगी, और हां, बिल्कुल शुरुआत से पूर्ण स्वचालन में डुबाना महंगा है। ऐसा क्या करें ताकि लागत इष्टतम हो? कम से कम, हमें स्पष्ट रूप से समझना चाहिए कि कैसे और क्या स्वचालित करना है। और यह समझ में नहीं आता है कि परीक्षण के साथ सब कुछ बंद न करें और कोड के 100% कवरेज के लिए प्रयास करें, लेकिन जोखिम मॉडल के आधार पर ऐसा करने के लिए। क्यूए इंजीनियर ही करेंगे।
   
5. "स्पीड! हम तेजी से पर्याप्त प्रसव करवाना चाहते हैं। हम भी विश्वसनीय होना चाहते हैं और हमारे उत्पाद त्रुटि मुक्त थे! " यहां मैं विकास के लिए दृष्टिकोण को बदलने का प्रस्ताव करता हूं। यदि यह स्थानीय रूप से डिबग मोड में सब कुछ चलाने के लिए फैशनेबल हुआ करता था, तो अब अक्सर गंभीर अनुप्रयोगों के लिए यह काम करने के लिए कुछ बुनियादी ढाँचा लेता है। यह वह जगह है जहाँ डॉक्यूरीकरण और विभिन्न स्टैंड के कार्यान्वयन के बारे में सभी नए रुझान अच्छी तरह से अनुकूल हैं। एक और बात महत्वपूर्ण है: यहां तक ​​कि बहुत पहले विकास के चरण में, आपको यह सोचने की ज़रूरत है कि इसे कैसे काम करने के लिए वितरित किया जाएगा, अर्थात्, न केवल हाथ से सब कुछ तैनात करें, बल्कि एक स्वचालित परिनियोजन प्रक्रिया सेट करें। यह हमें क्या देगा? जब उत्पादन के लिए वितरण का समय आता है, तो यह हमारे लिए केवल गणना बिंदु को बदलने के लिए पर्याप्त होगा, न कि पूरी प्रक्रिया को खरोंच से कॉन्फ़िगर करने के लिए। इससे डेवलपर को क्या मिलेगा? अधिक विश्वास है कि वह सब कुछ ठीक कर रहा है, क्योंकि डिलीवरी स्क्रिप्ट को एक से अधिक राउंड के लिए चेक किया गया है, और रिलीज के साथ कोई समस्या नहीं होनी चाहिए।
   

व्यापार

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

1. "क्या व्यवसाय के अनुरूप नहीं हो सकता है?" अक्सर, विकास यह भूल जाता है कि उत्पाद को न केवल विकसित किया जाना चाहिए, बल्कि बेचा भी जाना चाहिए, जिसके लिए बाजार में प्रवेश के लिए तैयार करने सहित उपायों के पर्याप्त बड़े सेट की आवश्यकता होती है। उत्पाद विकसित होने के बाद ऐसा करना एक गारंटीकृत विफलता है, यही वजह है कि बिक्री चैनल तैयार करने और एक नए उत्पाद को बढ़ावा देने का अधिकांश काम लगभग उसी क्षण शुरू होता है जब विकास शुरू होता है।
   
   “अगर विकास को रिलीज की तारीख देर हो गई तो क्या होगा? या क्या विकास बाजार में अपर्याप्त उच्च गुणवत्ता वाला उत्पाद लाएगा? ” नुकसान होगा। और न केवल सामग्री, बल्कि प्रतिष्ठित भी। व्यवसाय के लिए यह सुनिश्चित करना महत्वपूर्ण है कि समय पर बिक्री शुरू होने से, उत्पाद न केवल तैयार होगा, बल्कि उचित गुणवत्ता का भी होगा। यदि विकास की प्रक्रिया में परीक्षण के मैनुअल चरण हैं, तो अनिवार्य रूप से इन चरणों में व्यवधानों के जोखिमों को फिर से हल करने या ध्यान में रखना आवश्यक होगा। मानव कारक की भविष्यवाणी करना संभव है, लेकिन यह मुश्किल है और (मेरी राय) कोई कम खर्चीला नहीं है।
   
2. "व्यापार के बारे में और क्या परवाह है?" बेशक, वह विकास में पूंजी निवेश के बारे में चिंतित है। लेकिन अधिकांश हिस्सों के लिए पूंजी निवेश, हालांकि, शुरुआती स्तर पर किए जाते हैं, यानी। रिलीज से पहले, या कम से कम रिलीज से पहले, लागत बिक्री से ऑफसेट नहीं होती है। पूंजी निवेश के साथ, परिचालन खर्च भी होते हैं, जो परिचालन स्तर पर योगदान देना शुरू करते हैं और जितना संभव हो उतना उन्हें कम से कम करने की कोशिश करना महत्वपूर्ण है।
   
   "स्वचालन क्यों महंगा है (पूंजीगत व्यय के मामले में) इस मामले में मैनुअल दृष्टिकोण के संबंध में जीत?" मेरी राय एक स्पष्ट कारक है। स्वचालन एक ही विकास है। , . , , , , . , . यह महत्वपूर्ण क्यों है? . , , « , , , » , , .
   
3. — . , . , , . , .
   
   ? , - . . , , , . , , , , , . , .
   

मान लीजिए कि कोई व्यवसाय प्रक्रिया परिवर्तन की आवश्यकता से सहमत है और "यह सब एक बार में खरीदने के लिए तैयार है"। इसमें कितना खर्च आएगा और किन खर्चों को शामिल किया जाना चाहिए?

1. , , , , . : X Y , , , X Z , Z < Y. : , , ( ) .
   
2. — QA-. , «» . , QA- , , , . : , , , , , .
   — , . . , , , , , , , , , . .
   
3. — . , , . , , , , . , QA-. , . , , «» — , , , . , , .
   
4. , , — (, , - ). . , . , , , , , (), .
   

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

आगे बढ़ो। हमारे संदर्भ को न भूलें और परीक्षण फ़ंक्शन की संरचना को याद करें।

परीक्षकों

मौजूदा परीक्षण सुविधा का क्या होगा? यदि हम इस फ़ंक्शन की संरचना को फिर से देखते हैं, तो 90% निश्चितता के साथ हम यह कह सकते हैं कि पूरे ढांचे से 60% कर्मचारी फ़ंक्शन के नए रूप में उपयोगी नहीं होंगे, लेकिन कई BUT हैं।

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

«» , . «» , QA-. , — . , , ShiftLeft- QA- , - , QA- .

निश्चित रूप से, मैंने अभी तक इस व्यापक विषय में किसी भी प्रश्न का उत्तर नहीं दिया है। ये वे हैं जिन्हें मैं अभी तक नहीं समझ पाया हूं। आपकी टिप्पणियों की प्रतीक्षा है।