क्या परीक्षकों को रिलीज की मंजूरी देनी चाहिए, या परीक्षणों पर रिपोर्ट करना चाहिए?

Question

क्या परीक्षकों को साइनऑफ प्राधिकरण देना समझ में आता है? एक परीक्षण टीम चाहिए

1. बस सुविधाओं, मुद्दों, आदि का परीक्षण करें, और बस पास / असफल आधार पर रिपोर्ट करें, उन परिणामों पर कार्य करने के लिए दूसरों पर छोड़ दें, या
2. क्या उन परिणामों के आधार पर खुद को रिलीज करने का अधिकार है?

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

Comments

कृपया अपने प्रश्न को फिर से लिखें, ताकि यह एक सर्वेक्षण न हो। आप जिस समस्या को हल करने की कोशिश कर रहे हैं, वह क्या है?

— एम। डडली

"चाहिए" मोटे तौर पर कंपनी की संगठनात्मक संरचना पर निर्भर करता है। यदि वे उत्पादन में पाए जाने वाले कीड़े पर मापते हैं, तो एक छोटी गाड़ी को छोड़ने में सक्षम होना एक आवश्यक उपकरण है।

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

— अर्नेस्ट फ्रीडमैन-हिल

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

— Jan Hudec

Answer 1

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

अंततः क्यूए! = व्यवसाय और व्यवसाय को यह तय करने की आवश्यकता है कि क्या वे वर्तमान स्थिति में कोड को तैनात करने के साथ ठीक हैं या यदि लाभ नीचे की ओर या जो भी हो। यह अक्सर ग्राहकों या हितधारकों द्वारा तुरंत तैनाती से पहले किया जाता है और इसे अक्सर उपयोगकर्ता स्वीकृति कहा जाता है।

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

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

Comments

यदि आप निर्णय लेते हैं कि आप ग्राहक को 1234 के निर्माण पर स्वीकृति परीक्षण करने के लिए आमंत्रित करेंगे या यह स्वीकृति परीक्षण के लिए पर्याप्त नहीं है?

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

@BartvanIngenSchenau: उत्पाद स्वामी / परियोजना प्रबंधक के पास इन पर अंतिम शब्द होना चाहिए। क्योंकि यहां तक कि स्वीकृति परीक्षण अक्सर जाएगा उभार अगर जरूरत (अब आप भले ही हम नहीं इसके साथ काम करने के लिए Y प्राप्त कर सकते हैं, या आप जब तक हम इसे ठीक 2 अधिक महीने इंतजार करना चाहते हैं सुविधा एक्स चाहते हो?) और उत्पाद मालिक होना बातचीत कर रहा है कि

— Jan Hudec

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

— बिल

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

— विल

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

— बिल

Answer 2

किसी को उस अधिकार की आवश्यकता नहीं है । चाहे वह परीक्षक हो, परीक्षकों की टीम हो, परीक्षकों की टीम का नेता हो, या विकास संगठन का नेता कुछ अप्रासंगिक हो। या शायद अधिक सटीक रूप से, यह संगठन पर निर्भर करता है।

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

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

Answer 3

परीक्षकों को जारी करने के लिए साइन-ऑफ अथॉरिटी (यानी वीटो राइट) देना डेवलपर्स के लिए उस अधिकार को देने के रूप में अधिक समझ में आता है: कोई भी नहीं।

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

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

Comments

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

— maple_shaft

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

— बिल

Answer 4

At रिलीज ’या to रिलीज न करने’ का निर्णय एक व्यापारिक निर्णय के दिन के अंत में होता है, जहां कठोर जोखिम / इनाम विश्लेषण करने की आवश्यकता होती है।

किसी भी संगठन के लिए यह जिम्मेदारी लेने के लिए परीक्षण टीम को पूछने के लिए या परीक्षण टीम को इस जिम्मेदारी के लिए सहमत होने के लिए पागल है।

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

जैसा कि अन्य ने उल्लेख किया है, _ कोई व्यक्ति _ (और मेरा मानना ​​है कि यह एक व्यक्ति है) को 'रिलीज' या 'रिलीज नहीं' करने के लिए अधिकार की आवश्यकता है। उसी व्यक्ति ने उस निर्णय को विशिष्ट शर्तों (यानी कोई P1 ​​या P2 कीड़े) के तहत निर्धारित किया जा सकता है

Answer 5

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

जबकि मैं अपूर्ण रिलीज को बाहर नहीं भेजने के लिए परीक्षण टीम को समझता हूं और उसकी सराहना करता हूं, यह परिभाषित करने के लिए मजबूत उत्पाद स्वामित्व की आवश्यकता है कि "स्वीकार्य जोखिम" क्या है।

मेरे अनुभव में, परीक्षण टीम को सॉफ्टवेयर जारी करने पर वीटो दिया जाना चाहिए, लेकिन यह वीटो उत्पाद के मालिक द्वारा अति-योग्य होना चाहिए, लेकिन केवल लीड टेस्टर के साथ चर्चा के बाद।

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

Comments

यह एक वास्तविक समस्या है, लेकिन मुझे यकीन नहीं है कि अगर यह ओपी की समस्या है। मेरी व्याख्या यह है कि किसी तरह परीक्षक नई आवश्यकताओं की व्याख्या कर रहे हैं जो मूल रूप से परिभाषित नहीं थे।

— maple_shaft

परीक्षण टीमों के साथ मेरे अनुभव ने मुझे इसके दूसरे पक्ष पर गिरने के लिए प्रेरित किया है। मेरे लिए, QA को इस बात की कोई अपेक्षा नहीं होनी चाहिए कि वह अपनी टीम के बाकी सदस्यों को अपना मामला बनाए बिना ब्लॉक कर पाए या टीम को ओवरराइड करने के लिए मालिक बन जाए।

— बिल

यह सच है - मैं शायद पर्याप्त रूप से स्पष्ट नहीं था, वही मुद्दे होते हैं जब परीक्षक दोष बढ़ाते हैं, और मैं "कहानी के आडंबर में" उद्धृत करता हूं, जो उन्हीं मुद्दों की ओर ले जाता है - कुछ भी कभी भी जारी नहीं होता है।

— माइकल

मेरे मामले में, यह अधिक @maple_shaft व्याख्या है; स्पष्ट रूप से असमर्थित मामलों को संभालने में विफलता की रिपोर्टिंग के रूप में सॉफ्टवेयर को तोड़ने के तरीकों को खोजने में इतना कुटिल नहीं है।

— अर्नेस्ट फ्रीडमैन-हिल

@ ErnestFriedman-Hill ऐसा लगता है कि आप नकारात्मक आवश्यकताओं का वर्णन कर रहे हैं और ये वही हैं जो आपके कार्यात्मक आवश्यकता दस्तावेजों से गायब हैं। एक नकारात्मक आवश्यकता एक प्रणाली क्या नहीं करेगी के बारे में एक स्पष्ट बयान है, और नियमित आवश्यकताओं के रूप में स्वीकार्य हो सकता है। यदि ये घोषित किए जाते हैं तो नकारात्मक आवश्यकताओं के खिलाफ उनके परीक्षण के मामले मान्य नहीं हैं।

— maple_shaft