क्वालिटी एश्योरेंस डिपार्टमेंट (क्यूए) सॉफ्टवेयर में बग की खोज करता है। तरीके कंपनी से कंपनी में भिन्न होते हैं, लेकिन यह आमतौर पर उन कर्मचारियों द्वारा किया जाता है जो सॉफ्टवेयर से परिचित हैं। वे इसे विभिन्न तरीकों से उपयोग करते हैं और उन बग्स को खोजने की कोशिश करते हैं जिन्हें डेवलपर्स ने याद किया है।

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

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

क्यूए विभाग में निम्नलिखित समस्याग्रस्त व्यक्ति हैं:

• आग की नली
• अभियोक्ता
• भय उत्पन्न करनेवाला
• वैज्ञानिक
• गुमराह करने वाले
• उत्पीड़ित
• रैंडम क्लिकर
• ब्लिथली बोल्ड

आग की नली

एक परीक्षक जो इतनी सारी बग रिपोर्ट इतनी जल्दी करता है कि विकास टीम कभी खत्म नहीं होगी।

• अलार्मिस्ट में उत्परिवर्तित कर सकते हैं
• यह आंकड़ों की तरह एक परियोजना प्रबंधक के साथ संयोजन में खतरनाक है
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: उच्च

समस्या

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

पहली नज़र में, ऐसा लग सकता है कि उत्पाद की गुणवत्ता में कोई समस्या है, लेकिन हमेशा ऐसा नहीं होता है। एक पारंपरिक परीक्षक के विपरीत, जो एक बहुत छोटी गाड़ी के कार्यक्रम के साथ काम करता है, एक आग की नली एक या अधिक विशिष्ट विशेषताओं के साथ रिपोर्ट का हिमस्खलन उत्पन्न करती है:

• उनकी रिपोर्टें खराब रूप से विस्तृत हैं, जो अधिक त्रुटियों की तेजी से रिपोर्टिंग की अनुमति देता है।
• कई कीड़े दूसरों के डुप्लिकेट हैं, क्योंकि वे केवल एक मुख्य कारण के रूपांतर हैं।
• त्रुटि को पुन: पेश करने का समय नहीं है, क्योंकि रिपोर्ट लिखने के लिए इसे एक बार देखने के लिए पर्याप्त है।

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

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

निर्णय

फायर होज़ को ठीक करने से पहले, इसे सही ढंग से पहचानना और इसे एक प्रभावी क्यूए के साथ भ्रमित न करना महत्वपूर्ण है जो बहुत छोटी गाड़ी प्रणाली से टकराता है। सबसे स्पष्ट सबूत डेवलपर की शिकायतों से आता है:

• ज्यादातर त्रुटियां डुप्लिकेट हैं।
• कई कीड़े के मूल कारण समान हैं, इसलिए उन्हें एक बग के रूप में रिपोर्ट किया जा सकता है।
• त्रुटि संदेशों में विवरण नहीं है।

स्थिति को मापने के लिए, फायर नली को समझाया जाना चाहिए कि बड़ी संख्या में त्रुटियों की रिपोर्ट करने के लिए कोई प्रोत्साहन नहीं है, और लक्ष्य सिस्टम की गुणवत्ता में सुधार करना और डेवलपर्स की मदद करना है। उसके बाद, उत्पाद की गुणवत्ता में समान (या बेहतर) गति से सुधार होना चाहिए, लेकिन बिना घबराहट के।

अभियोक्ता

क्यूए, जो प्रत्येक पाया बग के बाद डेवलपर्स पर अपने कार्यक्रम का परीक्षण नहीं करने का आरोप लगाता है।

• अलार्मिस्ट में उत्परिवर्तित कर सकते हैं
• यह आंकड़ों की तरह एक परियोजना प्रबंधक के साथ संयोजन में खतरनाक है
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: कम

समस्या

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

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

दुर्भाग्य से, अभियोजकों को एक विशिष्ट और काफी पूर्वानुमानित प्रक्रिया के परिणामस्वरूप बनाया जाता है:

1. उत्पादन में एक महत्वपूर्ण त्रुटि का पता चला है।
2. परीक्षक पर इस बग को गायब करने का आरोप है।

ऐसा अक्सर भी होता है, और इसलिए क्यूए स्वाभाविक रूप से एक अकाट्य तर्क का उपयोग करके खुद को बचाता है।

निर्णय

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

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

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

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

भय उत्पन्न करनेवाला

क्यूए, जिसमें कहा गया है कि पूरे उत्पाद की गुणवत्ता का एक अस्वीकार्य स्तर है, जबकि इसकी राय केवल सतही छाप पर आधारित है।

• अभियोक्ता या आग नली में उत्परिवर्तन हो सकता है
• एक निराशावादी जैसे परियोजना प्रबंधक के साथ संयोजन में खतरनाक
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: उच्च

समस्या

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

