जुलाई के लिए "परीक्षक कैलेंडर"। विश्लेषिकी परीक्षण

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





विश्लेषिकी परीक्षण वर्कफ़्लो मॉडल


मॉडल 1


समाप्त कार्य दिए जाने के बाद परीक्षक एनालिटिक्स के साथ काम करता है। वह डेवलपर द्वारा किए गए कार्यों के प्रलेखन के रूप में एनालिटिक्स को पढ़कर कार्य को मान्य करता है। व्यावसायिकता के स्तर की परवाह किए बिना, सब कुछ गलत है। दोष एनालिटिक्स या डेवलपर कोड में हो सकते हैं।


विपक्ष:


  • परीक्षण चरण से पहले विश्लेषिकी में दोषों का पता नहीं लगाया जाएगा,
  • एक जोखिम है कि परीक्षण से कार्य पुनरीक्षण के लिए विश्लेषण पर वापस जाएगा। परिणामस्वरूप, TimeToMarket कार्य में काफी वृद्धि होती है।

परीक्षण के दौरान पहचानी गई विश्लेषिकी त्रुटियां महंगी या बहुत महंगी हैं।

पेशेवरों:


  • परीक्षक का समय उन कार्यों के लिए कम हो जाता है जहाँ विश्लेषक की आवश्यकता नहीं होती है (अवसंरचना, रीफैक्टरिंग)।

मॉडल 2


परीक्षक को विकास से स्थानांतरित करने से पहले ही कार्य से जोड़ा जाता है। वह एक कार्य पर प्रोटोटाइप को देखता है या सिर्फ प्रलेखन पढ़ता है। परीक्षक कार्य पर सभी प्रश्नों के विश्लेषक से पूछता है। विश्लेषक तुरंत टिप्पणियों को सही करता है। परीक्षक स्वीकृति परीक्षण करता है।


विपक्ष:


  • परीक्षक को निकटवर्ती क्षेत्र (डिजाइनिंग एनालिटिक्स और TK) का अध्ययन करना होगा,
  • इस मॉडल पर स्विच करने से, परीक्षक को पहले अधिक समय परीक्षण करना होगा, क्योंकि प्रक्रिया "समाप्त कार्य आ गया है - मैं विश्लेषण पढ़ता हूं - मैं भविष्य के कार्य के विवरण के लिए" स्ट्रेच "कर रहा हूं - मैं एनालिटिक्स पढ़ता हूं - मैं अर्थशास्त्र का परीक्षण कर रहा हूं - समाप्त कार्य आया - मैं परीक्षण कर रहा हूं"।

पेशेवरों:


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

यदि विकास टीम के पास विश्लेषकों के काम की समीक्षा नहीं है, तो परीक्षण विश्लेषिकी उत्पाद की गुणवत्ता में सुधार करती है और ToR में त्रुटियों के साथ विकास के कार्यों को स्थानांतरित करने के जोखिम को कम करती है।


जब हमने पहले मॉडल पर काम करने वाले परीक्षकों के लिए दूसरे मॉडल की सिफारिश की, तो हमने अक्सर सुना:


  • "हमारे पास लाइन में है और इसलिए अधिक लेने के लिए पर्याप्त वर्तमान कार्य हैं।"
  • "प्रबंधक से बात करें।"

विकास प्रक्रिया को नया स्वरूप देना एक गंभीर प्रबंधकीय कार्य है।

विकास से पहले विश्लेषिकी परीक्षण को लागू करें


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


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


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


स्टेज 0. टीम को परीक्षण विश्लेषिकी का विचार बेचें


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


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


जब चरण 0 पूरा हो जाता है, तो आप आगे बढ़ सकते हैं।


चरण 1. विकास प्रक्रिया में विश्लेषिकी परीक्षण का कार्यान्वयन


