आप यूनिट परीक्षणों में प्रबंधन को "निवेश" करने के लिए कैसे मना करते हैं?


45

आपने अपने प्रबंधक को इकाई परीक्षण करने के लिए कैसे मना लिया?

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

विशिष्ट प्रबंधन आपत्तियां हैं:

  1. ग्राहक ने यूनिट परीक्षणों के लिए भुगतान नहीं किया
  2. परियोजना इकाई परीक्षण के लिए समय की अनुमति नहीं देती है
  3. तकनीकी ऋण? क्या तकनीकी ऋण?

क्या आप अन्य आपत्तियों को जानते हैं? आपके जवाब क्या थे?

अग्रिम में धन्यवाद!


6
इस बहुत विषय के बारे में artofunittesting.com में एक पूरा अध्याय है ।
स्टुपरयूसर

6
परीक्षण और TDD, कृपया मिश्रण मत करो ! यह लोगों को लगता है कि जब तक वे TDD नहीं करते उन्हें परीक्षण की आवश्यकता नहीं है!
पी शेव्ड

1
जिन लोगों को समझाने की जरूरत है, वे समझाने से परे हैं। अपने परिदृश्य को एक खो कारण पर विचार करें।
मार्क कैनलास

@ पावेल, पहले तो मुझे लगा कि आप नाइटपैकिंग कर रहे हैं, लेकिन आप सही हैं। मैं इकाई परीक्षण, अवधि के लिए "अनुमति" चाहता हूं। टीडीडी मेरी अपनी चीज है।
लुइसगैब

6
अपेक्षा के अनुसार आपको अपने कोड कार्यों को सत्यापित करने की अनुमति प्राप्त करने की आवश्यकता क्यों महसूस होती है?
जाप

जवाबों:


25

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

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

संक्षेप में, मैंने परियोजना के लिए वास्तविक घंटों के खिलाफ हमारे अनुमानित घंटों की तुलना की और फिर हमारी दोष दर की तुलना अन्य टीमों की दोष दर से की। हमारे मामले में इन नंबरों की तुलना अनुकूल रूप से हुई और अधिक चिंताएं नहीं थीं।

इस अनुभव के आधार पर मेरा निष्कर्ष है:

... किसी को यह समझाने का सबसे अच्छा तरीका है कि कुछ करने के लिए आपका दृष्टिकोण व्यावहारिक और व्यावहारिक है, इसे करना है और इसे अन्य तरीकों के खिलाफ मापना है। लोग हठधर्मिता की परवाह नहीं करते हैं, या आपको क्यों लगता है कि कुछ सबसे अच्छा तरीका होना चाहिए। केवल लोगों को संख्या दिखाने और आपके दृष्टिकोण की प्रभावशीलता को मापने से आप वास्तव में दिखा सकते हैं कि आपकी प्रथाएं प्रभावी हैं।

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

इसलिए आपके मामले में, यदि आवश्यक हो तो मैं इसे चुपके से करूंगा (शायद कोड का एक छोटा क्षेत्र है जिसे आप परीक्षण करना शुरू कर सकते हैं कि अक्सर परिवर्तन होता है या जो आप के लिए जिम्मेदार हैं), लेकिन अपने नंबर पर नज़र रखें - क्या है अपने परीक्षण बनाने के लिए प्रयास? दोष दर क्या है? यह अन्य परियोजनाओं / टीम के सदस्यों के साथ कैसे तुलना करता है?

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


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

जो, डेडलिंक के बारे में क्षमा करें। मैंने अपने व्यक्तिगत ब्लॉग पर इसे रीपोस्ट किया है, इसलिए लिंक को अब काम करना चाहिए।
20 दिसंबर को पैड्सस्लैकर

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

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

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

20

निवेश पर रिटर्न (ROI) दिखाएं

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

उदाहरण: मैन्युअल रूप से परीक्षण सुविधा X को 30 मिनट लगते हैं। इसके लिए एक स्वचालित परीक्षण लिखने में 1 घंटा लगेगा। यहां तक ​​कि अगर हमारे पास कोई बग नहीं है, तो हमें परियोजना के दौरान सुविधा एक्स को दस बार परीक्षण करना होगा क्योंकि इसकी निर्भर परतें और घटक संशोधित हैं। इसलिए सुविधा X के परीक्षण को स्वचालित करने से हमें परियोजना के जीवन पर 4 घंटे की बचत होगी।

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

व्यवसाय समय और धन की बचत को समझते हैं। इसे कैसे बेचना है।


