सिस्टम टेस्टिंग के लिए सॉफ्टवेयर जारी करते समय नए फीचर्स जोड़े बिना बग्स को ठीक करना सही है?


10

यह प्रश्न अनुभवी परीक्षकों या टेस्ट लीड्स का है। यह एक सॉफ्टवेयर प्रोजेक्ट का एक परिदृश्य है:

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

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

क्या आप सहमत हो सकते हैं कि यह एक सामान्य परीक्षण सिद्धांत है। क्या परीक्षण टीम की चिंता वैध है। क्या आपने अपने प्रोजेक्ट में इसका अभ्यास किया है


यह ब्रांचिंग के दृष्टिकोण के बारे में एक बुरा लेख नहीं है: nvie.com/posts/a-successful-git-branching-model , आप विशेष रूप से इस कारण से मौजूद हॉटफ़िक्स शाखाओं पर अनुभाग में रुचि ले सकते हैं।
ज्ञान उर्फ ​​गैरी ब्यन

बिल्कुल ... उन नई विशेषताओं को एक अलग शाखा पर होना चाहिए, जबकि स्वीकृति के लिए बग फिक्स जो भी परीक्षण टीम परीक्षण कर रही है, उस पर है ...
रिग

जवाबों:


5

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


यह उपयोगकर्ताओं के लिए वास्तविक कार्यान्वयन की रिलीज़ नहीं है। यह कई पुनरावृत्तियों के बाद होगा। मैंने सिस्टम रिलीज़ के लिए प्रत्येक पुनरावृत्ति के बाद तैनात करने के लिए रिलीज़ शब्द का उपयोग किया।
सॉफ्टवेयड

4
@Pratik: देव टीम के नजरिए से, यह "रिलीज" है। कोड एक ऐसी स्थिति में है जिसे वे "किया" मानते हैं और बाहरी आंखों से देखने के लिए तैयार हैं।

4

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

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

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

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


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

2

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

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

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

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


0

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

यह कहने के बाद कि, परीक्षकों के लिए 'Ceteris paribus' (सभी 'अन्य' चीजों के बराबर होना) को ठीक करना चाहते हैं, यह समझ में आता है (आवश्यक नहीं)।

रिलीज़ और अंतिम-उपयोगकर्ता अपेक्षा के तरीके के साथ कुछ अन्य चिंताएं हो सकती हैं। उदाहरण के लिए, बग फिक्स + परीक्षण और एक और नई सुविधाओं + परीक्षण के केवल एक पुनरावृत्ति के बाद आपको रिलीज करने की आवश्यकता हो सकती है क्योंकि उपयोगकर्ता केवल नई सुविधाओं के होने पर पुन: स्थापित या अपग्रेड करना चाहते हैं। कुछ शीर्ष प्राथमिकता ASAP के रूप में सुधार की मांग कर सकते हैं।


0

आप दोनों टीमों को मर्ज करके इस (आम) समस्या को हल कर सकते हैं।

विकास टीम के भीतर परीक्षक, सुविधाओं के उत्पादन के रूप में परीक्षण, अधिकांश टीमों को आउटपुट की गुणवत्ता बढ़ाने में मदद कर सकते हैं।

मेरा सुझाव है कि आप इस उत्कृष्ट ब्लॉग पोस्ट को पढ़ने के लिए हेनरिक Kniberg कि समझाने Kaban । आपको स्क्रम प्रक्रिया में कई विचार मिलेंगे ( हेनरिक निबरग द्वारा एक मुफ्त पुस्तक भी )।

उन्होंने अपने ब्लॉग पर एक उत्कृष्ट कानबन वीएस स्क्रैम लेख भी लिखा ।

का आनंद लें।


0

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


0

यदि परीक्षक एक ग्राहक को एक परिभाषित रिलीज प्राप्त करने का प्रयास कर रहे हैं, जो नई सुविधाओं की उम्मीद नहीं कर रहा है, तो उनका अनुरोध उचित है, उचित है और आपको इसे वितरित करने के लिए पीछे की तरफ झुकना चाहिए।

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

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


0

"क्या आप सहमत हो सकते हैं यदि यह एक सामान्य परीक्षण सिद्धांत है।

Yes

क्या परीक्षण टीम की चिंता वैध है

Yes

क्या आपने अपनी परियोजना में इस अभ्यास का सामना किया है। "

Yes

:

and Yes Merging is the downside of it 

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


0

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

यहाँ कोई सही उत्तर नहीं है लेकिन कुछ बातों पर आपको गौर करना चाहिए:

  • क्या ये बग रिलीज़ (नई कार्यक्षमता के बिना) कभी भी उपयोगकर्ताओं के पास जा सकते हैं? यदि ऐसा है, तो हाँ, इसे शाखाबद्ध और परीक्षण किया जाना चाहिए और सभी को इसे एक उपरि के रूप में स्वीकार करने की आवश्यकता है।

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

  • उन्हें रिलीज़ करने के लिए वास्तव में कितना काम है? आम तौर पर यह एक दर्द है लेकिन काम की वास्तविक मात्रा आम तौर पर यह बहुत अच्छा नहीं है। जाहिर है कि आपको यह पुष्टि करने के लिए उनकी आवश्यकता होगी कि यह उनके लिए भी अधिक काम नहीं है (पहली बात जो मैं कहता हूं उसे देखें), लेकिन मैंने देखा है कि यह काम करते हैं।

  • क्या यहां संस्करण नियंत्रण का उपयोग करने का एक बेहतर तरीका है? मर्क्यूरियल जैसा कुछ (देखें http://hginit.com/ - इसे पढ़ें, यह अच्छा है) या एक और वितरित संस्करण नियंत्रण प्रणाली शाखाएं हैं और एक अलग तरीके से विलय करती हैं और आपको समस्या को गोल करने की अनुमति दे सकती हैं। वास्तव में, इस पर एक नज़र डालें क्योंकि मुझे लगता है कि यह आपकी समस्या का जवाब हो सकता है।

लेकिन सौभाग्य, यह एक दर्द है। इन सबसे ऊपर याद रखें कि आगे का सबसे अच्छा तरीका आपकी कंपनी, उत्पाद और स्थिति पर बहुत निर्भर करेगा, इसलिए सुनिश्चित करें कि आप इस बारे में सोचते हैं और बस शेल्फ से कुछ खींच नहीं सकते हैं और विश्वास करते हैं कि आपको इसका 100% पालन करना होगा।


0

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

यदि आप ज्ञात बग के शीर्ष पर नई सुविधाओं का निर्माण करते हैं, तो आप कार्ड का एक घर बना रहे हैं। आप संभवतः भंगुर, अप्रत्याशित सॉफ़्टवेयर विकसित कर सकते हैं। बगगी कोड और आपकी नई सुविधाओं के बीच अलगाव के स्तर के आधार पर, बग आपकी नई सुविधाओं को भी प्रभावित कर सकते हैं। यदि हां, तो आपको कैसे पता चलेगा कि आपकी नई सुविधाएँ सही तरीके से काम करती हैं?

यदि आप पहले अपने कीड़े ठीक करते हैं, तो आपके पास जो भी नई सुविधाएँ हैं, उनके लिए आपके पास एक मजबूत आधार होगा।

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

हमेशा नई सुविधाओं को जोड़ने से पहले कीड़े को ठीक करने की कोशिश करें!


0

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

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