अपनी छुट्टी के दिन एक परीक्षक सहकर्मी को न हटाने के 7 टिप्स

आज, दुनिया परीक्षक का दिन मनाती है। इस अवसर पर, हमने इन विशेषज्ञों के कार्य को विभिन्न दृष्टिकोणों से देखने में आपकी सहायता करने का निर्णय लिया, ताकि सहयोग से सभी प्रतिभागियों को अधिकतम लाभ और न्यूनतम तनाव मिले।

_{फोटो क्रेडिट : डेविड गोह्रिंग सीसी बाय}

1. "फिर से डबल-चेक करें, निश्चित रूप से कोई बग नहीं है"

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

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

कैसे हो : यह आसान है: यदि परीक्षक को आपके कोड में कोई दोष मिला और आप समझते हैं कि वह सही है, तो इस तथ्य को स्वीकार करना बेहतर है। आप दोनों का लक्ष्य एक है और एक ही लक्ष्य है - एक डिबगिंग और काम करने वाले उत्पाद को जारी करना। हास्य इस मुद्दे पर एक समझ में आने में मदद करता है। यहाँ एक लेख है जिसमें परीक्षक अपने कोड की सुरक्षा करने की कोशिश कर रहे डेवलपर्स द्वारा बयानों का "गोल्डन फंड" एक साथ रखते हैं। हम आपको उनके ऊपर जाने की सलाह देते हैं और कल्पना करते हैं कि ये "क्लासिक" वाक्यांश परीक्षक के दृष्टिकोण से कैसे ध्वनि करते हैं।

2. "रिलीज से एक सप्ताह पहले। मुझे उम्मीद है कि आपने अगले दो दिनों के लिए अन्य चीजों की योजना नहीं बनाई होगी। ”

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

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

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

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

_{फोटो: टिम रेगन सीसी बाय}

3. "मैंने जल्दी से कोड को घुमा दिया। देखो, कृपया। ”

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

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

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

4. "ऐसा लगता है कि मैं पहले ही इस बग से निपट चुका हूं। लेकिन मुझे बिल्कुल याद नहीं है ”

कभी-कभी एक सतही दृष्टिकोण एक प्रणालीगत समस्या है। कुछ टीमों में, बग रिपोर्ट समय और स्थान में खो जाती हैं। कोई भी रिपोर्ट का ठीक से जवाब नहीं दे रहा है, यह नहीं चिह्नित कर रहा है कि समस्या हल हो गई है या अभी भी सीमित है।

क्या गलत हो सकता है : डेवलपर्स किसी तरह के बग को ठीक करते हैं, जो सोचते हैं कि वे कोड में "मामूली" बदलाव करते हैं, इस बारे में परीक्षकों को सूचित करना भूल जाते हैं और कोड को रिलीज़ पर भेजते हैं। नतीजतन, समस्या बहुत देर होने पर पॉप अप हो जाती है। और परीक्षक अक्सर "चरम" होता है।

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

_{फोटो: टिम रेगन सीसी बाय}

5. "मुझे इसका परीक्षण क्यों करना चाहिए? मैं कोई परीक्षक नहीं हूँ! "

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

क्या गलत हो सकता है : इस स्थिति में परीक्षकों को एक पंक्ति में सभी कमियों से निपटना पड़ता है - यहां तक ​​कि सबसे आदिम और बेवकूफ गलतियों के साथ। बेशक, यह कष्टप्रद है।

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

6. "इगोर, आज आप ओलेग के साथ मिलकर काम करते हैं। आप इसे पसंद करेंगे

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

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

कैसे हो : मुख्य सलाह आपके कंधे को काट देना नहीं है। चुस्त और DevOps प्रथाओं आकर्षक लग सकता है, लेकिन उचित तैयारी के बिना वे काम नहीं करेंगे।

7. "मैं आपके डिवाइस को परीक्षणों के लिए ले जाऊंगा, क्या आपका मन करता है?"

डेवलपर के पास डिबगिंग शुरू करने का समय है, वह परीक्षक से "डिवाइस पर शाब्दिक रूप से 20 मिनट के लिए" पूछता है और लंबे समय तक इसे छोड़ देता है।

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

कैसे हो : अपने आप को रिमाइंडर, स्टिकर्स चिपकाएं, कुछ भी करें, लेकिन टेस्टर्स की चीजों को उनकी जगह और समय पर वापस करें।

_{फोटो: डेव एलन सीसी बाय}

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