टीम को समझाने के बाद, हम एनालिटिक्स परीक्षण को दैनिक वर्कफ़्लो में पेश करना शुरू करते हैं। यदि शुरू में वर्कफ़्लो इस तरह दिखता था:



कार्यान्वयन के बाद:



यदि आपकी टीम में कई विश्लेषक हैं जो विकास को कार्य देने से पहले एक दूसरे की समीक्षा करते हैं, तो हम एक बेहतर पाठ का परीक्षण करने के लिए आगे बढ़ते हैं। हमारा मतलब है कि एनालिटिक्स समीक्षा इसका परीक्षण नहीं कर रही है, बल्कि इसका केवल एक हिस्सा है।


चरण 2. परीक्षण विश्लेषण


ऐसे कार्य हैं जब प्रोटोटाइप एनालिटिक्स के टेक्स्ट संस्करण को प्रतिस्थापित करते हैं।


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


क्या विश्लेषण में जाँच की जा सकती है:


1. प्रस्तावित समाधान कार्य के उद्देश्यों को पूरा करता है।


उदाहरण के लिए, यदि कार्य का लक्ष्य उपयोगकर्ताओं से प्रतिक्रिया एकत्र करना है, तो समाधान में उपयोगकर्ता प्रतिक्रियाओं की रिकॉर्डिंग और भंडारण शामिल होना चाहिए।


2. व्याख्या की विशिष्टता।


उदाहरण के लिए, शब्द "वर्तमान दिन के लिए जानकारी दिखाएं" की व्याख्या अलग तरीके से की जा सकती है। आप समझ सकते हैं कि "सेटिंग्स में चयनित दिन के लिए जानकारी कैसे दिखाएं" या "आज के दिन के लिए दिन की जानकारी दिखाएं" के रूप में।


3. निर्णय की व्यवहार्यता।


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


4.Testiruemost।


यह कैसे सत्यापित किया जाए कि "खोज परिणामों में सुधार" की स्थिति स्पष्ट नहीं है। लेकिन अगर हम "खोज परिणाम" को नियंत्रण "दबाने" के बाद 1 सेकंड के भीतर उपयोगकर्ता को दिखाया जाना चाहिए - यह स्पष्ट है।


5. वैकल्पिक परिदृश्यों की उपलब्धता।


शब्दांकन में “यदि संख्या और दिनांक इंगित की जाती है, तो हम संख्या और दिनांक प्रिंट करते हैं। यदि तारीख निर्दिष्ट नहीं है, तो हम केवल संख्या प्रिंट करते हैं "पर्याप्त स्क्रिप्ट नहीं हैं:


  • कोई संख्या नहीं है, लेकिन एक तारीख है,
  • कोई डेटा नहीं।

6. अपवाद हैंडलिंग।


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


विश्लेषिकी परीक्षण करते समय कलाकृतियाँ


विश्लेषण के परीक्षण के बाद क्या कलाकृतियाँ रह सकती हैं:


  • संकलित परीक्षण के मामले
  • डेवलपर्स के लिए जाँच सूची।

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


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


परिणाम क्या है?


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


यह विश्लेषिकी परीक्षण प्रक्रिया कई कंटूर टीमों में लागू की गई है। विकास टीमों को कई निर्विवाद लाभ मिले:


  • परीक्षण के चरण में समय की बचत: परीक्षण डिजाइन और परीक्षण विश्लेषिकी की कोई कीमत नहीं है, क्योंकि सब कुछ पहले से ही किया जा चुका है,
  • चेकबेल के माध्यम से डेवलपर को त्वरित प्रतिक्रिया, महत्वपूर्ण कीड़े मिलने से पहले,
  • सभी इच्छुक पार्टियाँ जाँचकर्ताओं को पूर्व-जाँच कर सकती हैं और कुछ जाँचें जोड़ सकती हैं (परीक्षण के चरण में यह क्रिया "अधिक महंगी" है)।

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


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

Source: https://habr.com/ru/post/hi417287/


All Articles