परीक्षक-डेवलपर संचार


9

जबकि डेवलपर-डेवलपर, डेवलपर-क्लाइंट, डेवलपर-टीम मैनेजर संचार के बारे में बहुत कुछ लिखा गया है, मुझे कोई भी पाठ नहीं मिला जो परीक्षक-डेवलपर संचार और संबंध के बारे में दिशानिर्देश देता है।

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

किसी भी सलाह या अध्ययन के बारे में कि एक परीक्षक को डेवलपर्स के साथ कैसे संवाद करना चाहिए?

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


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

जवाबों:


11

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

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

इसका मतलब है कि जब मैं "काम एक साथ" के बारे में बात करता हूं। मुझे पूरा यकीन है कि एक टीम में संचार कैसे होना चाहिए। यह लेख इसे बहुत अच्छी तरह से समझाता है btw।

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


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

11

मैं देव और परीक्षण के बीच किसी भी तरह के संचार में दृढ़ विश्वास रखता हूं।

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

मैं हमेशा परीक्षकों को बताता हूं कि मैं उनके साथ काम करने और बोलने के लिए काम करता हूं, अगर उन्हें कोई संदेह है।

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


1
"बन फाइट" क्या हैं? :)
मार्की

1
+1 मैं अपने वर्तमान प्रोजेक्ट पर क्यूए लीड के साथ बहुत निकटता से काम करता हूं, और मुझे लगता है कि यह मेरी उत्पादकता के लिए बेहद फायदेमंद है। मैं भाग्यशाली हूं कि वह एक पूरी तरह से योग्य डेवलपर भी हैं, और वह अक्सर दोषों के समाधान का सुझाव देते हैं जो उन्हें पता चलता है।
एडम क्रॉसलैंड 14

1
बन फाइट = बन्स पर लड़ना .... बन = केक
ओज

2
केक मेरे कार्यालय में लड़ने लायक एकमात्र चीज है।
जेफ़ओ

2
.... केक है?
दान रे

4

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


2
+1 - और मैं इसे +1000 देना पसंद करूंगा। सॉफ़्टवेयर के निर्माण में डेवलपर्स महान हैं , लेकिन अक्सर वे जो भी बनाते हैं उसका उपयोग करने में विशेषज्ञ नहीं हैं । जब आप बग को ठीक करने के लिए बंदूक के नीचे एक डेवलपर होते हैं, और बग रिपोर्ट में स्पष्ट, प्रजनन निर्देशों का पालन करना आसान नहीं होता है, और जिस परीक्षक ने रिपोर्ट की थी वह उपलब्ध नहीं है, जीवन नरक है - और यह सच है चाहे आपका ईजाइल हो या कोई अन्य कार्यप्रणाली। अपनी बग रिपोर्ट लिखें जैसे कि आपकी दादी को प्रजनन करना था, और जीवन अच्छा होगा।
बॉब मर्फी

4

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


1
क्या अंत में एचआर उल्लंघन हुआ था?
नौकरी

नहीं, इस तरह के रूप में मानव संसाधन उल्लंघन नहीं था।
राहेल

3

चूँकि आपने कहा था कि आप एक फुर्तीले वातावरण में एक मात्र परीक्षक हैं (स्क्रेम को मानते हुए) संभवत: पूर्वव्यापी बैठक का उपयोग खुले मंच के रूप में किया जा सकता है ताकि संचार की प्रक्रिया को परिभाषित किया जा सके।

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

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

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


2

मैं उसी टीम के हिस्से के रूप में परीक्षकों को देखना पसंद करता हूं। उस संबंध में संचार का कोई मुद्दा नहीं है।

जब भी किसी टेस्टर को किसी डेवलपर से बात करनी होती है या अन्य तरीके से बस आती है और चलो एक चैट करते हैं। बस रोज की दिनचर्या।

हालांकि, दोनों पक्षों को एक-दूसरे का सम्मान करना होगा और अपना काम ठीक से करना होगा।

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

डेवलपर्स को बग रिपोर्ट को गंभीरता से लेना होगा और गहनता से जांच करनी चाहिए कि यदि आप बग को पांच क्लिक में पुन: पेश नहीं करते हैं तो समस्या को बंद करें।

पेशेवर रवैया यह सब लेता है।


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

1
@ एरॉन: आप सही कह रहे हैं। हालाँकि यदि आप परीक्षकों को अपने पैरों के नीचे एक निचली परत के रूप में देखने का निर्णय लेते हैं तो संचार संबंधी समस्याएं उत्पन्न होंगी

..मैं युक्ति लेता हूँ ... "क्या आपने आज एक परीक्षक को गले लगाया है?" यह अद्भुत काम करता है।
हारून McIver

2

नंबर 1 टूल जो मैंने पाया है कि मैं, एक परीक्षक (एसडीईटी) के रूप में, देव-परीक्षण संबंधों को बेहतर बनाने के लिए लाभ उठा सकता हूं, ईमानदार चापलूसी है, खासकर देवों से सलाह लेने के रूप में।

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

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


2

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

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

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