👨🏼‍🎓 🙌🏼 📰 दुनिया का युद्ध: प्रोग्रामर बनाम। परीक्षकों! 🤞 🏹 🔘

मैं एक परीक्षक हुआ करता था। मुझे याद है कि उन दिनों यह कभी-कभी प्रोग्रामरों से बेहद असंतुष्ट था:

ये शाश्वत संदिग्ध तर्क "यह एक बग नहीं है, यह एक विशेषता है" या "यदि यह एक बग है, तो यह महत्वहीन है, इसे रहने दें।"

लेकिन अगर सिस्टम दांव पर लग जाए तो कैसा रहेगा? '

फिर मैं एक प्रोग्रामर बन गया। और सब कुछ बदल गया - मैं संशोधन के लिए इन अंतहीन रिटर्न को बहुत अधिक प्रभावित करने लगा:

वे इसे पसंद नहीं करते हैं, यह यहाँ काम नहीं करता है! हां, इस विंडो में आम तौर पर अपठनीय पात्रों को कॉल करने और सम्मिलित करने के लिए क्या संदर्भ मेनू था? उन्होंने यह भी कैसे सोचा?! बुलशिट, मुकाबला मोड में कोई भी उपयोगकर्ता ऐसा नहीं करेगा!

मैं राज नहीं करूंगा, रहने दो!

सामान्य तौर पर, क्लासिक्स प्रोग्रामर और टेस्टर्स की दुश्मनी होती है।

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

प्रक्रिया है

उन दिनों में, हमारे पास एक बहुत ही सरल और समझने योग्य विकास प्रक्रिया थी:

कार्य -> प्रोग्रामिंग <-> परीक्षण -> रिलीज

और

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

खैर, यह एक आदर्श उदाहरण है!

प्रोग्रामर में

प्रवेश पर: नए कार्य और परीक्षण से रिटर्न।
बाहर निकलें: परीक्षण के लिए स्थानांतरण कार्य।

परीक्षकों पर

इनपुट: प्रोग्रामर से कार्य।
बाहर निकलें: प्रोग्रामर और संस्करण की आधिकारिक रिलीज़ के लिए कार्य वापस करना।

दरअसल, यह प्रक्रिया अपने आप में बुरी नहीं है - हर कोई अपनी दुनिया में रहता है और वही करता है जो उसे पसंद है।

लक्ष्य

लेकिन इस प्रक्रिया का एक बहुत ही विशिष्ट अंतिम लक्ष्य है - समय पर आवश्यक कार्यक्षमता के साथ उच्च गुणवत्ता वाले सॉफ़्टवेयर का उत्पादन करना।

दरअसल, इस समय समस्याएं शुरू होती हैं।

समस्याओं

एक बार एक प्रबंधक आता है और अंतिम लक्ष्य के बारे में याद दिलाना शुरू कर देता है।

विशिष्ट स्थिति:

प्रबंधक प्रोग्रामर के पास आता है और पूछता है "कब?", और वे जवाब देते हैं "हमें पता नहीं है, हमने सब कुछ किया, परीक्षकों से पूछें।"

प्रबंधक परीक्षकों के पास उसी प्रश्न के साथ जाता है जब "कब?" प्रोग्रामर के साथ। "

और प्रबंधक आगे और पीछे एक सर्कल में चलना शुरू करता है, लेकिन कोई रिलीज नहीं है।

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

यहाँ कुछ नियम हैं जो प्रबंधक के कई महीनों के थकने के बाद हमारे विभाग में बने हैं:

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

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

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

इसके अलावा, प्रोग्रामर और परीक्षकों के बीच संबंध में सुधार नहीं हुआ - जैसा कि दुश्मनी थी, इसलिए यह बनी रही।

जागरूकता

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

और इस संघर्ष की पूरी बात यह है कि उनके अलग-अलग लक्ष्य हैं !

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

निर्णय

दरअसल, समस्या का समाधान प्रोग्रामर और टेस्टर्स दोनों के लिए एक समान लक्ष्य निर्धारित करना है।

इसके अलावा, लक्ष्य स्पष्ट है - समय पर एक गुणवत्ता रिलीज की रिहाई।

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

जाहिर है, लक्ष्य बदलना आसान नहीं था। लेकिन जब से मैं अपने विचारों के तर्क से पूरी तरह से प्रभावित हो गया, मैं बदलने के लिए किसी भी प्रतिरोध को तोड़ने के लिए तैयार था!

यहाँ मुख्य बात यह है कि किया गया है:

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

और ये सभी प्रयास इसके लायक थे! प्रभाव बस अद्भुत था!

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

हमारी आँखों से पहले, कुछ छह महीनों के लिए, एक वास्तविक परिवर्तन हुआ है!

निष्कर्ष

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