बायाँ परीक्षण शिफ्ट गर्नुहोस्: सफ्टवेयर सफलताको लागि एक गोप्य मन्त्र

ठूलो संलग्नताको लागि DevOps अभ्यासहरू कार्यान्वयन गर्दै। तर उनको अनुसार, सिकाइ कहिल्यै रोकिदैन...

तलको कमेन्ट सेक्सनमा हामीलाई आफ्नो विचार/सुझाव दिनुहोस्।

अघिल्लो ट्यूटोरियल

सफ्टवेयर परीक्षण को अवधारणा बिस्तारै प्रस्तुत भयो जब उत्पादनबाट त्रुटिहरूले परियोजनाको बजेटमा असर गर्न थाल्यो र त्यसैले 'कार्यात्मक परीक्षण' परीक्षकहरूको धेरै दुबला टोलीसँग प्रभावकारी भयो। त्यस समयमा, हामी 20 विकासकर्ताहरूको टोलीको बिरूद्ध केवल दुई परीक्षक थियौं।

आईटी उद्योगले सफ्टवेयर विकासको लागि झरना मोडेललाई पछ्याउन थाल्यो जहाँ, हामी सबैलाई थाहा छ। , सफ्टवेयर विकास जीवनचक्र क्रमशः क्रमबद्ध रूपमा जान्छ।

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

परिचय बायाँ शिफ्टको अवधारणामा

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

सफ्टवेयरमा धेरै समय र प्रयास खर्च गरेपछि, अन्त्यमा पहिचान गरिएको महत्त्वपूर्ण बगका कारण, मिशन-क्रिटिकल सफ्टवेयरलाई जारी गर्न सकिएन। जसले गर्दा बजारले ठूलो नोक्सानी निम्त्याउँछ।

तसर्थ, अन्तिम चरणमा बगको पहिचानका कारण विमोचन ढिलो भयो वासमय, सफ्टवेयर तिनीहरूलाई ठीक गर्न आवश्यक प्रयास विचार गरेर खारेज गरिएको थियो, जुन वास्तवमा यसको लायक थिएन। प्रारम्भिक।

यो अनुभूति र सिकेको ठूलो पाठले सफ्टवेयर उद्योगमा ठूलो क्रान्ति ल्यायो र 'बायाँ सिफ्ट'2 नामक नयाँ अवधारणालाई जन्म दियो।> , जसको अर्थ 'परीक्षण चरण' लाई दायाँबाट बायाँतिर सार्नु वा प्रत्येक चरणमा परीक्षण समावेश गर्नु र परीक्षकहरूलाई समावेश गर्नु हो।

बायाँ परिक्षण सिफ्ट गर्नु भनेको अन्त्यमा मात्र परीक्षण नगर्नु हो तर लगातार परीक्षण गर्नुहोस्।

4>

बायाँ सिफ्ट परीक्षण के हो?

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

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

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

कसरी गर्छ। बायाँ प्रभाव सफ्टवेयर विकास शिफ्ट?

Shift Lift Approach ले सफ्टवेयर विकासलाई धेरै तरिकामा प्रभाव पार्छ।

