क्या गैर-मिशन महत्वपूर्ण सामान के लिए एंड-टू-एंड और एकीकरण परीक्षण इसके लायक हैं?

Question

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

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

मुझे लगता है कि मेरा सवाल है, सामान्य तौर पर एक एकीकरण परीक्षण और E2E परीक्षण लागत कितनी है और यह कितना पैसा बचाता है? क्या इसके लिए कोई जोखिम / लागत गणना करने का कोई तरीका है?

Comments

क्या इसके लिए कोई जोखिम / लागत गणना करने का कोई तरीका है? वास्तव में दोनों करने और फिर तुलना करने के अलावा, नहीं।

— रॉबी डी

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

— क्रिश्चियन हैकल

आपको क्या लगता है कि अगर अमेजन जैसे वेब स्टोर में कुछ घंटे या ऑर्डर खत्म हो गए तो बिजनेस पर क्या असर पड़ेगा? वे किसी भी कीमत पर वस्तुओं को फिर से भेजने की कोशिश कर सकते हैं, लेकिन यह उनकी प्रतिष्ठा के लिए क्या करेगा?

— बार्ट वैन इनगेन शेनॉ

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

— मार्क

Answer 1

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

इस प्रकार, आपके लागत आकलन में, आप विफलता के मामले में आपके बैकअप योजना के अनुमानों की लागत के विरुद्ध E2E परीक्षणों को लागू करने के लिए लागत की तुलना नहीं करते हैं, आप तुलना करते हैं:

• E2E परीक्षण मैन्युअल रूप से करने के लिए लागत (प्रत्येक नई रिलीज़ से पहले कई बार)

बनाम

• स्वचालित E2E परीक्षणों के निर्माण (और रखरखाव) के लिए लागत

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

ध्यान दें कि कुछ प्रकार के E2E परीक्षण हो सकते हैं जिन्हें आसानी से लागू किया जा सकता है, जहां ROI तुरंत स्पष्ट हो जाता है, लेकिन E2E परीक्षण भी ऐसे प्रकार के होते हैं, जहाँ विकास और रखरखाव अधिक महंगे हो सकते हैं, जो उन्हें कई वर्षों की अवधि में मैन्युअल रूप से करते हैं।

Comments

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

— मार्क

@ मर्क: मुझे लगता है कि आपने मेरे आखिरी वाक्य को गलत समझा, मैं अलग-अलग परीक्षणों के बारे में बात कर रहा था: जो लागू करने / बनाए रखने में आसान हैं, और जो नहीं हैं।

— डॉक ब्राउन

सही, संपादित संस्करण इसे स्पष्ट करता है।

— मार्क

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

— डॉक ब्राउन

Answer 2

शायद सहज रूप से काउंटर, स्वचालित परीक्षण वास्तव में विकास के समय को कम कर सकता है बनाम कोई परीक्षण नहीं। तो यह एक जीत है।

विचार यह है कि परीक्षण कई स्तरों पर योगदान करते हैं

1. फोर्स सख्त आवश्यकता सभा और विनिर्देश

   यह विकास की गति पर भारी प्रभाव डालता है। कोई और अधिक विस्तार, कोई गलतफहमी, कोई अनावश्यक सुविधाओं आदि के लिए नहीं पूछ रहा है

2. डेवलपर्स जानते हैं कि कोई सुविधा कब पूरी होती है

   अधिकांश परीक्षण डेवलपर्स द्वारा तैयार उत्पाद की जांच करने वाले परीक्षकों के बजाय कोड के लेखन के दौरान किया जाता है। इस परीक्षण को स्वचालित करने से इस कार्यभार में कमी आती है

3. नए फीचर्स द्वारा पेश किए गए बग्स को तुरंत पता चला।

   ये आसानी से आपको एक स्प्रिंट की कीमत दे सकते हैं और अगर वे बिना तय किए जाते हैं तो एक पूरी सुविधा के पुनर्लेखन की आवश्यकता होती है।

4. तेजी से रिलीज चक्र

   इसका मतलब उड़ान में कम कोड है, जिसका अर्थ है कम विलय, जिसका अर्थ है कम काम और डेवलपर्स के लिए कम जटिलता

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

साथ ही, आप मैन्युअल परीक्षण समय पर बचत करते हैं, साथ ही आपको अंत में एक बेहतर उत्पाद मिलता है।

Comments

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

— रॉबी डी

हाँ, मुझे लगता है कि हमारे पास जगह में यूनिट परीक्षण हैं

— मार्क

Answer 3

मेरा जवाब? शायद, शायद नहीं ।

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

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

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

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

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

इसलिए, मेरी रूढ़िवादी सलाह Google से परीक्षण पिरामिड का उपयोग करना है:

पहले अच्छे अनुमान के रूप में, Google अक्सर 70/20/10 विभाजन: 70% इकाई परीक्षण, 20% एकीकरण परीक्षण और 10% अंत-टू-एंड परीक्षण का सुझाव देता है। प्रत्येक टीम के लिए सटीक मिश्रण अलग-अलग होगा, लेकिन सामान्य तौर पर, इसे उस पिरामिड आकार को बनाए रखना चाहिए।

Answer 4

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

सॉफ्टवेयर विकास सभी को अक्सर संगठनात्मक राजनीति पर नजर रखने की आवश्यकता होती है।

Answer 5

"यह अच्छी तरह से ज्ञात है कि अंत-से-अंत और एकीकरण परीक्षण महंगा हैं।"

मुझे लगता है कि मैं इस दावे से असहमत हूं।

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

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

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

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

E2E सहित परीक्षण के किसी भी रूप का उपयोग करें जो आपको उचित लगता है। हालांकि उन पर ध्यान दें।

Answer 6

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

आपको पूछना चाहिए कि सबसे खराब मामला बग क्या है जो वास्तविक रूप से ई 2 ई-परीक्षण की कमी के कारण उत्पादन में समाप्त हो सकता है। और मर्फ़िस कानून को याद रखें।

Answer 7

मुझे लगता है कि यह सवाल एंटरप्राइज़ वेब एप्लिकेशन के बारे में है।

मध्यम-महत्वपूर्ण सामान के लिए मेरी सिफारिश:

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

मुझे लगता है कि अधिकांश परीक्षण एपीआई स्तर या घटक स्तर पर होने चाहिए। मुझे यूनिट परीक्षणों की परवाह नहीं है जो केवल कुछ आंतरिक कार्यों को निष्पादित कर रहे हैं।