क्या यह अच्छा है कि परीक्षक यह देखने के लिए प्रतिस्पर्धा कर रहे हैं कि कौन अधिक बग खोलता है?

Question

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

क्या यह परियोजना के लिए अच्छा है? यदि नहीं, तो मैं (एक सॉफ़्टवेयर डेवलपर के रूप में) परीक्षकों की टीम की सोच और दृष्टिकोण को बदलने की कोशिश कैसे कर सकता हूं?

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

OBS: यह प्रतियोगिता कंपनी का अभ्यास नहीं है! यह केवल उनके द्वारा आयोजित परीक्षकों के बीच और बिना किसी पुरस्कार के एक प्रतियोगिता है।

Comments

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

— थॉमस ओवेन्स

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

— आमोन

आपकी बात अच्छी तरह से ली गई है, लेकिन एक तरफ के रूप में, मैं सराहना करता हूं जब कोई मुझे बताता है कि मेरे काम में प्रयोज्य समस्याएं हैं। यह सॉफ्टवेयर में सही पाने के लिए सबसे कठिन चीजों में से एक है, और सही होने के लिए सबसे मूल्यवान भी है।

— jpmc26

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

— फेयरफॉक्स

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

— एरिक लिपर्ट

Answer 1

मुझे नहीं लगता कि यह अच्छा है कि वे किसी प्रतियोगिता में सबसे अधिक कीड़े ढूंढते हैं। जबकि यह सच है कि उनका काम बग ढूंढना है, उनका काम " सबसे अधिक कीड़े ढूंढना" नहीं है । उनका लक्ष्य सबसे ढूंढना नहीं है, उनका लक्ष्य सॉफ्टवेयर की गुणवत्ता में सुधार करना है। अधिक बग ढूंढने के लिए उन्हें पुरस्कृत करना प्रोग्रामर को उच्चतम गुणवत्ता कोड के बजाय, कोड की सबसे अधिक पंक्तियों को पुरस्कृत करने के समान है।

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

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

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

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

Comments

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

— डबलड्यू

फिर भी, मैं उस विचार की सिफारिश नहीं करूंगा क्योंकि यह जल्दी से उबाऊ हो जाता है जब तक कि आपकी टीम के सदस्य लगभग सभी समान रूप से मेल नहीं खाते (जो ऐसा नहीं होता)। अपने आप से मुकाबला करना बेहतर है।

— डबलड्यू

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

— dodgethesteamroller

आपका जवाब वही है जो मैंने सोचा था। लेकिन, परीक्षकों की पहचान के स्तर के बारे में @DoubleDouble बिंदु सोचने के लिए एक अच्छा बिंदु है!

— केवल एक जिज्ञासु मन

माना। भले ही मेरे पूर्व क्यूए नौकरी में कोई कठिन और तेज कोटा नहीं था, लेकिन कुछ ऐसे परीक्षक थे जिन्होंने महसूस किया कि हर छोटी नाइटिक को वे ढूंढना सबसे महत्वपूर्ण था जो वे पा सकते थे - "चरित्र की शर्ट जैसी चीजें बहुत लंबी हैं, ज्यादातर लोग करते हैं उस शर्ट को न पहनें जो लंबे समय तक "(जब चरित्र की शर्ट की लंबाई खेल के लिए पूरी तरह से अप्रासंगिक थी) असली बग के लिए खुदाई करने के बजाय" मेजबान पर [बार-बार कनेक्ट होने / डिस्कनेक्ट करने वाले नेटवर्क केबल को एक सहकर्मी द्वारा होस्ट किए गए गेम] के परिणाम में गेम द्वारा जब्त किया जा रहा है। क्लाइंट और जीत को होस्ट के ऑनलाइन रिकॉर्ड में जोड़ा जा रहा है "।

— डॉकटोर जे

Answer 2

मैं अन्य उत्तरों से थोड़ा असहमत होने जा रहा हूं। एक टेस्टर के लिए "फाइंडिंग बग्स" थोड़ा सा होता है जैसे "राइटिंग कोड" एक डेवलपर के लिए होता है। कच्ची राशि अर्थहीन है। परीक्षक का काम उन अधिकांश बगों को ढूंढना है जो मौजूद हैं, वे सबसे अधिक बग ढूंढने के लिए नहीं। यदि परीक्षक A उच्च गुणवत्ता वाले घटक में 10 में से 5 बगों का पता लगाता है और परीक्षक B निम्न गुणवत्ता वाले घटक में 263 बगों में से 58 पाता है, तो परीक्षक A बेहतर परीक्षक है।

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

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

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

Comments

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

— एट्सबी

क्योंकि यदि परीक्षक A उच्च गुणवत्ता वाले घटक में 10 में से 5 बगों का पता लगाता है और परीक्षक B कम गुणवत्ता वाले घटक में 263 बगों में से 58 पाता है, तो परीक्षक A बेहतर परीक्षक है।

— रोबोट

@ यदि कोई टूटा हुआ व्यवहार 10 अलग-अलग जगहों पर प्रकट होता है, तो वास्तविक टूटी हुई चीज़ के बारे में 1 बग्रेपोर्ट 8 अलग-अलग बग्रेपोर्ट से बेहतर है जो 10 में से 8 विभिन्न लक्षणों का वर्णन करता है।

— पीटरिस

@Peteris (और स्टीवन) ये दोनों दिलचस्प बिंदु हैं, लेकिन स्टीवन के उद्धृत बयान से वे प्रभावी रूप से संवाद नहीं कर रहे हैं ।

