असली परीक्षकों और नकली लोगों के बीच अंतर क्या है?

आज मुझे नींद नहीं आ रही थी। कठिन विचार पहले दिन मेरे नश्वर अस्तित्व का निरीक्षण नहीं कर रहे हैं।



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



पहला धर्मी विचार था: परीक्षण से नाराज होना!



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



लेकिन वहाँ हैं, उनके क्षेत्र में सच्चे प्रतिभाशाली हैं जो लाभकारी हैं, और, परीक्षण के क्षेत्र में "दलदली" श्रम बाजार के बावजूद, वे उच्च योग्य विशेषज्ञ हैं!



वे कौन हैं?

असली जेडी को नकली परीक्षकों से कैसे अलग करें?



विचारों का नतीजा था FALSE से वर्तमान परीक्षण के दस वर्ष की अवधि।

1. एक ही समय में परियोजना के साथ वास्तविक परीक्षक।

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



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



और इसके लिए आपको चाहिए:

* परियोजना के उद्देश्यों को ध्यान में रखें

* बाहरी परिस्थितियों (प्राथमिकताओं, समय सीमा, लक्ष्यों, शीर्ष-स्तरीय कार्यों) के अनुकूल होना

* यह पता लगाने में सक्षम हो: परियोजना को अपना लक्ष्य प्राप्त करने में मदद के लिए अब क्या करने की आवश्यकता है?



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



इसलिए, कार्य के बजाय "मैं डेवलपर्स के लिए बग्स का एक गुच्छा और डीडीओएस के लिए कैसे ढूंढूंगा", असली परीक्षकों को लगता है: "परियोजना को अब किस प्रारूप में और किन प्राथमिकताओं के साथ ज़रूरत है?"।

2. असली परीक्षक परीक्षण डिजाइन कर सकते हैं।

कोई manklicking और त्वरित परीक्षण!

असली परीक्षक परीक्षण डिजाइन कर सकते हैं। ऐसा करने के लिए, उन्होंने कम से कम ली कोपलैंड की टेस्ट डिज़ाइन बाइबिल को याद किया, और बहुत कम गुणवत्ता वाले गुणवत्ता जोखिम नियंत्रण में ।

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

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



पहले सोचने के लिए, फिर परखने के लिए!

3. असली परीक्षक परीक्षण के तहत सॉफ्टवेयर की वास्तुकला को समझते हैं।

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

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

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

अपनी आँखें खोलें और प्रकाश चालू करें! देखें कि आप क्या परीक्षण कर रहे हैं!



सॉफ्टवेयर कैसे काम करता है, यह आप जान सकते हैं:

* अधिक कुशलता से डिजाइन परीक्षण

* सॉफ्टवेयर के संचालन को प्रभावित करने वाले कारकों को जानते हुए, उच्च कवरेज प्रदान करें

* अधिक सटीक और सक्षम रूप से त्रुटियों को स्थानीयकृत करें - जिसका मतलब है कि डेवलपर्स के लिए समय की बचत और समग्र रूप से परियोजना!

4. असली परीक्षक संचार के स्वामी होते हैं।

कौन, यदि परीक्षक नहीं, तो बुरी खबर को ले जाना है? सबसे खराब बात आप कर सकते हैं यदि आप एक दोष पाते हैं तो डेवलपर को बताएं, "ठीक है, आपने गड़बड़ कर दी!"

हमें केवल एक दोष खोजने और पंजीकरण करने की आवश्यकता नहीं है। हमें इसे ठीक करने के लिए आसान और सुखद बनाने के लिए सब कुछ करने की आवश्यकता है।

सॉफ्टवेयर में तय किया गया हर बग ठंडा है, और कोई भी डेवलपर इसे समझता है।

केवल अगर उन्हें पहले नहीं बताया गया था कि वह "घास काटने", "बाजित" और "छोटी गाड़ी" है!



दोषों के बारे में डेवलपर्स के साथ संवाद करने के बारे में - मास्को क्लब ऑफ टेस्टर्स की बैठक में एलेक्सी बरनतसेव के भाषण की रिकॉर्डिंग ।

