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

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

पैसे क्यों गिनें

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

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

यहां तर्क सरल है: व्यापार - बहुत ग्राहकों के लिए जो हमें अपनी कंपनियों के लिए सॉफ़्टवेयर विकास का आदेश देते हैं - वास्तव में, सॉफ़्टवेयर की बिल्कुल भी आवश्यकता नहीं है। व्यवसाय को धन की आवश्यकता होती है, इस सॉफ़्टवेयर को लाभ मिलेगा।

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

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

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

कौन सा परीक्षण अधिक लाभदायक है

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

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

एकीकरण परीक्षण - 2x-3x या अधिक इकाइयों का एक साथ परीक्षण। प्रोग्रामर के आधार पर किसी प्रोजेक्ट पर ऐसे सैकड़ों या हजारों परीक्षण हो सकते हैं। गति - पूरे परीक्षण सूट के लिए सेकंड या मिनट। इकाई परीक्षणों की तुलना में लागत अधिक है।

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

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

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

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

विभिन्न प्रकार के स्वचालित परीक्षण के लिए, विचार करने के लिए तीन और महत्वपूर्ण पहलू हैं।

सबसे पहले, यह विश्वसनीयता है - परीक्षण को तोड़ना कितना आसान है (यह इकाई परीक्षणों के लिए सबसे अच्छा संकेतक है)।

फिर परीक्षण चलाने के लिए जो वातावरण चाहिए। यूनिट परीक्षण बहुत सरल हैं, वे स्वयं परीक्षण के तहत यूनिट के आसपास एक वातावरण बनाते हैं। एकीकरण परीक्षणों के लिए एक ऐसी सेवा की आवश्यकता होती है जिसे स्थापित किया जाना चाहिए, चलाना आदि स्वीकृति परीक्षणों के लिए तैयारी की आवश्यकता होती है, क्योंकि आवेदन को अपने वातावरण में काम करना चाहिए।

और अंत में - कवरेज (परीक्षण कवरेज)। यूनिट परीक्षणों में अच्छा कवरेज है और पूरे प्रोजेक्ट में उपयोग किया जाता है। एकीकरण परीक्षण आमतौर पर परियोजना के कुछ हिस्सों पर उपयोग किया जाता है, अर्थात, वे पूरी तरह से कार्यक्रम को कवर नहीं करते हैं। स्वीकृति परीक्षणों का कवरेज बदतर है - यह लिखने और उन्हें चलाने की जटिलता के कारण है, अक्सर वे मुख्य व्यवसाय मामलों को कवर करते हैं, यह कुल परियोजना मात्रा का 20-40% है।

निष्कर्ष

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

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