परीक्षक और प्रोग्रामर एक दूसरे को पसंद क्यों नहीं करते? [बन्द है]


18

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

क्या यह मेरे द्वारा किया गया सही निर्णय है, यह क्यों है, और इन प्रकार की समस्याओं से बचने के लिए हम क्या कर सकते हैं?


टिप्पणीकार: टिप्पणियां स्पष्टीकरण मांगने के लिए होती हैं, न कि विस्तारित चर्चा के लिए। यदि आपके पास एक समाधान है, तो एक उत्तर छोड़ दें। यदि आपका समाधान पहले से ही पोस्ट किया गया है, तो कृपया इसे बढ़ाएँ। यदि आप अन्य लोगों के साथ इस प्रश्न पर चर्चा करना चाहते हैं, तो कृपया चैट का उपयोग करें । अधिक जानकारी के लिए FAQ देखें ।

जवाबों:


50

मुझे लगता है कि यह सामान्यीकरण और सरलीकरण से अधिक है।

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

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

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

संपादित करें

यह भी ध्यान दें, कि मुझे लगता है कि दोनों के बीच संबंधों का समर्थन करने के लिए देवता की तुलना में परीक्षार्थी अधिक है।

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


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

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

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

28

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

समस्याएं क्यों बढ़ती हैं?

  • आप लगातार कर रहे हैं पहचानने एक दूसरे के काम करते हैं, और कुछ लोगों को किसी भी तरह का नहीं ले जा सकते critism
  • एक बुरा काम कर बरबाद करती है अपने विपरीत के समय
  • आप दोनों दबाव में हैं, एक ही समय में, एक ही चीज़ के लिए और कोई भी चीज़ों को पकड़ना नहीं चाहता है

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


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

16

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

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


2
माना। पहले दिन से ही परीक्षकों को विकास का हिस्सा बनाना (योजना और डिजाइन के दौरान परीक्षण बनाना) घर्षण से बचने में बहुत मदद करता है।
मार्टिन विकमैन

3
कार्यक्रम को बेहतर बनाने के तरीके खोजने में खामियों को खोजने से दृष्टिकोण को बदलने के लिए कुंजी है । एक परीक्षक के रूप में इस विचार को पकड़ना आसान है कि दोष ढूंढना आपका प्राथमिक लक्ष्य है।
eda-qa मोर्ट-ओरा-वाई


"बीयूज़" -> "क्योंकि"
पीटर मोर्टेंसन

8

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

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

मुझे लगता है कि व्यक्तित्व को इससे बाहर रखना और हाथ पर काम को केंद्रित करना तनाव को कम करने का एक लंबा रास्ता तय करता है। यदि कोई संगठन पर्याप्त बड़ा है, तो डबल ब्लाइंड परीक्षण एक महान विचार है।

एक परीक्षक जो स्पष्ट रूप से समस्याओं को व्यक्त कर सकता है, और कोडर जो स्पष्ट रूप से समाधान लागू करते हैं, एक महान टीम है।


5

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

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

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

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


5

जब प्रोग्रामर और परीक्षक एक-दूसरे को पसंद नहीं करते हैं, तो अक्सर ऐसा होता है क्योंकि वे गलती से कल्पना करते हैं कि उनका लक्ष्य संघर्ष है।


3

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

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

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


3

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

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

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

इसके अलावा कुछ डेवलपर्स QA को देखते हैं। फिर भी मैं बहुत बजाय QA ग्राहक की तुलना में एक दोष मिल जाएगा ....


2

हम यहां अपने परीक्षकों से प्यार करते हैं, लेकिन फिर हममें से कई लोग यह याद करते हैं कि हमारे पास पहले जैसा था, वैसा ही था। ओह ओह यह बेहतर है कि परीक्षकों को समस्याओं का पता लगाने की तुलना में आपके पास उत्पादन के लिए जाने के बाद ग्राहक मिल जाए। वहाँ एक डेवलपर जीवित नहीं है जिसने बग नहीं बनाया है या किसी आवश्यकता का गलत अर्थ नहीं लगाया है।

सभी पेशेवरों को विनम्रता और सम्मान के साथ व्यवहार करना है कि वे क्या करते हैं या नहीं। एक बार जब आप सोचने लगते हैं कि आपकी नौकरी उनकी तुलना में बेहतर या महत्वपूर्ण है तो आप हार गए हैं।

इस प्रश्न के आधार पर: सॉफ्टवेयर परीक्षण तकनीक या श्रेणियाँ मुझे संदेह है कि आपको सामान्य तौर पर परीक्षकों और परीक्षण के प्रति दृष्टिकोण समायोजन की आवश्यकता है।


2

एक डेवलपर के रूप में, मैंने परीक्षकों के साथ तनाव में अपने हिस्से का अनुभव किया है।

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

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

मैंने कुछ डेवलपर्स को भी जाना है जो परीक्षकों को दुश्मन मानते हैं - जैसे कि परीक्षक दोषों का परिचय दे रहे हैं। डेवलपर्स के लिए यह समझना महत्वपूर्ण है कि परीक्षक कभी भी गलती का परिचय नहीं देते हैं - वे इसे उजागर करते हैं।


1

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


1

एक आवश्यकता की सही व्याख्या दोनों पक्षों में हठ है, जहाँ मैं डेवलपर्स और परीक्षकों के बीच आम तौर पर संघर्ष देखने के लिए प्रवृत्त होता हूँ। हालांकि वहाँ झपकी या अहंकार की उपस्थिति हो सकती है, यह सिर्फ इतना है कि प्रत्येक पक्ष अपनी बंदूकों से चिपक जाता है और सही होना चाहता है।

इस समस्या से बचने का एक अच्छा तरीका यह है कि 3 पक्ष, डेवलपर, परीक्षक और कुछ मध्यस्थ या तो एक व्यापार विश्लेषक या परियोजना प्रबंधक काम करें, जिसके माध्यम से विभिन्न सीमा मामलों को कैसे नियंत्रित किया जाना चाहिए। डेवलपर्स और परीक्षकों के बीच असहमति होने पर विचार करने के लिए किस तरह का अहंकार पैदा हो सकता है।


1

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

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

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

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

बुरा जीजू।


1

यह अक्सर तीन कारकों से उत्पन्न होता है -

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

1

मुझे परीक्षक पसंद हैं, लेकिन दो मामलों में मैंने संघर्ष पाया है।

  1. जब प्रबंधन परीक्षक खेलते हैं और एक दूसरे से दूर हो जाते हैं।

  2. जब मुद्दों को लगातार प्रस्तुत किया जाता है, जिसमें विस्तार की कमी होती है, अर्थात "स्क्रीन x काम नहीं करता है"।


0

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

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

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