क्या सॉफ्टवेयर परीक्षण वास्तव में पेशेवर परियोजनाओं पर किया गया है?


25

मैं कई कंपनियों में कई परियोजनाओं के साथ शामिल रहा हूं क्योंकि मैं लंबे समय से डेवलपर रहा हूं और मैं एक ठेकेदार हूं।

मेरा अनुमान है कि 20% से कम परियोजनाओं का विधिपूर्वक परीक्षण किया जाता है। विधिवत परीक्षण के साथ मेरा मतलब है कि तदर्थ से परे कोई भी परीक्षण कोई योजना परीक्षण नहीं है।

मेरा यह भी अनुमान है कि 10% से कम परियोजनाओं का पूरी तरह से परीक्षण किया जाता है जहां उनके पास टीम के हिस्से के रूप में समर्पित परीक्षक हैं, परीक्षण योजना दस्तावेज, जहां डेवलपर्स स्वचालित परीक्षण लिखते हैं और फिर वे परीक्षण कवरेज को ट्रैक करते हैं और परिणाम मापते हैं।

दो सवाल

  1. इस मुद्दे के बारे में आपके प्रतिशत अनुमान क्या हैं?
  2. सॉफ्टवेयर परीक्षण के बारे में आपका पेशेवर अनुभव क्या है?

अतिरिक्त नोट

चूंकि मैथेमैटिकल टेस्टिंग प्रश्न में काफी पक्षपाती उत्तर मिल सकते हैं (लोग दूसरों से श्रेष्ठ होने के बारे में डींग मारना पसंद करते हैं) मैं अन्य डेवलपर्स को प्रोत्साहित करता हूं (जो मैथोडिकल परीक्षण के संपर्क में नहीं हैं) अपने उत्तर को भी प्रदान करने के लिए, क्योंकि अन्यथा यह परीक्षण जैसा लगेगा। आपकी कंपनी को छोड़कर हर जगह ... किया जा रहा है।


महान प्रश्न, सुधार के लिए समय निकालने के लिए धन्यवाद!

@ मर्क ट्रैप: धन्यवाद। मुझे लगता है कि यह काफी बुनियादी है, लेकिन मैं कुछ और पूछ सकता हूं (प्रश्नों के पिछले सेट पर आधारित)
रॉबर्ट कोरिटनिक

जवाबों:


8

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

उन्होंने कहा कि अभी भी ऐसी परियोजनाएं हैं जिनका अत्यधिक परीक्षण किया गया है और जिनका पर्याप्त परीक्षण नहीं किया गया है, लेकिन ये अल्पसंख्यक हैं।


मैंने अपना प्रश्न थोड़ा संपादित किया है। क्या आप अपना अनुमान भी बता सकते हैं?
रॉबर्ट कोरिटनिक

लगभग सभी परियोजनाओं (80% +) के साथ मैं व्यवस्थित रूप से परीक्षण किया गया है, लेकिन फिर मैंने लगभग अनन्य रूप से कॉर्पोरेट मिशन महत्वपूर्ण अनुप्रयोगों को किया है।
मार्टिन ब्राउन

मैं फार्मास्युटिकल कॉर्पोरेशन के लिए काम करता हूं। मैं कहूंगा कि पेशेवर परीक्षकों और डेवलपर्स द्वारा 80% अनुप्रयोगों का परीक्षण किया जाता है। वे 20% iPad पर प्रचार प्रस्तुति की तरह कम जोखिम वाले अनुप्रयोग हैं। लेकिन यहां तक ​​कि यह किसी के द्वारा जांचा जाने वाला विज्ञापन है।
योयसिबा

5

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


मैंने अपना प्रश्न थोड़ा संपादित किया है। क्या आप विकास पेशेवर बाजार के अपने अनुमान प्रदान कर सकते हैं। क्योंकि आपकी परियोजनाओं की जांच हो जाती है। और आपके परीक्षण स्वचालित हैं या नहीं?
राबर्ट कोरिटनिक

यह ऑफशोर टीम कौन है? क्या आप उन्हें एक प्रतिशोध देंगे?
मार्टिन ब्राउन

