एक बार फिर से परीक्षण की असहनीय आसानी के बारे में

हम बातचीत जारी रखते हैं।

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

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

शायद मैं सीधे उन्हीं बिंदुओं पर जाऊंगा।

1. परीक्षक को उत्पाद में परिवर्तन के बारे में पता होना चाहिए

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

पहली समस्या इस तरह के अलर्ट के लिए काम करने का तरीका ढूंढना है।

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

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

दूसरी समस्या यह है कि इन सूचनाओं को कैसे पहुंचाया जाए।

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

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

सामान्य तौर पर, इस तरह के अभ्यास को कम करने के कई अवसर हैं। यद्यपि अगर यह काम करता है - शुरुआती चरणों में पागल परिवर्तनों की अस्वीकृति तक, लाभ बहुत बड़ा है।

2. विदेशी कीड़े

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

3. मामूली कीड़े और इंटरफ़ेस बग्स / इमीटेशन्स को उड़ान में छोड़ना

अप्रिय, बहुत, मैं अपने अनुभव से जानता हूं। एक ओर, समस्या पर रिपोर्ट करना हमारा व्यवसाय है, दूसरी ओर, यह सच है कि काम बर्बाद हो गया है।

यहाँ सवाल है: कौन पुनर्निर्देशित करता है और क्यों? यदि एक प्रोग्रामर एक चीज है, अगर एक प्रोजेक्ट मैनेजर एक और (और कई अन्य चीजें हैं), तो प्रबंधक के पास बहुत सारे कारण हो सकते हैं कि यह दोष अब क्यों अनियंत्रित है, लेख में इस विषय पर हाल ही में एक टिप्पणी थी "परीक्षण: गंदगी से अमीरों तक। )।

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

क्या चुनना है? यह विशिष्ट स्थिति पर निर्भर करता है। यह वह जगह है जहां सबसे कठिन हिस्सा शुरू होता है - समस्या की पहचान करने और यह पता लगाने के लिए कि हमारे पास किस तरह की स्थिति है।

4. प्रयोगशाला

परीक्षण का माहौल महत्वपूर्ण है, फिर से बहस करने के लिए कुछ भी नहीं है। और निर्णय, सामान्य रूप से, सही है: आदर्श और क्रूर वास्तविकता के बीच एक मध्यम जमीन की तलाश करने के लिए।

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

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

ग्राहकों / उपयोगकर्ताओं (अल्फा, बीटा) के लिए परीक्षण का पासिंग भाग एक विकल्प है, लेकिन एक अलग लेख के लिए पर्याप्त पानी के नीचे रेक है। लेकिन आप कोशिश कर सकते हैं।

5. समय और रिपोर्टिंग

एक अनंत रूप से प्रासंगिक समस्या यह है कि परीक्षकों के काम का मूल्यांकन कैसे किया जाए, और यहां तक ​​कि तंग समय सीमा पर काम करने वालों को भी। और प्रोग्रामर, वैसे, भी।
या तो बगों की संख्या को देखें, या आलोचनात्मकता को, या उपयोगकर्ता की समीक्षा पर, या बस झांकने पर देखें। साहित्य और जीवन में कई विकल्प हैं।

यदि हम उत्पाद पर काम के परिणाम / शर्तों के बारे में बात करते हैं - प्रोग्रामर और परीक्षक के काम का मूल्यांकन करते हैं, और बाकी टीम भी, एक साथ। हमने सभी पर एक साथ उत्पाद पर काम किया, परिणाम भी सामान्य है।

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

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

6. फार्म के कीड़े के साथ क्या होता है: प्रजनन योग्य नहीं, मनाया और आदि?

यहाँ, सामान्य तौर पर, सबकुछ पैराग्राफ 3 के समान है। या मैं कुछ याद कर रहा हूँ?

7. स्वचालन बनाम मैनुअल परीक्षण

समस्याओं का अच्छी तरह से वर्णन किया गया है। इस मामले में, निर्णय एक विशेष परियोजना / उत्पाद से इतनी दृढ़ता से जुड़ा हुआ है कि किसी भी सामान्य सिफारिश को देना मुश्किल है।

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

8. कंपनी की समग्र संरचना में परीक्षक की स्थिति

और यहाँ सब कुछ फिर से परीक्षक के हाथों में है।

यदि कंपनी में परीक्षक अत्यधिक मूल्यवान हैं, और वे बकवास में लगे हुए हैं, तो बहुत जल्द वे एक क्लीनर के स्तर पर होंगे।
यदि परीक्षक परियोजना और इसके प्रतिभागियों के लिए वास्तविक लाभ लाते हैं, तो विश्वसनीयता बढ़ेगी।
बेशक, ऊपर की ओर आंदोलन लंबे समय तक और सिंहासन से गिरने के लिए अधिक कठिन है, लेकिन हर जगह ऐसा ही है।

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

यह कठिन है।