क्या परीक्षकों को अपने काम को स्वचालित करना चाहिए?

Question

हम अपनी परीक्षण प्रक्रिया को सेटअप करने का प्रयास कर रहे हैं। हमें आश्चर्य है कि क्या हमारे परीक्षकों को स्वचालित प्रतिगमन परीक्षण विकसित करना चाहिए, या यदि डेवलपर्स को ऐसा करना चाहिए।

और अन्य प्रकार के स्वचालित परीक्षणों के बारे में क्या? क्या परीक्षकों को उनका विकास करना चाहिए?

Comments

बस उन्हें "परीक्षण में डेवलपर्स" कहना शुरू करें और अस्पष्टता हल हो गई है।

— एडवर्ड स्ट्रेंज

@Crazy लेकिन 2 डेवलपर टीमों के लिए अधिक महंगा नहीं है?

— Jader Dias

क्या महंगा है? एक खराब परीक्षण उत्पाद बेचना? विकास प्रक्रिया में अड़चन है क्योंकि डेवलपर्स उत्पाद के बजाय परीक्षण लिख रहे हैं?

— एडवर्ड स्ट्रेंज

Answer 1

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

साथ ही कार्यात्मक आवश्यकताओं की उनकी समझ डेवलपर्स की समझ से उच्च स्तर की हो सकती है - इसलिए प्रोग्रामर के कट्टर निम्न-स्तरीय ज्ञान के बीच बैठे, लेकिन बीए की तुलना में उच्च स्तर पर नहीं।

Comments

लेकिन क्या वे सिर्फ डेवलपर्स को उस टेस्ट केस को लिखने के लिए नहीं कह सकते हैं?

— जदर डायस

उपरोक्त कारणों के लिए, डेवलपर्स को आंतरिक कार्यान्वयन के बारे में अधिक जानकारी होगी और यह बाहर से आने वाले सॉफ़्टवेयर से अलग तरीके से संपर्क करेगा।

— जेम्स लव

मैं यह नहीं देख सकता कि एक परीक्षण मामले का कार्यान्वयन एक व्यक्ति से दूसरे व्यक्ति में कैसे भिन्न हो सकता है।

— Jader Dias

@ जैदर, आप अलग-अलग लोगों को मूल कोड लिखे जाने की तुलना में स्वचालित परीक्षण लिखना चाहते हैं। अन्यथा परीक्षण कोड के साथ काम करने के लिए पक्षपाती होंगे जैसा कि लिखा गया था।

— मार्की

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

— एथेल इवांस

Answer 2

यदि आप इसे स्वचालित कर सकते हैं, तो इसे स्वचालित करें।

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

Comments

लेकिन उन्हें केवल डेवलपर्स ही क्यों और कैसे चाहिए?

— Jader Dias

@ जदरियास, जैसा कि उल्लेख किया गया है, परीक्षकों के पास उस कोड के बारे में कोई पूर्वाग्रह नहीं होना चाहिए, जिस पर वे परीक्षण करने का प्रयास कर रहे हैं

— कैफ़ीक

Answer 3

मेरी राय में, डेवलपर्स और परीक्षक विभिन्न प्रकार के परीक्षणों के लिए जिम्मेदार हैं।

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

इस बिंदु से परीक्षक को सिस्टम वाइड टेस्ट लिखने के लिए जिम्मेदार होना चाहिए जो यह सुनिश्चित करता है कि व्यावसायिक तर्क काम करता है।

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

Comments

अपने अंतिम वाक्य के बारे में उत्सुक - आपको नहीं लगता कि देवता कार्यात्मक परीक्षणों में योगदान कर सकते हैं? क्या होगा यदि परीक्षक परीक्षण संरचना को रेखांकित करते हैं और परीक्षण मामलों की पहचान करते हैं और देवता केवल कार्यान्वयन में सहायता करते हैं?

— मिस सेलानी

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

— टेलर मूल्य

Answer 4

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

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

जोड़ने के लिए संपादित: मैं 5 साल के अनुभव के साथ एक एसडीईटी हूं। मैं 10+ वर्षों के अनुभव के साथ महान देवों के साथ काम करता हूं, और हाल ही में उनके साथ परीक्षण टोंटी के माध्यम से प्राप्त करने के लिए काम कर रहा हूं।

Answer 5

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

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

Comments

विज़ुअल स्टूडियो 2010 (प्रीमियम या अल्टीमेट, याद नहीं रख सकता है) कि यूआई परीक्षण को स्वचालित करने के लिए स्क्रीन एक्शन रिकॉर्ड करने वाली कोई चीज़ है। मैंने यूआई टेस्टिंग SharePoint, अविश्वसनीय रूप से सामान के शो करते समय एंड्रयू वुडवर्ड एमवीपी द्वारा इसका एक डेमो देखा।

— जेम्स लव

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

— वृषण

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

— ग्लेनट्रॉन

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

— टेस्टेरैब

Answer 6

एक महत्वपूर्ण अंतर जो वास्तव में यहाँ महत्वपूर्ण है वह यह है: क्या आपके परीक्षक केवल जाँच कर रहे हैं, या वे परीक्षण कर रहे हैं ?

माइकल बोल्टन की यह ब्लॉग पोस्ट इसे बेहतर बताती है, लेकिन संक्षेप में: क्या वे केवल व्यवहार की पुष्टि करने के लिए देख रहे हैं, या वे सिस्टम के साथ मुद्दों को ढूंढ रहे हैं?

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

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

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

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