बायाँ शिफ्ट बारे केही मुख्य बुँदाहरू तल दिइएको छ:

  • Shift Left दृष्टिकोणले सबैमा परीक्षकहरू समावेश गर्ने र सबैभन्दा महत्त्वपूर्ण रूपमा महत्वपूर्ण चरणहरू कार्यक्रमको मा केन्द्रित छ। । यसले परीक्षकहरूलाई दोष पत्ता लगाउनबाट आफ्नो फोकसलाई दोष निवारणमा फर्काउन र कार्यक्रमको व्यावसायिक लक्ष्यहरू ड्राइभ गर्न सक्षम बनाउँछ।
  • शिफ्ट बायाँ दृष्टिकोणले प्रदान गर्दछ, परीक्षणको लागि उच्च महत्त्व जसको साथमा परीक्षकहरूको भूमिका र जिम्मेवारी धेरै बढ्छ।
  • परीक्षण टोलीको लागि जिम्मेवारी बढ्दै जाँदा, टोलीले 'सफ्टवेयरको पहिचान गर्न सफ्टवेयरको परीक्षणमा ध्यान केन्द्रित गर्दैन। बगहरू' , तर प्रारम्भिक चरणहरूदेखि नै टोलीसँग सक्रिय रूपमा कार्य गर्दछ र टोलीलाई उत्कृष्ट परीक्षण नेतृत्व र मार्गदर्शन प्रदान गरेर एक बलियो र प्रभावकारी परीक्षण रणनीति योजना र निर्माण गर्नको दीर्घकालीन दृष्टिकोणमा ध्यान केन्द्रित गरेर। उत्पादन, परीक्षण कार्यको जिम्मेवारी लिनुको सट्टा।
  • Shift Left दृष्टिकोणले परीक्षकहरूका लागि पहिले परीक्षणहरू डिजाइन गर्ने अवसर , जहाँ परीक्षणहरू पूर्ण रूपमा ग्राहकको अनुभव र उनीहरूको अपेक्षाहरूमा केन्द्रित हुन्छन् जसले विकासकर्ताहरूलाई यी परीक्षणहरूमा आधारित सफ्टवेयर विकास गर्न सक्षम गर्दछ। र यसैले ग्राहक आवश्यकताहरू पूरा गर्नुहोस्।
  • बायाँ शिफ्ट दृष्टिकोण केवल परीक्षकहरूसँग मात्र समाप्त हुँदैन। लेटमा सर्नु र परीक्षण गतिविधिहरू निरन्तर सञ्चालन गर्नाले विकासकर्ताहरूलाई तिनीहरूको कोडको थप स्वामित्व लिन अनुमति दिनेछ र परीक्षणमा उनीहरूको जिम्मेवारी बढाउन।
  • सिफ्ट बायाँ दृष्टिकोणले परीक्षकहरूलाई व्यवहार-संचालित विकास BDD र परीक्षण-संचालित विकास TDD अपनाउन पनि प्रोत्साहित गर्दछ, जसले सफ्टवेयरमा दोषको प्रवेश रोक्न मद्दत गर्दछ।
  • एजाइलमा बायाँ परिक्षण शिफ्ट गर्नुहोस्: शिफ्ट बायाँ दृष्टिकोणले एजाइल स्क्रम टीमहरू बनाउन समर्थन गर्दछ जसमा अनिवार्य रूपमा परीक्षकहरू समावेश हुन्छन् अन्य भूमिकाहरू र नियमित स्ट्यान्ड अप कलहरूमा परीक्षकहरू, अन्य अन्तरक्रियाहरू, समीक्षा बैठकहरू जसले परीक्षकहरूलाई कार्यक्रमसँग सम्बन्धित थप जानकारीहरू प्रदान गरेको छ र त्यसैले उनीहरूलाई सफ्टवेयरको विस्तृत विश्लेषणमा संलग्न हुन र संलग्न हुन अनुमति दिएको छ र सफ्टवेयरमा रहेका त्रुटिहरूलाई रोक्न मद्दत गर्ने द्रुत प्रतिक्रिया प्रदान गर्दछ।

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

बायाँ सिफ्टमा परीक्षकहरूले फरक रूपमा के गर्नुपर्छ?

बायाँ सिफ्ट रणनीति:

#1) टेस्ट टोलीमा परीक्षकहरूले फरक तरिकाले के गर्छन् भनेर तल उल्लेख गर्नका लागि केही मुख्य कारकहरू छन्। प्रोजेक्ट प्रारम्भदेखि नै प्रणालीमा प्रारम्भिक रूपमा संलग्न हुन आवश्यक छ ताकि बाँकी टोली र व्यवसायसँग एकीकरण विकास गर्न प्रत्येक चरणमा उपयोगी इनपुटहरू प्रदान गर्न सफ्टवेयर विकासको।

#2) परीक्षण टोलीले व्यवसायसँग काम गर्नुपर्छ & सञ्चालन टोली र कार्यक्रममा स्पष्टता प्राप्त गर्नुहोस् र मागको स्पष्ट दृष्टिकोण प्रदान गर्नुहोस् र कार्यक्रमलाई राम्रोसँग स्रोत र्याम्प-अप आवश्यकताहरू, प्रशिक्षण आवश्यकताहरू, र परीक्षण उपकरण आवश्यकताहरूमा कुशलतापूर्वक योजना बनाउन मद्दत गर्नुहोस्। अग्रिम।

#3) परीक्षण टोलीहरूले सफ्टवेयर विकासको सुरुमा सबै व्यापार सरोकारवालाहरूसँग अन्तरक्रिया गर्नुपर्छ उत्पादनको स्पष्ट दृश्यता प्राप्त गर्न 9 & एक एकीकृत परीक्षण रणनीति डिजाइन गर्नुहोस् र एक अनुकूलित परीक्षण प्रयासको लागि योजना बनाउनुहोस्, परीक्षण वातावरण, तेस्रो पक्षहरू, स्टबहरू, इत्यादिमा निर्भरता विश्लेषण गर्नुहोस्, र तयार गर्नुहोस्। बलियो स्वचालन रणनीति र फ्रेमवर्क र एक प्रभावकारी परीक्षण डाटा व्यवस्थापन निर्माणयोजना।

#4) टेस्ट टोलीले टोलीलाई उत्कृष्ट टेस्ट नेतृत्व र मार्गदर्शन प्रदान गर्न बाँकी टोलीसँग काम गर्नुपर्छ यसरी परीक्षण गतिविधिहरूको लागि जिम्मेवारी लिनुको सट्टा दीर्घकालीन उत्पादन दृष्टिलाई ध्यानमा राख्दै।

#5) आवश्यकताहरू कुनै पनि कार्यक्रमको सफलताको लागि कुञ्जी र आधार हुन् र राम्रो- परिभाषित आवश्यकताहरूले परियोजनाको सफलतालाई परिभाषित गर्दछ। आवश्यकता योजनाको चरणमा, परीक्षकहरूले कुनै पनि अस्पष्टता, राम्रो स्पष्टता, पूर्णता, परीक्षण योग्यता, स्वीकृति मापदण्ड परिभाषा, इत्यादिको लागि आवश्यकताहरूको समीक्षा र विश्लेषण गर्न आवश्यक छ

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

#6) 8 लाई बाहिर ल्याएर आवश्यकताहरूमा पर्याप्त स्पष्टता र परिशुद्धता ल्याउनुहोस्।>वास्तविक उदाहरणहरू जसले प्रयोगमा रहेका सुविधाहरू चित्रण गर्दछ।

#7) परीक्षकहरूले डिजाइन समीक्षा बैठकहरूमा उपस्थित हुन आवश्यक छ नियमित रूपमा र उत्पादन डिजाइन र वास्तुकला बुझ्नुहोस् र डिजाइन त्रुटिहरू पहिचान गर्नुहोस्, वैकल्पिक डिजाइन विकल्पहरू सुझाव दिनुहोस्, त्रुटिहरू पहिचान गर्नुहोस्, र डिजाइनहरू तोड्नको लागि तदनुसार परीक्षण परिदृश्यहरू सिर्जना गर्नुहोस्।

#8) परीक्षकहरूले पहिले नै स्थिर परीक्षण (समीक्षाहरू) गर्न आवश्यक छ र मुख्य परियोजनामा ​​प्रतिक्रिया प्रदान गर्न आवश्यक छ।कागजातहरू ताकि त्रुटिहरू सफ्टवेयरमा ग्राउन्ड हुनबाट र पछि यसको प्रभावलाई फराकिलो हुनबाट रोक्न सकिन्छ।

#9) परीक्षण टोलीले डिजाइन र विकास टोलीसँग सहकार्य गर्नुपर्छ मा कोड विकास गर्न अग्रिम परीक्षण परिदृश्यहरू उपलब्ध गराउनुहोस् र सबै सम्भावित वास्तविक-समय परिदृश्यहरू र व्यापार प्रवाहहरू सम्बोधन गर्नुहोस्।

#10) परीक्षण टोलीले डिजाइन गर्नुपर्छ बलियो र बलियो परीक्षण परिदृश्यहरू ताकि परीक्षणको क्रममा केही दोषहरू मात्र पहिचान गर्न सकिन्छ र परीक्षण चरणमा प्रवेश गर्दा ठूला दोषहरू रोक्न सकिन्छ।

#11) परीक्षकहरूले जति सक्दो चाँडो परीक्षण गर्नुपर्दछ , यो स्ट्यान्डअलोन वा स्थानीय प्रणालीमा होस्, ताकि दोष पछिका चरणहरूमा नपरोस्।

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

शिफ्ट बायाँ परीक्षणका फाइदाहरू

द शिफ्ट लेफ्ट दृष्टिकोणले चुस्त घोषणापत्रमा आधारित काम गर्दछ र त्यसका धेरै फाइदाहरू पनि छन्।

तिनीहरू हुन्:

  • व्यक्ति र अन्तरक्रियाहरू प्रक्रियाहरूमा र उपकरणहरू।
  • कार्यकारी सफ्टवेयर विस्तृत कागजातहरूमा।
  • ग्राहक सहयोग सम्झौता वार्तामा।
  • प्रतिक्रिया गर्दै एउटा योजना पछ्याएर परिवर्तन गर्नुहोस्।

हामीले देख्न सक्छौं कि दायाँ तर्फका वस्तुहरूमा मूल्य रहेको बेला, हामी बायाँ तर्फका वस्तुहरूको लागि बढी मूल्यवान छौँ।

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

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

निष्कर्ष

'Shift Left' अवधारणाले सम्पूर्ण 'परीक्षण' भूमिकाको लागि ठूलो परिवर्तन ल्यायो। त्यतिन्जेल, परीक्षणको लागि एकमात्र फोकस 'दोष पत्ता लगाउन' मा मात्र थियो, र अब परीक्षण परिप्रेक्ष्यबाट 'बायाँ सिफ्ट' को उद्देश्य 'प्रारम्भिक दोष पत्ता लगाउन स्थिर परीक्षण' को यात्रा हो। 2>

यसैले, Shift Left सफ्टवेयर विकास पद्धतिमा सफ्टवेयर उद्योगमा बजारमा गति, सफ्टवेयरको गुणस्तर सुधार गर्न, र 'टाइम टु मार्केट' घटाउने ठूलो फड्को हो।

0 लेखकको बारेमा: यो लेख STH टोली सदस्यले लेखेको हो गायत्री सुब्रह्मण्यम। उनी ९० को दशकदेखि सफ्टवेयर परीक्षणमा छिन्, जब उद्योगमा परीक्षकको भूमिका सुरु भएको थियो। आफ्नो परीक्षण करियरको दौडान, उनले धेरै TMMI मूल्याङ्कनहरू, परीक्षण औद्योगिकीकरण कार्यहरू, र TCOE सेटअपहरू परीक्षण वितरणहरू ह्यान्डल गर्नका अतिरिक्त गरेकी छिन्।
माथि स्क्रोल गर्नुहोस्