परीक्षण: लत्ता से धन के लिए

प्रस्तावना

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

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

एक बार की बात है

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

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

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

साल बीत गए

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

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

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

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

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

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

कल

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

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

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

एक तरफ, मैंने देखा कि कैसे कभी-कभी परीक्षकों के फल महत्वहीन होते हैं और क्यों जब परीक्षक दिल से पीएम को चिल्लाता है "मेरे पास ओपेरा में एक महत्वपूर्ण बग है, तो इसे जारी करना असंभव है", अपने हाथ से अपने चेहरे को कवर करते हुए, वह कहता है "यह आवश्यक है!" आज भी भागीदारों के साथ बातचीत, ग्राहकों के साथ पदोन्नति की चर्चा, मॉडरेशन के लिए 20,000 सामग्री इकाइयाँ, 3 कार्य निर्धारित करना और अगले सप्ताह के लिए 6 सुविधाएँ काम करना शामिल हैं।

गीतात्मक विषयांतर:

“जब मैं परियोजना का प्रबंधन करने के लिए आया था, तो मैंने टिकट प्रणाली में 500 टिकटों को खुद को सौंपा, जिनमें बग्स भी शामिल थे जिन्हें मैंने एक बार 2-3 साल पहले एक परीक्षक के रूप में सेट किया था। पहली बात मैंने इन बगों के साथ किया ... प्राथमिकता को कम कर दिया। आखिरकार, अगर परियोजना 2-3 वर्षों के लिए इन बगों के साथ रहती थी, तो वे वास्तव में राजनीतिक नहीं हैं। "

दूसरी ओर, ऐसे विपरीत मामले थे जब अपर्याप्त परीक्षण गहराई या स्वचालन की कमी के कारण साइट को भारी धन की कमी हुई या आधे दिन के लिए गिर गया, जो कि 100k मेजबानों के दर्शकों के साथ एक परियोजना के लिए अस्वीकार्य था।

उदाहरण के लिए, ऐसे मामले थे

"1 मार्च को 00:00 बजे से, साइट 12 बजे तक नीचे चली गई (डेवलपर द्वारा फिक्स करने से पहले) इस तथ्य के कारण कि उपयोगकर्ता का व्यक्तिगत कार्ड 30-31 फरवरी को जन्म की नकली तारीख का संकेत दे सकता है, जो कि भाग्य की इच्छा से ब्लॉक में उपयोगकर्ता नाम आउटपुट प्रोसेसर द्वारा गलत तरीके से मान्य किया गया था। "आज का जन्मदिन है:", जिसने स्पष्ट रूप से 1 मार्च को जन्मों की सूची में कटौती की और मुख्य पृष्ठ पर सीमित संख्या में उपयोगकर्ता नाम प्रदर्शित किए, लेकिन इस तारीख को स्थानांतरित किए गए फ़ेक में कटौती नहीं की, सॉफ्टवेयर संघर्ष आसानी से गिरने और डेवलपर के आने से पहले न उठने का फैसला किया। "

"अचानक यह पता चला कि डेटा संग्रहीत करने के लिए हमारा वितरित सर्वर सिस्टम विफल हो गया और" पी "अक्षर वाले खातों का पंजीकरण बंद हो गया। सब कुछ ठीक होगा, लेकिन हमारे पास प्रति दिन 4,500 पंजीकरण थे। यानी औसतन आंकड़ों के अनुसार, हर दिन 200 लोगों को पंजीकरण के दौरान एक अकथनीय समस्या का सामना करना पड़ा, अगर हम यह मान लें कि आधे बाएं (100 लोग), कंपनी को रोजाना $ 30 का नुकसान होता है, क्योंकि आंकड़ों के अनुसार, हर तीसरे व्यक्ति ने पंजीकरण के दौरान "$ 1 के लिए प्रीमियम खाता" खरीदा। । नुकसान कम हैं, लेकिन इस क्षेत्र में ऑटोटैस्ट्स के कवरेज की अपूर्णता के कारण, इस बग का केवल छह महीने बाद पता चला ... इस तरह के एक तिपहिया पर, कंपनी ने लगभग $ 5000 खो दिए

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

फ्रीलांस के लिए बहुत अधिक ऑर्डर थे, अब कंपनियों को एहसास हुआ कि परीक्षक टीम को लेने से वे छवि और वित्तीय नुकसान से भी बचते हैं (टेस्ट सर्वर पर कोड अपलोड करने के आधे घंटे बाद बग को ठीक करने के लिए यह एक चीज है, ग्राहक की लाइव परियोजना पर इसे ठीक करने के लिए एक और बात है। वास्तव में पहले से ही वितरित किया गया है)।

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

आज

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

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

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

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

कल हमें क्या इंतजार है?

मैं एक soothsayer नहीं हूँ, मैंने केवल पेशे में अपने विकास के रास्ते के साथ परीक्षण के विकास का एक छोटा सा ऐतिहासिक खंड बनाया है। इसलिए, मैं प्रसिद्ध फिल्म से शब्द कहूंगा:

"भविष्य पूर्व निर्धारित नहीं है और इसके अलावा कोई अन्य भाग्य नहीं है जो हम बनाते हैं।"