मेरो टाउकोमा बगसँग परीक्षण गर्दै (सफ्टवेयर प्रकार होइन)

QA मा काम गर्दा, म प्राय: मेरो टाउकोमा आवाज सुन्छु, "के तपाइँ निश्चित हुनुहुन्छ कि तपाइँ सबै कुरा जाँच गर्नुभयो?" कहिलेकाहीँ यो एक उपयोगी नज हो, तर यदि अनचेक छोडियो भने, यो एक समस्या हुन थाल्छ। तल, म यो कष्टप्रद भित्री बग बारे कुरा गर्नेछु र यो कसरी प्रकट हुन्छ।

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

भित्री बगको अपसाइडहरू: "के तपाइँ निश्चित हुनुहुन्छ कि तपाइँ सबै कुरा जाँच गर्नुभयो?"

यसले तपाईंलाई सावधानी र विस्तारमा ध्यान दिएर सरल कार्यहरूमा पनि पुग्न धक्का दिन्छ।

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

यो स्वीकार गर्न लाजमर्दो छ, तर मैले फरक कार्यबाट सूत्रको साथ गणनाहरू प्रयोग र प्रमाणीकरण गरिरहेको छु। जब दुई कार्यहरू सम्बन्धित थिए, सूत्रहरू स्वतन्त्र रूपमा काम गर्न मानिन्छ। यो निरीक्षणलाई महसुस गर्दै, मैले तुरुन्तै सही गणना नियमहरू अनुरोध गरें, कार्य पुन: परीक्षण गरे, र पत्ता लगाएँ कि विकासकर्ताले उही गल्ती गरेको थियो। उनीहरूले पनि अन्य कार्यको सूत्र प्रयोग गरेका थिए।

यो कष्टप्रद सानो बगले मलाई गैर-तुच्छ त्रुटिहरू फेला पार्न र उत्पादनलाई थप विश्वसनीय बनाउन अनुमति दिन्छ।

एकचोटि मैले परीक्षण योजना पार गरेपछि, यो सानो समस्याकर्ताले विचारहरू फ्याँक्न थाल्छ, "यदि ग्राहकले ठूलो फन्ट साइज वा पुरानो ओएस प्रयोग गर्दछ भने के हुन्छ?"

यसको लागि धन्यवाद, म मेरो परीक्षणहरू अझ राम्ररी दस्तावेज गर्छु, र म प्रायः मेरो रिपोर्टहरूमा भिडियो र स्क्रिनसटहरू समावेश गर्दछु।

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

त्यो आत्म-प्रतिबिंबित नोटमा, यो भित्री आवाजको डाउनसाइडहरूमा जाऔं

यसले मलाई धेरै चिन्तित बनाउँछ, प्रायः कुनै राम्रो कारण बिना

यो कहिलेकाहीँ एक स्क्रू-अप पछि हुन्छ, तर त्यहाँ पनि समय छ जब सानो बगको आवाज पाइप बिना उत्तेजित हुन्छ। केही अवसरहरूमा, म ओछ्यानमा गएपछि पनि यसले मलाई एक्लै छोड्दैन, र मैले अरू के जाँच गर्नुपर्छ भन्ने बारे म आफैलाई नोटहरू बनाउँछु।

यसले अक्सर मलाई धेरै जटिल परीक्षण केसहरूमा समय बर्बाद गर्छ

यो पहिलो बिन्दुको प्रत्यक्ष परिणाम हो: चिन्ताले मेरो टाउकोमा अनौठो र सबैभन्दा भयानक परिदृश्यहरू पैदा गर्छ। यस क्षणमा, तिनीहरू आलोचनात्मक देखिन्छन्, तर फर्केर हेर्दा, तिनीहरू प्रायः "चन्द्रमा मुनिको पाइन रूखमा सिट्टी बजाउँदा के हुन्छ?" जस्तो देखिन्छ।

यसले मलाई अन्य कामहरूमा ध्यान केन्द्रित गर्नबाट रोक्छ

कहिलेकाहीँ, कार्यलाई अर्को स्थितिमा सार्दा र केहि नयाँ सुरु गरेपछि पनि, ती परीक्षण केसहरूको बारेमा विचारहरूले मलाई सताउँछ र मलाई नयाँ कार्यमा ध्यान केन्द्रित गर्नबाट रोक्छ। यस्तो अवस्थामा, चिन्तित जाँचकर्ता-बग बन्द गर्न गाह्रो हुन सक्छ।

त्यसोभए, कसैको फाइदाको लागि यो बग कसरी लाभ उठाउन सक्छ, र तपाइँ यसलाई कसरी लिनबाट जोगाउनुहुन्छ?

पहिलो कुरा

जुन कुरा मेरो टाउकोमा पस्यो जब म डाउनसाइडहरूको बारेमा लेख्दै थिए - र मैले मन्त्र जस्तै दोहोर्याउने कुरा - यो हो: पूर्ण परीक्षण एक मिथक हो। त्यहाँ सधैं बगहरू हुनेछन्।

