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

कुछ समय के लिए मैं इस विचार के साथ रहा, कार्यों में सेटिंग के दौरान कार्यों की एक चेकलिस्ट लिखी, "फीचर-टीम" की बैठकें आयोजित कीं, जिसमें कार्यान्वयन से पहले कार्य की बारीकियों पर चर्चा करने के लिए पीएम, क्यूए, फ्रंटेंड और बैकेंड को आमंत्रित किया गया था।

जो लोग समझते हैं कि वे किस बारे में बात कर रहे हैं, उन्होंने पहले ही पकड़ पर ध्यान दिया है, वे नहीं हैं?

यदि आप जानते हैं कि "चुस्त परीक्षण" क्या है, तो आप पाठ्यक्रम लेने के लिए सुझाव के साथ आ सकते हैं, लेख के कुछ दृष्टिकोण और विकिपीडिया पर दृष्टिकोण।

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

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

हमारा कार्य प्रवाह कैसे व्यवस्थित था

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

1. ग्राहक से बयान (मान पीएम)

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

2. परीक्षक द्वारा समस्या के बयान की समीक्षा

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

3. सभी इच्छुक या "फीचर-टीम" द्वारा कार्य की चर्चा

मंच को आवश्यकतानुसार चलाया गया। यदि समीक्षा के बाद, परीक्षक ने फैसला किया कि कार्य स्पष्ट है और अतिरिक्त चर्चा की आवश्यकता नहीं है, तो हम चौथे पैराग्राफ पर आगे बढ़े।

यदि मंच आवश्यक था, तो बैठक में आवश्यकताओं, अतिरिक्त कार्य पर स्पष्टता प्रदान की गई थी। अक्सर कार्य को विघटित कर दिया गया था, फ्रंटेंड और बैकेंड के स्वतंत्र संचालन के दौरान परीक्षण की स्थिति पर चर्चा की गई थी।

4. एक बैकलॉग में काम किया गया, योजना बनाई गई, बाहर किया गया, लुढ़का और लाभ और खुशी मिली

ऐसा लगता है कि सब कुछ इतना बुरा नहीं है, लेकिन सुधार करने के लिए कुछ है: कम से कम, आप कुछ अतिरिक्त कदम निकाल सकते हैं, क्योंकि हम यह नहीं समझते हैं कि वे क्यों हैं।

सुधार के लिए क्या किया गया है

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

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

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

इस विषय पर क्या पढ़ें

“चुस्त परीक्षण। संपूर्ण टीम के लिए प्रशिक्षण पाठ्यक्रम, “जेनेट ग्रेगरी और लिसा क्रिस्पिन। पुस्तक हाल ही में रूसी अनुवाद में प्रकाशित हुई है और ओजोन पर उपलब्ध है।

वास्तव में क्या बदल गया है

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

आपको किन कठिनाइयों का सामना करना पड़ा?

1. एक इकाई परीक्षण क्या है

हमें इस तथ्य का सामना करना पड़ रहा है कि हम, क्यूए, यह नहीं समझ रहे हैं कि यूनिट परीक्षण क्या परीक्षण कर रहे हैं और इसलिए उन पर भरोसा नहीं करते हैं, और हमारी सतर्कता के लिए, हम परीक्षण को एक उच्च स्तर पर लिखते हैं और एक ऊँची एड़ी के जूते के साथ "स्वचालित करने के लिए, आप दया नहीं करेंगे"।

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

एक चयनित तीर - एक यात्रा - इकाई परीक्षण में एक जांच

नतीजतन, कुछ महीनों के बाद, मैं खुद एक छोटी इकाई परीक्षण लिखता हूं और ऊपरी स्तरों पर अनावश्यक जांच हटाता हूं। यह, ज़ाहिर है, मुख्य रूप से कॉपी-पेस्ट है, लेकिन सचेत!

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

2. वर्तमान कार्यान्वयन में, सभी परीक्षणों को संशोधनों के बिना छोड़ा नहीं जा सकता है

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

निष्कर्ष

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

  
  

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

  
  

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

• सामान्य तौर पर, चंचल परीक्षण दृष्टिकोण और इसमें प्रस्तावित मूल्य, सिद्धांत और व्यवहार काफी स्पष्ट चीजों का पालन करते हैं, जैसा कि उच्च बीजगणित में मेरे पसंदीदा शिक्षक ने कहा: "लेकिन यहां सामान्य ज्ञान को लागू करना आवश्यक है।" यह निम्नलिखित के लायक है, और न केवल परीक्षण में।

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

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