परीक्षणको आधारभूत समस्या

परिचय

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

• GOST 7400-81। घरायसी बिजुली केतली र बिजुली समोवर। विशिष्टताहरू (संशोधन नम्बर १-८ सहित)
• GOST IEC 60335-1-2015 घरेलु र यस्तै बिजुलीका उपकरणहरू। सुरक्षा। भाग १. सामान्य आवश्यकताहरू
  पूर्ण चेकलिस्टको साथ राम्रो परीक्षण योजनाको बारेमा सोच्न गाह्रो छ।

तर दोस्रो भाग एउटा प्रश्नको रूपमा बाहिरियो: "के त्यहाँ सबै परीक्षकहरूमा सामान्य समस्याहरू छन् जसले तिनीहरूलाई अझ प्रभावकारी रूपमा काम गर्नबाट रोक्छ?"

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

परिभाषाहरू

एउटा नयाँ समस्या समाधान गर्दा मैले सामान्यतया गर्ने पहिलो कुरा भनेको यो के हो भनेर बुझ्ने प्रयास गर्नु हो, र यो गर्नको लागि मैले यसलाई प्रस्तुत गर्ने शब्दहरूको अर्थ बुझ्नुपर्छ। बुझ्नको लागि मुख्य शब्दहरू निम्न हुन्:

• समस्या
• परीक्षक
• परीक्षक काम
• परीक्षक दक्षता

विकिपिडिया र सामान्य ज्ञानमा फर्कौं:
समस्या (प्राचीन ग्रीक πρόβλημα) व्यापक अर्थमा - एक जटिल सैद्धान्तिक वा व्यावहारिक मुद्दा जसलाई अध्ययन र समाधान आवश्यक छ; विज्ञान मा - एक विरोधाभासी स्थिति जुन कुनै पनि घटना, वस्तु, प्रक्रिया को व्याख्या मा विरोध स्थिति को रूप मा देखिन्छ र यसलाई समाधान गर्न एक पर्याप्त सिद्धान्त आवश्यक छ; जीवनमा, समस्यालाई मानिसहरूले बुझ्न सक्ने रूपमा तयार पारिएको छ: "मलाई के थाहा छ, मलाई थाहा छैन कसरी," अर्थात्, यो थाहा छ के प्राप्त गर्न आवश्यक छ, तर यो कसरी गर्ने थाहा छैन। । ढिलो बाट आउँछ। lat समस्या, ग्रीकबाट। πρόβλημα "अगाडि फ्याँकिएको, अगाडि राखिएको"; προβάλλω बाट "अगाडि फ्याँक्नुहोस्, तपाईंको अगाडि राख्नुहोस्; दोष"।

यसले धेरै अर्थ राख्दैन, वास्तवमा, "समस्या" = "जुनसँग व्यवहार गर्न आवश्यक छ।"
परीक्षक - एक विशेषज्ञ (हामी प्रकारहरूमा विभाजन गर्दैनौं, किनकि हामी सबै परीक्षकहरूमा रुचि राख्छौं) जसले कम्पोनेन्ट वा प्रणालीको परीक्षणमा भाग लिन्छ, जसको परिणाम हो:
परीक्षकको काम - परीक्षण संग सम्बन्धित गतिविधिहरु को एक सेट।
दक्षता (lat. effectivus) - प्राप्त परिणाम र प्रयोग गरिएका स्रोतहरू बीचको सम्बन्ध (आईएसओ 9000: 2015)।
नतिजा - कार्यहरू (नतिजा) वा घटनाहरूको श्रृंखला (श्रृङ्खला) को परिणाम, गुणात्मक वा मात्रात्मक रूपमा व्यक्त। सम्भावित परिणामहरूमा लाभ, हानि, लाभ, हानि, मूल्य, र विजय समावेश छ।
"समस्या" को रूपमा, त्यहाँ थोरै अर्थ छ: कामको परिणामको रूपमा बाहिर आएको कुरा।
स्रोत - एक व्यक्ति वा मान्छे को कुनै पनि गतिविधि प्रदर्शन को मात्रात्मक मापन सम्भावना; सर्तहरू जसले इच्छित परिणाम प्राप्त गर्न निश्चित रूपान्तरणहरू प्रयोग गर्न अनुमति दिन्छ। परीक्षक एक व्यक्ति हो, र महत्त्वपूर्ण स्रोतहरूको सिद्धान्त अनुसार, प्रत्येक व्यक्ति चार आर्थिक सम्पत्तिहरूको मालिक हो:
नगद (आय) एक नवीकरणीय स्रोत हो;
ऊर्जा (जीवन शक्ति) एक आंशिक नवीकरणीय स्रोत हो;
समय एक निश्चित र मौलिक रूपमा गैर-नवीकरणीय स्रोत हो;
ज्ञान (सूचना) एक नवीकरणीय स्रोत हो, यो मानव पुँजीको अंश हो जुन बढ्न सक्छ र नष्ट हुन सक्छ।[1].

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

निर्णय

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

1. आवश्यकताहरु संग काम गर्दै
2. प्राविधिक विनिर्देशों को गठन
3. विकास
4. परीक्षण गर्दै
5. उत्पादनमा जारी गर्नुहोस्
6. समर्थन (वस्तु १ मा जानुहोस्)

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

यसलाई कसरी व्यवहार गर्ने?

निष्कर्षहरू एकदम स्पष्ट छन् र लामो समयको लागि धेरै द्वारा प्रयोग गरिएको छ:

1. विकास र परीक्षण लगभग एकैसाथ सुरु र अन्त्य हुनुपर्छ (यो सामान्यतया विभाग द्वारा गरिन्छ QA)। आदर्श विकल्प तब हुन्छ जब सबै प्रकार्यताहरू विकसित भइरहेका हुन्छन्, जब यो तयार भइसकेपछि अटोटेस्टहरू द्वारा कभर गरिएको हुन्छ, कुनै प्रकारको प्रयोग गरेर रिग्रेसन (र सम्भव भए पूर्व-कमिट) परीक्षणमा व्यवस्थित हुन्छ। CI.
2. परियोजनामा ​​जति धेरै सुविधाहरू छन् (यो जति जटिल छ), नयाँ कार्यक्षमताले पुरानोलाई तोड्दैन भनेर जाँच गर्नको लागि त्यति नै बढी समय खर्च गर्नुपर्नेछ। तसर्थ, परियोजना जति जटिल छ, त्यति नै स्वचालन आवश्यक छ प्रतिगमन परीक्षण.
3. प्रत्येक चोटि हामीले उत्पादनमा बग मिस गर्छौं र प्रयोगकर्ताले फेला पार्छौं, हामीले बिन्दु 1 (आवश्यकताहरूसँग काम गर्दै, यस अवस्थामा, प्रयोगकर्ताहरू) बाट सुरु हुने परियोजना जीवन चक्रमा जाँदा थप समय खर्च गर्नुपर्छ। बग हराउने कारणहरू सामान्यतया अज्ञात हुनाले, हामीसँग केवल एक अप्टिमाइजेसन मार्ग बाँकी छ - प्रयोगकर्ताहरूले फेला पारेका प्रत्येक बगलाई पुन: देखा पर्दैन भनेर निश्चित हुन रिग्रेसन परीक्षणमा समावेश गर्नुपर्छ।

स्रोत: www.habr.com