3
इसके अलावा, एक बार एप्लिकेशन को तैनात करने और कोई व्यक्ति परिवर्तन के लिए कहता है, तो यह देखना बहुत आसान है कि क्या आप अपने परिवर्तनों के साथ कुछ भी तोड़ रहे हैं।
m4tt1mus 22

4
@ मटिमस: बिल्कुल - एक स्वचालित परीक्षण सूट एक वार्षिकी की तरह भुगतान करता है; यह वास्तव में, बीमा है
स्टीवन ए। लोव 22

15

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

प्रबंधन कोड की पंक्तियों की गणना करने वाला नहीं है, लेकिन वे देखेंगे कि आपके सभी चेकइनों में QA (या ग्राहकों) से उच्च पास दर हैं और वे अंततः पूछेंगे कि क्यों ... तो आप सभी "BAM! TD!" ! "

आप परियोजना, प्रक्रिया या स्रोत के साथ खिलवाड़ नहीं कर रहे हैं ... इसलिए मुझे नकारात्मक कारण नहीं दिख रहा है। ईमानदारी से, मुझे कोई कारण नहीं दिखाई देता है कि यह आपके सभी मैनुअल रन + इनपुट + जाँच परिणामों के परीक्षण की तुलना में अलग-अलग समय-वार है।


4
+1: आपको वैसे भी परीक्षण करना होगा। "परीक्षण" कैसे किया जाना चाहिए, इस बारे में वक्रोक्ति के बजाय केवल यूनिट परीक्षण लिखें।
S.Lott

1
बस उन्हें स्थानीय रूप से साझा कोड आधार के साथ टीम के माहौल में अच्छा काम नहीं करता है, अन्य लोग अपने परिवर्तनों के साथ आपके परीक्षणों को तोड़ते रहेंगे।
एल्ब

3
@ एएलबी: यह वह मूल्य है जो आप भुगतान करते हैं जब प्रबंधन बोर्ड पर नहीं मिलता है - हालांकि बिना किसी परीक्षण से बेहतर।
स्टीवन एवर्स

3
वाहवाही। कोई भी परीक्षा बिना परीक्षा से बेहतर है। यदि किसी और के परिवर्तन के कारण परीक्षण टूट जाता है, तो यह पूछने का एक अच्छा कारण है कि एपीआई बिना किसी घोषणा के क्यों बदल गया।
एसएलटी 4

"प्रबंधन कोड की पंक्तियों को गिनने वाला नहीं है" यह बहुत सही है। जवाब के लिए धन्यवाद!
लूइसगैब

7

1) ग्राहक ने यूनिट परीक्षणों के लिए भुगतान नहीं किया

ग्राहक (सोचा कि वे) एक काम कर समाधान के लिए भुगतान किया। दोषों को ठीक करने वाले अनुबंधों के आधार पर वास्तव में आपकी कंपनी के लिए लाभदायक हो सकता है। अगर वहाँ पर्याप्त ताला है। तो एक काम के समाधान के लिए भुगतान करने के लिए वापस जा रहा है। टीडीडी को उस लक्ष्य की सहायता करनी चाहिए।

2) परियोजना टीडीडी के लिए समय की अनुमति नहीं देती है

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

3) तकनीकी ऋण? क्या तकनीकी ऋण?

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

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

मैं उन नए बिंदुओं को बढ़ाने के बजाय आपके द्वारा बताए गए विशिष्ट बिंदुओं को संबोधित कर रहा हूं क्योंकि प्रगति करने के लिए वहां कोई रास्ता नहीं है या यह समझने के लिए कि इसे कॉकब्लॉक क्यों किया जा रहा है।


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

1
जिसने भी सुविधाओं / सुधारों को जोड़ा और इकाई परीक्षणों को अद्यतन नहीं किया वह इकाई परीक्षण की अवधारणा को नहीं समझ पाया।
अकीरा यामामोटो

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

4

उत्पादन के मुद्दों का सामना करने वाले प्रत्येक ग्राहक के लिए,

  1. एक इकाई परीक्षण लिखें और प्रबंधक को यह कहते हुए एक ईमेल भेजें कि आपने परिदृश्य को कवर करने के लिए एक इकाई परीक्षण जोड़ा है।

  2. और उसे बताएं कि यह मुद्दा फिर से उत्पादन में नहीं होगा क्योंकि हमारी यूनिट का परीक्षण रात में चल रहा है और हमें पता चलेगा कि इस यूनिट की परीक्षण विफलता को देखने से पहले कोड उत्पादन में जाता है।

  3. उसे बताएं कि अगर कोड के उत्पादन में जाने से पहले ही हमारे पास इस यूनिट का परीक्षण होता, तो यह उत्पादन मुद्दा कभी नहीं होता।

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


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