परीक्षण के खिलाफ परीक्षक

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

ये रही बात। व्यावसायिक विचारों को लागू करने की गति एक महत्वपूर्ण कारक बन गई है। एसजे में यह गति कार्य को पूरा करने के लिए लिए गए औसत समय से अनुमानित है। कंपनी में यह समय 65 दिनों के बराबर था। हां, उपयोगकर्ता को भेजने के लिए एक कार्य बनाने से 2 महीने।

एंटन का कहना है कि वे सचेत परीक्षण के कारण प्रक्रियाओं को 3 गुना तेज करने में सक्षम थे। अब हम आपको बताएंगे कि यह क्या है और वास्तव में कैसा है।

यह पहले कैसे था?

प्रक्रिया इस प्रकार थी:

• 40 डेवलपर्स के लिए 5 परीक्षक;

• प्रत्येक कार्य का अलग-अलग परीक्षण किया जाता है;

• समाप्त कार्य रिलीज़ शाखा में विलय हो जाते हैं;

• रिलीज पर, स्वीकृति परीक्षण किया जाता है;
  फिर एकीकरण।
  

यदि परिणाम सफल रहा, तो उपयोगकर्ताओं को रिलीज़ भेज दिया गया, और परीक्षण की प्रतीक्षा कर रहे 50-60 कार्य लगातार बोर्ड पर लटके हुए थे।

आपने कार्य कैसे किया:

• विकास से, कार्य परीक्षण में आ गया और दूसरों की प्रतीक्षा की अथाह सूची में खो गया;

• सूची में, वह कुछ दिनों से लेकर एक महीने तक गा सकती है;

• तब परीक्षक द्वारा कार्य की जांच की गई, उस पर कीड़े बनाए गए और इसे वापस विकास में भेजा गया;

• प्रोग्रामर ने बग्स को ठीक किया और एक परीक्षण के लिए फिर से काम वापस कर दिया।

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

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

क्यों नहीं?

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

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

गंभीरता से, यह सप्ताह में 2 बार मैनुअल चेक के 1.5 दिनों का है। बार-बार मैनुअल जांच के साथ क्या किया जाना चाहिए? स्वचालित।

यह 100 मामलों को स्वचालित करने के लिए निकला। स्वचालन पर साझा करने, पत्र भेजने, एसएमएस प्राप्त करने के लिए लाभहीन मामले, लाभहीन रहे। परीक्षक प्रसन्न थे, क्योंकि परीक्षण के रिलीज के लिए कम नियमित लागतें थीं - 1.5 घंटे के बजाय 3 घंटे। दूसरे, ऑटोटैस्ट त्वरित प्रतिक्रिया देते हैं कि क्या कोई रिलीज देखना शुरू करना है और किसी कार्य को रिलीज होने से पहले ही बग को पकड़ने देना है।
लगभग सब कुछ तय हो गया था, लेकिन फिर सीटीओ आया।

और क्या गलत है?

उन्होंने आकर कहा कि हमें यह देखने की जरूरत है कि काम के घंटों का ओवरडोज अब भी कहां है। लोगों ने बैठकर महसूस किया कि दोहराए जाने वाले कार्य केवल रिलीज पर थे - यह स्वीकृति और एकीकरण था।

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

देवोप ने स्क्रिप्ट बनाना शुरू कर दिया, और परीक्षक यह सुनिश्चित करने के लिए रिलीज़ के प्रत्येक कार्य के मामलों की दोबारा जाँच करते हैं कि सब कुछ एक साथ चला गया है और सभी कार्य यथावत हैं। ऐसा लगता है कि उन कार्यों की जांच करना मुश्किल है जो पहले से ही देख चुके हैं। लेकिन यह पता चला कि रिलीज में प्रत्येक परीक्षक के लिए लगभग 5 कार्य थे, और जटिल मामले सामने आए, जैसे डेटाबेस में कुछ बदलना, स्क्रिप्ट चलाना, प्राप्त पत्र की जांच करना। इस पूरे चरण में बहुत समय लगा: सभी परीक्षकों के काम के 2 से 10 घंटे तक।

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

अब ठीक है?

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

और क्या? व्यवसाय से बहुत अधिक हॉटफ़िक्स। व्यवसाय ने कुछ तारीख के लिए एक फीचर जारी करने की योजना बनाई थी, इसकी घोषणा की और एक विज्ञापन लॉन्च किया, और परीक्षक थे: "लिटर, गे, हमने यहां रिलीज की योजना बनाई है और यह कार्य अगले सप्ताह ही समाप्त होगा।" इसलिए, ऐसे प्रत्येक कार्य के लिए, उत्पाद दीमा ने उनका सहारा लिया।

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

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

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