आमतौर पर बड़ी कंपनियों के पास अन्य देशों (ज्यादातर एशिया में) में आरएंडडी सेंटर हैं। जहां अपतटीय विकास किया जाता है। अपतटीय विकास का उद्देश्य विकास लागत (इसका कुछ हिस्सा) को कम करना है।
निपुण

2

पिछले 15 वर्षों के दौरान मैंने जिन तीन कंपनियों के लिए काम किया है, उन सभी में यूनिट परीक्षण थे जो स्वचालित रूप से चलाए गए थे।

उन कंपनियों में से दो पर मैंने उन्हें शुरू करने के लिए धक्का दिया।


मैंने अपने प्रश्न को थोड़ा संपादित किया। क्या आप पेशेवर बाजार पर सॉफ्टवेयर परीक्षण के बारे में अपना अनुमान प्रदान कर सकते हैं?
राबर्ट कोरिटनिक

@ रॉबर्ट: मैं एक सामान्य अनुमान देने के लिए पर्याप्त नौकरी नहीं कर रहा हूं। मैं जो कुछ जानता हूं, उससे चीजें बेहतर होती जा रही हैं। लेकिन फिर, यह मुझे था, जो मैं आपको बताए गए तीन मामलों में से दो में स्वचालित इकाई परीक्षणों के लिए जोर दे रहा था ...
sbi

लेकिन आप अन्य कंपनियों में अन्य डेवलपर्स से बात करते हैं, क्या आप नहीं?
रॉबर्ट कोरिटनिक

2

पिछले 9 वर्षों में, मैं मूल रूप से केवल स्वीकृति / प्रतिगमन परीक्षण मिला है। केवल कुछ यूनिट परीक्षण थे।


मैंने अपना प्रश्न थोड़ा संपादित किया है। क्या आप पेशेवर बाजार में सॉफ्टवेयर परीक्षण के अपने अनुमान प्रदान कर सकते हैं?
राबर्ट कोरिटनिक

2

हाँ।

परीक्षण की मात्रा एप्लिकेशन की आवश्यक विश्वसनीयता के साथ-साथ प्रोग्रामर संस्कृति की परिपक्वता के अनुपात में है।

वेब साइटों अक्सर चल रहे हैं बग छेद (टूटी कड़ियाँ हैं एक दोष)।

वीडियो गेम अक्सर छोटी गाड़ी है।

विंडोज (अंत में) काफी विश्वसनीय है।

राउटर बहुत विश्वसनीय हैं

अस्पताल की निगरानी "तोड़ो मत"

ध्यान दें कि विफलता की राजकोषीय लागत भी विश्वसनीयता से संबंधित है।


2
मैं आपसे बहुत असहमत हूं - आपने कभी राउटर को विफल नहीं देखा है? क्या Xbox, Playstation और Wii गेम लॉक-अप करते हैं? कभी विंडोज में एक ब्लू-स्क्रीन या 'एप्लिकेशन जवाब नहीं दे रहा है'?
JBRWilkinson

@JBRWilkinson मुझे लगता है कि आपके गायब होने की गंभीरता को कम करने के साथ-साथ संभवतः पीसी गेम्स के विशाल बहुमत को भी शामिल किया जाए, जैसा कि पॉल कहते हैं, अक्सर छोटी गाड़ी है। वैसे भी, सूची शायद कुछ सुधार का उपयोग कर सकती है, लेकिन भावना सही है: विश्वसनीयता अक्सर विफलता से जुड़े राजकोषीय घाटे से संबंधित होती है।
जय कार्र

1

10 वर्षों में मैंने कभी औपचारिक कोड परीक्षण वाली परियोजना पर काम नहीं किया।

मेरी वर्तमान नौकरी में हमारे पास केवल कार्यात्मक परीक्षण है।

समस्या यह है कि प्रबंधन में कोई भी कोड परीक्षण के बारे में नहीं जानता है। टेस्ट डिपार्टमेंट कोड परीक्षण के बारे में भी नहीं जानता है, वे सिर्फ उच्च स्तर के विनिर्देश का पालन करते हैं और सत्यापित करते हैं कि क्या हम एक व्यवहार / कार्यात्मक दृष्टिकोण से अनुपालन करते हैं।

हमारे पास एक योग्य सॉफ्टवेयर लीडर नहीं है जो हमें अच्छी तरह से कोड करने के लिए मजबूर करता है। परिणाम स्पेगेटी कोड है, बहुत सारे प्रतिगमन, याद कार्यक्रम और इतने पर ...


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

