कहिले प्रयोगकर्ता कथाहरू स्वचालित गर्न?

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

पहिले, केहि मापदण्ड र परीक्षण स्वचालन भएको कारणहरूको बारेमा एक नजर राख्दछ जसले 'किन परीक्षणहरू / स्वत: हुनु हुँदैन' भन्ने प्रश्नको उत्तर दिनुपर्दछ।



पुनरावृत्ति

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




विश्वसनीयता

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



समय

स्वचालित परीक्षणले पनि हाम्रो समय बचत गर्नुपर्दछ। यदि एक साधारण परीक्षण पूरा गर्न १० मिनेट लाग्छ तर समान परिणाम मैन्युअल रूपमा १ मिनेटमा निर्धारित गर्न सकिन्छ, त्यसो भए यो राम्रो छ कि यस्ता परीक्षणहरूलाई स्वचालित रूपमा प्रयोग नगर्नुहोस्।




सुरक्षा जाल

स्वचालित परीक्षणहरूले विकासकर्ताहरूको लागि सुरक्षा नेट प्रदान गर्नुपर्दछ कि राम्रो काम गर्ने कोडबाट कुनै विचलन, कोड बेसमा परिवर्तनको परिणाम स्वरूप, छिटो हाईलाइट हुन्छ र विकासकर्तालाई रिपोर्ट गरिन्छ।



कथाहरू कहिले स्वचालित हुनु पर्छ?

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

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

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


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

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

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

केही संगठनहरूले कडा नियम पनि लाद्छन् कि यो कहानी पूर्ण 'स्वचालित' नभएसम्म 'सम्पन्न' हुँदैन! के हामी एक महत्त्वपूर्ण सुविधाको रिलीज गर्न जाँदैछौं किनभने QA विभिन्न कारणहरूले गर्दा समयमा स्वचालन प्रदान गर्न सकेन वा प्रदान गर्न सकेन? वा एउटा कहानी 'सम्पन्न' भएको छैन किनभने हामीसँग पृष्ठमा एक बटनको अस्तित्व जाँच गर्न स्वचालित स्क्रिप्ट छैन। गम्भीरतापूर्वक?


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

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

रोचक लेख