तपाईं जतिसुकै गहिरो भए पनि, कार्यहरू र परिदृश्यहरूको प्रत्येक संयोजनको भविष्यवाणी गर्न असम्भव छ, जसको मतलब तपाईंले आफ्ना प्रयोगकर्ताहरूले गर्नु अघि प्रत्येक एकल बग समात्न सक्नुहुन्न।

विशेष गरी निरन्तर परिवर्तन भइरहेको संसारमा।

यो केहि चीज हो जुन तपाईले स्वीकार्नु पर्छ र अगाडि बढ्नु पर्छ।

यसले मलाई उत्पादन बगहरूको मूल कारणहरूको विश्लेषण गर्न मद्दत गर्‍यो - जसलाई केही मानिसहरू पोस्टमार्टम भन्छन्। यो बग कसरी भयो र यसलाई फेरि हुनबाट रोक्न हामीले के गर्न सक्छौं भनेर पत्ता लगाउन संलग्न सबैसँग कुरा गर्दा यो हो।

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

तैपनि आकाश खसेको छैन । काम जारी रह्यो, र हामी सबैले ती क्षेत्रहरूमा नजिकबाट ध्यान दियौं जहाँ हामी पहिले चिप्ल्यौं।

दोस्रो कुरा

मैले परीक्षण डिजाइन प्रविधिहरू: निर्णय तालिकाहरू र राज्य संक्रमण रेखाचित्रहरू लागू गरिरहेको पेस्की चेकर-बगलाई शान्त गर्न प्रयोग गर्थे।

यसले तपाइँलाई एप्लिकेसनको तर्क कल्पना गर्न र सम्भावित परीक्षण केसहरूको स्पष्ट चित्र प्राप्त गर्न मद्दत गर्दछ, जसको मतलब तपाइँ तिनीहरूलाई बेवास्ता गर्नुहुन्न भन्ने कुरामा तपाइँ बढी विश्वस्त हुन सक्नुहुन्छ।

यदि तपाईंलाई रिफ्रेसर चाहिन्छ भने, निर्णय तालिका एउटा तालिका हो जहाँ हामी स्तम्भ र पङ्क्तिहरूमा सर्तहरू र नियमहरू प्रविष्ट गर्छौं। एकपटक हामीले सबै सर्तहरू र नियमहरूका लागि विकल्पहरू निर्दिष्ट गरिसकेपछि, हामी अपेक्षित परिणाम भर्छौं।

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

तेस्रो,

त्यो कष्टप्रद भित्री बग को लागि उपाय वास्तवमा मलाई सबै आफैमा भेट्टाए। यो स्क्रू-अप पछि परीक्षण केसहरू र सञ्चारको सहकर्मी समीक्षा हुन पुग्यो।

सरल, सायद स्पष्ट पनि, तर यो एक आकर्षण जस्तै काम गर्दछ।

र चौथो

मेरो दिमागलाई शान्त पार्ने तरिका प्रभावकारिता र जोखिमहरू मूल्याङ्कन गरेर थियो। जब भित्री बगले मेरो कानमा फुसफुसाउन थाल्यो, "केही थप परीक्षण केसहरू हेर्नुहोस्," म मेरो टोलीको नेतृत्वलाई सम्झन्छु र तीन प्रश्नहरू सोध्छु:

• कति समय लाग्छ?
• के फाइदा हुनेछ?
• यसले महत्त्वपूर्ण कुरा पत्ता लगाउने सम्भावना के छ?

हो, कहिलेकाहीँ फरक भाषा सेटिङहरू, गाढा र हल्का विषयवस्तुहरू, फन्ट साइज बढेको, र यस्तै अन्य धेरै OS संस्करणहरूमा परीक्षण गर्न अर्थ लाग्छ, तर प्रायः होइन, यी जाँचहरू अनावश्यक हुन्छन्।

त्यस्ता परीक्षणहरू गर्दा तपाईंले बग फेला पारेको कल्पना गर्नुहोस्: यसले कुन प्राथमिकता पाउनेछ? पुन: उत्पादन गर्नका लागि विशेष चरणहरूको कारणले गर्दा, दुर्घटनालाई पनि सानो प्राथमिकता तोक्न सकिन्छ।

यी चेकहरूले कति समय लिनेछन्? पाँच देखि दस मिनेट - ठूलो कुरा होइन, तर त्यो समय सधैं उपलब्ध छैन। त्यस समयमा, तपाईंले औसत आकारको कार्यको विवरण पढ्न सक्नुहुन्छ।

लपेट्दै (म आशा गर्छु)

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

म तपाईंलाई केही सहयोग दिन चाहन्छु, र सायद तपाईं थकित नहुन्जेल यससँग लड्नुको सट्टा, तपाईंले यो सानो जनावरसँग काम गर्ने र यसलाई आफ्नो सहयोगी बनाउने तरिका फेला पार्नुहुनेछ।