वापरकर्त्याच्या कथा स्वयंचलित कधी करायच्या?

आपण क्यूए म्हणून चपळ वातावरणामध्ये काम केले असेल तर बहुधा आपण एखाद्या चाचणी स्वयंचलनास आला असाल. मी युनिट टेस्ट ऑटोमेशन म्हणजे सामान्यत: विकसक केंद्रित क्रियाकलाप नसतो, परंतु कार्यशील स्वीकृती चाचणी ऑटोमेशन जे सामान्यत: क्यूए किंवा चाचणीमध्ये सॉफ्टवेअर डेव्हलपरची नवीन फॅन्सी भूमिका केली जाते.

प्रथम, चाचणी स्वयंचलितकरण होण्यामागील काही निकष आणि कारणांवर नजर टाकू या, ज्यामुळे “चाचण्या का स्वयंचलित नसाव्यात” या प्रश्नाचे उत्तर दिले पाहिजे.



पुनरावृत्ती

स्वयंचलित चाचण्या पुनरावृत्ती करण्यायोग्य असाव्यात आणि प्रत्येक रनमध्ये आउटपुट सुसंगत असावे जेणेकरुन विकसक चाचणीच्या निकालावर अवलंबून राहू शकतील. याचा अर्थ असा आहे की जर एखादी चाचणी फक्त एकदा चालविली जात असेल तर आम्ही सामान्यत: स्वयंचलितपणे स्वयंचलितरित्या जाऊ शकणार नाही; जर आपण बर्‍याच दुव्यांसह दुवा पुनर्निर्देशन स्क्रिप्ट तपासण्यासारख्या मोठ्या संख्येच्या डेटा विरूद्ध चाचणी करीत असाल तर याला अपवाद आहे.




विश्वसनीयता

स्वयंचलित चाचण्या खरोखरच सत्यापन योग्यरित्या तपासल्या पाहिजेत आणि वैध अपेक्षित परिणामाविरूद्ध वास्तविक निकाल निर्धारित करण्यास सक्षम असतील. याचा अर्थ असा आहे की जर परिणाम सहजपणे निर्धारित केले जाऊ शकत नाहीत किंवा स्वयंचलित चाचण्या पर्यावरणाच्या समस्येच्या अधीन आहेत ज्यामुळे परीक्षेच्या निकालांमध्ये चुकीच्या सकारात्मकता येऊ शकतात, तर चाचण्या विश्वसनीय असू शकत नाहीत.



वेळ

स्वयंचलित चाचण्यांमुळे आपला वेळही वाचला पाहिजे. जर एखादी साधी चाचणी पूर्ण होण्यास 10 मिनिटे लागतील परंतु समान निकाल स्वहस्ते 1 मिनिटात निश्चित केला जाऊ शकतो, तर अशा चाचण्या स्वयंचलित न करणे चांगले.




सुरक्षा जाळी

स्वयंचलित चाचण्यांनी विकासकांना एक सुरक्षित जाळे प्रदान केले पाहिजे जेणेकरुन कोड बेसमधील बदलांच्या परिणामी चांगल्या कार्यकारी कोडमधून कोणतेही विचलन द्रुतपणे हायलाइट केले जाईल आणि विकसकांना कळविले जाईल.



कथा कधी स्वयंचलित करावी?

ठराविक स्प्रिंटमध्ये, असे म्हणा की तेथे stories कथा आहेत ज्या स्प्रिंटसाठी वचनबद्ध आहेत त्यापैकी 5 वरील निकषांवर आधारित स्वयंचलित होण्यासाठी चांगल्या उमेदवार आहेत. परंतु या कथा स्वयंचलित करण्याचा सर्वोत्तम वेळ कधी आहे? वैशिष्ट्ये विकसित होत असताना आपण स्वयंचलित चाचण्या लिहाव्यात? एखादे वैशिष्ट्य विकसित होईपर्यंत आपण प्रतीक्षा करावी आणि नंतर स्वयंचलित चाचण्या लिहावे? आपण स्प्रिंटच्या शेवटपर्यंत थांबू आणि नंतर कथा स्वयंचलित करू?

काही प्रकरणांमध्ये जेव्हा कथा दोष निराकरणे किंवा अस्तित्त्वात असलेल्या वैशिष्ट्यात थोडी बदल किंवा वर्धित असतात तेव्हा स्वयंचलित चाचण्या लिहिण्यात अर्थ प्राप्त होतो कारण वैशिष्ट्य विकासकांद्वारे सुधारित केले जात आहे. वैशिष्ट्य सुधारित करण्यासाठी विद्यमान स्वयंचलित चाचणी देखील असू शकते ज्यात आपल्याला नवीन बदल सामावून घेण्यासाठी स्क्रिप्ट चिमटा करणे आवश्यक आहे.

