एक प्रोग्रामर के जीवन में परीक्षण

प्रोग्रामर को परीक्षण की आवश्यकता क्यों है?

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

सॉफ़्टवेयर के संबंध में, हम कह सकते हैं कि परीक्षण का कार्य यह जाँचना है कि प्रोग्राम:

• वह करती है जो उसे करना है
• वह नहीं करती जो उसे नहीं करना चाहिए

दूसरा बिंदु, पहले से कम महत्वपूर्ण नहीं है, लेकिन बाद में उस पर अधिक।

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

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

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

इसलिए, हमें एक नया तथ्य मिलता है: सॉफ्टवेयर की ख़ासियत यह है कि इसमें कई अलग-अलग कार्य परिदृश्य हैं। उनमें से कुछ स्पष्ट हैं, अन्य को प्रलेखित किया जा सकता है, अन्य को ग्रहण किया जा सकता है, अन्य का अनुमान लगाया जा सकता है, और अन्य 50% आपके दिमाग में भी नहीं आएंगे।

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

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

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

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

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

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

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

याद रखें, किसी समस्या को हल करने का पहला कदम यह स्वीकार करना है कि कोई समस्या है । आप उस गलती को ठीक नहीं कर सकते जिसके बारे में आप नहीं जानते।

परीक्षण स्वचालन

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

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

सॉफ्टवेयर विकास प्रक्रिया में इसमें निरंतर परिवर्तन होते हैं। लगातार बदलाव करने की प्रक्रिया में, प्रोग्रामर अक्सर कुछ ऐसा तोड़ देते हैं जो हाल तक ठीक काम करता था।

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

यहाँ सभी सॉफ्टवेयर को दो भागों में विभाजित किया जा सकता है:

• कार्यक्रम व्यक्ति के साथ बातचीत करता है
• प्रोग्राम दूसरे प्रोग्राम के साथ इंटरैक्ट करता है

पहला विकल्प स्वचालित करना अधिक कठिन है, इसके लिए विशेष ऑटोमेटर परीक्षकों की आवश्यकता होती है, उन्हें क्यूए ऑटोमेशन या सॉफ्टवेयर टेस्ट इंजीनियर भी कहा जाता है।

लेकिन दूसरा विकल्प स्वतंत्र रूप से स्वचालित हो सकता है और होना चाहिए। यदि आपके पास सॉफ़्टवेयर का एक टुकड़ा है जो:

• अच्छी तरह से काम करता हुँ
• पहले से ही परीक्षण किया
• एक अलग मॉड्यूल या तार्किक ब्लॉक के रूप में लागू किया गया
• बदलने की योजना नहीं बना रहा है
• अन्य मॉड्यूल या प्रोग्राम इस पर निर्भर करते हैं
• कार्यात्मक विफलता महंगी है

मैं इसके लिए परीक्षण लिखने के लिए समय निकालने की सलाह देता हूं जो इसकी वर्तमान कार्यक्षमता के प्रमुख पहलुओं को कैप्चर करता है। इसके लिए अपने कार्य समय का 5% , या प्रति माह 1 दिन आवंटित करना उचित होगा।

परीक्षणों के लिए परीक्षण लिखने की आवश्यकता नहीं है।

कोई भी आपके परीक्षणों का समर्थन नहीं करेगा। अन्य प्रोग्रामर नहीं, स्वयं नहीं। ऐसा कोई नहीं करता। सभी लिखित परीक्षाओं में से 99% परित्यक्त और/या अक्षम हैं। यदि आप परीक्षण नहीं लिख सकते - मत लिखो। केवल तभी लिखें जब आप उनके बिना बिल्कुल नहीं कर सकते।

परीक्षण के प्रकार

प्रत्येक प्रोग्रामर, यदि उसने विशेष प्रशिक्षण नहीं लिया है, तो वह अपने शब्दों में बता सकेगा कि परीक्षण क्या है: यह जाँचना कि क्या कार्यक्रम वह करता है जो उसे करना चाहिए। हालांकि, इस क्षेत्र के पेशेवर परीक्षण के पूरे क्षेत्रों (प्रकारों) को अलग करते हैं।

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

मान लें कि आप एक विशिष्ट ऑनलाइन स्टोर का परीक्षण कर रहे हैं। फिर परीक्षण के क्षेत्रों को निम्न प्रकारों में विभाजित किया जा सकता है: प्रदर्शन परीक्षण, कार्यात्मक परीक्षण, एकीकरण परीक्षण और इकाई परीक्षण।

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

ऐसा होने से रोकने के लिए, आपको ऐसी समस्याओं की पहले से पहचान करने और उन्हें खत्म करने के लिए कदम उठाने की आवश्यकता है। यह लोड परीक्षण का उपयोग करके किया जाता है , या इसे प्रदर्शन परीक्षण भी कहा जाता है।

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

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

अंत में, जटिल उत्पाद अक्सर स्वतंत्र मॉड्यूल में टूट जाते हैं। ऐसे मॉड्यूल से, आप अंतिम उत्पाद को एक कंस्ट्रक्टर के रूप में इकट्ठा कर सकते हैं। यदि आप ऐसा मॉड्यूल विकसित कर रहे हैं या ऐसे मॉड्यूल के साथ इंटरैक्ट कर रहे हैं, तो आपको यूनिट परीक्षण करने की आवश्यकता होगी ।

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

परीक्षण के और भी प्रकार हो सकते हैं: उत्पाद जितना जटिल होगा, उसके विकास के उतने ही अधिक पहलुओं को नियंत्रित करने की आवश्यकता होगी।