इटली के लिए मेरा अनुमान औपचारिक कोड परीक्षण के 10% से कम है। शायद लगभग केवल मिशन-महत्वपूर्ण कोड।
जादूगर

मैंने आयरलैंड, इंग्लैंड, स्कॉटलैंड और स्लोवेनिया में काम किया है और ऐसा लगता है कि इटली कोई अलग नहीं लगता।
रॉबर्ट कोरिटनिक

1

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

हम अपने द्वारा बनाए गए प्रत्येक एप्लिकेशन पर पद्धतिगत परीक्षण लागू करते हैं। शायद, परीक्षण की गुणवत्ता मानक तक नहीं है, लेकिन हम उन्हें रोजगार देते हैं।


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

हमारे अधिकांश परीक्षण मैन्युअल रूप से किए जाते हैं।
शमीम हाफिज

1

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

मैंने कहा, मुझे नहीं लगता कि जोखिम प्रबंधन योजना औपचारिक परीक्षण की कमी का कारण है। मुझे लगता है कि यह गैर-तकनीकी प्रबंधकों द्वारा प्रदान किए गए मूल्य को समझने और केवल लागत को देखने का एक परिणाम है।


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

3
मैं उस हठधर्मिता पर अधिक से अधिक संदेह कर रहा हूं, विशेष रूप से यह सार्वभौमिक रूप से कैसे लागू किया जाता है। मुझे यकीन है कि यह कुछ समय के लिए सही है, लेकिन सभी बग समान रूप से नहीं बनाए गए हैं, और न ही सभी एप्लिकेशन हैं। मुझे यह निगलने में बहुत मुश्किल है कि 10 लोगों द्वारा उपयोग किए जाने वाले आंतरिक ऐप में एक बग को ठीक करने के लिए काफी अधिक महंगा है अगर यह यूनिट परीक्षण के दौरान एक पैच रिलीज में पाया जाता है। यह घातीय रूप से अधिक शर्मनाक हो सकता है, लेकिन अधिक महंगा नहीं है जब तक कि आप उस समय की वास्तविक लागतों को अनदेखा नहीं करते जब एक परीक्षक बग ढूंढने में खर्च करता है।
JohnFx

2
मुझे यह भी आश्चर्य है कि अगर वे आँकड़े बड़े पैमाने पर परियोजनाओं (जैसे ऑपरेटिंग सिस्टम) पर लागू नहीं होते थे, जो वे से बनाए गए थे और सीआरयूडी प्रकार के ऐप्स में अनुवाद नहीं करते हैं, जिनमें से अधिकांश हम एक जीवित के लिए बनाते हैं।
जॉनएफएक्स

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

1

मेरा नमूना प्रतिशत घटाने के लिए बहुत छोटा है, लेकिन यहाँ वैसे भी जाता है।

एक एक फैबलेस चिप + फर्मवेयर कंपनी थी, जिसने कट्टरपंथी परीक्षण किया था। स्थापना के दसियों पर 24/7 स्वचालित परीक्षण, समानांतर में इकाइयों के प्रत्येक परीक्षण दसियों। सॉफ्टवेयर टीम परीक्षण सॉफ्टवेयर विकसित करने के लिए समर्पित है। हार्डवेयर टीम परीक्षण रिसाव का निर्माण करने के लिए समर्पित। प्रतियोगियों के दसियों के खिलाफ संगतता परीक्षण। हेक, उन्होंने चिप्स विकसित करने के लिए मल्टी-मिलियन डॉलर के चिप टेस्टर इंस्टॉलेशन को भी खरीदा और डिबग करने के लिए कुछ परीक्षणों को चलाया, जब चिप्स फाउंड्री छोड़ते हैं।

एक और एक बैंक था। यह एक पूरी तरह से अलग वातावरण है: कोई उत्पाद जारी नहीं करता है, लेकिन बहुत सारे और बहुत सारे इन-हाउस सॉफ़्टवेयर लगातार चलते रहते हैं। इन लोगों ने अपने द्वारा किए गए हर एक परिवर्तन के cr * p का परीक्षण किया। वे DEV / QA / PROD वातावरण, स्वचालित प्रतिगमन परीक्षण, उत्पादन में रिलीज़ होने से पहले अंतिम उपयोगकर्ताओं द्वारा हस्ताक्षरित अनिवार्य QA परीक्षण से बहुत सख्त अलगाव थे।