— एट्सबी

@Atsby आपके द्वारा उद्धृत वाक्य में, पहला क्लॉज एक सापेक्ष कथन है (बग्स का सबसे बड़ा अंश खोजें), और दूसरा निरपेक्ष है (बग्स की सबसे बड़ी संख्या ढूंढें)। यह अंतर यह है कि इस बाल्टी को ९ ०% भरने और इस बाल्टी को १/२ गैलन से भरने के बीच का अंतर है जब बाल्टी 1 गैलन रखती है।

— dodgethesteamroller

Answer 3

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

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

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

Comments

+1 लेकिन आपकी बेहतर मीट्रिक के साथ एकमात्र समस्या यह है कि यह उपयोगकर्ता बग रिपोर्टिंग सिस्टम में सुधार नहीं करने के लिए एक प्रोत्साहन बनाता है ... विचार सही है, लेकिन शायद यह अधिक सामान्य होना चाहिए 'आधिकारिक परीक्षण प्रक्रिया के बाहर पाए जाने वाले कीड़े'

— user56reinstatemonica8

@ user568458 - मैं यह मान रहा था कि प्रश्न में संगठन के पास आंतरिक क्यूए और ग्राहक-सहायता समर्थन के लिए अलग-अलग टीमें थीं, और यह प्रश्न केवल आंतरिक क्यूए के साथ निपटा। यदि दोनों एक ही टीम हैं, तो आपको वास्तव में हितों का टकराव होगा (चाहे मेरी पद्धति का उपयोग किया जाए या नहीं)।

— BTA

Answer 4

गेम को बग ढूंढने से कुछ भी गलत नहीं है। आप लोगों को प्रेरित करने का एक तरीका मिल गया है। यह अच्छा है। यह प्राथमिकताओं को संप्रेषित करने में विफलता भी बताती है। प्रतियोगिता को समाप्त करना एक बेकार होगा। आपको प्राथमिकताओं को सही करने की आवश्यकता है।

कुछ वास्तविक खेलों में एक साधारण स्कोरिंग प्रणाली है। बग का शिकार क्यों करना चाहिए?

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

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

Answer 5

बग ढूंढना उनका काम है। जब तक वे चीजों को कम कुशल नहीं बना रहे हैं (उदाहरण के लिए, उनमें से कई को कवर करने के लिए एक के बजाय 10 टाइपो की प्रति के लिए एक बग को खोलकर) यह उन्हें वही करने के लिए प्रोत्साहित कर रहा है जो वे करने जा रहे हैं, इसलिए मैं एक नकारात्मक पहलू के ज्यादा नहीं देख सकता।

Comments

Moot के साथ अधिक सहमत नहीं हो सका। बेशक लोग कुछ बेवकूफी कर सकते हैं (टाइप 100 के टाइप्स आदि) - लेकिन किसी भी स्कीम का पालन करते समय "लोग कुछ बेवकूफी कर सकते हैं"।

— फेटी

Answer 6

यह @ CandiedOrange के उत्तर पर एक विस्तार है ।

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

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

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

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

Comments

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

— कैंडिड_ऑरेंज

Answer 7

क्या यह परियोजना के लिए अच्छा है?

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

यदि नहीं, तो मैं (एक सॉफ़्टवेयर डेवलपर के रूप में) परीक्षकों की टीम की सोच और दृष्टिकोण को बदलने की कोशिश कैसे कर सकता हूं?

अपने प्रोजेक्ट मैनेजर के साथ समस्या को उठाएं। उन्हें इस तरह की बात को अपनी नौकरी का हिस्सा मानना ​​चाहिए। यदि आपका पीएम अनिच्छुक है या उससे निपटने में असमर्थ है, तो आप अपनी खुद की नकल की रणनीतियों को विकसित करने में फंस जाते हैं। (जो एक अलग सवाल होगा)

Answer 8

मुझे लगता है कि यह कैसे होगा (या यह पहले से ही कैसा है) यदि यह इस तरह से चलता है, तो आपको आवश्यक रूप से निम्न गुणवत्ता नहीं मिलेगी। अल, हालांकि मुझे लगता है कि यह गुणवत्ता के अनुपात में मात्रा को कम कर देगा। यह निर्भर करता है कि यह बुरी बात है या नहीं। यह निर्भर करता है अगर

स्क्रीन संवर्द्धन, प्रयोज्य, या बेवकूफ कीड़े के बारे में रिपोर्टिंग बग।

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

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

Comments

मैं प्रयोज्य मुद्दों के बारे में जानना चाहता हूं। हम उन्हें "युक्ति में बग" के रूप में संदर्भित करते हैं।

— रबरडक

@ रुबरडैक अगर यह टीम के साथ 100% स्पष्ट है, तो उन्हें यह बताने का एक कारण है कि आपको यह बताना पसंद नहीं है कि वे क्या करते हैं और वे क्यों जानते हैं। इसलिए उन्हें चेतावनी दें। यदि टीम के साथ इस बारे में विशिष्ट रूप से बात नहीं की जाती है, तो मुझे नहीं लगता कि आप वास्तव में उन पर पागल हो सकते हैं और बस एक रिपोर्ट का उदाहरण दें जिसे आप अस्वीकार करते हैं और उन्हें बताएं कि आप इसे ऐसा नहीं चाहते हैं।

— लोको