और कैसा है?

समय बचाएं - नए कार्यों का परीक्षण करने के लिए सप्ताह में 12 घंटे, नीरस जांच पर कम डिमोटेशन। Minuses की - कीड़े दिखने की तारीख से 5 दिनों तक रह सकते हैं। बहुत तेजी से सफलतापूर्वक किया गया है, लेकिन एक ही समय में, लोगों को सबसे महत्वपूर्ण बात पर बहुत कम प्रभाव पड़ा है - उत्पादन पर एक कार्य पूरा करने के लिए लिया गया औसत समय।

वे लक्ष्य की ओर आगे बढ़े, लेकिन उस तक नहीं पहुंचे। हां, परीक्षक अपना समय नए कार्यों के लिए समर्पित कर सकते थे, लेकिन मार्ग की गति के लिए यह बाल्टी में एक बूंद थी।

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

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

संक्षेप में, 300 वस्तुओं की सूची से केवल 50 ही बचे हैं।

आप पहले से ही इसके साथ काम कर सकते हैं। वैसे, वेब विकास क्या बोनस देता है?

• लड़ाई में पाए जाने वाले कीड़े को जल्दी से प्रतिक्रिया करने की क्षमता;

• समस्याओं की ऑनलाइन निगरानी;

• उपयोगकर्ताओं के साथ संपर्क में तकनीकी सहायता।

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

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

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

परीक्षण करने में विफलता एक जिम्मेदार और खतरनाक कदम है।

अगर आप भी ऐसा करना चाहते हैं:

• महत्वपूर्ण कार्यक्षमता की सूची सार्वजनिक रूप से उपलब्ध है ताकि डेवलपर्स इसे एक्सेस कर सकें;

• नए दृष्टिकोण का मूल्यांकन करने के लिए, जीरा को "= = उत्पन्न में संबंध" जोड़ें। तो आप ट्रैक कर सकते हैं कि कितने कीड़े अप्राप्य कार्यों से गुजरते हैं;

• चूंकि यह अधिकांश कार्यों का परीक्षण करने के लिए बेतहाशा गूंगा नहीं है, इसलिए उनमें से कुछ मुख्य मामलों की जांच करें, लेकिन रिलीज में ताकि डालना धीमा न हो;

• पुरानी योजना के अनुसार परीक्षण करने के लिए महत्वपूर्ण कार्यक्षमता।

क्या बदलेगा?

• अधिकांश कार्य परीक्षण चरण के दौरान स्किडिंग को रोक देंगे;

• परीक्षक केवल व्यवसाय-महत्वपूर्ण कार्यों से निपटेंगे;

• महत्वपूर्ण बात तेजी से परीक्षण में लिया जाता है, क्योंकि महत्वहीन अब बोर्ड में हस्तक्षेप नहीं करता है।

इतना बुरा क्या है

• वास्तविक उपयोगकर्ताओं को छोटी त्रुटियों का सामना करने की अधिक संभावना है;

• तकनीकी सहायता पर भार बढ़ रहा है, क्योंकि उपयोगकर्ताओं से मिस्ड बग आना शुरू हो जाते हैं।

क्या यह चोट लगी थी?

लोगों ने छह महीने के भीतर वर्णित सभी चरणों को पूरा किया। हां, यह चोट लगी है, लेकिन आउटपुट निम्नलिखित था:

किसी कार्य को पूरा करने के लिए लिया गया औसत समय 19 दिनों तक कम हो गया था और यह लगातार घट रहा है;
परीक्षण कार्यों का प्रवाह कम हो गया है। विकास के साथ समानांतर में महत्वपूर्ण विशेषताओं के परीक्षण के लिए परीक्षकों ने तैयारी शुरू की;
उत्पाद डिमा ने एंटोन में जाना पूरी तरह से बंद कर दिया।

निष्कर्ष के बजाय

दवा या विमान निर्माण में हमारे दृष्टिकोण का उपयोग न करें। ऐसी स्थितियों में जो जीवन के लिए जोखिम से जुड़ी नहीं हैं - अपने निर्णयों और दृष्टिकोण का परीक्षण करें।

पुस्तकों पर विश्वास न करें और परीक्षण के लिए परीक्षण रोक दें, केवल इसलिए कि यह कहीं लिखा गया है।

अपने आप से पूछें कि क्या आप व्यवसाय की अपेक्षाओं को पूरा करते हैं और क्या आपकी टू-डू सूची में प्रत्येक वस्तु वास्तव में उपयोगी है।

सुपरजोब आपके साथ था। सभी को जागरूकता!