सह-श्रमिकों को इकाई-परीक्षण लिखने के लिए कैसे प्रेरित करें? [बन्द है]


92

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

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

मैंने यूनिट-परीक्षणों के बारे में कुछ बैठकें कीं और मैंने यूनिट-टेस्ट लिखने के फायदे भी दिखाए। लेकिन किसी की दिलचस्पी नहीं दिख रही है।

Q1: मैं अपने साथी सहकर्मियों को इकाई-परीक्षण लिखने के लिए कैसे प्रेरित करूँ?

Q2: मैं अपने व्यक्तिगत कोड गुणवत्ता मानकों का पालन करने के लिए कैसे प्रेरित रहूं? (कभी-कभी यह वास्तव में निराशा होती है!)

पुनश्च: कुछ निराशाजनक तथ्य (1 वर्ष में पहुंच गए):

  • कुल इकाई-परीक्षण: 1693
  • कुल "उदाहरण इकाई-परीक्षण": लगभग 50
  • मेरे द्वारा किया गया: 1521

संपादित करें: क्या मुझे बहुत अधिक उम्मीद है? यह मेरा पहला कार्यस्थल है और मैं अपना सर्वश्रेष्ठ प्रदर्शन करने की कोशिश कर रहा हूं।

संपादित करें 2: सभी उत्तरों के आधार पर मैंने अपने लिए एक छोटी सूची बनाई है। मैंने प्राइवेट में दो डेवलपर से बात की है और हमने एक अच्छी और ईमानदार बात की है।

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

दूसरे ने कहा कि वह यूनिट-टेस्ट लिखने में दिलचस्पी नहीं रखता है। वह सोचता है कि उसके वेतन के लिए उसका काम काफी अच्छा है। वह अधिक प्रयास नहीं करना चाहता। मैं काफी अवाक था। ठेठ 9-5 "कार्यकर्ता"।

अगले हफ्ते मैं दूसरे डेवलपर्स से बात करने जा रहा हूं।

आपके महान जवाब (अब तक!) और आपके समर्थन के लिए धन्यवाद। मैं वास्तव में इसकी प्रशंसा करता हूँ! बहुत कुछ सीखा है, बहुत बहुत धन्यवाद!


पिछले 17 वर्षों में आपके द्वारा किए गए अन्य 172 यूनिट परीक्षण थे या कोई और यूनिट परीक्षण कर रहा है जिसे आप उनके योगदान को तुच्छ बता रहे हैं?
जेबी किंग

