- परिचय डावीकडे शिफ्ट करण्याच्या संकल्पनेकडे
- शिफ्ट लेफ्ट टेस्टिंग म्हणजे काय?
- कसे होते. सॉफ्टवेअर डेव्हलपमेंटवर डावीकडे प्रभाव टाकायचा?
- परीक्षकांनी डावीकडे शिफ्टमध्ये वेगळे काय करावे?
- शिफ्ट लेफ्ट टेस्टिंगचे फायदे
- निष्कर्ष
खालील टिप्पण्या विभागात तुमचे विचार/सूचना आम्हाला कळवा.
पूर्व ट्यूटोरियल
सॉफ्टवेअर चाचणी ही संकल्पना हळूहळू प्रचलित झाली जेव्हा उत्पादनातील दोष प्रकल्पाच्या बजेटवर येऊ लागले आणि म्हणूनच परीक्षकांच्या अत्यंत दुबळ्या टीमसह 'कार्यात्मक चाचणी' लागू झाली. त्या वेळी, आम्ही 20 विकासकांच्या संघाविरुद्ध फक्त दोन परीक्षक होतो.
IT उद्योगाने सॉफ्टवेअर डेव्हलपमेंटसाठी धबधब्याचे मॉडेल फॉलो करण्यास सुरुवात केली, ज्यामध्ये आपण सर्व जाणतो. , सॉफ्टवेअर डेव्हलपमेंट लाइफसायकल क्रमाक्रमाने क्रमाने जाते.
म्हणून, जर तुम्ही डावीकडून उजवीकडे सुरुवात केली, तर चाचणी टप्पा सॉफ्टवेअर डेव्हलपमेंट लाइफसायकलच्या अगदी उजवीकडे आहे.
परिचय डावीकडे शिफ्ट करण्याच्या संकल्पनेकडे
काही कालांतराने, लोकांना सॉफ्टवेअर चाचणी चे महत्त्व आणि 'चाचणी टप्पा' अत्यंत उजवीकडे किंवा शेवटी ठेवण्याचा परिणाम लक्षात आला. सॉफ्टवेअर डेव्हलपमेंट लाइफसायकल. ही जाणीव झाली कारण अत्यंत उजवीकडे आणि शेवटी ओळखल्या जाणार्या बगची किंमत खूप जास्त होती आणि प्रचंड मेहनत होती & त्यांचे निराकरण करण्यासाठी खूप वेळ लागला.
अशी काही प्रकरणे होती जेव्हा सॉफ्टवेअरवर इतका वेळ आणि मेहनत खर्च केल्यानंतर, शेवटी ओळखल्या गेलेल्या महत्त्वपूर्ण बगमुळे, मिशन-क्रिटिकल सॉफ्टवेअरला सोडले जाऊ शकले नाही. त्यामुळे बाजाराचे मोठे नुकसान होते.
म्हणूनच, शेवटच्या टप्प्यात बग ओळखल्यामुळे एकतर रिलीज होण्यास उशीर झाला किंवाकाही वेळा, सॉफ्टवेअरचे निराकरण करण्यासाठी आवश्यक असलेल्या प्रयत्नांचा विचार करून ते स्क्रॅप केले गेले, जे खरोखर फायदेशीर नव्हते.
'दोष पकडले जातात तेव्हा ते कमी खर्चिक असतात लवकर.
या जाणिवेने आणि शिकलेला मोठा धडा, सॉफ्टवेअर उद्योगात मोठी क्रांती घडवून आणली आणि 'डावीकडे शिफ्ट'2 नावाच्या नवीन संकल्पनेला जन्म दिला. , म्हणजे 'चाचणी टप्पा' उजवीकडून डावीकडे हलवणे किंवा प्रत्येक टप्प्यावर चाचणी समाविष्ट करणे आणि संपूर्ण परीक्षकांचा समावेश करणे.
डावीकडे शिफ्ट चाचणीचा अर्थ असा आहे की फक्त शेवटी चाचणी करू नका सतत चाचणी.
शिफ्ट लेफ्ट टेस्टिंग म्हणजे काय?
सर्वप्रथम, 'डावीकडे शिफ्ट' हे तत्त्व सॉफ्टवेअर डेव्हलपमेंट टप्प्यात सर्व भागधारकांसोबत लवकर सहकार्य करण्यासाठी चाचणी टीमला समर्थन देते . त्यामुळे ते गरजा स्पष्टपणे समजून घेऊ शकतात आणि सॉफ्टवेअर 'फेल फास्ट'ला मदत करण्यासाठी चाचणी प्रकरणे डिझाइन करू शकतात आणि टीमला सर्व अपयश लवकरात लवकर दुरुस्त करण्यास सक्षम करू शकतात.
डावीकडे शिफ्ट करण्याचा दृष्टीकोन म्हणजे फार पूर्वी परीक्षकांना सामील करून घेण्याशिवाय काहीच नाही. सॉफ्टवेअर डेव्हलपमेंट लाइफ सायकलमध्ये, ज्यामुळे त्यांना आवश्यकता, सॉफ्टवेअर डिझाइन, आर्किटेक्चर, कोडिंग आणि त्याची कार्यक्षमता समजून घेता येईल, ग्राहकांना, व्यवसाय विश्लेषकांना आणि विकासकांना कठीण प्रश्न विचारू शकतात, स्पष्टीकरण शोधू शकतात आणि समर्थन देण्यासाठी शक्य असेल तेथे अभिप्राय प्रदान करू शकतात. संघ.
हा सहभाग आणि समजून घेईलपरीक्षकांना उत्पादनाविषयी संपूर्ण ज्ञान मिळवण्यासाठी, विविध परिस्थितींचा विचार करण्यासाठी आणि सॉफ्टवेअर वर्तनावर आधारित रिअल-टाइम परिस्थिती तयार करण्यासाठी नेतृत्व करा जे कोडिंग पूर्ण होण्यापूर्वीच दोष ओळखण्यात टीमला मदत करेल.
कसे होते. सॉफ्टवेअर डेव्हलपमेंटवर डावीकडे प्रभाव टाकायचा?
शिफ्ट लिफ्ट अॅप्रोच सॉफ्टवेअर डेव्हलपमेंटवर अनेक प्रकारे प्रभाव पाडतो.
खाली शिफ्ट लेफ्ट बद्दल काही प्रमुख मुद्दे दिले आहेत: 2
- शिफ्ट लेफ्ट पध्दत प्रोग्रामच्या सर्व आणि सर्वात महत्वाचे टप्पे मध्ये परीक्षकांचा समावेश करण्यावर लक्ष केंद्रित करते . हे परीक्षकांना दोष शोधण्यापासून त्यांचे लक्ष दोष निवारणाकडे वळविण्यास आणि कार्यक्रमाची व्यावसायिक उद्दिष्टे साध्य करण्यास सक्षम करते.
- डावीकडे शिफ्ट दृष्टीकोन प्रदान करते, चाचणीला उच्च महत्त्व ज्याने परीक्षकांच्या भूमिका आणि जबाबदाऱ्या मोठ्या प्रमाणात वाढतात.
- चाचणी संघासाठी जबाबदारी वाढल्यामुळे, टीम फक्त 'ओळखण्यासाठी सॉफ्टवेअरची चाचणी करण्यावर लक्ष केंद्रित करत नाही. बग्स' , परंतु दीर्घकालीन दृष्टिकोनावर लक्ष केंद्रित करून संघाला उत्कृष्ट कसोटी नेतृत्व आणि मार्गदर्शन प्रदान करून एक मजबूत आणि प्रभावी चाचणी धोरण आखण्यासाठी आणि तयार करण्यासाठी सुरुवातीच्या टप्प्यापासूनच संघासोबत सक्रियपणे कार्य करते. केवळ चाचणीच्या कामाची जबाबदारी घेण्याऐवजी उत्पादन.
- शिफ्ट लेफ्ट दृष्टिकोन परीक्षकांना प्रथम चाचण्या डिझाइन करण्याची संधी , जिथे चाचण्या ग्राहकांच्या अनुभवावर आणि त्यांच्या अपेक्षांवर पूर्णपणे लक्ष केंद्रित करतात ज्यामुळे विकासक या चाचण्यांवर आधारित सॉफ्टवेअर विकसित करू शकतील. आणि त्यामुळे ग्राहकांच्या गरजा पूर्ण करा.
- डावीकडे शिफ्ट करण्याचा दृष्टीकोन केवळ परीक्षकांसोबतच संपत नाही. लेट मध्ये जाणे आणि चाचणी क्रियाकलाप सतत पार पाडणे देखील विकसकांना त्यांच्या कोडची अधिक मालकी घेण्यास अनुमती देईल आणि चाचणीवरील त्यांच्या जबाबदाऱ्या वाढवतील.
- शिफ्ट डावा दृष्टिकोन देखील परीक्षकांना वर्तणूक-चालित विकास BDD आणि चाचणी-चालित विकास TDD अवलंबण्यास प्रोत्साहित करतो, जे सॉफ्टवेअरमध्ये दोष समाविष्ट होण्यास प्रतिबंध करण्यास मदत करते.
- चपळ मध्ये शिफ्ट लेफ्ट टेस्टिंग: शिफ्ट लेफ्ट अॅप्रोच चपळ स्क्रम टीम्स तयार करण्यास समर्थन देते ज्यात अनिवार्यपणे परीक्षकांचा समावेश असतो इतर भूमिकांसह आणि नियमित स्टँड अप कॉल्स, इतर संवादांमध्ये परीक्षकांचा समावेश होतो, पुनरावलोकन मीटिंग्ज ज्याने परीक्षकांना प्रोग्रामशी संबंधित अधिक माहिती दिली आहे आणि म्हणूनच त्यांना सॉफ्टवेअरच्या तपशीलवार विश्लेषणात सहभागी होण्याची आणि सहभागी होण्याची परवानगी दिली आहे आणि जलद अभिप्राय प्रदान केला आहे ज्यामुळे सॉफ्टवेअरमधील दोष टाळण्यास मदत होईल.
एकंदरीत शिफ्ट लेफ्ट चाचणी परीक्षकांना शक्य तितक्या लवकर 'गेट इनव्हॉल्व्हड अर्ली' करण्यासाठी कॉल करतेचर्चेत गुंतून राहा आणि प्रत्येक टप्प्यावर कल्पना, आवश्यकता यावर सहयोग करा जिथे स्टेजच्या निकालाचा अंतिम वितरण करण्यायोग्य मूल्यावर परिणाम होतो आणि प्रकल्पाला जोखीम ओळखण्यात आणि ते आधीच कमी करण्यात मदत करा.
परीक्षकांनी डावीकडे शिफ्टमध्ये वेगळे काय करावे?
डावीकडे शिफ्ट स्ट्रॅटेजी:
#1) टेस्ट टीममध्ये परीक्षक वेगळ्या पद्धतीने काय करतात हे लक्षात घेण्यासारखे काही महत्त्वाचे घटक खाली दिले आहेत. प्रोजेक्ट सुरू झाल्यापासूनच सिस्टममध्ये लवकर गुंतणे आवश्यक आहे जेणेकरुन उर्वरित कार्यसंघ आणि व्यवसायासोबत एकीकरण विकसित करण्यासाठी प्रत्येक टप्प्यावर उपयुक्त इनपुट प्रदान करता येईल सॉफ्टवेअर डेव्हलपमेंटचे.
#2) चाचणी संघाने व्यवसायासोबत काम केले पाहिजे & ऑपरेशन्स टीम आणि प्रोग्रामवर स्पष्टता मिळवतात आणि मागणीचे स्पष्ट दृश्य प्रदान करतात आणि प्रोग्रामसाठी संसाधन रॅम्प-अप गरजा, प्रशिक्षण गरजा आणि चाचणी साधनांच्या आवश्यकतांवर कार्यक्षमतेने नियोजन करण्यात मदत करतात. आगाऊ.
#3) उत्पादनाची स्पष्ट दृश्यमानता मिळविण्यासाठी चाचणी संघांनी सॉफ्टवेअर डेव्हलपमेंटच्या सुरुवातीच्या काळात सर्व व्यावसायिक भागधारकांशी संवाद साधला पाहिजे 9 & एकीकृत चाचणी धोरण डिझाइन करा आणि ऑप्टिमाइझ केलेल्या चाचणी प्रयत्नांची योजना करा, चाचणी वातावरण, तृतीय पक्ष, स्टब इत्यादींवर अवलंबित्वाचे विश्लेषण करा आणि एक तयार करा मजबूत ऑटोमेशन धोरण आणि फ्रेमवर्क आणि एक प्रभावी चाचणी डेटा व्यवस्थापन तयार करायोजना.
#4) कसोटी संघाला संघाला उत्तम कसोटी नेतृत्व आणि मार्गदर्शन प्रदान करण्यासाठी उर्वरित संघासोबत काम करावे लागेल अशा प्रकारे केवळ चाचणी क्रियाकलापांची जबाबदारी घेण्याऐवजी दीर्घकालीन उत्पादन दृष्टीकोन लक्षात ठेवा.
#5) आवश्यकता या कोणत्याही कार्यक्रमाच्या यशाची गुरुकिल्ली आणि आधार आहेत आणि चांगल्या- परिभाषित आवश्यकता प्रकल्पाच्या यशाची व्याख्या करतात. आवश्यकता नियोजन टप्प्यात, परीक्षकांना आवश्यकतेचे पुनरावलोकन आणि विश्लेषण करणे आवश्यक आहे कोणत्याही संदिग्धता, उत्तम स्पष्टता, पूर्णता, चाचणीक्षमता, स्वीकृती निकष व्याख्या इ.
तसेच गहाळ आवश्यकता (असल्यास) ओळखणे आणि अवलंबित्व आणि अंमलबजावणी धोरणे समजून घेणे आवश्यक आहे. क्लिअर रिक्वायरमेंट्स सॉफ्टवेअरला 'फेल फास्ट' करण्यात आणि सर्व अपयश लवकरात लवकर दुरुस्त करण्यात मदत करतात.
#6) 8 समोर आणून आवश्यकतांमध्ये पुरेशी स्पष्टता आणि अचूकता आणा>वास्तविक उदाहरणे
जे वापरात असलेल्या वैशिष्ट्यांचे वर्णन करतात.#7) परीक्षकांना डिझाइन पुनरावलोकन बैठकांना उपस्थित राहणे आवश्यक आहे नियमितपणे आणि उत्पादनाची रचना आणि आर्किटेक्चर समजून घ्या आणि डिझाइनमधील त्रुटी ओळखा, पर्यायी डिझाइन पर्याय सुचवा, त्रुटी ओळखा आणि डिझाइन खंडित करण्यासाठी त्यानुसार चाचणी परिस्थिती तयार करा.
#8) परीक्षकांनी अगोदरच स्थिर चाचणी (पुनरावलोकन) करणे आवश्यक आहे आणि मुख्य प्रकल्पावर अभिप्राय देणे आवश्यक आहेदस्तऐवज जेणेकरुन दोषांना सॉफ्टवेअरमध्ये ग्राउंड होण्यापासून आणि नंतर त्याचा प्रभाव वाढवण्यापासून प्रतिबंधित केले जाईल.
#9) चाचणी टीमने डिझाइन आणि डेव्हलपमेंट टीमसोबत सहयोग केले पाहिजे मध्ये कोड विकसित करण्यासाठी आणि सर्व संभाव्य रिअल-टाइम परिस्थिती आणि व्यवसाय प्रवाहांना संबोधित करण्यासाठी आगाऊ चाचणी परिस्थिती प्रदान करणे.
#10) चाचणी संघाला डिझाइन करावे लागेल मजबूत आणि मजबूत चाचणी परिस्थिती जेणेकरुन चाचणी दरम्यान फक्त काही दोष ओळखले जातील आणि चाचणी टप्प्यात प्रवेश करताना मोठे दोष टाळले जातील.
#11) परीक्षकांना शक्य तितक्या लवकर चाचणी करावी लागेल , ती स्वतंत्र किंवा स्थानिक प्रणालीवर असेल, जेणेकरून दोष नंतरच्या टप्प्यात येऊ नये.
संपूर्ण क्रक्स परीक्षकांसाठी 'शिफ्ट लेफ्ट' संकल्पनेतील दोष शक्य तितक्या लवकर सर्व शक्य मार्गांनी शोधणे आहे.
शिफ्ट लेफ्ट टेस्टिंगचे फायदे
द शिफ्ट डावा दृष्टीकोन चपळ घोषणापत्रावर आधारित कार्य करतो आणि त्याचे अनेक फायदे देखील आहेत.
ते आहेत:
- व्यक्ती आणि परस्परसंवाद प्रक्रियांवर आणि साधने.
- कार्यरत सॉफ्टवेअर सर्वसमावेशक कागदपत्रांवर.
- ग्राहक सहयोग कराराच्या वाटाघाटींवर.
- प्रतिसाद प्लॅन फॉलो करण्यापेक्षा बदला.
आम्ही पाहू शकतो की उजवीकडील आयटममध्ये मूल्य असताना, आम्ही डाव्या बाजूला असलेल्या आयटमसाठी अधिक मूल्य देतो.
बरं, डावीकडे शिफ्ट सुमारे आहेप्रक्रियेच्या आधी चाचणीची कल्पना आणणे ज्यामुळे चांगली आणि अधिक कार्यक्षम चाचणी आणि सॉफ्टवेअरची गुणवत्ता सुधारते.
थोडक्यात, शिफ्ट लेफ्ट टेस्टिंग प्रक्रिया आहे:9
- दोष लवकर शोधणे ज्यामुळे प्रकल्पाची किंमत कमी होते.
- शेवटी दोष कमी करण्यासाठी सतत पुन्हा पुन्हा चाचणी करणे.
- ते सर्वकाही स्वयंचलित करा आणि बाजारपेठेसाठी वेळ सुधारा.
- ग्राहकांच्या आवश्यकतांवर लक्ष केंद्रित करण्यासाठी आणि ग्राहक अनुभव सुधारण्यासाठी.
निष्कर्ष
'Shift Left' या संकल्पनेने संपूर्ण 'चाचणी' भूमिकेत प्रचंड परिवर्तन घडवून आणले. तोपर्यंत, चाचणीचे एकमेव लक्ष फक्त 'दोष शोधणे' वर होते आणि आता चाचणीच्या दृष्टीकोनातून 'डावीकडे शिफ्ट' करण्याचे उद्दिष्ट 'अर्ली डिफेक्ट डिटेक्शन ते स्टॅटिक टेस्टिंग'असा प्रवास आहे. 2> .
अशाप्रकारे, मार्केट टू मार्केट, सॉफ्टवेअर गुणवत्ता सुधारणे आणि 'टाईम टू मार्केट' कमी करण्यासाठी सॉफ्टवेअर डेव्हलपमेंट पद्धतीमध्ये सॉफ्टवेअर उद्योगात शिफ्ट लेफ्ट ही मोठी झेप आहे.
0 लेखकाबद्दल: हा लेख एसटीएच टीम सदस्याने लिहिलेला आहे गायत्री सुब्रह्मण्यम. ती 90 च्या दशकापासून सॉफ्टवेअर चाचणीत आहे, जेव्हा परीक्षकाची भूमिका उद्योगात सुरू झाली होती. तिच्या चाचणी कारकिर्दीत, तिने चाचणी डिलिव्हरी हाताळण्याव्यतिरिक्त बरेच TMMI मूल्यांकन, चाचणी औद्योगिकीकरण कामे आणि TCOE सेटअप केले आहेत.