5. असली परीक्षक आवेदन क्षेत्र में अच्छी तरह से वाकिफ हैं।

एक बार मैंने अकाउंटिंग सॉफ्टवेयर के विकास में लगी मॉस्को कंपनी में परीक्षण प्रक्रिया का ऑडिट किया। कंपनी प्रबंधन के अनुसार, परीक्षकों ने कई दोषों को याद किया। कारण सरल था: कंपनी के विश्लेषक (2 पीसी।) कंपनी के परीक्षकों के लिए परीक्षण के मामले लिखे (~ 15 पीसी।)। परीक्षकों ने उन्हें पास किया और परीक्षण मामलों में दस्तावेज से सॉफ्टवेयर के व्यवहार में सभी विचलन दर्ज किए।

उसी समय, उन्हें यह भी समझ में नहीं आया कि संतुलन क्या है और सिद्धांत सिद्धांतों से क्या उत्पन्न होता है!



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



ऐसा होने से रोकने के लिए, वास्तविक परीक्षकों को यह जानना होगा कि उत्पाद कैसे काम करता है। उन्हें उपयोगकर्ता, उसके मानसिक मॉडल को जानना चाहिए: उत्पाद का उपयोग कैसे किया जाता है? किन स्थितियों में? कैसे?

6. असली परीक्षक विशेषज्ञ नहीं हैं।

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



अनुभवहीन गति के साथ, नई तकनीक और दृष्टिकोण उभर रहे हैं। सभी दिशाओं के उन्नत परीक्षक इसे बनाते हैं, इसे अभी बनाएं!



और कोई ऐसे क्षेत्र में विशेषज्ञ कैसे हो सकता है जो अभी तक गठित नहीं हुआ है? इसमें किसी चीज़ को "सही" कहा जाना बहुत ही लचीला है?



"मैं एक विशेषज्ञ हूँ!" = "मैं अब विकास नहीं करूँगा।" और यह असली परीक्षकों के बारे में नहीं है।

7. असली परीक्षक लक्ष्य चुनते हैं, साधन नहीं।

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



परीक्षण में (जैसा कि, संभवतः, अन्य क्षेत्रों में?) "शांत", "दिलचस्प" और "चलो कोशिश करें?" से कई निर्णय किए जाते हैं।



लेकिन "शीतलता" की अवधारणा बिल्कुल नहीं है! प्रत्येक परियोजना, प्रत्येक टीम की अपनी काम करने की स्थिति होती है, और प्रभावी परीक्षण हमेशा संदर्भ से निर्धारित होता है !



जब असली परीक्षक कुछ लागू करने का निर्णय लेते हैं, तो वे कहते हैं: "यह हमारी परियोजना के लिए उपयोगी होगा, क्योंकि ..."। और ये शब्द एक असली परीक्षक को एक नकली से कुछ और से अलग करते हैं।

8,9,10। असली परीक्षक अपने काम से प्यार करते हैं, अपने उत्पादों से प्यार करते हैं और लगातार विकसित हो रहे हैं।

दस घोषित अंकों से मिलान करने के लिए, मैं संक्षेप में तीन और कवर करूंगा:

* असली परीक्षक अपने काम से प्यार करते हैं, हमेशा उसमें रचनात्मकता पाते हैं, और उनकी दिनचर्या नहीं हो सकती है! क्योंकि प्रत्येक नए कार्य को बेहतर, बेहतर, अधिक कुशलता से किया जाता है - और इसलिए अधिक दिलचस्प और अधिक दिलचस्प!

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

* असली परीक्षक लगातार विकसित हो रहे हैं। और वे एक युवा नाजुक उद्योग विकसित कर रहे हैं!

निष्कर्ष

असली परीक्षक खुद निष्कर्ष निकालेंगे :-)



और मैं सिर्फ इन विरले लोगों से कहना चाहता हूं जिन्हें लाल किताब में दर्ज किया जा सकता है: "धन्यवाद!"

अभी भी खड़े नहीं होने के लिए धन्यवाद।

परियोजनाओं को लाभान्वित करने के लिए धन्यवाद।

उद्योग को विकसित करने के लिए धन्यवाद!