आप इस बारे में बहुत बात कर सकते हैं कि QAs टायर डेवलपर्स को कैसे बर्बाद करते हैं और अपना समय बर्बाद करते हैं (टाइप भ्रामक का परीक्षक देखें), लेकिन यह एक दुगनी स्थिति है। वास्तव में, बहुत बार, डेवलपर जानबूझकर क्यूए खराब सॉफ्टवेयर का परीक्षण करता है ताकि किए गए काम का इनाम मिल सके या यह दावा किया जा सके कि वह समय सीमा पूरी कर चुका है। जब QA इस तरह की प्रणाली का परीक्षण शुरू करता है, तो यह तुरंत बहुत सी त्रुटियों का सामना करता है जो कि डेवलपर को दिखनी चाहिए। इसलिए, यह स्पष्ट है कि वह पूरे उत्पाद को देखा और जो गंभीर रूप से कम गुणवत्ता का दावा करता है, को एक्सट्रपलेशन करता है।

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

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

पानी के साथ बच्चे को फेंकने का यह एक क्लासिक मामला है। कभी-कभी क्यूए सही विकल्प बनाता है, खासकर जब विकास टीम को क्यूए में असत्यापित सॉफ़्टवेयर को स्थानांतरित करने के लिए एक प्रतिष्ठा है। लेकिन ऐसा होता है कि अलार्म एक कमजोर डेवलपर की वजह से उठाया जाता है, जिसका कोड पैनिक बनाने वाले के लिए सबसे पहले था।

निर्णय

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

आमतौर पर, बड़ी विकास टीमों में, कम गुणवत्ता वाले कोड व्यक्तिगत डेवलपर्स से उत्पन्न होते हैं, पूरी टीम के नहीं। इसलिए, यह आवश्यक है कि कम सक्षम डेवलपर्स के काम का अंतिम परीक्षण किया जाता है, या यह कि यह अलार्मिस्ट में नहीं आता है। हालांकि, यह सही समस्या को छिपाता है कि टीम में डेवलपर्स हैं जो परियोजना को नकारात्मक रूप से प्रभावित करते हैं ।

वैज्ञानिक

एक परीक्षक जो अपना अधिकांश समय बगों के दस्तावेजीकरण में बिताता है, नए खोजने में नहीं।

• दलितों में उत्परिवर्तन हो सकता है
• पेटेंट लेखक जैसे उत्पाद प्रबंधक के साथ संयुक्त होने पर खतरनाक
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: कम

समस्या

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

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

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

निर्णय

एक क्यूए वैज्ञानिक को सही रिपोर्ट लिखना सिखाकर उसे सही करना आसान है। अक्सर, सुधार तुरंत होता है जैसे ही वे समझाते हैं कि उसकी क्या आवश्यकता है। सही शैली सिखाने का सबसे प्रभावी तरीका सही प्रारूप में एक या अधिक रिपोर्ट को फिर से लिखना है, जो भविष्य के लिए एक मॉडल के रूप में काम करेगा। नतीजतन, एक उत्साही परीक्षक उन त्रुटियों की स्पष्ट और संक्षिप्त रिपोर्ट लिखेगा जिन्हें अधिक आदर्श नहीं बनाया जा सकता है।

गुमराह करने वाले

एक क्यूए, जो अक्सर त्रुटिपूर्ण रूप से त्रुटियों की रिपोर्ट करता है, डेवलपर को गलत तरीके से आगे बढ़ाता है जब वह समस्या को पुन: उत्पन्न करने और ठीक करने का प्रयास करता है।

• अलार्मिस्ट में उत्परिवर्तित कर सकते हैं
• यह आंकड़ों की तरह एक परियोजना प्रबंधक के साथ संयोजन में खतरनाक है
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: उच्च

समस्या

त्रुटि रिपोर्ट में निम्नलिखित शामिल होना चाहिए:

1. यह निर्धारित करने की क्षमता कि वास्तव में गलती है
2. बग खेलने के लिए चरणों को परिभाषित करने की क्षमता
3. त्रुटि का एक पूर्ण विवरण, अक्सर एक मूल कारण के साथ
4. बग खेलने के लिए स्पष्ट चरण

इनमें से किसी भी चरण में, रिपोर्ट डेवलपर को गुमराह कर सकती है, जिसके परिणामस्वरूप वह समय बर्बाद करेगा:

• यदि कोई त्रुटि नहीं है, तो डेवलपर एक ऐसी समस्या की तलाश में समय बिताता है जो मौजूद नहीं है
• यदि त्रुटि को पुन: प्रस्तुत नहीं किया जा सकता है, तो डेवलपर अपने प्रजनन पर समय बिताता है
• यदि त्रुटि ठीक से वर्णित नहीं है, तो डेवलपर बहुत विशिष्ट या बहुत व्यापक मूल कारण के लिए खोज करने में समय बिताता है
• यदि पुन: प्रस्तुत करने के चरण गलत हैं, तो डेवलपर उन्हें व्याख्या करने के लिए समय बिताता है या कोई बग घोषित नहीं कर सकता है, हालांकि वह करता है

कभी-कभी एक डेवलपर को एक साधारण परीक्षक त्रुटि के कारण भ्रमित हो जाता है। लेकिन एक भ्रामक परीक्षक अक्सर ऐसी रिपोर्ट तैयार करता है, जिससे डेवलपर्स में काफी असंतोष होता है। यदि स्थिति जारी रहती है, तो परीक्षक अंततः डेवलपर्स के विश्वास को खो देंगे, और वे भी असली बग्स को ठीक करना बंद कर देंगे, उनकी त्रुटि रिपोर्ट को खारिज कर देंगे।

