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