2009-05-11 22 views
5

मैं एक विकास टीम में एम्बेडेड एक सॉफ्टवेयर परीक्षण इंजीनियर हूं। मेरे काम का एक बड़ा हिस्सा परियोजना के स्वचालित परीक्षण (मुख्य रूप से इकाई/एकीकरण परीक्षण) की स्थिति की जांच करना शामिल है।स्वचालित परीक्षण: डेवलपर्स की सहायता और शिक्षित करने के तरीके?

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

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

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

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

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

मेरा प्रश्न है: जब टीम की सहायता करने की बात आती है, तो क्या मैं कुछ बेहतर कर सकता हूं? आपको क्या दृष्टिकोण मिले हैं जो फायदेमंद हो सकते हैं?

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

* संपादित करें: उत्तर के लिए धन्यवाद; उनमें से सभी उपयोगी सुझाव थे। मैंने शीर्ष को सबसे अच्छा जवाब के रूप में चिह्नित किया क्योंकि मुझे लगता है कि यह डेवलपर समर्थन के लिए नीचे आता है, और जोड़ी प्रोग्रामिंग कुछ ऐसा है जो मैंने अभी तक नहीं किया है (परीक्षणों के बाद कुछ अचूक 'यहां मैं यह कैसे करूँगा' प्रदर्शनों से कम लिखा हुआ)। मैं किसी ऐसे व्यक्ति के साथ जाऊंगा जो कुछ परीक्षण करने के साथ संघर्ष करता है :) चीयर्स।

+1

आपकी वर्तमान प्रक्रिया मेरे लिए अच्छी लगती है: मुझे नहीं लगता कि इसे कैसे सुधारें। – ChrisW

+1

इसी प्रकार के प्रश्न: http://stackoverflow.com/questions/581589/introducing-unit-testing-to-a-wary-team और http: // stackoverflow।कॉम/प्रश्न/416231/कैसे करें-आप-persuade- दूसरों को लिखने के लिए-इकाई-परीक्षण –

+0

धन्यवाद, मैं उन पर ध्यान दूंगा। –

उत्तर

5

यदि आपके पास कुछ लोग हैं जो परीक्षण में कमजोर होते हैं, तो उनके साथ बैठें, प्रोग्रामिंग, सॉर्ट करें, और जैसे ही वे अपने कोड पर काम करते हैं, आप उन्हें यह देखने में सहायता कर सकते हैं कि वे इसका परीक्षण कैसे कर सकते हैं।

थोड़ी देर के बाद इन लोगों को यूनिट परीक्षण में बेहतर होना चाहिए, और इस पर आपके काम का भार कम होना चाहिए।

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

आपको टीम की लीड के काम को भी शामिल करना चाहिए, क्योंकि यह सुनिश्चित करने के लिए कि हर कोई परीक्षण अच्छी तरह से लिखने के तरीके को समझता है, उसकी जिम्मेदारी का हिस्सा है या होना चाहिए।

+0

जोड़ी प्रोग्रामिंग सुझाव अच्छा है। मैं निश्चित रूप से यह कोशिश करूंगा :) –

1

कुछ बातें मुझे क्या करना चाहते हैं:

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

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

+0

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

+1

मार्क- मैं संरचित * और * कुकबुक के लिए जाऊंगा। सामान्य इकाई परीक्षण सिद्धांत और आपकी कंपनी – tddmonkey

1

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

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

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

+0

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

+1

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

1

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

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

संबंधित मुद्दे