निर्णय

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

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

उत्पीड़ित

क्यूए, जो डेवलपर्स द्वारा इस हद तक पीटा जाता है कि यह किसी भी त्रुटि की रिपोर्ट करने की संभावना नहीं है, उनकी ओर से बदमाशी का डर है।

• एक नीरस साहस में उत्परिवर्तित कर सकते हैं
• प्राइम डोना प्रकार और बंधक लेने वालों के साथ संयोजन में खतरनाक
• सुधार संभावना: कम
• परियोजना के लिए खतरा: कम

समस्या

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

• पहले से ही डेवलपर्स के महान आत्मविश्वास को जीत लिया, इसलिए उनकी बग को हमेशा गंभीरता से लिया जाता है।
• बग को न पहचानने वाले डेवलपर के साथ विवाद में कम आक्रामकता और दृढ़ता दिखाने में सक्षम।

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

• डेवलपर के पास आत्म-महत्व की एक उच्च भावना है (एक डेवलपर जैसे कि प्रमा दान ) देखें
• डेवलपर का मानना ​​है कि वह परीक्षक से बेहतर जानता है कि सिस्टम कैसे काम करता है (एक बंधक लेने वाले की तरह एक डेवलपर देखें)

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

• उन्होंने डेवलपर के साथ बात की, और उन्होंने कहा कि यह कोई गलती नहीं है।
• उन्होंने एक बग रिपोर्ट दर्ज की, लेकिन डेवलपर ने इसे खारिज कर दिया।
• उन्होंने एक गलती पाई, लेकिन "यह नहीं समझा कि यह पर्याप्त महत्वपूर्ण था।"

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

निर्णय

डेवलपर्स बहुत बार सीधे परीक्षकों का मजाक उड़ाते हैं। इस प्रकार, उन्हें किसी भी गुंडे की तरह माना जाना चाहिए:

• QA को तुरंत रोकने और आक्रामक व्यवहार से परहेज करने की मांग की।
• ट्रेन पेशेवर संचार।
• यदि डेवलपर अपने व्यवहार को ठीक नहीं कर सकता है तो उसे खारिज करें।

विशेष रूप से गंभीर मामलों में, कार्मिक विभाग को हस्तक्षेप करना होगा, खासकर अगर स्थिति खुली दुश्मनी में बदल गई हो।

यह दुखद है कि यह स्थिति अपवाद के बजाय आदर्श है। अंतर केवल शत्रुता की डिग्री है।

रैंडम क्लिकर

QA जो यादृच्छिक क्लिक विधि द्वारा त्रुटियों की खोज करता है।

• एक फायर होज़ में म्यूट कर सकते हैं
• पेटेंट लेखक जैसे उत्पाद प्रबंधक के साथ संयुक्त होने पर खतरनाक
• सुधार संभावना: कम
• परियोजना के लिए खतरा: कम

समस्या

सिस्टम में कीड़े की खोज दो मुख्य तरीकों द्वारा की जाती है:

1. परीक्षण मामलों के अनुसार योजनाबद्ध तरीके से परीक्षण मामलों की सूची तैयार करना।
2. उपयोगकर्ता के कार्यों का अनुकरण करने के प्रयास में आवेदन के आसपास बेतरतीब भटकना।

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

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

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

निर्णय

एक यादृच्छिक क्लिकर दो मामलों में से एक में दिखाई दे सकता है:

1. उन्हें यह नहीं सिखाया गया कि आवेदन का सही परीक्षण कैसे किया जाए।
2. वह सक्रिय रूप से एक परीक्षण योजना लिखने से बचता है।

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

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

ब्लिथली बोल्ड

, -, .

• :
• :

समस्या

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

एक लापरवाह परीक्षक से विशिष्ट बग रिपोर्ट में निम्नलिखित वाक्यांश शामिल हैं:

• "यह काम नहीं करता है।"
• "यह फिर से टूट गया है।"
• "यदि आप वास्तव में इस सुविधा का उपयोग करते हैं तो समस्या स्पष्ट होगी।"
• "मुझे नहीं पता कि वे क्यों चूक गए।"
• "अगली बार इसे ध्यान से देखें"
• "मुझे नहीं पता कि हम इसे सही तरीके से लागू क्यों नहीं कर सकते हैं"

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

निर्णय

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

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

यह अक्सर इसे ठीक करने की कोशिश करने की तुलना में लापरवाह साहसी परीक्षक को हटाने के लिए अक्सर अधिक कुशल होता है। अपने कार्यों से, वह निश्चित रूप से यह स्पष्ट करता है कि वह परीक्षण में संलग्न नहीं होना चाहता है, इसलिए इसे हटाना आम हित में है।

यह भी देखें:

• "डेवलपर्स के बीच समस्या व्यक्ति"
• "परियोजना प्रबंधकों के बीच समस्या व्यक्ति"