तो, हाँ, लोग विधिपूर्वक परीक्षण करते हैं। लेकिन जैसा कि आप बता सकते हैं कि मैंने कभी ऐसे स्थान पर काम नहीं किया है जो विशिष्ट कंप्यूटर उपयोगकर्ता के लिए आपके विशिष्ट GUI सॉफ़्टवेयर को शिप करता है।


1

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

हमारे परीक्षण के परिणाम एफडीए को प्रस्तुत किए जाते हैं (अब तक हमने दो एफडीए मंजूरी प्राप्त की है - प्रत्येक उपमहाद्वीप लगभग 500 पृष्ठ लंबा था)। हमारे विकास और परीक्षण दोनों तरीके दोनों समय-समय पर ऑडिटिंग के अधीन हैं।

इसलिए यह न केवल बड़ी कंपनियां हैं जो बहुत सारे औपचारिक परीक्षण करती हैं।

नोट - मेरे 25+ वर्षों के अनुबंध प्रोग्रामिंग / परामर्श में, मैंने कई कंपनियों के लिए भी काम किया है, जिन्होंने वस्तुतः कोई औपचारिक परीक्षण नहीं किया था। उनमें से ज्यादातर अब आसपास नहीं हैं।


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

0

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


मैंने अपना प्रश्न थोड़ा संपादित किया है। क्या आप पेशेवर बाजार में सॉफ्टवेयर परीक्षण के अपने अनुमान प्रदान कर सकते हैं?
रॉबर्ट कोरिटनिक

@ रॉबर्ट: मैं आपके प्रश्न "सॉफ़्टवेयर परीक्षण के अनुमान" को नहीं समझता। क्या आप मेरी राय पूछ रहे हैं कि कितनी कंपनियां परीक्षण करती हैं? मेरा अनुमान शायद 90% या उससे अधिक होगा जो मैंने अपनी आँखों से देखा है। परीक्षण व्यावसायिक विकास का एक सामान्य हिस्सा है।
ब्रायन ओकले

0

आठ या तो कंपनियों के माध्यम से अपने कैरियर के अंतिम बीस वर्षों में, मैंने कभी ऐसी परियोजना पर काम नहीं किया है जो परीक्षण नहीं करती है। परीक्षण की राशि प्रत्येक कंपनी में भिन्न होती है, लेकिन मैंने कभी भी काम किया है हर पेशेवर विकास परियोजना ने औपचारिक परीक्षण किया। यह दोनों छोटी और मध्यम आकार की कंपनियों (जहां "छोटे" का मतलब 10 कर्मचारियों से कम है, और "मध्यम आकार" का अर्थ है एक दो हज़ार कर्मचारी या उससे कम)।

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


0

यह ग्राहक की जरूरतों पर निर्भर करता है। एक अनुबंध की स्थिति में संभवतः स्वीकृति परीक्षण होते हैं। घर में आमतौर पर थोड़ा परीक्षण के साथ एक स्लैपजोब होता है। उपभोक्ता सामान आमतौर पर अक्सर कार्यक्षमता में कवर किया जाता है, लेकिन किनारों के आसपास मोटा होता है।


0

संक्षिप्त उत्तर: हां

लंबा जवाब:

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

  2. मैं ऊपर उल्लिखित कारकों के विभिन्न संयोजन के साथ कई परियोजनाओं के माध्यम से किया गया है:

    • कोई औपचारिक इकाई परीक्षण, केवल एकीकरण परीक्षण और ज्यादातर एडहॉक परीक्षण

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

व्यक्तिगत स्तर पर मैं अपने विकल्पों की समझ बनाए रखना चाहता हूं, जब वह मेरे साथ काम कर रही तकनीक के लिए उचित परीक्षण लिखने की बात करता है, और उन्हें अपने विवेक से अभ्यास करता है। मूल रूप से चीजें जो वास्तव में सार्थक हैं और मेरे काम के लिए फायदेमंद हैं, और संख्याओं को इतना क्रैंक नहीं कर रही हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.