डेवलपर्स और परीक्षकों के झगड़े के बारे में किस्से एक बार सच थे, लेकिन अब आप शायद ही ऐसे संघर्षों को पूरा कर सकते हैं। सॉफ्टवेयर रिलीज पर शांत सहयोग, सामान्य लक्ष्यों पर ध्यान केंद्रित, ब्ला ब्ला ब्ला ...
लेकिन अगर आप बारीकी से देखते हैं, तो उत्पादक सहयोग की उपस्थिति अक्सर डेवलपर्स की समझ की पूर्ण कमी को छिपाती है: "ये परीक्षक बिल्कुल क्यों हैं ??"। यह गलतफहमी अक्सर आपसी है, और स्पष्ट शांति के बावजूद, यह संयुक्त कार्य में केवल उत्पादकता की उपस्थिति को छोड़ देता है।
ऐसा क्यों हो रहा है?
1. कुछ योग्य परीक्षक हैं।यह डेवलपर्स के भारी बहुमत के प्रति डेवलपर्स की ओर से काफी अपेक्षित नकारात्मक रवैया का कारण बनता है, जिन्हें "योग्य" के रूप में वर्गीकृत नहीं किया जा सकता है।
2. परीक्षण हमेशा फायदेमंद से बहुत दूर है।सामान्य तौर पर, परीक्षण की प्रभावशीलता का मूल्यांकन करना मुश्किल है। हर परियोजना समझ और मापने योग्य परीक्षण उद्देश्यों का दावा नहीं कर सकती है। इसलिए, परीक्षक अक्सर "अधिक बग, बेहतर" पर विचार करते हैं। लेकिन पाया दोष अच्छे नहीं हैं!
3. परीक्षण अक्सर विकास से "समय लेता है"।उत्पाद, इसकी वास्तुकला में गहराई से उतरने के लिए, सही परीक्षक अनिवार्य रूप से डेवलपर्स में खोदते हैं। खैर, यह कौन प्यार करता है? :)
4. पीएम अक्सर आग में ईंधन डालते हैं, "क्या कोई बग है?" तय किया जाना चाहिए! ”लेकिन सब कुछ तय करने की जरूरत नहीं है, और विशेष रूप से सब कुछ तय करने की जरूरत नहीं है। कई डेवलपर्स जो इसे समझते हैं वे आरएम के साथ बहस करने के बजाय दोष को छिपाना पसंद करते हैं।
5. कुछ डेवलपर्स कीड़े होने के बारे में परेशान हैं।इसके अलावा, सिद्धांत रूप में, तार्किक। मैंने कोशिश की, मैंने कोशिश की, और फिर बम - गलतियों! हम सचेत रूप से समझते हैं कि यह सही है और इस तरह से हम सॉफ्टवेयर को बेहतर बनाएंगे, लेकिन यह अवचेतन रूप से अप्रिय है और मैं एक पुनरावृत्ति को रोकना चाहता हूं।
परिणाम क्या है?
परिणाम एक दुष्चक्र है। उपरोक्त पांच कारणों (और संभवतः केवल उन्हें नहीं) के कारण, डेवलपर्स का मानना है कि उन्हें परीक्षण की आवश्यकता नहीं है। नतीजतन, वे परीक्षण का समर्थन नहीं करते हैं जैसा कि इसे करना चाहिए। नतीजतन, परीक्षक अपना अधिकतम नहीं बना पाते हैं, और यह सब समान कारणों की पुनरावृत्ति की ओर जाता है।
मानक योजना में, जब डेवलपर्स लिखते हैं और लिखते हैं, और तब परीक्षकों को परीक्षण (उत्पाद!) के लिए एक उत्पाद देते हैं, एक बड़ा घात होता है। उदाहरण के लिए, तीन महीने, विकास का आधा साल, कुछ आकार लेने से पहले पारित किया जो एक कस्टम उत्पाद की तरह दिखता था। इस उत्पाद का परीक्षण परीक्षकों द्वारा किया जाता है। वे गैस दोष बनाते हैं जो स्पष्ट नहीं हैं कि कैसे (और डेवलपर्स, खराब कीड़े पर संभोग करना, एक लंबे समय के लिए पता करें कि क्या और कहां गलत है)। इसे स्थानीय बनाना मुश्किल है, इसे ठीक करना मुश्किल है, और सबसे खराब यह है कि कीड़े दिखाई देते हैं और दिखाई देते हैं। कल रिलीज? और यहाँ आपके 10 और आलोचक हैं! शीत युद्ध शुरू होता है :) रिहाई पर चला गया? और बग सभी हैं और हैं।
और परीक्षण की बेकारता में राय की पुष्टि की जाती है, और सब कुछ एक सर्कल में चला जाता है।
क्या परीक्षण ऐसे स्वादिष्ट और स्वस्थ के विकास को दे सकता है?
वास्तव में, स्पष्ट परीक्षण उद्देश्यों की अनुपस्थिति में, घटनाओं के उपरोक्त विकास में आश्चर्य की बात नहीं है। लेकिन यह अलग तरह से होता है। सौभाग्य से :)
कोई भी प्रोजेक्ट जितना जल्दी संभव हो उतना सफल और उच्च गुणवत्ता के साथ जारी करना चाहता है। बेशक, किसी उत्पाद में दोषों के बारे में जानकारी किसी उत्पाद की स्थिति का आकलन करने में मदद करती है, लेकिन क्या यह लॉन्च करने में तेज़ और अधिक सफल है? शायद ही।
क्या मदद करता है?
1. परीक्षण लक्ष्यों का औपचारिककरण।क्यों जरूरी है? परिणामस्वरूप आप क्या प्राप्त करना चाहते हैं?
यदि आप शुरू में इस विचार के साथ आते हैं कि "अच्छी तरह से, परीक्षण से कोई लाभ नहीं है", तो यह नहीं होगा। और अगर आप में बदल जाते हैं, अपने शलजम, मंथन खरोंच, मन meeps आकर्षित, आप हमेशा यह पता लगा सकते हैं कि यह आपके लिए सबसे सही कैसे होना चाहिए। लेकिन यहां सफलता की कुंजी केवल एक निर्माण की उपस्थिति नहीं है, बल्कि विकास और परीक्षण का एक बहुत तंग सहयोग है।
2. विकास के पहले दिनों से परीक्षण।यह वह चीज है जो लगभग किसी भी डेवलपर से चलती है। लेकिन व्यर्थ में। डेवलपर का तर्क आमतौर पर इस प्रकार है: "मेरे पास अभी तैयार उत्पाद नहीं है, कुछ भी परीक्षण करने की आवश्यकता नहीं है!"। लेकिन तैयार उत्पाद में बग्स को ढूंढना अधिक कठिन है, बाद में, लंबे समय तक, और उन्हें ठीक करना भी अधिक कठिन है! जैसे ही पहला घटक कम से कम स्थिर इंटरफेस के साथ दिखाई देता है, इसे जांचने की आवश्यकता है!
घटक परीक्षण और क्या देता है?
- साधारण बगिया। समस्याओं को लंबे समय तक स्थानीय करना आवश्यक नहीं है, आप तुरंत देख सकते हैं कि कुछ गलत कहां है।
- छिपे हुए दोषों का पता लगाना। जटिल वास्तुकला के साथ एक बड़े उत्पाद में, निचले स्तर पर दोष हमेशा छिपाना आसान होता है: यूआई में कुछ दर्ज न करें, उदाहरण के लिए। लेकिन अगर नीचे का स्तर एक बग रहता है जो उपयोगकर्ता को दिखाई नहीं देता है, तो उत्पाद में कोई बग नहीं है! लेकिन एक जोखिम है कि वह कल दिखाई देगा :) क्या आज उसे पकड़ने और जोखिमों को समतल करने से रोकता है?
- कम सॉफ्टवेयर स्थिरीकरण अवधि । आमतौर पर एक परियोजना पर दोष अभिसरण का एक ग्राफ क्या है? प्रेरित दोषों की आलोचना एक निश्चित बिंदु से घट जाती है, और उनकी संख्या बढ़ती है। यह परीक्षण के लिए कार्यक्षमता को "अनलॉक" करने की अवधि है। हमारी खिड़की कार्यक्रम में नहीं खुलती है? अवरोधक। लेकिन हम इस फॉर्म में 10 दोष नहीं खोज सकते। क्या आपने इसे ठीक किया है? लेकिन इनपुट क्षेत्र काम नहीं करता है और विंडो में ~ 9 अधिक समस्याएं हैं। आलोचक। क्या आपने इसे ठीक किया है? पाठ बॉक्स में 10 छोटी त्रुटियां मिलीं। आदि प्रत्यावर्तन। अधिक त्रुटियां हैं, लेकिन वे कम हैं। इस बीच, कुछ त्रुटियां हैं, लेकिन वे डरावने हैं, परीक्षक एक निर्धारण की प्रत्याशा में छत पर थूकते हैं। आधे डेवलपर्स ने छत पर भी थूक दिया, क्योंकि उन पर कोई कीड़े नहीं हैं, और हम "बगफिक्स" चरण पर हैं। घटक परीक्षण आपको तुरंत उनमें से एक अच्छा आधा खोजने की अनुमति देता है। इसलिए - बग फिक्स, सुविधाजनक होने पर, और वास्तविक रूप से अपनी योजनाओं का मूल्यांकन करें।
3. संक्रमण।यानी जानकारी साझा करना। अधिकतम करने के लिए। अगर किसी ने एक बार कहा था कि यह कैसे काम करता है यह जानने के बिना सॉफ्टवेयर का परीक्षण करना अधिक कुशल है, तो आपको धोखा दिया गया था। परीक्षकों को पता नहीं है कि किसी ऑपरेशन के निष्पादन पर क्या प्रभाव पड़ता है। UI विकल्प? कोई समस्या नहीं। लेकिन आमतौर पर, उनके अलावा, अभी भी बहुत सारे कारक हैं जो केवल डेवलपर्स को पता है।
क्या करें?
साझा करें और महान मत बनो!
एक छिपा हुआ छोटा दोष आज कल एक बड़ी बवासीर का खतरा है।
4. दोषों के लिए एक सामान्य दृष्टिकोण विकसित करना।बेशक, अगर डेवलपर आज किसी तरह के बग फिक्स पर स्विच नहीं करना चाहता है, तो वह बग्स को छिपाने के लिए सब कुछ करेगा। पुराने जमाने की आवाज़ लगती है, क्या अब वे ऐसा नहीं करते हैं? सच नहीं है, वे करते हैं। यह एक प्राकृतिक प्रक्रिया है :)
लेकिन अगर डेवलपर्स को पता है कि बीटीएस (बग ट्रैकिंग सिस्टम) में बग सिर्फ जानकारी है, लेकिन हमेशा कार्रवाई के लिए संकेत नहीं है, तो उनकी उपस्थिति परेशान नहीं होगी।
उसी समय, परीक्षण के लिए कभी-कभी कुछ बगों का निर्धारण बहुत महत्वपूर्ण होता है। उन्हें ब्लॉकर्स कहा जाता है (ये ऐसे दोष हैं जो उपयोगकर्ता के दृष्टिकोण से बहुत महत्वपूर्ण नहीं हो सकते हैं, लेकिन कार्यक्षमता के किसी भी महत्वपूर्ण हिस्से के परीक्षण को रोकते हैं)। यहां उन्हें वास्तव में निश्चित, महत्वपूर्ण और अधिमानतः जल्दी से तय करने की आवश्यकता है।
5. तोते के परिणाम को न मापें।कभी-कभी परियोजना प्रबंधन उन परीक्षकों की प्रशंसा करता है, जिन्होंने आलोचक को रिलीज से कुछ घंटे पहले पाया। बहुत सारे कीड़े? अच्छा किया। डेवलपर्स, अक्सर, उदाहरण के लिए, KLOCs के साथ, नेतृत्व को मापने की कोशिश करते हैं। लेकिन न तो कोड की मात्रा, न ही बग की संख्या हमें रिहाई के करीब लाती है, कभी-कभी - इसके विपरीत! वास्तव में टीम वर्क का संकेतक क्या है?
केवल जारी। समय पर और उच्च गुणवत्ता।
और इसका मतलब है कि दोष, कोड की रेखाएं, औसत आलोचना और अन्य बकवास औपचारिकताएं हैं जो प्रबंधन को चार्ट को देखते हुए, पतवार को महसूस करने में मदद करती हैं।
ps एक कंपनी में जहां मैंने काम किया था, एक ठीक दिन उन्होंने कोड की लिखित पंक्तियों की संख्या से डेवलपर्स का एक मूल्यांकन पेश किया। अगले महीने, कुल प्रतिबद्ध कोड की तुलना में लगभग दोगुना था। बस इसकी गुणवत्ता की कल्पना करें :)
औपचारिकता संख्याओं पर ध्यान केंद्रित करती है और परिणाम से दूर जाती है।
6. उत्पाद परीक्षण सुनिश्चित करना।यह हमारे लिए बहुत महत्वपूर्ण है (हम = पूरी परियोजना, न केवल परीक्षक!) हमारे सॉफ़्टवेयर का त्वरित परीक्षण करने में सक्षम होने के लिए। और इसके लिए, कभी-कभी आपको प्रयास करना होगा। अवरोधक लॉक करें? परीक्षण के लिए अतिरिक्त इंटरफेस बनाएँ? इंटरफेस के स्थिरीकरण का वादा करें और हर तरह से अपना वादा निभाएं?
यह महत्वपूर्ण है! बहुत ...
निष्कर्ष
सभी परियोजना प्रतिभागियों को प्रभावी परीक्षण में रुचि है। यह आपको विकास लागत और बग फिक्स, स्तर परियोजना जोखिमों को बचाने, उत्पाद की गुणवत्ता में सुधार, डेवलपर्स को अनावश्यक कार्यों से बचाने की अनुमति देता है ... सामान्य तौर पर, यदि परियोजना का सही परीक्षण किया जाता है, तो पाया गया दोषों की कुल संख्या आमतौर पर केवल कम है!
लेकिन!
डेवलपर्स और आरएम की मदद, समर्थन और समझ के बिना परीक्षण इस सबसे "सही" परीक्षण प्रदान करने में हमेशा सक्षम होते हैं।
ऐसा होने के लिए, हमें और अधिक संवाद करने की आवश्यकता है। पता करें कि कौन उम्मीद करता है कि परीक्षण से क्या परिणाम निकलते हैं, कौन से लक्ष्य निर्धारित करते हैं। किसे मदद की ज़रूरत है, जो मौजूदा प्रक्रिया में है उसे पसंद नहीं है।
इस तरह के मुद्दों पर खुलकर चर्चा करने के बाद, हम परीक्षण और परियोजना को पूरी तरह से अधिक प्रभावी बना सकते हैं, और इस रास्ते पर मुख्य बाधा ग्राहक नहीं हैं, उपकरण नहीं हैं, तकनीक नहीं हैं, लेकिन सिर्फ
गलतफहमी है ।