इतर प्रकरणांमध्ये, जेव्हा कथा अनुप्रयोगासाठी नवीन वैशिष्ट्य अंमलात आणण्याविषयी असते, तेव्हा अंतिम उत्पादन आधीपासूनच चाचण्या लिहिण्यास सक्षम असल्याचे आपल्याला कसे कळेल? येथे मी वैशिष्ट्य फायलींबद्दल बोलत नाही ज्या स्वीकृतीच्या चाचण्यांचे आगाऊ वर्णन करतात, परंतु वितरित कोडच्या विरूद्ध चालणार्‍या वास्तविक फिक्स्चर किंवा सेलेनियम चाचण्या (चाचण्यांची अंमलबजावणी).


सर्वात महत्वाची ओळ म्हणजे- कोणतीही चाचणी जी एकापेक्षा जास्त वेळा होणार आहे ती स्वयंचलित केली जावी. आणि कोणत्या चाचण्या आम्ही एकापेक्षा जास्त वेळा अंमलात आणणार आहोत? रीग्रेशन टेस्ट. आणि रीग्रेशन टेस्ट्स म्हणजे काय? नवीन फेरबदल आणि वैशिष्ट्यांचा परिणाम म्हणून अनुप्रयोगाने कार्यक्षमतेत दडपण आणले आहे की नाही हे निर्धारित करते.

परंतु, आपण ज्ञात इनपुट आणि आऊटपुटसह वागण्याच्या दृष्टीने स्थिर, चांगल्या प्रकारे समजल्या जाणार्‍या आणि निरोधक प्रणालीविरूद्ध केवळ स्वयंचलित रीग्रेशन चाचण्या लिहू शकता.

एखाद्या वैशिष्ट्याबद्दल विकसित होत असल्याने त्याबद्दल स्वयंचलित चाचण्या लिहिण्याचा प्रयत्न करण्याचा प्रश्न म्हणजे आपण संभाव्यत: स्वयंचलित स्क्रिप्ट लिहिण्यासाठी बराच वेळ घालवू शकता जे स्प्रिंट दरम्यान सतत बदलत असते. शिवाय, आपण एखाद्या स्प्रींटवर वचनबद्ध असल्याचे आणि नंतर नंतर स्प्रिंटमधून बाहेर काढले गेलेले किती वेळा पाहिले आहे? मग आम्ही अशी काहीतरी स्क्रिप्ट करण्यात वेळ वाया घालवला ज्यामुळे ती सिस्टममध्ये बनली नाही.

काही संस्था अगदी कठोर नियम लागू करतात की कथा पूर्णपणे स्वयंचलित होईपर्यंत “पूर्ण” केली जात नाही! क्यूए विविध कारणांमुळे वेळेत ऑटोमेशन प्रदान करू शकत नाही किंवा वेळेत ऑटोमेशन प्रदान करू शकला नाही म्हणून आम्ही सोडले जाणारे एक महत्त्वाचे वैशिष्ट्य थांबवणार आहोत? किंवा कथा “पूर्ण” केली जात नाही कारण आपल्याकडे पृष्ठावरील बटणाचे अस्तित्व तपासण्यासाठी स्वयंचलित स्क्रिप्ट नाही. गंभीरपणे?


ऑटोमेशन चाचणीचा सर्वात चांगला हेतू म्हणजे रिप्रेशन टेस्टिंग आणि बेसलाइनमधील बदल शोधण्यात सक्षम होण्यासाठी आणि स्वयंचलित चाचणीतून अर्थपूर्ण निकाल मिळविण्यासाठी प्रतिज्ञात चाचणी नेहमीच एखाद्या ज्ञात राज्य आणि डिट्रिमिनिस्टिक सिस्टमच्या विरूद्ध चालविली जातात. आणि एकदाच व्यक्तिचलितरित्या उत्तीर्ण झाले, तर आपण मॅन्युअल अंमलबजावणीविरूद्ध स्वयंचलित धावण्याच्या परिणामाची तुलना करू शकता.

या व्याख्याानुसार, कथा स्प्रिंटमध्ये स्वयंचलित (अंमलबजावणी) आणि केवळ जेव्हा वैशिष्ट्य पूर्णपणे व्यक्तिचलितपणे सत्यापित केले जाईल. एकदा कथा पूर्ण झाल्यानंतर आणि ती व्यक्तिचलितपणे प्रथम सत्यापित केली गेली तर ती एक विश्वासार्ह वैशिष्ट्य आणि एक स्थिर प्रणाली आहे जी आपण त्यानंतर स्वयंचलित चाचण्या डिझाइन आणि लिहू शकता. एकदा स्वयंचलित चाचणी लागू झाल्यानंतर, पुढील वैशिष्ट्ये विकसित केली जात असल्याने रिग्रेसन दोष शोधण्यासाठी आणि शोधण्यासाठी हे प्रतिगामी चाचणी सूटमध्ये जोडले जाईल.

मनोरंजक लेख