16
अन्य 172 यूनिट परीक्षण एक डेवलपर द्वारा किए गए थे जिन्होंने कंपनी छोड़ दी थी। sad :(
lurkerbelow

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

1
जिज्ञासा से बाहर, क्या आपके सहकर्मियों के पास वैकल्पिक डिबगिंग रणनीति है? टीडीडी यह साबित करने के लिए उपयोगी है कि कुछ उम्मीद के मुताबिक काम करता है, लेकिन अज्ञात मुद्दों के लिए इतना नहीं। वे केवल डिबगर में हुक करने के साथ सहज हो सकते हैं।
स्पेंसर रथबुन

3
परीक्षण उद्देश्यों के लिए डिबगर को हुक करना सही है, लेकिन यह सुनिश्चित नहीं करता है कि कोड कुछ दिनों / हफ्तों / महीनों में काम करेगा और यही वास्तविक मुद्दा है।
lurkerbelow

जवाबों:


48

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

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

लंबी कहानी छोटी, इस तरह की कुछ परिस्थितियाँ जैसे ट्रांसपायर्ड और 2 और डेवलपर्स टीडीडी / टेस्टिंग उत्साही बन गए (अभी भी कुछ और जाने बाकी हैं, लेकिन यह आशाजनक लग रहा है)।

सलाह के लिए, आप TDD काटा के साथ जा सकते हैं; सरल कार्य के रूप में करने का विरोध किया एक परीक्षण पहले दृष्टिकोण का उपयोग कर लागू करने के लिए कोई परीक्षण । कार्य कितना जटिल है, इसके आधार पर, गैर-परीक्षण दृष्टिकोण आमतौर पर धीमा होना चाहिए, विशेष रूप से वृद्धिशील आवश्यक परिवर्तनों के साथ:

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

  • समय लागू करने के लिए सुविधा (कोई परीक्षण नहीं लिखा गया था; मेरा मानना ​​है कि ऐसा अक्सर होता है इसलिए इस तरह के उदाहरण को ढूंढना अपेक्षाकृत आसान होना चाहिए)
  • टीडीडी के साथ सुविधा को लागू करने का अनुमानित समय (या दृष्टिकोण के बाद भी परीक्षण ; कोई फर्क नहीं पड़ता - क्या महत्वपूर्ण है इकाई परीक्षणों की उपस्थिति)
  • बगैर परीक्षण किए कोड पर बग को सुलझाने में समय व्यतीत होता है

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

उन उदाहरणों का परिणाम सरल प्रश्न होना चाहिए - यदि आप एक्स-घंटे के विकास की सुविधा वाई खर्च कर सकते हैं , तो इसे 2x में करने पर जोर क्यों देंगे ?


आपके सहयोग के लिए धन्यवाद। मुझे लगता है कि मैं katas के साथ एक TDD मीटिंग शेड्यूल करने जा रहा हूं। दो डेवलपर प्रति बैठक ताकि मैं संभव मदद कर सकूं। हाँ, सॉफ्टवेयर "काम करता है"। लेकिन बहुत सारे कीड़े "लौट" रहे हैं। यदि कोई मॉड्यूल A में कुछ ठीक करता है तो शायद कुछ मामलों में सबमॉड्यूल A1 अभ्यस्त काम नहीं करेगा। क्यूए के दौरान वे बग (अधिकतर) नहीं पाए जाते हैं। यही समय की बर्बादी है। लेखन इकाई परीक्षण: (हो सकता है) 1h। ग्राहक से बग रिपोर्ट, विश्लेषण, योजना, फिक्सिंग, कोड की समीक्षा, बिल्डिंग, हॉटफ़िक्स डिलीवरी, आदि के बारे में .. 6-8h।
lurkerbelow

चित्र के लायक 1000 शब्द और सभी। यह दिखाते हुए कि यह समय बचाता है, कहने की तुलना में अधिक आश्वस्त है इससे समय बचाना चाहिए
R0MANARMY

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

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

@ रोबर्टहवे: आप इसके बारे में सही हैं, "विकास" मेरी तरफ से खराब शब्द है। मैं सॉफ्टवेयर के एक टुकड़े को डिजाइन करने, कार्यान्वित करने, जारी करने और बनाए रखने की बेहतर प्रक्रिया के साथ कुछ भी नहीं कर सका । लंबे समय तक यूटी, इस प्रक्रिया को छोटा / सरल करें और यही मेरे दिमाग में था।
किमी

28

पहले आपको यह जानना होगा कि वे परीक्षण क्यों नहीं लिख रहे हैं।

तंग देव कार्यक्रम अक्सर कारण होता है, लेकिन आप कहते हैं कि आपके पास ऐसा नहीं है।

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

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

एक और मजबूत कब्ज है, क्योंकि वे वास्तव में अधिक काम के लिए कोई मूल्य नहीं देखते हैं, भले ही वे विचार के लिए होंठ सेवा दे रहे हों।

तो आप अलग-अलग कारणों से कैसे निपटते हैं?

कारण एक सरल है, उन्हें एक उदाहरण दिखाएं कि यह विकास के समय को कैसे बचाता है।

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

कारण 3 प्रशिक्षण है, सिर्फ दिखावा नहीं। उन्हें एक प्रशिक्षण वर्ग में परीक्षण लिखें।

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

कारण 4 को संबोधित करने का एक और तरीका यह है कि प्रबंधन इसे प्रक्रिया का हिस्सा बनाए और कोड कोड समीक्षा पास न करे जब तक कि परीक्षण भी कोड समीक्षा पास न करें। उन दर्द बिंदुओं में से एक के बाद या अधिमानतः कुछ दिनों में आपके पास एक नीति बनाने के बाद उनसे संपर्क करने के लिए सबसे अच्छा है।

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


9

मैं टीडीडी के लाभों को प्रदर्शित करके शुरू करूंगा । इकाई परीक्षण के लाभों को प्रदर्शित करने का प्रयास करें।

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

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

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

आगे पढ़ने के लिए अच्छा संदर्भ:


3
@lurkerbelow, ठीक है, और अब आपका अगला काम बग्स के लिए उन लोगों की निगरानी करना है - अपने बग ट्रैकर और कोड परिवर्तन पर नज़र रखें। यदि कोई बग नहीं हैं, तो आपके सहयोगी के पास एक बिंदु है। यदि भार हैं, तो आपके पास एक बिंदु है। किसी भी तरह से, आपके पास कुछ अनुभवजन्य साक्ष्य होंगे।
gbjbaanb

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

7

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

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

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


7

यह उदाहरण के द्वारा सीसे का एक बड़ा मामला लगता है ।

मानव स्वभाव के दो अंतर्निहित पहलू हैं जिनसे आप लड़ रहे हैं:

  • रचनात्मक लोगों को प्रक्रिया पसंद नहीं है।
  • ज्यादातर लोग अपनी गुणवत्ता पर बाहरी नकारात्मक निर्णय पसंद नहीं करते हैं।

व्याख्यान, प्रबंधन की घोषणा, या तर्क के साथ भी यह लड़ना बहुत कठिन है। आपको मानव प्रकृति के एक वैकल्पिक पहलू का लाभ उठाते हुए जीतना होगा।

  • लोग सबसे अच्छे कर्मचारियों के व्यवहार की नकल करते हैं

यदि सर्वश्रेष्ठ कर्मचारी टीडीडी का उपयोग करते हैं और यह काम करता है, तो प्रक्रिया का विस्तार होगा। यदि वे नहीं करते हैं, तो यह नहीं होगा। यदि आपको किसी को समझाने की आवश्यकता है, तो यह शीर्ष 1 या 2 कर्मचारी हैं।


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

3

उनसे पूछों।

आप कहते हैं कि लोगों को बताया गया है, और सहमत हैं कि उन्हें और परीक्षण लिखने चाहिए। वे क्यों नहीं हैं?

यह साधारण प्रेरणा का विषय हो सकता है (अक्सर बार नहीं)। वे उनके बारे में भूल सकते हैं। वे समय के दबाव में महसूस कर सकते हैं। वे शायद नहीं जानते कि अच्छे परीक्षण कैसे लिखें। वे सोच सकते हैं कि आप इतने अच्छे हैं कि उन्हें ऐसा करने की आवश्यकता नहीं है। मूल कारण जानने से आपको समस्या को बेहतर ढंग से हल करने में मदद मिलेगी।


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

2
मैं अन्य लोगों की "गलतियों" की ओर इशारा नहीं करना चाहता। हो सकता है कि मुझे निजी होने के दौरान चिट चैट करनी चाहिए, जैसे बीयर या दस। समय दबाव वास्तव में एक बिंदु नहीं है। हमारे पास पर्याप्त बफर समय के साथ एक शानदार कार्यक्रम है। (150% + अनुमानित)
lurkerbelow

2

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

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

दूसरा बड़ा विक्रेता QA चक्र है। अपनी कंपनी में टीडीडी के शुरू होने से पहले हम हर हफ्ते परीक्षण करने के लिए क्यूए के लिए नई रिलीज को आगे बढ़ाएंगे। वे उस रिलीज से बग का ढेर बना देंगे, हम उन बग को ठीक करते हैं और एक और रिलीज को आगे बढ़ाते हैं। समाप्त होने तक दोहराएं। पहली परियोजना जो हमने टीडीडी को की थी, उसे कई हफ्तों बाद तक क्यूए के लिए एक पुश आउट की आवश्यकता नहीं थी। और पाए जाने वाले कीड़े की संख्या बहुत कम है। एक समान परियोजना की तुलना में 10%। क्या आपके पास अपनी टीम के लिए उन आँकड़ों को संकलित करने के लिए वैसे भी है?

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

अंत में, उन्हें दिखाएं कि वे विश्वास के साथ कोड को कैसे रिफैक्ट कर पाएंगे।

जब आप परीक्षण लिखने का मन नहीं करते हैं, तो उसे ध्यान में रखें। :)


1

मैं HLGEM के उत्तर पर विस्तार करना चाहूंगा , विशेष रूप से इस खंड में:

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

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

पुराने कोड पर परीक्षण करने की कोशिश करना जो कि परीक्षण के साथ दिमाग में नहीं लिखा गया था, निराशा से परे हो सकता है।


1

मैंने कुछ तकनीकों का उपयोग किया है:

a) एक स्वचालित बिल्ड सेट करें। जब कोई आपके द्वारा परीक्षण की गई चीज को तोड़ता है, तो उन्हें दिखाएं कि परीक्षण ने यह कैसे पता लगाया और बग कितना खराब रहा होगा।

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

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


ग) मेरे मामले के लिए अच्छा लग रहा है
Nakilon

0

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


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

1
इकाई परीक्षण एकीकरण परीक्षण से अलग है। मेरा मानना ​​है कि डेवलपर एकीकरण परीक्षण के लिए भी जिम्मेदार है और क्यूए की भूमिका यह सुनिश्चित करने के लिए होगी कि सब कुछ क्रम में है (सत्यापन की सीमा तक वे प्रदर्शन कर सकते हैं)। बेशक, संस्करणों में समस्याएं हो सकती हैं, लापता टुकड़े, सर्वरों को कोड का वितरण आदि, जिन्हें जल्दी पकड़ा नहीं जा सकता है, लेकिन इनका आवश्यकताओं या इकाई परीक्षण से कोई लेना-देना नहीं है।
NoChance
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.