😪 😊 🐗 जल्दी से उठाया नहीं गिर माना जाता है 🧖🏻 🐚 🛸

यह दो अलग-अलग मामलों में कठोर सॉफ्टवेयर परीक्षण के महत्व पर ध्यान केंद्रित करेगा:

जब आगे उत्पाद समर्थन मुश्किल है
जब उत्पाद विकास और समर्थन को एक ही प्रक्रिया में मिला दिया जाता है

सुविधा के लिए, मैं पहला विकल्प "ऑफ़लाइन", और दूसरा - "ऑनलाइन" कहूंगा।

लेख का मुख्य विचार यह है कि "ऑफ़लाइन" विकल्प के लिए, गुणवत्ता परीक्षण की उपलब्धता "ऑनलाइन" विकल्प के लिए महत्वपूर्ण है, एक अच्छी तरह से स्थापित विकास प्रक्रिया पूरी तरह से परीक्षण से अधिक महत्वपूर्ण है ।

मैं कुछ उदाहरण दूंगा।

विकल्प "ऑफ़लाइन"

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

"ऑनलाइन" विकल्प एक परियोजना है जिस पर डेवलपर्स लगातार काम करते हैं और अपडेट स्वचालित रूप से उपयोगकर्ताओं को मिलते हैं

क्रोम ब्राउज़र (लगातार स्वचालित रूप से अद्यतन);
फेसबुक, लाइवजर्नल (डेवलपर्स लगातार वहां कुछ बदल रहे हैं);
जीमेल।

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

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

ऐसा लगता है कि ठीक यही कारण है कि फेसबुक जैसे उत्पादों में डेवलपर्स विश्वसनीय इकाई परीक्षणों के साथ पूरे कोड को कवर करने की तलाश नहीं करते हैं (मैंने हाल ही में इसके बारे में हैबे पर पढ़ा है)।

व्यक्तिगत अनुभव से थोड़ा सा:

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

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

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

जल्दी से उठाया नहीं गिर माना जाता है

More articles: