हम सिस्टम को लागू करने की तुलना में कार्यात्मक परीक्षण को लागू करने में अधिक समय बिता रहे हैं, क्या यह सामान्य है?

Question

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

प्रबंधक नीति हर एक कार्यक्षमता का परीक्षण करना है जिसे हम जोड़ते हैं, भले ही वह व्यवसाय महत्वपूर्ण न हो (यानी एक नया सीआरयूडी)।

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

तो, सिस्टम कोड लिखने, यूनिट टेस्ट और फिक्सिंग क्यूए टिकेट्स की तुलना में अधिक समय कार्यात्मक खर्च करने में क्या मूल्य है? क्या यह सामान्य है? क्या हमें केवल महत्वपूर्ण कार्यक्षमता के लिए कार्यात्मक परीक्षण नहीं लिखना चाहिए और क्यूए को बिना किसी महत्वपूर्ण कार्यक्षमता के प्रतिगमन परीक्षण करने देना चाहिए?

नोट: हम चिकित्सा सॉफ्टवेयर या नासा सॉफ्टवेयर विकसित नहीं कर रहे हैं या कुछ भी महत्वपूर्ण नहीं है।

Comments

हमारे पास परीक्षण नहीं हैं। हम तथ्य के बाद चीजों को ठीक करने में बहुत समय खर्च करते हैं। "आप मुझे अभी भुगतान कर सकते हैं, या आप मुझे बाद में भुगतान कर सकते हैं।" यह बाद में है और यह सुंदर नहीं है।

— 21

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

— माइकल बोर्गवर्ड 22

डेवलपर

— gnat

क्या यह

— gnat

Answer 1

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

किसी एप्लिकेशन पर स्वचालित कार्यात्मक परीक्षण करने के लिए कुछ अच्छे कारण हैं।

• जब आपकी वेब साइट पर एक नई सुविधा जोड़ी जाती है, तो आपको तुरंत पता चल जाता है कि उस नई सुविधा के लिए किए गए परिवर्तन आपकी साइट पर किसी अन्य कार्यक्षमता को तोड़ते हैं या नहीं।
• यह इस बात का ज्ञान है कि आवेदन कैसे चलता है और व्यावसायिक आवश्यकताओं को प्राप्त करने के लिए एक साथ काम करता है।
• जब तीसरी पार्टी लाइब्रेरी को अपडेट करने का समय है, तो आप इसे अपडेट कर सकते हैं और देख सकते हैं कि क्या कुछ टूटता है या नहीं। अपने आप को हर पेज से गुजरने के बजाय, आप एक कंप्यूटर आपके लिए कर सकते हैं और आपको उन सभी परीक्षणों की सूची दे सकते हैं जो टूट गए।
• लोड परीक्षण! आप एक साथ सभी हज़ारों उपयोगकर्ताओं को एक साथ अपनी साइट को हिट कर सकते हैं और आप देख सकते हैं कि आपकी साइट कहाँ दबाव में कम हो जाती है और बकल हो जाती है। आप देख सकते हैं कि आपकी साइट देर रात कॉल करने से पहले ही बताती है कि साइट दुर्घटनाग्रस्त हो गई है।
• कार्यात्मक परीक्षण को मैन्युअल रूप से करने में समय लगता है। हां, मामलों को लिखने में लंबा समय लगता है, लेकिन यदि आपको 500 पृष्ठों के परीक्षण के साथ एक बांधने की मशीन के साथ बैठना पड़ता है जिसे आपको उत्पाद को जहाज करने से पहले पूरा करना होता है तो आप चाहते हैं कि आपके पास स्वचालित परीक्षण हो!
• परीक्षण दस्तावेज तेजी से पुराने हो जाते हैं। जब एक नई सुविधा जोड़ी जाती है, तो आपको मास्टर परीक्षण दस्तावेज़ को अपडेट करना सुनिश्चित करना होगा। अगर किसी ने कुछ परीक्षणों को छोड़ दिया है, तो आप अचानक उन पृष्ठों में रेंगने वाले कीड़े पा सकते हैं जो "किए गए और परीक्षण किए गए" हैं। मैं वर्तमान में उस तरह के माहौल में काम करता हूं, और मैं आपको आश्वस्त कर सकता हूं, यह एक बुरा सपना है।

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

यह आपकी सुरक्षा का जाल है। जब कोई अंदर जाता है और एक संग्रहित खरीद को हाईजैक करता है और एक छोटा सा बदलाव करता है तो यह उनके कोड के साथ काम करेगा, आप पकड़ लेंगे कि इस प्रक्रिया में 3 अन्य सुविधाओं को तोड़ दिया है। आप उस रात को पकड़ लेंगे और समय सीमा से पहले की रात नहीं!

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

Comments

आपके उत्तर के लिए धन्यवाद। मैं कार्यात्मक परीक्षणों के महत्व और लाभों के बारे में जानता हूं, मेरी चिंता सभी परीक्षण के लागत-लाभ के बारे में है। हम पिछले तीन वर्षों से कार्यात्मक परीक्षण विकसित कर रहे थे, लेकिन अब इस परियोजना में, मुझे लगता है कि परीक्षण को लागू करने की लागत उत्पादन में एक बग खोजने, एक टिकट बढ़ाने और इसे ठीक करने से कहीं अधिक है ... मुझे आश्चर्य है कि अगर ऐसी कुछ परिस्थितियाँ मौजूद हैं जहाँ कार्यात्मक परीक्षण नहीं करना बेहतर है (लागत-लाभ के संदर्भ में) इसे नहीं बनाने से, और मुझे आश्चर्य है कि अगर हम ऐसी परिस्थिति में हैं, तो बुद्धिमानी से चुनना बेहतर है कि क्या परीक्षण करें।

