सॉफ्टवेयर रखरखाव पर परीक्षक का दृष्टिकोण

मैं सॉफ्टवेयर के गुणों में से एक पर अपने विचार साझा करना चाहता हूं: स्थिरता।



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

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

आप एक इमारत में इलेक्ट्रिक्स बिछाने के साथ एक सादृश्य दे सकते हैं:

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

एक परीक्षक के रूप में, मैं आपको स्थिरता बनाए रखने के लिए निम्नलिखित पहलुओं पर ध्यान देने की पेशकश कर सकता हूं।

कार्यात्मकता प्रलेखन।

दस्तावेज़ीकरण की आवश्यकता न केवल "उपयोगकर्ताओं को कहीं बाहर है", बल्कि यह भी है कि दोपहर 12 बजे कोई भी व्यक्ति जो उत्पाद से अपरिचित है, दूसरों से मदद के बिना इसका उपयोग कर सकता है। उदाहरण के लिए:

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

इन्फ्रास्ट्रक्चर प्रलेखन

उत्पाद बनाने के लिए कई उपकरणों का उपयोग करने की संभावना है। उनमें से:

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

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

समस्याओं और जोखिमों का दस्तावेजीकरण

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

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

यदि विकास ऐसी जानकारी का खुलासा करता है कि भविष्य में समस्याएं उत्पन्न हो सकती हैं, तो ऐसी जानकारी को जोखिम के रूप में वर्णित किया जाना चाहिए। उदाहरण के लिए, यदि एक मॉड्यूल 100 उपयोगकर्ताओं के साथ एक प्रणाली में उपयोग किया जाता है, तो यह संभवतः 500 उपयोगकर्ताओं के साथ टूट जाएगा।

टिप्पणियाँ और कोड विवरण

सभी वास्तुशिल्प योजनाओं सहित सभी मॉड्यूल के तकनीकी विवरण के साथ एक दस्तावेज हो सकता है।

प्रयुक्त उपकरणों पर जानकारी

उदाहरण के लिए, डिबगिंग और परीक्षण के लिए कौन से उपकरण और कैसे उपयोग करें।

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

इसमें उपकरण के प्रचलन पर ध्यान देना शामिल है। भले ही कुछ उपकरण हाथ में कार्य के लिए अच्छी तरह से अनुकूल हैं, लेकिन यह पुराना है और समर्थित नहीं है, यह मुश्किल हो सकता है।

कार्य पूर्ण होना

जैसा कि पेरेटो सिद्धांत कहता है: 20% काम पूरा करने में 80% समय लगता है।

और अगर कुछ पूरा नहीं हुआ है, तो एक कारण रहा होगा। सबसे अधिक संभावना है, यह महंगा था।