— पाब्लो लास्कानो

@donsenior ~ अगर आपको लगता है कि परीक्षण करने में बहुत समय लग रहा है, तो उन उपकरणों को देखें जिनका आप उपयोग कर रहे हैं। क्या आप उनका सही इस्तेमाल कर रहे हैं? क्या आप भी समय की बचत करने वाले औजारों का उपयोग कर रहे हैं? लेखन परीक्षण कोड लिखने में अधिक समय लेता है b / c आपके पास लिखने के लिए अधिक कोड है। यह परीक्षण की प्रकृति है। यदि आप चुनना शुरू करते हैं और चुनते हैं कि किसके लिए परीक्षण लिखना है, तो यह इस बिंदु पर पहुंच जाएगा कि कोई भी परीक्षण नहीं लिखेगा, या वे परीक्षण मैला हो जाएगा।

— 21

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

— पाब्लो लास्कानो

@donsenior ~ ज़रूर, किसी मामले का परीक्षण करने के लिए QA 5min लेता है, लेकिन इसे परीक्षण करने के लिए कंप्यूटर को एक सेकंड से भी कम समय लगता है। आपसे पूछा जाना चाहिए "हाथ से परीक्षण करने के लिए 5 मिनट लगने वाली चीज़ को लिखने में 2 दिन क्यों लगते हैं"? फिर से, अपने औजारों को देखें। शायद क्यूए कुछ परीक्षण मामलों को भी लिख रहा होगा? समस्या आपके सिस्टम के लिए परीक्षण मामले नहीं लिख रही है, यह है कि उन परीक्षण मामलों को कैसे लिखा जा रहा है।

— तन्य

अच्छी तरह से यह परीक्षण चलाने में एक सेकंड से अधिक समय लगता है (याद रखें कि यह कार्यात्मक परीक्षण हैं, इकाई परीक्षण नहीं)। लेकिन यह कोई समस्या नहीं है, वे रात में चलते हैं। मुझे लगता है कि आप सही हैं कि क्यूए के रूप में अच्छी तरह से कुछ परीक्षण मामलों को लिखना चाहिए, लेकिन दुख की बात है कि एक निर्णय नहीं है जो मैं कर सकता हूं। आपके उत्तर के लिए बहुत बहुत धन्यवाद, मैंने इसे स्वीकार किया है!

— पाब्लो लास्कानो

Answer 2

2 बार से अधिक ... मुझे थोड़ा सा लगता है। आप इसके कारणों का विश्लेषण कर सकते हैं, वे इसमें शामिल हो सकते हैं:

• परीक्षण के निर्माण और रखरखाव के लिए खराब उपकरण का समर्थन

• वेब सेवाओं के अनुबंधों को डिजाइन में पर्याप्त रूप से वर्णित नहीं किया गया है। डेवलपर्स को परीक्षण करते समय अनुबंधों को पूरा करने की आवश्यकता होती है, जो आमतौर पर एक समय लेने वाली संरेखण प्रक्रिया होती है।

अपने डेवलपर्स से बात करें।

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

Comments

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

— पाब्लो लास्कानो

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

— डंक

Answer 3

क्या सिस्टम को सामान्य रूप से लागू करने की तुलना में कार्यात्मक परीक्षण को लागू करने में अधिक समय खर्च करना है?

पूर्ण रूप से। वास्तव में अच्छे परीक्षण लिखने से कई (अच्छी) दुकानों में अधिकांश समय लगने की संभावना है।
तो 2-1 का अनुपात ठीक है। कम अनुभवी डेवलपर्स स्वयं अक्सर परीक्षण के लिए हर समय नहीं लेते हैं।

Answer 4

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

यूनिट परीक्षण कोड होते हैं, इसलिए उनमें बग (सभी अन्य कोड की तरह) शामिल होंगे। उन बग को ठीक करने में समय लगता है।

मेरे अनुभव के यूनिट-परीक्षणों में वे परीक्षण कर रहे सिस्टम की तुलना में कहीं अधिक कीड़े हैं, और इन्हें ठीक करना एक निरंतर बोझ है।

Answer 5

यह गुणवत्ता के बारे में है।

यदि आपको बाजार प्राप्त करने की आवश्यकता है - तो आप अपने ऐप को जल्द से जल्द विकसित करेंगे। तुम भी सभी =) पर स्वत: परीक्षण नहीं है, लेकिन आप अपने प्रतिस्पर्धियों से पहले अपने app अपने श्रवण के लिए दे देंगे।

लेकिन अगर आप जानते हैं कि आपका श्रवण दूर नहीं जाएगा तो आप कुछ भी करेंगे आप उन्हें निराश नहीं कर सकते। हर बग टिकट आपकी प्रतिष्ठा में कमी लाएगा। कल्पना करें कि एक बग आपकी प्रतिष्ठा के 50 प्रतिशत को हटा देगा, अगला - एक और 25 प्रतिशत और एक। तो क्या बहुत सारे परीक्षण हो सकते हैं?

Comments

अगर मैं वास्तव में टिकट कम कर रहा हूं तो वास्तव में मुझे यकीन नहीं है। हो सकता है कि हमने क्यूए टिकट को कम (लेकिन बहुत अधिक नहीं) किया है, लेकिन इस परीक्षण के द्वारा पाए जाने वाले बगों की दर इतनी बड़ी नहीं है (मेरे दृष्टिकोण से) सॉफ्टवेयर एनीनेयरों के 2/3 लागत को सही ठहराने के लिए कार्यात्मक परीक्षण विकसित करना।

— पाब्लो लास्कैनो

Answer 6

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

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

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